Возможность кастомизации систем класса ITSM/ESM давно воспринимается как одна из ключевых и обсуждаемых тем при выборе продукта. Кажется удобно и проверено: платформа-конструктор, где можно «собрать всё под себя». Руководители довольны тем, что каждый департамент получит что-то заточенное под свои «суверенные» процессы, а вендоры на вопрос «А можно в вашей системе вот так?» отвечают утвердительно.
Однако, за перспективами такой гибкости легко потерять главное — стратегическую управляемость и поддерживаемость продукта при игре «в долгую». Создавая индивидуальные кастомные компоненты для разных отделов компании, платформа рискует потерять универсальность управления цепочками создания ценности и внутренними процессами. В таких системах перестает существовать единый набор правил — разные отделы имеют разные статусные модели запросов, каталог услуг у каждого департамента отличается по архитектуре, стыки при маршрутизации запросов начинают «искрить», отчетность у каждого из отделов имеет разную форму, и их приходится «сшивать» вручную.
Рост трудностей управления в масштабе компании пропорционален росту кастомизаций внутри платформы, но в рамках изолированной работы отдельных «башен» организации такой подход кажется удобным. Постоянно находясь в «тумане» обсуждения планов и подготовки ТЗ на будущие кастомизации и их согласования между отделами может потеряться суть: цель ITSM платформ не в том, чтобы угодить каждому отдельному подразделению, а в том, чтобы построить сквозное и прозрачное управление цифровыми продуктами и процессами внутри компании.
На первый взгляд кажется странным, ведь все понимают риски внедрения супер-кастомизированных ITSM/ESM-систем: непредсказуемые сроки реализации и проблемы с поддерживаемостью. Почему же тогда вендоры десятилетиями идут по этому пути и продолжают "раздувать" проекты кастомизациями?
- Бесконечный консалтинг. Чем больше доработок, тем больше платных часов на внедрение, интеграцию и поддержку. Вендоры зарабатывают не только на лицензиях, но и на консалтинге — иногда именно он даёт основную маржинальность.
- Эффект «золотой клетки» и сложность замены. Чем больше кастомных сценариев внедрено, тем труднее заказчику уйти к другому поставщику. Даже если лицензии обойдутся дешевле, миграция с «кучей кастомов» может быть дороже самого перехода. Кастомизированная система становится настолько уникальной, что её невозможно сравнивать с «коробкой» конкурентов.
- Подыгрывание запросам. Заказчики часто приходят с конкретными требованиями: «нам нужно именно так». Вендоры понимают: проще сказать «да» и настроить кастом, чем спорить и объяснять, что это приведёт к негативным последствиям.
- Краткосрочный комфорт. Руководитель отдела получает именно то, что хотел «здесь и сейчас». А такие последствия, как неподдерживаемость, блокировка обновлений, трудности с новыми подрядчиками, могут проявиться уже через 2−3 года.
Интерес заказчика — тоже ловушка
Нужно признать, что в кастомизациях виноваты не только вендоры. Заказчики сами подталкивают их к этому:
На короткой дистанции кастомизация действительно может казаться выгодной: люди получают интерфейс, статусы и процессы «под себя». Но на длинной — к сожалению, приводит к потерям.
- «У нас уникальные процессы, стандарт нам не подходит» — очень частые тезисы.
- Каждый департамент хочет своё поле, свой отчёт, свою форму заявки.
- Руководители IT боятся сопротивления пользователей и идут на поводу у «локальных» требований.
На короткой дистанции кастомизация действительно может казаться выгодной: люди получают интерфейс, статусы и процессы «под себя». Но на длинной — к сожалению, приводит к потерям.
Почему никто не предлагает альтернативу?
- Менять рынок сложно. Объяснить директорам подразделений и бизнес-заказчикам, что лучше следовать стандартам и выстраивать свои процессы универсально — значит идти против устоявшегося менталитета. Это требует образовательной работы, долгосрочной стратегии и наглядных примеров. Что не мало важно, в этом случае придется показывать заказчику необходимость проведения огромной работы по развитию корпоративной культуры внутри — «ломать» стены между «башнями», приводить все к единым стандартам и долго работать с людьми, начиная с самого верха.
- Инерция. Так делают десятки лет — «зачем менять то, что продаётся».
- Страх потерять сделки. Если один вендор скажет: «мы не будем кастомизировать», заказчик пойдёт к конкуренту, который скажет «да» на любой каприз.
Почему менять подход всё же необходимо?
Мультисорсинг и SIAM-модели меняют правила игры:
- Бесконечная кастомизация делает систему неспособной интегрировать новых подрядчиков, строить сквозные SLA и быстро масштабировать или видоизменять каталог услуг.
- Жизнь с отсутствием единой «точки истинности» и несогласованности процессов приводит к нарастанию конфликтов как в рамках платформы, так и между людьми.
- Современные ИТ-руководители начинают требовать прозрачности и быстрой адаптации, а не "вечного внедрения".
- Некоторые крупные компании не могут измерить эффективность своего портфеля услуг из-за невозможности строить сквозную отчетность (end-to-end).
- Появление зрелых «коробочных» платформ показывает, что можно внедрять быстро и без хаоса, сохраняя гибкость, особенно для мультисорсинговых сред.
Управляемая коробочность как ответ
В продукте R-Service мы сознательно пошли против тренда «супер-конструкторов» и ограничили кастомизацию. Это было осознанное решение и экспертная ставка на будущее, продиктованное не техническими рамками, а стратегией.
Почему так?
R-Service — это не просто ITSM, а платформа управления услугами в логике SIAM. Ключевое в SIAM— сквозная универсальность процессов. Гибкая маршрутизация любого типа запроса и связи SLA должны «стыковаться» между десятками и сотнями подрядчиков. Механизмы настройки быстрого масштабирования сложных цепочек создания ценности доступны администраторам и пользователям платформы с самых ранних этапов работы с продуктом.
Одновременно с этим, за счет мультитенантности, платформа дает инструменты гибкой настройки процессов для каждого департамента или подрядчика, не нарушая сквозную интеграцию.
Дело в балансе
Кастомизация и разделение единой платформы на несколько «точек истинности» — нет. Нельзя переписать логику ядра и сломать универсальность.
Универсальная настройка — да. Дать возможность сконфигурировать любой процесс так, чтобы он соответствовал требованиям конкретного заказчика или отрасли, но при этом сохранил совместимость и единый язык данных для всей экосистемы.
Именно это даёт возможность:
- подключать новых игроков быстро и без переписывания системы;
- строить end-to-end соглашения (SLA) для мультисорсинговой среды;
- поддерживать обновляемость продукта без риска поломать кастомные сценарии.
R-Service — это прежде всего экспертиза. Поэтому, платформа не про «каждый живёт по-своему», а про то, чтобы все участники сложных и комплексных моделей работали по единым правилам, сохраняя гибкость там, где она нужна бизнесу.
Единые и универсальные процессы и инструментарий, одна точка истинности, возможность быстро масштабировать экосистему — вот основные преимущества такого подхода, которые можно получить уже спустя пару часов после установки платформы.