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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


К выводам

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

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