Концепция ESM шире, но и сложнее изначальной ITSM, и потому та и другая востребованы для разных категорий российских заказчиков.
Спрос на ITSM, по утверждению Михаила Миронова, директора отделения Low-code-решений IBS, поддерживается масштабными изменениями корпоративных ИТ-ландшафтов: «Многие организации за последние годы внедрили новые платформы, перестроили интеграции, пересмотрели модели сопровождения. В результате инфраструктура стала сложнее, а число участников сервисного процесса заметно выросло. На этом фоне особенно востребованы единая точка входа для обращений, прозрачная маршрутизация заявок, контроль выполнения SLA и понятное распределение ответственности между ИТ-подразделениями, бизнесом, подрядчиками и вендорами. Рынок активно движется в сторону ESM; сервисный подход выходит за пределы ИТ. Отдельное направление — процессы УЦР (концепция устойчивого цифрового развития бизнеса), охраны труда, промышленной и пожарной безопасности, экологического контроля».
Поскольку ITSM-системы создавались для использования ИТ-специалистами, их интерфейсы и принципы работы в целом ориентировались на подготовленных технических профессионалов. Концепция ESM требует снижения порога сложности и повышения гибкости, но не в ущерб функциональности. Как разработчику сделать такую систему удобной для всех своих заказчиков — не сваливаясь притом в бесконечную кастомизацию?
Одна из самых распространенных ошибок при развитии ESM-платформы, на которую обращает внимание Михаил Миронов, — попытка автоматизировать каждое исключение и особенность процессов через индивидуальные доработки: «В какой-то момент такая система становится дорогой в сопровождении и слишком зависимой от людей, которые ее когда-то создавали. Важно соблюдать баланс между гибкостью и стандартизацией. Типовые задачи должны закрываться средствами платформы и low-code/no-code-инструментами. Каждый запрос на доработку необходимо отдельно анализировать: действительно ли нужен новый функциональный блок или проблему можно решить изменением маршрута согласования, настройкой ролей либо интеграцией с другой системой».
Михаил Миронов напоминает, что при всей своей привлекательности ITSM/ESM — одна из самых сложных категорий проектов для интеграторов: «Интегратору необходимо найти баланс между типовой функциональностью продукта и реальными особенностями бизнеса заказчика, фактически выступая архитектором организационных изменений. Интеграторы активно используют ITSM и ESM-платформы внутри собственных компаний. Такой опыт позволяет на практике увидеть реальные ограничения решений, оценить стоимость изменений после запуска и понять, какие показатели действительно помогают управлять сервисами, а какие остаются формальностью».
По солидарному мнению подавляющего большинства экспертов, российский рынок ITSM/ESM активно развивается, демонстрируя при этом ощутимую эволюцию требований заказчиков к вендорам.
Михаил Миронов соглашается с тем, что рынок находится в активной фазе развития: «С одной стороны, сохраняется высокий спрос на зрелые инструменты управления ИТ-сервисами: контроль SLA, управление изменениями, активами, знаниями и качеством поддержки. С другой — заметно растет интерес к ESM как к единой модели сервисного взаимодействия внутри компании. На российском рынке сформировался широкий набор решений разных классов. Отдельный тренд последних лет — запрос на измеримый результат. Растет интерес к аналитике и ИИ-инструментам, однако практика показывает, что эффект от искусственного интеллекта напрямую зависит от качества данных и зрелости процессов. Если базовые процессы не выстроены, ожидать серьезного результата только за счет ИИ не стоит».
Как указывает Михаил Миронов, интеграторы фактически помогают заказчику спроектировать сервисную архитектуру компании: определить каталог услуг, роли участников процессов, правила эскалации, SLA, интеграционные контуры и подходы к дальнейшему развитию платформы: «В практике IBS мы сталкивались с разными сценариями автоматизации — от классического ITSM до процессов УЦР и охраны труда, в том числе на базе „Битрикс24“. Несмотря на различия предметных областей, базовая логика у таких процессов похожа: есть событие или обращение, ответственный, регламент, сроки исполнения, контрольные точки и необходимая отчетность. Разница заключается в методологии. Если для ITSM существует зрелая база в виде библиотеки инфраструктуры информационных технологий, то для направлений вроде УЦР, охраны труда или промышленной безопасности приходится учитывать отраслевые требования, внутренние регламенты и постоянные изменения нормативной базы».
Полная версия материала — на IT Channel News