Выбор «ESM или не ESM» — это выбор архитектуры контура сервисов, а не бренда в тендере. Ниже — как устроена единая платформа, чем её заменяют на практике и как сравнивать развёртывание, эксплуатацию, поддержку и внедрение.
Две архитектуры
Единая ESM-платформа. Обращения, изменения, активы/CMDB, задачи и база знаний живут в одной модели данных и одном рабочем месте агента. Процессы и SLA настраиваются на платформе; интеграции смотрят в ядро, а не сшивают продукты между собой. AI, если есть, работает на тех же объектах — без отдельного контура «рядом».
Связка аналогов (best of breed). ITSM — одна система, учёт активов — другая, проекты — третья, портал — четвёртая, знания — в wiki. Потоки склеивают шиной, скриптами и выгрузками. Каждая система сильна в своём классе, но отчёт «от заявки до CI и проекта» собирается снаружи.
Между ними — ITSM «с модулями» одного вендора: формально одна закупка, фактически разные продукты с разной глубиной CMDB и задач. Для сравнения ниже это ближе к связке, если модель данных и интерфейс агента не общие.
Что обычно ставят вместо единой платформы
- Классический ITSM + отдельная CMDB / MDM. Зрелый процесс инцидентов, слабая связка с активами и договорами.
- Service desk + трекер задач (Jira и аналоги) + wiki. Быстрый старт для разработки, слабый каталог услуг и SLA для бизнес-подразделений.
- ERP / HR-контур как «заявки». Удобно для кадровых и финансовых процессов, плохо как рабочее место агента поддержки.
- Самописный портал + почта + таблицы. Нулевая лицензия, высокая стоимость сопровождения и нет единой отчётности.
- Набор low-code/BPM без сервисной модели. Гибкие процессы, нет из коробки ITIL-контуров, CMDB и очереди агента.
Аналог выигрывает, когда уже есть сильная система в одном контуре и нет задачи сводить HR, ИТ и АХО в одном отчёте. Единая платформа выигрывает, когда заказчик считает полную стоимость владения и время до нового процесса.
Развёртывание
Единый контур ставится как одно приложение (on-premise или частное облако): каталог, агент, CMDB, задачи — один инсталлятор, одна схема БД, один контур SSO. Связка требует согласовать версии, шину, окружения и сетевые доступы между продуктами; пилот часто «зеленеет» в ITSM и буксует на CMDB.
Данные в ESM-сценарии заказчика обычно не выходят из контура. В связке каждый продукт тянет свой облачный или вендорский контур — политику ИБ приходится писать несколько раз.
Эксплуатация
Один контур: один мониторинг, один бэкап, одна модель прав, один журнал аудита. Инцидент «не создаётся заявка» диагностируется в платформе, а не между тремя вендорами.
Связка: каждая система живёт своим релизом. Обновление ITSM может сломать коннектор к CMDB. Ночной расчёт связей и дневная очередь агента расходятся — это уже не «баг продукта», а шов архитектуры.
Нагрузка: ESM масштабирует очереди и карточки как один профиль. Связка масштабирует то, что уже стало узким местом, и оставляет остальные системы с запасом, за который всё равно платят.
Поддержка
Платформа: одна линия эскалации, один пакет обновлений, база знаний на тех же объектах, что и тикеты. Кастомизация в low code переживает апгрейд, если держаться модулей.
Связка: три контракта поддержки, три окна обновлений, три ответа «это на стороне соседа». Скрипты швов сопровождает внутренняя разработка — скрытая ставка, которой нет в лицензии ITSM.
Внедрение
Единая платформа хорошо ложится на короткий пилот: один процесс, узкая группа, затем каталог и SLA, затем остальные контуры. Служба видит то же рабочее место, что будет в проме.
Связка чаще внедряется «по продуктам»: сначала service desk, через квартал CMDB, затем задачи. Бизнес всё это время живёт без сквозного отчёта. Срок до «картины целиком» длиннее, даже если первый тикет открыли быстрее.
Итоги
| Характеристика | Единая ESM-платформа | Связка аналогов (ITSM + CMDB + задачи + wiki) | Самописный контур / почта |
|---|---|---|---|
| Модель данных | Одна: обращение, услуга, CI, задача | Несколько, сшивка интеграциями | Нет или таблицы |
| Рабочее место агента | Одно окно | Переключение между системами | Почта и чаты |
| Развёртывание | Один контур, on-prem / частное облако | Несколько инсталляций и швов | Быстрый старт, хрупкий рост |
| Срок пилота | Недели на один процесс | Быстрый desk, долгая склейка | Дни на форму, месяцы на учёт |
| Эксплуатация | Единые мониторинг, бэкап, права | Несколько контуров и расписаний обновлений | На команде, которая писала |
| Обновления | Платформенный релиз | Согласование версий и коннекторов | Свой релиз или застой |
| Поддержка | Один вендор / одна линия | Несколько вендоров, споры о швах | Только внутренняя |
| Внедрение новых услуг | Настройка на платформе | Доработка в каждой системе | Новая разработка |
| Отчётность | Сквозная без ETL | Витрина или ручная сшивка | Слабая |
| CMDB и обращения | Связь из коробки | Интеграция, лаги, расхождения | Обычно отсутствует |
| AI в процессе | На данных платформы | Отдельный контур или не используется | Точечные боты |
| ИБ и контур данных | Одна политика, данные внутри | Несколько контуров и облаков | Зависит от реализации |
| TCO на 3 года | Ниже за счёт внедрения и сопровождения швов | Лицензии плюс интеграторы и внутренняя разработка | Дёшево на старте, дорого в изменениях |
| Когда выбирать | Несколько служб, нужен единый отчёт и быстрые изменения | Уже есть сильный продукт в одном контуре | Временный контур, нет сервисной модели |
Итог для выбора простой: если заказчик покупает очередь тикетов, хватит service desk. Если покупает управление услугами предприятия — IT, HR, активы и работы в одном контуре, — связка аналогов каждый квартал возвращает стоимость шва. Единая ESM-платформа окупается не «богаче модулем», а тем, что шов не нужно содержать.