Гибкий workflow запросов vs хардкода в ITSM-системе

В ITSM-системе применяются понятия жизненный цикл и статус запроса. Статусная модель имеет большое значение, ведь в ней закладываются логика и правила, по которым будут обрабатываться заявки пользователей. Зачастую потребности в специфических настройках у клиентов шире, чем предлагает ИТ-продукт. Возникает необходимость выбора между универсальным подходом к настройкам и специализацией, когда учитываются процессы клиента и обеспечивается работоспособный workflow, но «приносятся в жертву» общие принципы построения системы.

В статье поговорим про поиск баланса между универсальностью и уникальными настройками в ITSM-системе. Что лучше — получить широкий охват процессов управления или сразу адаптировать их под задачи клиента. Для этого рассмотрим, какие разные подходы мы использовали в no-code решении Naumen Service Desk Pro при настройке жизненных циклов запросов и как это помогло трансформировать продукт.

Кастомизация под клиента

Изначально в проектах внедрения Naumen Service Desk Pro делалась ставка на возможности платформы, которая предоставляет различные инструменты для настройки общей функциональности и жизненных циклов (ЖЦ).

Соответственно мы учитывали потребности клиента в автоматизации бизнес-процессов и выполняли нужные настройки. При этом всегда отталкивались от заложенной в системе статусной модели. В итоге любой процесс реализовывался через тонкую настройку статусов и описание системной логики при работе с каждым из них.

Такой индивидуальный подход можно сравнить с изготовлением доспехов для средневекового рыцаря, когда каждая деталь подгонялась под конкретную фигуру. Это долго и дорого, но рыцарь получал тот доспех, который ему как раз. Другим рыцарям подобный доспех уже не подходил, потому что и телосложение, и защитные задачи отличались.

Каковы плюсы подхода:

✔ Реализация ожиданий клиента по процессу обработки запросов.

✔ Автоматизация любого процесса из практик ITIL.

С какими проблемами столкнулись:

✖ Невозможность масштабирования внутри компании заказчика. Каждый процесс настраивается индивидуально, а значит переиспользовать опыт для других процессов затруднительно.

✖ Каждый новый заказчик — новая реализация, что увеличивает трудозатраты на внедрение проектов.

✖ Сложности в техподдержке системы. Каждая реализация несет дополнительные затраты, потому что приходится разбираться с новыми механиками. Как результат — стоимость обновления клиентов «улетает в космос».

✖ Такой подход разнится с общим продуктовым подходом.

Создание универсального шаблона

Проектный опыт Naumen SD Pro показывает, что в большинстве случаев можно предложить более универсальное решение клиенту и одновременно кастомизировать продукт. Например, снизить роль доработок в самом жизненном цикле и позиционировать его как фундамент для дальнейшей настройки в системе.

Такие выводы позволили сформировать новое видение — попробовать создать универсальный шаблон жизненного цикла. Это как сконструировать подходящий всем «доспех», да и делать его быстрее.

Настройка набора статусов, который можно использовать как универсальный шаблон

Подобную реализацию можно описать следующим образом:

у любого ЖЦ есть начальный и конечный статус;
для запросов настраиваются несколько статусов («В работе первой линии», «В работе второй линии», «В работе третьей линии», «В работе четвертой линии»). Статусы последовательны, и при переходе в каждый из них для выполнения запроса подключаются соответствующие специалисты;
вводятся вспомогательные статусы, которые помогают в решении запроса. Например, если нужно уточнить дополнительную информацию, согласовать или эскалировать запрос.

С помощью текущего подхода удалось добиться большей типизации при внедрении основных бизнес-процессов.

Каковы плюсы подхода:

✔ Поддержка механизма настроек более упрощенная за счет единого подхода.

✔ Возможность уложить в такой ЖЦ любой процесс и практику.

✔ Продукт становится тиражируемым в другие подразделения (АХО, HR, юридический отдел и другие).

С какими проблемами столкнулись:

✖ Те кейсы, которые не укладывались в шаблон, приходилось решать индивидуально, что возвращает проект внедрения к первому сценарию кастомной настройки или постоянному поиску обходных решений.

✖ Для некоторых заказчиков подобная схема не подходит в части именования статусов. В результате требовалась гибкость применения статусов к различным процессам.

✖ Для типового продукта в сложных сценариях обнаружились ограничения при настройках шаблона. Например, для процесса ЗНИ, когда есть множество статусов и они не вписываются в текущую схему.

В итоге разработанный шаблон не мог претендовать на универсальность. Требовался другой сценарий, который охватывал бы больше клиентских кейсов и оставался при этом продуктовым. Нужно решение, которое позволяло бы без привлечения вендора перенастраивать ЖЦ так, как это необходимо менеджерам услуг.

Масштабирование и тиражирование

По мере развития продукта и ухода от кастомизации под конкретного клиента возникли другие вопросы, которые не решались универсальным шаблоном ЖЦ в запросах. Вот некоторые из них:

Для части услуг необходима своя статусная модель с названиями статусов, отличных от «В работе N линии».
Процесс управления ЗНИ предполагает разные сценарии в зависимости от самой услуги. В рамках только одной системы (например, SAP) может быть несколько типовых сценариев под изменения. Если взять не одну систему, а около десятка, то получаем множество сценариев, которые сложно уложить в один шаблон прохождения запросов по ЖЦ. Поэтому нужны инструменты для настроек без привлечения вендора.
Реализация маршрутов от согласования изменений и проведения CAB до разработки, тестирования и переноса на продуктивные среды.

Такие вопросы ставили перед продуктом новые вызовы. С одной стороны, мы предоставляем каркас, а с другой — не обеспечиваем гибкость. По аналогии со средневековым рыцарем, которому дали хорошо защищающие от внешних угроз доспехи, но в них сложно передвигаться из-за невозможности подогнать размер под себя.

В рамках продукта стали искать решение, которое позволило бы:

обеспечить настройку ЖЦ под разные услуги;
сохранить единый подход к управлению статусной моделью;
поддерживать фундаментальные принципы работы со статусами и заложенной для них в системе функциональностью;
производить настройки без вмешательства вендора на уровне менеджеров услуг или менеджера каталога услуг.

По большому счету задача звучала как: «Развить текущее решение, чтобы покрыть проблемные области и при этом сохранить продуктовый подход». А значит условные доспехи рыцаря получили бы свою гибкость и перестали сковывать движения.

Гибкий подход к настройкам

При аналитике нового механизма решили, что в настройке ЖЦ отказываемся от устойчивых линий поддержки и добавляем гибкости. Это позволит создавать столько рабочих статусов, сколько необходимо. Вместе с тем у каждой услуги могут быть свои требования к ЖЦ. Тогда настройка масштабируется в зависимости от конкретного вида обращения до всего процесса.

В результате возникла идея добавить в продукт пользовательские статусы, которые будут создавать сами менеджеры услуг и ассоциироваться с системным статусом. Далее в Naumen SD Pro на этот статус завязывается вся необходимая логика.

Гибкий подход к настройке статусов в системе автоматизации

Концепция в следующем:

вводится слой системных и пользовательских статусов. Системные статусы закладываются в продукт, и на них завязывается логика работы с запросами. Пользовательские статусы настраиваются менеджером под конкретные кейсы. Их количество не ограничивается, и можно задать свое наименование. Пользовательский статус обязательно должен быть ассоциирован с системным;
за счет ассоциирования с системными статусами у пользовательских сохраняется вся логика работы со вспомогательными статусами;
пользовательские статусы связываются между собой и образуют цепочку прохождения запроса по рабочим статусам там, где требуется согласование или подключение специалистов;
поддерживается обратная связь по пользовательским статусам, что позволяет настраивать ветвления и обратные переходы.

Визуализация статусной модели в Naumen Service Desk Pro

Новая реализация позволила найти баланс между общими продуктовыми принципами и адаптацией системы под задачи клиентов.

Каковы плюсы подхода:

✔ Гибкость настройки статусов без привлечения администраторов, излишней декомпозиции на подзапросы, с последующими обновлениями продукта.

✔ Единообразная отчетность за счет унификации системных статусов.

✔ Единый подход к управлению статусной моделью.

✔ Повышение гибкости интерфейса для более органичного встраивания системы в бизнес-процессы.

✔ Улучшение пользовательского опыта за счет прозрачного отображения статуса запроса.

К выводам

Последовательная «эволюция» настройки workflow запросов в Naumen SD Pro помогла решить множество недостающих кейсов при автоматизации бизнес-процессов наших клиентов. Одновременно мы сохранили продуктовый подход, что дало масштабируемость механизма и поддержку регулярных обновлений ITSM-системы.

Отказ от хардкодного подхода, когда статусная модель имела ограничения, позволяет более гибко настраивать жизненные циклы запросов и количество статусов. Можно сказать, что теперь рыцарь в своих доспехах получил не только хорошую броню, но и ее вариативность.