Поделиться
Ловушка универсальности: почему систему управления услугами нельзя выбирать по списку функций
Выбор системы управления ИТ-услугами (ITSM-системы) выглядит как универсальная задача: собрать требования, сравнить решения, выбрать то, что лучше соответствует чек-листу. Но на практике такой подход далеко не всегда приводит к ожидаемому результату. Даже системы, которые формально закрывают одинаковые требования, могут по-разному работать в реальной среде компании. Проблема обычно связана не с недостатком функций, а с самим подходом к формированию требований: универсальный набор критериев плохо работает там, где у компаний различаются процессы, операционная логика и модель управления сервисами.
Откуда на самом деле берутся требования к ITSM
Кажется, достаточно собрать требования всех подразделений и сравнить решения по чек-листу. Но на практике такой подход не работает. Существенная часть требований возникает не внутри ИТ-функции и даже не внутри конкретной организации, а задается самой средой, в которой компания работает. На нее влияют регуляторы, клиенты, партнеры, характер операций и цена ошибки. Поэтому вопрос о выборе ITSM-системы на практике начинается не с перечня функций, а с понимания того, в какой логике живет бизнес и какие процессы для него действительно критичны.
Именно здесь становится видна главная проблема универсального подхода. Когда компания пытается делать выбор только на основе длинного общего чек-листа, в одном списке оказываются требования разной природы и веса. Одни из них действительно влияют на эффективность процессов. Другие лишь описывают желательные свойства системы. А третьи вообще заимствуются по инерции: потому что так принято проводить тендер или так делали в предыдущих проектах.
Подход может выглядеть основательным, но мало что дает: системы сравнивают по сотням критериев, хотя на практике важны лишь единицы. Вместо длинного списка требований нужна модель, которая выделяет ключевое с учетом отрасли.
Как тип деятельности меняет требования к ITSM
Требования к ITSM-системе определяются не универсальным набором функций, а характером работы компании. Для одних организаций критичны контроль, доказуемость и соблюдение регламентов. Для других на первом месте скорость реакции, устойчивость к массовым инцидентам и быстрое восстановление сервиса. Для третьих важнее способность системы сопровождать длинный процесс, в котором участвуют разные подразделения, и удерживать связность всех действий, а не только обрабатывать отдельные заявки.
Это хорошо видно на примере отраслей. В финансовых организациях и госсекторе ITSM-система становится частью контрольной среды, поэтому здесь особенно важны неизменяемая история, фиксированные маршруты и проверяемость действий. В ритейле и телекоме ключевыми становятся скорость, автоматизация, работа в условиях распределенной инфраструктуры и большого потока обращений. В страховании на первый план выходит поддержка длительного бизнес-процесса, где система должна удерживать общий контекст, связывать обращения между собой и отражать участие разных функций в единой рабочей цепочке.
Например, в финансовой организации деградация сервиса может быть критичнее, чем формальный отказ. Если система доступна, но операция проходит дольше нормы, это уже влияет на проведение платежей и закрытие операционного дня. В такой среде ITSM-система должна уметь работать не только с недоступностью, но и с деградацией как с инцидентом высокого приоритета.
В страховании ИТ часто работает не с отдельной заявкой, а с длинным бизнес-контекстом. Например, исправление интеграции может повлиять на пересчет суммы ущерба по конкретному страховому случаю, и системе важно сохранить эту связь. Иначе через несколько месяцев будет трудно восстановить, кто, что и на каком основании изменил.
В ритейле критичен другой сценарий. Если после обновления перестают работать терминалы сразу в нескольких городах, поддержка не может обрабатывать сотни одинаковых заявок как независимые обращения. Здесь важны массовый характер инцидента, единый статус для затронутых точек и быстрое восстановление продаж, а не идеальная детализация каждого тикета.
Когда компания понимает, к какому типу задач ближе ее реальная работа, выбор перестает быть поиском самой функциональной системы на рынке. Он превращается в поиск решения, которое соответствует характеру управления сервисами, ожиданиям бизнеса и той логике работы, в которой системе предстоит существовать каждый день.
Главная ошибка: выбор системы вместо выбора модели управления
На практике компании часто выбирают не подход к управлению сервисами, а программный продукт. Проект начинается, как закупка системы: формируется список требований, сравниваются решения, оцениваются демонстрации, обсуждаются сроки внедрения. В стороне остается главный вопрос: какую именно модель управления сервисами должна поддерживать будущая система и в какой операционной логике ей предстоит работать.
Из-за этого в выборе начинает доминировать функциональность. Побеждает решение, которое выглядит более полным, современным или удобным. Но сама по себе полнота функций еще не означает, что система принесет бизнесу пользу. Если она не соответствует тому, как организация управляет изменениями, инцидентами, доступами, согласованиями и внутренними сервисами, ожидаемого эффекта не будет. Отсюда и типичная ситуация: система внедрена, процессы формально настроены, но пользователи продолжают решать задачи через почту и мессенджеры, а часть работы по-прежнему выполняется вручную. Даже очень продвинутый продукт не заработает, если он чужд для той среды, в которую его пытаются встроить.
Что действительно стоит оценивать при выборе ITSM
- Соответствие процессной модели компании. Для одних организаций решающими становятся доказуемость действий, жесткая фиксация маршрутов и невозможность обойти обязательные этапы. Для других на первом месте — скорость восстановления, автоматические реакции и сокращение ручных операций. Для третьих критична способность удерживать длинный процесс с множеством связанных обращений, участников и этапов. При выборе важно смотреть не на названия модулей, а на то, насколько система поддерживает нужный тип управления сервисами.
- Пригодность к реальной эксплуатации, а не только к демонстрации. Система может выглядеть убедительно на презентации, но это еще не значит, что она выдержит массовые инциденты, распределенную структуру, высокую нагрузку, сложные согласования или длинные цепочки взаимосвязанных действий. Именно в работе становится понятно, способна ли она поддерживать темп процессов без обходных сценариев и ручного дублирования.
- Возможности для интеграции и управления изменениями. ITSM или ESM не существуют изолированно. Система должна быть связана с мониторингом, учетными системами, документооборотом, CRM и другими контурами, от которых зависит исполнение процесса. При этом важно, чтобы она позволяла адаптировать процессы под изменения в компании. Поэтому оценка должна ответить на вопрос, насколько легко решение может быть встроено в существующий ландшафт.
Почему нужна связка методологии и технологии
Даже если система формально поддерживает нужные процессы, это еще не означает, что они будут работать в логике бизнеса. Поэтому для зрелой реализации ITSM недостаточно только технологической платформы. Нужна и методологическая основа, которая помогает выстроить процессы последовательно, определить логику маршрутов, уровни согласований, роль соглашения об уровен обслуживания SLA и точки интеграции с другими системами.
Если в проекте есть только технология, система рискует остаться набором инструментов, которые можно настроить, но трудно превратить в полноценную модель управления сервисами. Если есть только методология, но нет достаточной технологической гибкости, процессы остаются на уровне правильной концепции, которую сложно адаптировать под особенности компании, встроить в существующий ландшафт и развивать дальше. Это особенно заметно в крупных организациях, где одной автоматизации обращений уже недостаточно. Например, в страховании заявка в ИТ может становиться триггером для задач юристов, экспертов и партнерских СТО в рамках одного процесса урегулирования. А в ритейле система должна выдерживать пиковые нагрузки уровня черной пятницы, когда лавинообразно растет поток обращений и критична не только логика маршрутов, но и технологическая устойчивость платформы.
Именно поэтому особую ценность получают решения, в которых методология и технология изначально соединены. Пример такого подхода — Altevics, созданный в партнерстве Cleverics и GreenData. В этом случае методологическая экспертиза в ITSM сочетается с гибкостью low-code платформы, что позволяет не просто автоматизировать обращения, а поддерживать сложные маршруты, интеграции и реальные процессы бизнеса.
Заключение
Оценивать ITSM-систему стоит не по объему функциональности и не по тому, насколько убедительно она выглядит на этапе выбора, а по ее способности поддерживать критичный для бизнеса сценарий работы. Именно это определяет, станет ли она реальным инструментом управления сервисами или останется решением, которое соответствует требованиям только на бумаге. Для крупных компаний особенно важен подход, в котором процессная экспертиза сочетается с технологической гибкостью. Все остальное — только производные от этого выбора.
Короткая ссылка
