В ITSM-системе применяются понятия жизненный цикл и статус запроса. Статусная модель имеет большое значение, ведь в ней закладываются логика и правила, по которым будут обрабатываться заявки пользователей. Зачастую потребности в специфических настройках у клиентов шире, чем предлагает
В статье поговорим про поиск баланса между универсальностью и уникальными настройками в
Кастомизация под клиента
Изначально в проектах внедрения Naumen Service Desk Pro делалась ставка на возможности платформы, которая предоставляет различные инструменты для настройки общей функциональности и жизненных циклов (ЖЦ).
Соответственно мы учитывали потребности клиента в автоматизации
Такой индивидуальный подход можно сравнить с изготовлением доспехов для средневекового рыцаря, когда каждая деталь подгонялась под конкретную фигуру. Это долго и дорого, но рыцарь получал тот доспех, который ему как раз. Другим рыцарям подобный доспех уже не подходил, потому что и телосложение, и защитные задачи отличались.
Каковы плюсы подхода:
✔ Реализация ожиданий клиента по процессу обработки запросов.
✔ Автоматизация любого процесса из практик ITIL.
С какими проблемами столкнулись:
✖ Невозможность масштабирования внутри компании заказчика. Каждый процесс настраивается индивидуально, а значит переиспользовать опыт для других процессов затруднительно.
✖ Каждый новый заказчик — новая реализация, что увеличивает трудозатраты на внедрение проектов.
✖ Сложности в техподдержке системы. Каждая реализация несет дополнительные затраты, потому что приходится разбираться с новыми механиками. Как результат — стоимость обновления клиентов «улетает в космос».
✖ Такой подход разнится с общим продуктовым подходом.
Создание универсального шаблона
Проектный опыт Naumen SD Pro показывает, что в большинстве случаев можно предложить более универсальное решение клиенту и одновременно кастомизировать продукт. Например, снизить роль доработок в самом жизненном цикле и позиционировать его как фундамент для дальнейшей настройки в системе.
Такие выводы позволили сформировать новое видение — попробовать создать универсальный шаблон жизненного цикла. Это как сконструировать подходящий всем «доспех», да и делать его быстрее.
Подобную реализацию можно описать следующим образом:
- у любого ЖЦ есть начальный и конечный статус;
- для запросов настраиваются несколько статусов («В работе первой линии», «В работе второй линии», «В работе третьей линии», «В работе четвертой линии»). Статусы последовательны, и при переходе в каждый из них для выполнения запроса подключаются соответствующие специалисты;
- вводятся вспомогательные статусы, которые помогают в решении запроса. Например, если нужно уточнить дополнительную информацию, согласовать или эскалировать запрос.
С помощью текущего подхода удалось добиться большей типизации при внедрении основных
Каковы плюсы подхода:
✔ Поддержка механизма настроек более упрощенная за счет единого подхода.
✔ Возможность уложить в такой ЖЦ любой процесс и практику.
✔ Продукт становится тиражируемым в другие подразделения (АХО, HR, юридический отдел и другие).
С какими проблемами столкнулись:
✖ Те кейсы, которые не укладывались в шаблон, приходилось решать индивидуально, что возвращает проект внедрения к первому сценарию кастомной настройки или постоянному поиску обходных решений.
✖ Для некоторых заказчиков подобная схема не подходит в части именования статусов. В результате требовалась гибкость применения статусов к различным процессам.
✖ Для типового продукта в сложных сценариях обнаружились ограничения при настройках шаблона. Например, для процесса ЗНИ, когда есть множество статусов и они не вписываются в текущую схему.
В итоге разработанный шаблон не мог претендовать на универсальность. Требовался другой сценарий, который охватывал бы больше клиентских кейсов и оставался при этом продуктовым. Нужно решение, которое позволяло бы без привлечения вендора перенастраивать ЖЦ так, как это необходимо менеджерам услуг.
Масштабирование и тиражирование
По мере развития продукта и ухода от кастомизации под конкретного клиента возникли другие вопросы, которые не решались универсальным шаблоном ЖЦ в запросах. Вот некоторые из них:
- Для части услуг необходима своя статусная модель с названиями статусов, отличных от «В работе N линии».
- Процесс управления ЗНИ предполагает разные сценарии в зависимости от самой услуги. В рамках только одной системы (например, SAP) может быть несколько типовых сценариев под изменения. Если взять не одну систему, а около десятка, то получаем множество сценариев, которые сложно уложить в один шаблон прохождения запросов по ЖЦ. Поэтому нужны инструменты для настроек без привлечения вендора.
- Реализация маршрутов от согласования изменений и проведения CAB до разработки, тестирования и переноса на продуктивные среды.
Такие вопросы ставили перед продуктом новые вызовы. С одной стороны, мы предоставляем каркас, а с другой — не обеспечиваем гибкость. По аналогии со средневековым рыцарем, которому дали хорошо защищающие от внешних угроз доспехи, но в них сложно передвигаться
В рамках продукта стали искать решение, которое позволило бы:
- обеспечить настройку ЖЦ под разные услуги;
- сохранить единый подход к управлению статусной моделью;
- поддерживать фундаментальные принципы работы со статусами и заложенной для них в системе функциональностью;
- производить настройки без вмешательства вендора на уровне менеджеров услуг или менеджера каталога услуг.
По большому счету задача звучала как: «Развить текущее решение, чтобы покрыть проблемные области и при этом сохранить продуктовый подход». А значит условные доспехи рыцаря получили бы свою гибкость и перестали сковывать движения.
Гибкий подход к настройкам
При аналитике нового механизма решили, что в настройке ЖЦ отказываемся от устойчивых линий поддержки и добавляем гибкости. Это позволит создавать столько рабочих статусов, сколько необходимо. Вместе с тем у каждой услуги могут быть свои требования к ЖЦ. Тогда настройка масштабируется в зависимости от конкретного вида обращения до всего процесса.
В результате возникла идея добавить в продукт пользовательские статусы, которые будут создавать сами менеджеры услуг и ассоциироваться с системным статусом. Далее в Naumen SD Pro на этот статус завязывается вся необходимая логика.
Концепция в следующем:
- вводится слой системных и пользовательских статусов. Системные статусы закладываются в продукт, и на них завязывается логика работы с запросами. Пользовательские статусы настраиваются менеджером под конкретные кейсы. Их количество не ограничивается, и можно задать свое наименование. Пользовательский статус обязательно должен быть ассоциирован с системным;
- за счет ассоциирования с системными статусами у пользовательских сохраняется вся логика работы со вспомогательными статусами;
- пользовательские статусы связываются между собой и образуют цепочку прохождения запроса по рабочим статусам там, где требуется согласование или подключение специалистов;
- поддерживается обратная связь по пользовательским статусам, что позволяет настраивать ветвления и обратные переходы.
Новая реализация позволила найти баланс между общими продуктовыми принципами и адаптацией системы под задачи клиентов.
Каковы плюсы подхода:
✔ Гибкость настройки статусов без привлечения администраторов, излишней декомпозиции на подзапросы, с последующими обновлениями продукта.
✔ Единообразная отчетность за счет унификации системных статусов.
✔ Единый подход к управлению статусной моделью.
✔ Повышение гибкости интерфейса для более органичного встраивания системы в
✔ Улучшение пользовательского опыта за счет прозрачного отображения статуса запроса.
К выводам
Последовательная «эволюция» настройки workflow запросов в Naumen SD Pro помогла решить множество недостающих кейсов при автоматизации
Отказ от хардкодного подхода, когда статусная модель имела ограничения, позволяет более гибко настраивать жизненные циклы запросов и количество статусов. Можно сказать, что теперь рыцарь в своих доспехах получил не только хорошую броню, но и ее вариативность.
