Тема 6.6 — Управление поставщиками и интеграцией услуг (SIAM)

В хозяйстве здравоохранения и ухода, сшитом из десятков поставщиков, услуга, которую на самом деле получают ваши пациенты и клиницисты, хороша лишь настолько, насколько хороши швы между вендорами, — поэтому кто-то должен владеть сквозным целым, которого не описывает ни один отдельный контракт.

Почему это важно в здравоохранении и уходе#

Ни один современный траст NHS или интегрированная система ухода (ICS) не работает на одном поставщике. Один клинический процесс — направление от врача общей практики, ставшее амбулаторным приёмом, письмом, результатом анализа и рецептом — может пройти через электронную медицинскую карту одного вендора, интеграционный движок другого, платформу хостинга третьего, сетевого провайдера, национальную службу Spine и сервисный стол управляемых услуг, ведомый четвёртой стороной, которую вы никогда не встречали. Контракт на каждую часть может быть здрав. Услуга, которую получает пациент, живёт в промежутках между ними.

Это эксплуатационная сторона коммерческих отношений, и именно здесь ценность либо реализуется, либо тихо теряется. Команды закупок и коммерции (см. тему 6.3 — Закупки и коммерческие вопросы) хорошо покупают, присуждают контракт и передают подписанное соглашение; то, что происходит в последующие годы — сотрудничают ли поставщики или обвиняют друг друга, чинится ли сбой за час или гноится неделю, можете ли вы когда-нибудь уйти, — работа управления поставщиками и интеграцией услуг. Ошибитесь — и провал не абстрактен. Интерфейс патологии, молча теряющий результаты, общая запись ухода, показывающая устаревшую аллергию, служба аутентификации, блокирующая клиницистов при передаче смены: это события безопасности пациентов, начинающиеся как проблемы интеграции (см. тему 1.6 — Клиническая безопасность и управление рисками).

Ставки обострены тремя чертами сектора. Общественные деньги требуют, чтобы купленные результаты были поставленными результатами, а сервисные кредиты и ценность активно добивались, а не оставлялись на столе. Законные обязанности по защите данных, клинической безопасности и кибербезопасности должны проходить вниз по всей цепочке поставок, включая субподрядчиков, которых вы не выбирали (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность). А концентрация критичных услуг у горстки крупных поставщиков означает, что вымогательский инцидент, банкротство или сбой ёмкости одного вендора может отключить целый регион. Управление поставщиками как портфелем, а не по одному контракту, — теперь обязанность устойчивости, а не административная.

Ключевые понятия#

Интеграция и управление услугами (SIAM) — подход к управлению, координирующий нескольких поставщиков услуг и интегрирующий их для поставки бизнесу единой сквозной услуги. Он возник как дисциплина именно потому, что организации отошли от единого генподрядчика к модели эксплуатации с несколькими источниками (multi-sourced), а затем обнаружили, что кто-то всё ещё должен заставить части вести себя как целое. SIAM — не продукт, который покупают; это операционная модель с определёнными ролями, процессами и управлением. Авторитетный справочник — Scopism SIAM Body of Knowledge, стоящий рядом с ITIL и более широкой практикой управления ИТ-услугами (ITSM), а не заменяющий их.

Модель SIAM имеет три слоя. Заказчик, или сохраняемая организация (retained organization), оставляет за собой подотчётности, которые нельзя передать на аутсорс: стратегию, спрос, архитектуру, коммерческое владение и окончательную обязанность заботы о пациентах. Интегратор услуг — слой (внутренняя команда, внешний поставщик или гибрид), координирующий провайдеров, владеющий сквозными процессами, такими как управление крупными инцидентами, и держащий сквозной взгляд. Поставщики услуг, часто организованные в башни услуг (хостинг, пользовательские вычисления, клинические приложения, сети), каждый поставляют определённый ломоть. Это термины SIAM, а не энциклопедические статьи, поэтому они названы здесь простым языком и опираются на свод знаний SIAM.

Под этим лежит коммерческая механика. Аутсорсинг и его вариант по данным и процессам, аутсорсинг бизнес-процессов, описывают передачу работы внешнему провайдеру; управляемые услуги описывают текущую эксплуатацию систем от вашего имени по подписке. Результативность управляется соглашением об уровне услуг (SLA) — измеримым, обычно контрактным обязательством — всё чаще дополняемым соглашением об уровне опыта (XLA), измеряющим результат, который пользователь реально испытывает, а не компонентную метрику, которую поставщику удобно выполнить. У XLA нет устоявшейся энциклопедической статьи; рассматривайте это как новую практику, а не стандарт.

Два понятия риска обрамляют тему. Управление третьими сторонами — дисциплина надзора за внешними провайдерами и, что важно, их собственными субподрядчиками — четвёртыми сторонами, глубоко в цепочке поставок. Управление рисками цепочки поставок занимается сбоями, распространяющимися по этой цепочке, а концентрационный риск — термин, заимствованный из банковского дела, — описывает опасность чрезмерной зависимости от единственного поставщика, платформы или региона. Управление ими не даёт удобному решению о поставках стать системной уязвимостью. Наконец, избегание привязки к поставщику и стимулирование непрерывного улучшения — две перспективные обязанности, не дающие живой услуге закостенеть.

Лучшие практики#

1. Назовите подотчётного владельца сквозной услуги, а не только каждого контракта. Определяющий провал multi-sourcing: каждый владеет ящиком, а никто — стрелками между ними. Установите роль в сохраняемой организации — часто руководитель интеграции услуг или офис управления поставщиками, — подотчётную за всю клиническую или бизнес-услугу в том виде, как её переживает пользователь, с полномочиями созывать поставщиков и арбитрировать. Этот владелец держит сквозной SLA, даже когда ни один вендор не может, и это человек, которого совет может спросить «почему система направлений не работала шесть часов?» и получить ответ, а не круг обвинений.

2. Выбирайте и проектируйте модель SIAM осознанно, затем впишите её в контракты. Решите рано, внутренний ли интегратор услуг, внешний или гибрид, и будьте честны в компромиссе: внутренний интегратор сохраняет контроль и знания, но требует дефицитной возможности; внешний покупает зрелость, но добавляет слой для управления и потенциальный конфликт интересов, если он также ведёт башню. Определите башни, сквозные процессы, которыми владеет интегратор, и обязательства сотрудничества каждого провайдера. Принципиально: эти обязательства должны появиться в контракте каждого провайдера — обязанность сотрудничать, присоединяться к мосту крупных инцидентов интегратора, делиться данными, — потому что поставщик в эксплуатации сделает только то, что было куплено при присуждении (см. тему 6.3 — Закупки и коммерческие вопросы).

3. Сегментируйте поставщиков и тратьте внимание там, где оно важно. Не каждый вендор заслуживает одинакового управления; обращение с перепродавцом массовых лицензий как со стратегическим партнёром EPR тратит усилия впустую и обделяет отношения, которые важны. Используйте модель сегментации, такую как матрица Крэлджика, чтобы разложить поставщиков по критичности для бизнеса и сложности рынка на стратегических, рычаговых, узких мест и массовых, и сопоставьте ритм управления с сегментом: ежеквартальные исполнительные деловые обзоры для стратегических партнёров, лёгкий мониторинг результативности для массовых. Так вы также фокусируете гарантии, инвестиции в отношения и планирование выхода на немногих поставщиках, чей провал по-настоящему ударил бы.

4. Управляйте результатами и опытом, а не только компонентными метриками. Хозяйство поставщиков может выполнить каждый отдельный SLA — 99,9% доступности сервера, тикеты закрыты в срок, — пока реальный день клинициста мучителен, а путь сломан от начала до конца. Дополните компонентные SLA соглашениями об уровне опыта и сквозными мерами, отражающими то, что переживают пациенты и персонал, и берегитесь «арбузной» отчётности: зелёной снаружи, красной внутри. Там, где метрику можно выполнить накруткой (закрытие и повторное открытие тикетов, переклассификация серьёзности), переработайте её так, чтобы стимул поставщика совпадал с результатом, которого вы действительно хотите.

5. Ведите один интегрированный процесс инцидентов и проблем по всем поставщикам. Когда инцидент охватывает нескольких вендоров, проблема «вращающегося кресла» — каждый поставщик настаивает, что неисправность в другом месте, пока услуга лежит, — самый разрушительный образец в multi-sourcing. Дайте интегратору услуг полномочия объявлять крупный инцидент, собирать каждого релевантного провайдера на один мост и вести разрешение независимо от того, чей компонент виноват, по правилу «без вины: сначала починить, потом делить вину». Это зеркалит внутренние дисциплины ITIL, которые ваша функция управления услугами уже ведёт (см. тему 3.8 — Управление услугами и живая эксплуатация), расширенные через контрактную границу, чтобы цепочка поставок вела себя как одна операционная команда во время кризиса.

6. Сделайте управление контрактом и результативностью активной, подкреплённой доказательствами дисциплиной. Контракт, оставленный в ящике после подписи, — брошенные деньги и рычаг. Проводите структурированные обзоры результативности по SLA, отслеживайте и действительно взыскивайте сервисные кредиты, где они причитаются, ведите общий реестр рисков и проблем и держите аудируемую запись результативности, которая будет важна при продлении или споре. Сервисные кредиты — не цель: они сигнал и рычаг; зрелые отношения используют устойчивую недостаточную результативность, чтобы запустить планы улучшения и в конце концов выход, а не просто чтобы получить небольшую скидку (см. тему 6.4 — Управление и обеспечение гарантий).

7. Пропускайте обязательства по клинической безопасности, защите данных и кибербезопасности до самого низа цепочки. Ваши законные обязанности не заканчиваются на главном поставщике; они должны достигать субподрядчика, хостящего данные, и библиотеки с открытым кодом внутри продукта. Требуйте передачи вниз обязательств клинической безопасности по соответствующим стандартам, условий обработки данных и кибер-контролей, согласованных с руководством NCSC по цепочке поставок, и требуйте видимости четвёртых сторон, чтобы знать, кто на самом деле в цепочке. Явно оценивайте концентрационный риск: если три ваши критичные услуги находятся в одном регионе гиперскейлера или у одного провайдера управляемых услуг, единичный сбой — региональный сбой, а смягчение — решение, которое совет должен принять сознательно (см. тему 3.9 — Непрерывность бизнеса и аварийное восстановление).

8. Планируйте выход, пока вы не отчаялись его совершить. Самое дешёвое время обеспечить свою способность уйти — до подписи; в момент, когда это больше всего нужно, весь рычаг утрачен. Ведите живой план выхода для каждого критичного поставщика, охватывающий извлечение данных в открытых документированных форматах, передачу знаний, обязательства поддержки перехода и активы и лицензии, которые понадобились бы для повторного развёртывания в другом месте. Реальная переносимость доказывается, а не обещается: проверьте, что вы можете экспортировать данные и поднять их где-то ещё, потому что контрактное право на ваши данные в проприетарном дампе — не то же, что способность ими пользоваться (см. тему 4.0 — Техническая архитектура, облако и унаследованные системы, об избегании привязки к поставщику на практике).

Вопросы для обсуждения с командой#

1. Когда инцидент пересекает трёх поставщиков в 2 часа ночи, у кого есть полномочия заставить их всех действовать как одну команду и обязывает ли каждый контракт их отвечать на вызов? Это важно, потому что провал «вращающегося кресла» — не технический пробел, а пробел полномочий: поставщики ведут себя рационально, защищая свой SLA и перекладывая вину, и только назначенный интегратор с контрактной поддержкой может это переломить. Честно обсудите, существует ли такая роль в вашей организации сегодня, есть ли у неё реальные полномочия или она лишь созывает и умоляет и действительно ли ваши контракты провайдеров требуют сотрудничества на общем мосту крупных инцидентов или лишь поощряют его. Подумайте о труднейших случаях — неисправность, охватывающая национальную службу, провайдера хостинга и вендора приложений, где первопричина подлинно неоднозначна первый час. Посмотрите, действует ли у вас правило «сначала восстановить, потом делить» без вины или разрешение застревает, пока коммерческие команды спорят об ответственности. Хороший ответ называет подотчётного интегратора, указывает на статьи контракта, принуждающие к сотрудничеству, и может описать недавний межпоставщиковый инцидент, где модель выдержала, — или откровенно признаёт, что в прошлый раз не выдержала.

2. Потерю каких поставщиков мы подлинно не пережили бы внезапно и что мы на самом деле сделали бы утром, когда они провалились? Это заставляет вести разговор о концентрационном риске, который удобство поставок склонно хоронить: хозяйство накапливает зависимости от нескольких стратегических партнёров и горстки платформ, а совокупная подверженность редко наносится на карту, пока инцидент её не выявит. Обсудите, какие вендоры — единые точки отказа для клинической услуги, контрактная, техническая или основанная на знаниях эта зависимость и как глубоко в цепочку четвёртых сторон уходит реальный риск — субобработчик, офшорная команда поддержки, единственный регион гиперскейлера. Честно взвесьте компромисс: консолидация покупает эффективность, интеграцию и лучшие цены, а диверсификация покупает устойчивость ценой, и верный ответ — сознательный выбор совета, а не случайность прошлых закупок. Подумайте, тестируются ли ваши планы выхода и непрерывности для этих поставщиков или лишь написаны и могли бы вы извлечь и повторно разместить свои данные, если бы поставщик обанкротился на следующей неделе. Честный ответ отличает поставщиков, которыми вы управляете, от немногих, чей провал — экзистенциальное событие, и показывает, что остаточный риск по последним сознательно принят на верном уровне.

3. Измеряем ли мы то, что переживают наши клиницисты и пациенты, или только то, что нашим поставщикам легко отчитать зелёным? Этот вопрос выявляет разрыв между компонентными SLA и реальными результатами, где многоисточниковые услуги тихо разочаровывают, даже когда каждый дашборд зелёный. Изучите, где в вашем хозяйстве прячется «арбузная» отчётность — индивидуально выполненные метрики, складывающиеся в сломанный путь, тикеты, закрытые просьбой к пользователю попробовать снова, доступность, измеренная на сервере, которого не касается ни один клиницист. Обсудите, есть ли у вас настоящие сквозные меры или меры уровня опыта, кому они принадлежат и стимулируются ли поставщики на результат, которого вы хотите, или на прокси, который можно накрутить. Подумайте о напряжении: более богатое измерение на основе опыта стоит денег и усилий и может оспариваться поставщиками, чьи кредиты зависят от старой метрики. Сильный ответ может указать хотя бы на одну сквозную меру, отражающую реальность пользователя, объясняет, как она управляется по поставщикам, и откровенен о том, где нынешние SLA вознаграждают неверное поведение и нуждаются в пересмотре при следующей точке разрыва.

4. Кто должен вести наш слой интеграции — внутренняя команда, внешний поставщик или гибрид — и честны ли мы в конфликте интересов, который создаёт этот выбор? Решение «сделать или купить» для самого интегратора услуг часто принимается по умолчанию, а не осознанно, и формирует каждые последующие отношения. Обсудите реальный компромисс: внутренний интегратор сохраняет знания и контроль внутри сохраняемой организации, но требует дефицитной, дорогой возможности, которую траст может не суметь удержать; внешний интегратор быстро покупает зрелость и инструменты, но добавляет слой для управления и становится остро проблемным, если тот же поставщик ещё и ведёт башню услуг и фактически проверяет собственную домашнюю работу. Подумайте о средних случаях — гибрид, где сохраняемая организация владеет подотчётностью и арбитражем, а партнёр обеспечивает операционную машинерию, — и есть ли у вашей организации коммерческая и техническая старшинность, чтобы направлять интегратора, а не быть им ведомой. Честно посмотрите, где знания об интеграции живут сегодня и что произойдёт с вашим сквозным видом, если контракт этого интегратора закончится. Честный ответ называет, кто интегрирует, объясняет, почему эта модель выбрана для вашего контекста, а не унаследована, и может указать на защитные меры, не дающие интегратору, также поставляющему услуги, оценивать собственную результативность.

5. Достигают ли наши законные обязанности по клинической безопасности, защите данных и кибербезопасности четвёртых сторон глубоко в цепочке или останавливаются на главном поставщике, с которым мы подписали? Это важно, потому что подотчётность за событие безопасности пациентов или утечку данных не следует за контрактом; она остаётся у сохраняемой организации, даже когда сбой произошёл тремя ярусами ниже, у субобработчика или офшорной команды поддержки, которых вы не выбирали. Изучите, реальны и проверены ли ваши статьи передачи вниз — действительно ли обязательства клинической безопасности по соответствующим стандартам, условия обработки данных и кибер-контроли контрактно наложены на субподрядчиков и есть ли у вас хоть какая-то видимость того, кто эти субподрядчики. Обсудите напряжение: главные поставщики сопротивляются раскрытию своей цепочки поставок как коммерчески чувствительной, тогда как вы не можете оценить риск, которого не видите, а требование прозрачности четвёртых сторон может замедлить закупки и сузить рынок. Подумайте о конкретном отказе — библиотека с открытым кодом внутри продукта, субподрядчик хостинга, сторонний аналитический инструмент — и обнаружил ли бы инцидент там ваши обязательства обеспечиваемыми или лишь стремлениями. Сильный ответ показывает, что передача вниз написана, подтверждена доказательствами и время от времени аудируется, а не предполагается, и может назвать, где в цепочке видимость сейчас заканчивается.

6. После подписания контракта кто активно им управляет — взыскивает кредиты, ведёт улучшения и держит поставщиков к ценности, которую мы купили, — а не подшивает в ящик? Определяющая утечка в multi-sourcing происходит после присуждения, когда внимание закупок уходит дальше, а никто не владеет годами эксплуатации, где ценность реализуется или тихо теряется. Обсудите, проводите ли вы структурированные обзоры результативности по SLA, действительно ли отслеживаете и взыскиваете причитающиеся сервисные кредиты и запускает ли устойчивая недостаточная результативность план улучшения или просто поглощается. Подумайте о напряжении: погоня за кредитами может испортить отношения, от которых вы зависите, а зрелый подход рассматривает кредиты как сигнал и рычаг улучшения, а не скидку для получения, — но поставщики быстро узнают, какие клиенты никогда не проверяют. Посмотрите, ведёте ли вы аудируемую запись результативности, которая будет важна при продлении или споре, и является ли непрерывное улучшение контрактным ожиданием или эпизодической любезностью. Честный ответ описывает, кто владеет каждым стратегическим отношением, указывает на недавний случай, где подкреплённое доказательствами управление результативностью изменило поведение поставщика, и откровенно признаёт, где контракты идут без управления, а ценность утекает год за годом.

На практике: пример из здравоохранения и ухода#

Northmoor Integrated Care System ведёт цифровое хозяйство, типичное для своего масштаба: размещённую в хостинге электронную медицинскую карту от одного крупного вендора, платформу общей записи ухода от другого, интеграционный движок и слой интерфейсов от специалиста, национальные службы от NHS England, связь от сетевого провайдера и управляемый сервисный стол, ведомый системным интегратором, чья поддержка первой линии сама передана субподрядчику офшором. Каждый контракт закупался отдельно за десятилетие, у каждого свой SLA, и до недавнего времени каждым управлял другой менеджер в другой дирекции.

Проблема заявляет о себе в понедельник. Клиницисты сообщают, что направления от врачей общей практики приходят в острый траст с отсутствующими вложениями, иногда на часы позже. Вендор EPR сообщает 100% доступности и закрывает тикет. Интеграционный поставщик говорит, что его движок пропускает каждое получаемое сообщение. Вендор общей записи ухода говорит то же. Сетевой провайдер не показывает неисправностей. Каждый поставщик зелёный; путь направлений янтарный, идущий в красный; и никто не владеет стрелкой между ящиками. Девять дней пациенты ждут, пока тикеты отскакивают.

Ответ Northmoor — создать функцию интеграции услуг внутри сохраняемой организации, возглавляемую руководителем по управлению поставщиками и услугами с небольшой командой и, принципиально, полномочиями, вмененными советом. Сначала они сегментируют хозяйство — EPR, общая запись ухода и интеграционный поставщик обозначены как стратегические, сетевой провайдер — как узкое место, перепродавцы лицензий — как массовые — и задают соответствующий ритм управления. Затем они переписывают операционное приложение к каждому стратегическому контракту при следующей статье о разрыве, включая обязанность присоединяться к мосту крупных инцидентов интегратора в течение тридцати минут и делиться диагностическими данными по запросу. Сквозная мера «направление доставлено полным и вовремя» определена и отчитывается наряду с компонентными SLA, принадлежащая интегратору, а не какому-либо одному вендору.

Испытание приходит шесть месяцев спустя, когда сообщения с результатами начинают молча отказывать. На этот раз интегратор объявляет крупный инцидент в течение часа, собирает всех трёх стратегических поставщиков плюс сетевого провайдера на один мост по правилу без вины и ведёт их, чтобы проследить сообщение от начала до конца. Первопричина оказывается в изменении кодировки символов, развёрнутом интеграционным поставщиком, которое EPR не смогла разобрать, — неисправность, жившая именно в шве, которого не видел ни один поставщик. Она исправлена за четыре часа, совместная запись проблемы фиксирует исправление, а сервисный кредит взыскан и реинвестирован в общий набор регрессионных тестов. Между тем ICS тихо замечает, что все три стратегических поставщика размещаются в одном облачном регионе, фиксирует концентрационный риск в board assurance framework и заказывает проверенное упражнение по извлечению данных, чтобы, если когда-нибудь понадобится переехать, переносимость была доказана, а не обещана.

Секторные линзы#

Стартап#

Стартап в цифровом здравоохранении обычно находится по другую сторону этой темы: он — интегрируемый поставщик, и его коммерческое будущее зависит от того, быть ли добрым гражданином в чужой модели SIAM. Выигрыш работы NHS всё чаще означает доказательство, что вы присоединитесь к мосту крупных инцидентов, раскроете своих субобработчиков, пропустите вниз обязательства клинической безопасности и защиты данных и чисто вернёте данные при выходе, так что раннее построение этих возможностей сотрудничества — конкурентное преимущество, а не накладные расходы. Внутри стартап также потребитель критичных третьих сторон — собственного облачного хоста, платёжного процессора и провайдера аутентификации — и несёт реальный концентрационный риск почти без рычага над вендорами, намного крупнее его. Дисциплина, которая масштабируется, — держать карту зависимостей актуальной, избегать архитектурной привязки там, где доступна дешёвая стоимость переключения, и быть честным с клиентами о четвёртых сторонах в вашей собственной цепочке.

Малый бизнес#

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или агентство ухода на дому, клиника на одной площадке — несёт те же законные обязанности по клинической безопасности, защите данных и кибербезопасности, что и крупный траст, но управляет стеком поставщиков без выделенной ИТ-функции и с малым контрактным рычагом. На практике вся дисциплина SIAM схлопывается на одного-двух человек, делающих и другую работу, так что реалистичный ход — определить двух-трёх поставщиков, от которых клинический день по-настоящему зависит, — клиническая система, связь, канал общей записи, — и управлять этими отношениями осознанно, принимая более лёгкое касание для остальных. Концентрационный риск остр и неизбежен: единая система управления практикой или одна широкополосная линия могут быть полной единой точкой отказа, и смягчение часто операционное (процедура простоя, второе соединение), а не второй поставщик. Выход и переносимость здесь так же важны, потому что малый поставщик, привязанный к проприетарной записи, имеет ещё меньше власти двигаться, так что вопросы, на которых стоит настаивать перед поставщиком, — экспорт данных в открытом формате и что произойдёт, если контракт закончится. Небольшой поставщик технологий здравоохранения, перешагнувший стадию стартапа, сталкивается с зеркальным отражением: он должен удовлетворять обязательствам сотрудничества, передачи вниз и выхода, которых теперь требуют его клиенты NHS, без команды комплаенса, которая была бы у более крупного вендора.

Предприятие#

Крупный траст, коллаборатив поставщиков или ICS — архетипичный заказчик SIAM: десятки поставщиков, долгоживущее хозяйство, собранное последовательными закупками, и услуги, чьим сквозным поведением никто полностью не владеет. Реалистичная цель — работающая сохраняемая организация с подлинной возможностью интеграции услуг, сегментация поставщиков, чтобы внимание шло к стратегическому меньшинству, и сквозное управление инцидентами и проблемами, работающее через контрактные границы, — а не фантазия о идеально согласованных SLA. Труднейшая работа контрактная и культурная: дооснащение обязанностей сотрудничества в унаследованные соглашения, как позволяют статьи о разрыве, и смещение поставщиков от защиты своего ящика к владению своей долей целого. В таком масштабе крупнейшие выигрыши устойчивости дают нанесение концентрационного риска на карту по портфелю и тестирование выхода для горстки поставщиков, чей провал был бы региональным событием.

Правительство#

Национальный орган — NHS England, делегированное министерство здравоохранения или оператор рамок, такой как Crown Commercial Service, — формирует среду, в которой каждый траст управляет своими поставщиками. Его рычаг — задавать ожидания через Sourcing Playbook и стандартные условия Government Commercial Function, делать сотрудничество, переносимость и гарантии цепочки поставок рыночным умолчанием, а не тем, о чём каждый покупатель договаривается в одиночку с позиции слабости. Правительство также несёт системный взгляд: оно может видеть, как отдельный траст не может, когда единственный поставщик или платформа стали критичной третьей стороной для всей системы, и должно управлять этой концентрацией как вопросом национальной устойчивости. Его обязанность — обеспечить, чтобы дизайн рамок, режимы гарантий и национальные службы сокращали привязку и единые точки отказа, а не закрепляли их (см. тему 9.1 — Работа с местными и национальными правительствами).

Типичные виды отказов#

• Вакуум подотчётности. Каждый поставщик владеет компонентом, и никто — сквозной услугой, так что межграничным проблемам нет дома. Назовите подотчётного интегратора с реальными полномочиями.
• Инцидент «вращающегося кресла». Поставщики перекладывают вину, пока услуга лежит, и никто не уполномочен заставить их сотрудничать. Вмените единый мост крупных инцидентов и правило «сначала восстановить» без вины в каждом контракте.
• «Арбузные» SLA. Каждая компонентная метрика зелёная, пока реальная услуга красная; поставщики отчитываются по метрике, а не результату. Добавьте сквозные меры и меры уровня опыта, которыми владеет интегратор.
• Единообразное управление. Обращение с массовым перепродавцом и стратегическим партнёром EPR одинаково тратит усилия впустую и обделяет важные отношения. Сегментируйте поставщиков и сопоставляйте ритм управления с критичностью.
• Контракт в ящике. После подписи никто не управляет результативностью, не взыскивает кредиты и не ведёт улучшения, так что ценность утекает год за годом. Ведите активное, подкреплённое доказательствами управление контрактом.
• Невидимые четвёртые стороны. Обязательства передаются главному поставщику и на нём останавливаются, оставляя неизвестных субподрядчиков, хранящих данные или риск. Требуйте видимости цепочки поставок и передавайте контроли до самого низа.
• Неуправляемая концентрация. Критичные услуги тихо консолидируются на одном поставщике, платформе или регионе, пока единичный сбой не становится системным. Наносите на карту и сознательно принимайте концентрационный риск на уровне совета.
• Теоретический выход. Контрактное право на ваши данные, никогда не проверенное, — не переносимость. Докажите извлечение данных и повторное размещение до того, как они понадобятся.

Модель зрелости#

Контрольный список#

• Названная роль в сохраняемой организации подотчётна за сквозную услугу и держит сквозной SLA.
• Модель SIAM — интегратор, башни, сквозные процессы — определена и вписана в контракты поставщиков.
• Поставщики сегментированы по критичности, с ритмом управления, соответствующим каждому сегменту.
• Сквозные меры и меры уровня опыта дополняют компонентные SLA и принадлежат интегратору.
• Существует единый межпоставщиковый процесс крупных инцидентов, с контрактно вменённым правилом «сначала восстановить» без вины.
• Результативность по контрактам активно пересматривается, сервисные кредиты отслеживаются и взыскиваются, планы улучшения запускаются.
• Обязательства по клинической безопасности, защите данных и кибербезопасности переданы субподрядчикам, с видимостью четвёртых сторон.
• Концентрационный риск по поставщикам, платформам и регионам нанесён на карту и сознательно принят на уровне совета.
• Для каждого критичного поставщика есть живой план выхода, охватывающий данные, знания и поддержку перехода.
• Извлечение данных и повторное размещение для критичных услуг проверены, а не только контрактно обещаны.

Ключевые источники#

• Scopism — SIAM Body of Knowledge и SIAM Professional Body of Knowledge — окончательный открытый справочник по ролям, структурам и процессам интеграции и управления услугами.
• AXELOS — ITIL 4 — практики управления ИТ-услугами по инцидентам, проблемам, изменениям и управлению поставщиками, которые SIAM расширяет на поставщиков.
• UK Government Commercial Function — The Sourcing Playbook и Outsourcing Playbook — руководство государственного сектора по поставкам, управлению контрактами и выходу.
• Crown Commercial Service — рамочные соглашения и стандартные условия для закупок технологий и управляемых услуг в государственном секторе.
• National Cyber Security Centre (NCSC) — Supply chain security guidance — оценка и управление кибер-риском по поставщикам и субподрядчикам.
• HM Government / Cabinet Office — руководство по управлению критичными третьими сторонами и концентрационным риском в государственных услугах.
• NHS England — стандарты клинической безопасности DCB0129/DCB0160 и требования к обработке данных, передаваемые вниз поставщикам.

Литература#

1. Service integration and management — Wikipedia — https://en.wikipedia.org/wiki/Service_integration_and_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
4. Outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Outsourcing
5. Business process outsourcing — Wikipedia — https://en.wikipedia.org/wiki/Business_process_outsourcing
6. Managed services — Wikipedia — https://en.wikipedia.org/wiki/Managed_services
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Third-party management — Wikipedia — https://en.wikipedia.org/wiki/Third-party_management
9. Supply chain — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain
10. Supply chain risk management — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_risk_management
11. Concentration risk — Wikipedia — https://en.wikipedia.org/wiki/Concentration_risk
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Continual improvement process — Wikipedia — https://en.wikipedia.org/wiki/Continual_improvement_process
14. Kraljic matrix — Wikipedia — https://en.wikipedia.org/wiki/Kraljic_matrix
15. Scopism — SIAM Body of Knowledge — https://www.scopism.com/
16. AXELOS — ITIL 4 — https://www.axelos.com/certifications/itil-service-management
17. UK Government Commercial Function — The Sourcing Playbook — GOV.UK — https://www.gov.uk/government/publications/the-sourcing-playbook
18. National Cyber Security Centre — Supply chain security guidance — NCSC — https://www.ncsc.gov.uk/collection/supply-chain-security
19. Crown Commercial Service — GOV.UK — https://www.gov.uk/government/organisations/crown-commercial-service