Когда у вас разные точки входа в каждый отдел — в ИТ писать, в HR звонить — сотрудник половину рабочего времени бегает между разными каналами в попытке решить свой вопрос. Или хотя бы найти того, кто его решит.
А когда вы пытаетесь сделать общий источник данных для всех обслуживающих подразделений и создать наконец одну-единственную точку входа для всех запросов сотрудника, приходится объединять интеграциями с десяток систем. Чтобы не мучаться, есть такой класс систем как ESM-платформы. Разбираемся, зачем бизнесу такое решение, оправдан ли хайп, поможет ли платформа связать разные точки входа в один удобный канал.
Как десятки интеграций вас ограничивают
Представьте пять городов, между которыми нужно наладить прямое железнодорожное сообщение: Москва—Петербург, Москва—Казань, Петербург—Казань и так далее. Чтобы связать каждый город с каждым напрямую, нужно построить 10 отдельных линий. Добавьте шестой город, и линий станет уже 15, потому что новый узел приходится тянуть к каждому из пяти существующих.
Это формула n(n−1)/2: число попарных связей растёт квадратично, а не линейно.
В ИТ-инфраструктуре происходит то же самое, только вместо городов — системы. Пять систем (сервис-деск, HR-портал, бухгалтерская программа, юридический трекер, система закупок) дают 10 потенциальных интеграций. Добавьте CRM и систему учёта активов — станет уже 28 связей вместо 10. Каждую такую связь нужно тестировать при каждом обновлении любой из двух систем, чинить, когда меняется формат данных, и документировать, чтобы через год не искать концы. Поэтому у ИТ-отдела всегда есть очередь из мелких интеграционных задач, которая никогда не заканчивается.
Возвращаясь к железнодорожной метафоре, поезда из всех городов приходят на один центральный вокзал, и дальше пассажир пересаживается там, а не ищет прямой рейс. Добавление нового города требует одной новой ветки, а не пяти, не нужно от Саратова прокладывать рельсы до каждого города в стране. Так работает архитектурная идея ESM-системы, где вместо того чтобы тянуть прямую интеграцию между HR-системой и сервис-деском, между сервис-деском и бухгалтерией, между бухгалтерией и юристами, каждая система подключается один раз к центральному сервисному слою. Десять систем в такой модели — это десять подключений, а не 45 попарных связей.
Масштаб задачи, кстати, легко недооценить. По данным Zylo, средний портфель приложений в компании — около 305 SaaS-инструментов. Такое количество разрозненных систем в реальности нужно каким-то образом свести в управляемую среду, и без условного вокзала от мира корпоративных систем ИТ-отдел обречен вечно строить интеграции.
Что такое ESM (и чем оно не является)
Подход Enterprise Service Management — это распространение принципов сервисного управления, отработанных в ИТ (тикеты, workflow, SLA, каталог услуг), на остальные бизнес-функции: HR, финансы, юристов, АХО, закупки.
При этом ESM не заменяет HR-систему или учётную систему бухгалтерии, он не требует выкидывать то, что уже работает и настроено. Отдел кадров продолжает вести дела в своей системе, бухгалтерия — в своей, а слой ESM-системы берёт на себя маршрутизацию запроса, статус его выполнения и общий каталог услуг, видимый сотруднику независимо от того, какой отдел закрывает вопрос.
Российские компании, например, последние несколько лет решают задачу интеграции систем в специфическом контексте массового ухода зарубежных ITSM/ESM-платформ (включая ServiceNow). В 2022 году многим компаниям пришлось не просто заменить один инструмент на другой, а пересобрать всю цепочку связей между системами почти с нуля. Например, Systeme Electric при замене ServiceNow объединила 10 подразделений на ESM-платформе, а Альфа-Лизинг — 9 отделов, при этом больше половины запросов приходит именно в не-ИТ подразделения.
Типовой путь интеграции в компании выглядит одинаково независимо от отрасли: аудит текущей ИТ-инфраструктуры и точек соприкосновения систем, проектирование архитектуры (прямые API-интеграции, шина данных ESB или брокер сообщений), выбор конкретного стека и только потом — разработка адаптеров и настройка маршрутизации. Архитектурный выбор на втором этапе определяет, что будет, когда систем станет больше. Либо появится паутина точечных API-интеграций, которую нужно перепроверять при каждом обновлении любой из сторон, либо централизованный слой, куда каждая система подключается один раз.
Что в итоге получается с ESM:
Единая точка входа для обращений сотрудника в любое подразделение.
Стандартизация процессов: workflow, SLA и статусы запросов работают по одной логике во всех функциях, а не изобретаются в каждом отделе с нуля.
Прозрачность портфеля сервисов, так как появляется единый каталог услуг — видно, что вообще можно запросить и кто за это отвечает.
Управляемая нагрузка на интеграции, рост числа подключённых систем не приводит к взрывному росту числа связей между ними.
Пример
Рассмотрим сценарий «Принять нового сотрудника с 1 июня в московский офис», реализованный через SimpleOne ESM.
Руководитель подает заявку через портал ESM-платформы. Система создает интегрированную услугу «Онбординг», которая автоматически генерирует подзадачи для разных подразделений.
Пользователь, например, сотрудник HR, заполняет интерактивную форму на портале — указывает ФИО, выбирает должность, отмечает нужное оборудование. В зависимости от выбора появляются дополнительные поля или скрываются ненужные.
Из одной формы создается пакет обращений, которые сразу направляются в профильные подразделения, минуя первую линию поддержки:
HR: подготовка трудового договора, внесение в кадровую систему, присвоение табельного номера;
IT: создание учетной записи в Active Directory, настройка доступов к корпоративным системам, заказ оборудования;
АХО: бронирование места, заказ мебели, настройка настольной лампы;
Служба безопасности: проверка благонадежности, оформление пропуска, проведение инструктажа;
Администрация: подготовка welcome-пакета, заказ корпоративного мерча.
Подзадачи запускаются параллельно или последовательно в зависимости от бизнес-логики:
если бюджет превышает определенную сумму, запускается дополнительное согласование с финансовой системой;
если сотрудник удаленный, задача по подготовке рабочего места не создается;
если должность требует специальных разрешений, добавляется расширенная проверка службой безопасности.
Дополнительно платформа интегрируется с корпоративными системами через API:
кадровая система автоматически получает данные о новом сотруднике;
система заказов создает заявки на оборудование;
Active Directory получает запрос на создание учетной записи;
система бронирования резервирует рабочее место.
В центре контроля SLA система отслеживает выполнение всех подпроцессов. Когда все выполнено, общая услуга автоматически закрывается. Если возникает просрочка — механизм автоэскалации отправляет предупреждения ответственным.
Все участники видят общий статус в реальном времени через единую платформу. Заявитель отслеживает прогресс, исполнители понимают свою роль в общем процессе. После завершения система автоматически отправляет опрос по удовлетворенности и формирует аналитику по исполнению целевых показателей качества услуги.
С чего начать
С вопроса: какие системы у вас вообще есть и какие из них реально нужно связывать между собой?
Сначала нужно составить список систем, которые сейчас используются в разных отделах — сервис-деск, HR-портал, бухгалтерская программа, система закупок. Затем отметить, какие из них уже связаны точечными интеграциями. На этом шаге можно обнаружить десятки полу-рабочих связей, часть из которых никто уже не помнит.
Дальше стоит посмотреть не на системы, а на путь запроса. Здесь полезно на время забыть слово «интеграция» и посмотреть на вещи чуть шире: не какие системы связаны, а что вообще происходит с запросом сотрудника от момента, когда он его отправил, до момента, когда вопрос закрыт. Часто выясняется, что запрос физически проходит через несколько подразделений — ИТ передаёт часть работы в АХО, АХО согласовывает с закупками, — и на каждой такой передаче кто-то вручную копирует данные из одной системы в другую или просто пишет письмо коллеге. Каждая такая ручная передача — это полноценная точка отказа, где теряется контекст, срываются сроки, и никто потом не может сказать, на каком этапе запрос застрял.
Если по итогам такого разбора выясняется, что типовой запрос сотрудника проходит через одну систему, то прямая точечная интеграция может быть простым и оправданным решением, не нужно городить лишнюю архитектуру. Но если запрос регулярно проходит через три-четыре системы с ручными передачами между ними, полезно будет иметь центральный слой в виде ESM-системы, потому что количество таких переходов будет только расти, а с ним и число мест, где всё может сломаться.
Итоговый порядок действий перед тем, как проектировать или перепридумывать архитектуру обработки данных в разных системах:
Составить полный список систем, которые используются сервисными подразделениями.
Зафиксировать, какие связи между ними уже есть, и какие из них реально поддерживаются, а какие де-факто сломаны или обходятся вручную.
Проследить путь нескольких типовых запросов сотрудников через отделы и системы, отмечая каждую ручную передачу.
Оценить, сколько систем и ручных передач в среднем участвует в одном запросе, чтобы определить, нужен ли центральный узел или хватит точечных интеграций.
Только после такого аудита имеет смысл разбираться в архитектурных вариантах, потому что выбор между ними зависит от того, что показал разбор реальных путей запроса.
Следующий логичный вопрос — чем ESM отличается от BPM и Low-code платформ, ведь на первый взгляд все они обещают связать процессы между отделами. Разберём это в следующей статье серии.
У вас сколько интеграций с интеграциями?
