В предыдущих статьях мы сделали обзор SIAM методологии, подробно разобрали роль Сервис-интегратора и проанализировали ключевые бизнес-драйверы перехода к SIAM.
В этой статье перейдем к рассмотрению основных практик SIAM.
Для начала коротко обозначим саму проблему: почему классическое управление поставщиками перестает работать и где ценность развития текущих подходов к управлению?
В крупных компаниях ИТ-ландшафт редко строится вокруг одного поставщика. Как правило, он представляет собой целую экосистему, в которую входят:
- Инфраструктурный аутсорсер вперемешку с внутренней службой.
- Поставщики разных приложений.
- Облачные провайдер.
- Сторонние и внутренние сервис-дески, КЦ, ОЦО.
- Внутренние и внешние команды разработки.
- Интеграторы отдельных платформ.
Очевидно, что каждый из участников будет работать по собственным процессам, метрикам и контрактам. В результате формируется типичная картина:
- ответственность за конечный результат фрагментирована;
- процессы разорваны между компаниями;
- инциденты передаются между поставщиками;
- управленческая информация противоречива и нет общей точки истины;
- поставщики оптимизируют свою работу под SLA и не работают на качество услуг.
Именно этот класс проблем и призвана решать модель SIAM.
SIAM – это не отдельный процесс, а операционная модель управления мультипровайдерной экосистемой, в рамках которой:
- появляется слой сервис-интегратора, действующего от имени компании;
- формируется единая структура корпоративного управления, включающая внешних поставщиков;
- процессы измеряются и выполняются сквозь всех поставщиков.
При этом важно понимать:
SIAM редко внедряется как единый проект в полном объеме.
На практике большинство компаний последовательно внедряют отдельные SIAM-практики, каждая из которых помогает решить конкретные управленческие задачи и устранить наиболее острые точки разрыва.
Теперь перейдем непосредственно к самим практикам.
Практика 1. Стратегические и тактические Комитеты корпоративного управления
Одна из первых практик, которая появляется в SIAM-модели — это многоуровневая структура корпоративного управления.
В традиционной модели управление поставщиками происходит через:
- встречи по анализу текущих договоров;
- ретроспективные обзоры сервисов;
- переговоры о SLA.
Но на крупных масштабах при наличии большого количества поставщиков этого уже недостаточно. Поэтому SIAM предлагает совместные управленческие органы.
Типовая структура корпоративного управления
Пример применения
Внедрение интегрированного комитета по изменениям (Интегрированный CAB) позволяет решить здесь и сейчас проблему конфликтующих изменений.
До внедрения
Каждый поставщик проводил собственные изменения. Изменения пересекались без согласованности действий. Возникали инциденты.
После внедрения интегрированного CAB:
- Изменения анализируются в контексте всей сервисной архитектуры.
- Поставщики координируют планы релизов.
- Снизилось количество инцидентов после изменений.
Практика 2. Кросс-функциональные команды поставщиков
В мультивендорной среде большинство проблем возникает на границе ответственности поставщиков.
Типичный пример — это крупный инцидент:
- инфраструктура — один поставщик;
- приложение — другой;
- поддержка интеграции — третий;
- сеть — четвертый.
Каждый анализирует только свою область.
SIAM предполагает для таких ситуаций создание кросс-организационных команд.
Команды могут быть как постоянными, так и временными (для крупных инцидентов или проектов).
Как это работает
Команда формируется из:
- представителей сервис-интегратора;
- специалистов поставщиков;
- архитекторов заказчика;
- владельцев сервисов.
Задачи команды заключаются в следующем:
- Сквозной анализ проблемы (end-to-end).
- Устранение организационных барьеров.
- Принятие решений без эскалации по контрактной линии.
Пример применения
Внедрение кросс-функциональных команд по анализу инцидентов позволяет эффективно сократить среднее время ремонта (MTTR) крупных инцидентов, если проблема деградации или недоступности критически важных сервисов или бизнес-приложений длительное время не решается.
Почему это работает
Вместо последовательной передачи инцидента между поставщиками кросс-функциональная команда со всеми представителями внешних поставщиков сразу решает проблему совместно, а бизнес в лице сервис-интегратора выступает координационным органом.
Практика 3. Интегрированные процессные модели
SIAM не заменяет ITSM-процессы, он перестраивает их архитектуру.
Ключевая идея:
Процесс должен работать через организации, а не внутри них.
В SIAM создаются интегрированные модели процессов которые описывают:
- роли заказчика;
- роли сервис-интегратора;
- роли поставщиков;
- точки взаимодействия между ними.
Процессы могут исполняться в разных компаниях, но работают они как единая операционная модель.
Пример — Управление инцидентами
Процесс управления инцидентами в SIAM-модели обычно включает несколько последовательных этапов:
- Регистрация инцидента.
- Первичная диагностика.
- Маршрутизация.
- Совместное расследование.
- Восстановление сервиса.
Каждый этап может выполняться разными организациями, но по общей модели процесса — SIAM поднимает практики ITIL на новый уровень и включает в себя всех внешних игроков, участвующих в цепочках создания ценности.
Практический эффект
Это решает ключевую проблему мультисорсинговой среды — инциденты перестают «теряться» между поставщиками, появляются эффективные инструменты управления.
Практика 4. Общая модель данных и отчетности
Еще одна типичная проблема мультисорсинговой среды — несопоставимые данные и отсутствие единой точки истинности.
Например:
- разные приоритеты инцидентов;
- разные категории запросов;
- разные SLA-метрики.
В SIAM создается:
- единый словарь данных;
- стандарты отчетности;
- единая модель KPI.
Это позволяет:
- Получать сквозные (end-to-end) метрики.
- Сравнивать поставщиков.
- Управлять качеством сервиса.
В контексте рынка ITSM инструментов эта проблема как никогда актуальна. Вендоры предлагают огромное количество платформенных решений с бесконечным количеством кастомизаций, которые «развязывают руки» для доработки инструмента под свое видение и свои интересы. От сюда и начинается несогласованность модели данных и процессов, которые могут быть разными от команды к команде или от отдела к отделу, а «сшивание» этих данных в единые отчеты для управления никогда не дадут понятной и прозрачной картины.
Поэтому SIAM рекомендует очень внимательно подходить к выбору инструментария, делая акцент на коробочности и универсальности решения, которое поможет компании выстраивать стратегию на долгосрочную перспективу. Подробнее о преимуществах коробочных ITSM инструментов можно прочитать здесь.
Практика 5. Модель сотрудничества
SIAM рассматривает сотрудничество поставщиков как операционную практику, а не культурный лозунг.
Для этого вводятся формальные механизмы:
- совместные KPI;
- соглашения о сотрудничестве;
- регулярные встречи между поставщиками;
- совместные инициативы по улучшению сервисов и процессов.
Эти механизмы превращают поставщиков из конкурирующих подрядчиков в полноценных участников цепочки создания ценности.
Почему SIAM практики внедряют постепенно
SIAM тяжело внедрить в корпоративное управление целиком, однако, методология внутри себя дает дорожную карту, как сделать внедрение практик и инструментов в ограниченных объемах.
Большинство компаний начинают с одной или двух доменных областей, в которых необходимо решить наиболее критичные проблемы:
Таким образом, SIAM становится следующим этапом эволюции классических моделей управления сервисов.
Что важно понимать руководителям сервисных организаций
SIAM — это не просто методология.
Это архитектура управления сервисной экосистемой, которая включает:
- Структуры корпоративного управления.
- Интегрированные процессы.
- Модели сотрудничества.
- Механизмы управления поставщиками.
Главная ценность SIAM заключается в том, что он предлагает уже готовые практические инструменты.
И именно поэтому многие организации начинают внедрение не с масштабной трансформации, а с точечного применения конкретных SIAM-практик, которые позволяют восстановить управляемость сложной сервисной среды.