22 августа 2025 г.
Автоматизация сервисного подхода помогает компаниям выстроить четкое и согласованное управление ключевыми корпоративными процессами. Именно эту задачу и решает внедрение ESM-систем.
Особенности подготовки к проектам мы рассматривали в первой публикации из серии статей, посвященных специфике автоматизации управления корпоративными сервисами (ESM).
Однако на этапе реализации проектов часто упускаются важные аспекты, которые могут негативно сказаться на управлении бизнес-процессами организации. В том, какие ошибки встречаются при проектировании ESM-системы чаще всего и как их избежать, помогли разобраться эксперты К2Тех по управлению корпоративными и ИТ-сервисами — Александр Трошкин и Анна Панина.
1. Как излишняя детализация требований к ESM-системе влияет на сроки проекта
На этапе проектирования нередко возникает желание детально описать все требования. Но в этой фазе важнее сосредоточиться на общей концепции будущей системы, а не погружаться в проработку каждой детали. Излишне долгий сбор данных и многоступенчатые согласования затягивают проект, отдаляя момент, когда компания сможет получить реальный эффект.
«Мы часто сталкиваемся с подобными кейсами в своей работе, — говорит Александр Трошкин, руководитель направления „Управление ИТ и корпоративными сервисами“ К2Тех. — Типичный пример из нашего опыта: на этапе проектирования появляется желание согласовать полный перечень полей для всех объектов системы, включая поля информационного характера, и детально зафиксировать особенности их реализации — наименования, ограничения, расположение на форме, подсказки по заполнению. В итоге время, заложенное на фазу проектирования, тратится на обсуждение деталей, а общее концептуальное понимание остается несформированным. Для эффективного использования ресурсов проекта целесообразно начинать с верхнеуровневой концепции, постепенно углубляясь в детали на более поздних этапах».
На этапе проектирования важно зафиксировать ключевые элементы концепции:
- Системные объекты — структуру, логику и связи объектов в системе;
- Процессы — состав работ, состав ролей и основных атрибутов;
- Интеграции — состав и результат взаимодействия систем;
- Миграцию данных — состав и структуру данных.
2. Почему концепция ESM-системы важнее точечных требований
В процессе проектирования и внедрения системы, а также при последующей технической поддержке и сопровождении неизбежно появляются новые требования.
Это связано с необходимостью компаний быстро адаптироваться к меняющимся условиям рынка и сохранять конкурентоспособность.
Однако важно тщательно анализировать новые требования, чтобы избежать таких проблем в будущем —
как:
дополнительные затраты, нарушени
е
я целостности и согласованности системы, снижение достоверности данных и эффективности процессов.
«Такое в нашей практике происходит нередко, — добавляет Александр Трошкин. — Например, мы рекомендуем запретить редактирование уже закрытых записей в системе, чтобы обеспечить корректность отчетности, на основе которой принимаются управленческие решения. В одном из недавних проектов данные из системы действительно использовались для оперативного управления и проведения стратегических сессий по развитию компании. Однако на этапе опытно-промышленной эксплуатации возникло предложение создать роль, позволяющую изменять в том числе исторические данные. Предварительный анализ показал, что это может нарушить целостность данных и снизить обоснованность управленческих решений, основанных на них. В итоге было принято совместное решение отказаться от реализации этого требования».
Для каждого поступающего в рамках проекта требования необходимо провести предварительный анализ по следующему минимальному набору критериев:
- Влияние на концепцию — влияние на уже выстроенную логику работы систем и процессов;
- Нормативно-правовое соответствие — соответствие внутренним и внешним политикам, в том числе политикам информационной безопасности;
- Экономическая целесообразность реализации требования.
Расширенный перечень критериев приведен в последнем разделе.
3. К чему приводит отсутствие баланса между автоматизацией и ручным трудом
Автоматизировать и контролировать каждую операцию в рамках процессов — это частое и понятное желание при внедрении ESM-системы. Кастомизация, т. е. реализация в системе возможностей сверх коробочного решения — действительно неотъемлемая часть работ подобных проектов.
Однако перед тем, как реализовать такого рода требования, стоит соотнести потенциальную выгоду и риски. Также нужно учитывать издержки на поддержку кастомных функций, на обучение и развитие внутреннего центра компетенций после передачи системы заказчику. Совокупные затраты на реализацию и поддержку функциональности стоит сравнить с другими вариантами достижения результата, например, со стоимостью частичной автоматизации или ручного выполнения функции.
Показателен в этом контексте пример из реализованных К2Тех проектов. Компания периодически сталкивалась с ошибками при отправке счетов: некоторые сотрудники невнимательно проверяли документы и направляли их далее с неверными реквизитами. Заказчик предложил внедрить механизм обязательного двойного согласования перед отправкой — каждый счет должен быть проверен и одобрен двумя ответственными лицами, чего ранее в процессе не предусматривалось. Анна Панина уточняет: «В реализации это достаточно простое требование, но оно бы приводило к нерациональному использованию человеческих ресурсов. Вместо введения дополнительных действий в системе было рекомендовано сфокусироваться на повышении квалификации персонала при работе с документами. По результатам совместного обсуждения было принято решение проводить обучение персонала».
Отсутствие баланса между автоматизацией и ручным трудом может привести к:
- нерациональному использованию бюджета проекта;
- неэффективному использованию рабочего времени сотрудников;
- снижению лояльности сотрудников;
- регулярным нарушениям SLA на решение заявок.
4. Почему важно планировать участие внутренних ресурсов в проекте
Необходимостью участия команды заказчика в основных стадиях проекта никого не удивишь. Однако, по нашему опыту, есть несколько задач, которые регулярно недооцениваются при планировании внутренних ресурсов, что приводит к увеличению сроков и росту бюджета проекта.
«При проектировании одним из обязательных требований стала интеграция со смежной системой, — делится примером из проектного опыта Анна Панина. — Мы настроили интеграцию нашей ESM-системы со смежной и определили дату ее выхода в опытную эксплуатацию. Однако оказалось, что у команды, которая занимается поддержкой и сопровождением смежной системы, релизный цикл занимает больше времени, и в эксплуатацию они смогут выйти позже назначенного срока. В результате сроки запуска интеграции сдвинулись, подстроившись под релизный цикл смежной системы, а также появились внеплановые затраты, в том числе на корректировку плана работ и взаимодействие со смежными командами».
Чтобы избежать подобных ситуаций, важно корректно планировать внутренние ресурсы, включая:
- Участие смежных команд/подрядчиков в реализации интеграций. Команды смежных систем должны согласовывать действия, чтобы интеграция в инфраструктуру заказчика прошла бесшовно.
- Регулярное взаимодействие с командами внедрения и обеспечения единого информационного поля. Результат проекта, его сроки и итоговый результат напрямую зависит от прозрачной, своевременной и периодической коммуникации.
- Сбор требований силами команды заказчика. Даже если в проект заложены трудозатраты команды исполнителя, заказчик все равно будет принимать участие в сборе и верификации требований.
- Бизнес-тестирование командой заказчика. Хотя бизнес-тестирование и проводится обычно силами исполнителя, зачастую заказчик хочет самостоятельно протестировать настроенные процессы и удостовериться в их корректности.
- Обучение и вовлечение будущего центра компетенций в проекте. Это позволяет внутренним командам быстрее освоить систему, а также обеспечивать поддержку пользователей и сопровождение системы после завершения проекта.
Коротко о главном: как предостеречь себя от ошибок
Подводя итог, следует еще раз подчеркнуть, что каждый из четырех аспектов может привести к увеличению TTM (time to market) и стоимости внедрения ESM-системы.
Эксперты К2Тех подготовили список из 20 параметров, на которые можно опираться при анализе требований к ESM-системе.
- Влияние на концепцию: требование не противоречит сложившейся концепции проекта.
- Нормативно-правовое соответствие: требование не противоречит имеющимся внешним и внутренним политикам компании.
- Информационная безопасность: требование соответствует внешним и внутренним политикам информационной безопасности.
- Альтернативные сценарии реализации: варианты реализации требования другими путями, например, выполнения сотрудниками дополнительной ручной операции.
- Стоимость реализации требования: планируемые финансовые затраты на реализацию требования.
- Источники финансирования: финансовые источники реализации требования. Финансирование может осуществляться как из бюджета самого проекта, так и из бюджета развития смежной системы, например, при оценке требований, касающихся интеграции.
- Экономическая целесообразность: выгоды от внедрения функционала превышают стоимость его реализации и поддержки.
- Сроки реализации требования: требуемое для реализации требования время, начиная от планирования и заканчивая промышленной эксплуатацией.
- Периодичность и охват: реализованный функционал будет часто использоваться в работе существенной частью сотрудников.
- Экономия времени: реализованный функционал сокращает время на выполнение работ.
- Организационные изменения: влияние требования на организационные изменения внутри компании. Например, необходимость реструктуризации существующих команд, внедрения новых технологий, изменения графика работы сотрудников.
- Контроль: влияние требования на возможность оценки эффективности деятельности. Может потребоваться пересмотр состава метрик или корректировка пороговых значений KPI затронутых процессов.
- Топ менеджмент: влияние требования на работу топ-менеджмента. Требование должно быть оценено с точки зрения влияния на непрерывность работы и возможность принятия стратегических решений на уровне топ-менеджмента.
- Влияние на смежные процессы/системы: перечень смежных процессов/систем, затронутых реализацией требования, а также необходимых для полноценной работы изменений в этих процессах/системах.
- Привлекаемые эксперты и команды: перечень экспертов и команд, в том числе смежных процессов и систем, которых нужно привлечь для реализации требования.
- Документация: перечень документов, которые потребуется изменить или разработать при проработке и реализации требования.
- Обучение: необходимость обучения сотрудников после реализации требования.
- Совместимость с обновлениями от вендора: добавление требования не приводит к сбою работы ESM-системы при появлении обновленных версий со стороны вендора.
- Техническая поддержка: стоимость, условия и варианты технической поддержки, особенно при реализации значительного объема кастомного функционала, требующего дополнительных ресурсов для обеспечения стабильной работы.
- Техническое сопровождение: необходимость, стоимость, условия и варианты технического сопровождения как элемента развития системы в соответствии с изменяющимися потребностями бизнеса.
Источник: Александр Трошкин, Александр Трошкин, руководитель направления «Управление ИТ и корпоративными сервисами» К2Тех; Анна Панина, руководитель практики ESM К2Тех
