Supplier Management: управление поставщиками и подрядчиками ИТ

Зачем отдельная практика

Без управления поставщиками типичная картина: договоры лежат у юристов, контакты подрядчика — в личной переписке одного сотрудника, а когда провайдер лёг, оператор не знает, куда звонить и что обещано в договоре. Supplier Management закрывает это:

• единый реестр поставщиков с контактами, договорами, обязательствами;
• привязка поставщиков к услугам (какой вендор за что отвечает);
• контроль исполнения их обязательств (UC — underpinning contracts);
• понятный путь эскалации к внешней стороне прямо из инцидента.

Это прямое продолжение Service Level Management: ваш SLA перед бизнесом обеспечивается цепочкой OLA (внутренние команды) и UC (поставщики). Слабое звено в этой цепочке рушит весь SLA.

Категоризация поставщиков

Не все вендоры одинаково важны — управлять ими нужно по-разному. Классическая матрица по влиянию на бизнес и стоимости:

• Стратегические — критичны для бизнеса, тесная интеграция (например, провайдер связи для колл-центра, вендор основной АБС). Регулярные ревью, совместное планирование.
• Тактические — значимы, но заменяемы; среднее взаимодействие. Контроль по SLA, периодические встречи.
• Операционные — рутинные поставки (расходники, мелкий софт). Управление по факту.
• Товарные (commodity) — легко заменяемы, низкий риск.

Смысл: тратить силы на управление пропорционально риску. На стратегического поставщика — QBR (квартальные ревью) и план развития; на товарного — просто реестр и контроль счетов.

Контракты (UC) и контроль SLA подрядчика

С каждым значимым поставщиком должен быть UC (underpinning contract) с измеримыми обязательствами, и эти обязательства должны быть совместимы с вашим SLA перед бизнесом:

SLA бизнесу: восстановить сервис за 4ч
  └─ UC с хостером: замена сервера за 3ч  ← должно укладываться
  └─ UC с провайдером: канал за 2ч

Если UC подрядчика допускает 8 часов, а вы обещали бизнесу 4 — вы заложили гарантированное нарушение (см. разбор SLA). Контроль исполнения UC — это не «доверяем на слово»: фиксируйте фактические времена реакции подрядчика в инцидентах. Через квартал у вас будет статистика «обещал 3ч — по факту в среднем 5ч», и это аргумент для пересмотра договора или смены вендора.

Эскалация к поставщику из инцидента

Когда корень инцидента — на стороне вендора, оператор не должен искать телефон в чужой переписке. Зрелый процесс встраивает поставщика в эскалацию:

• в карточке услуги/CI указан ответственный поставщик и канал обращения к нему;
• при эскалации «к вендору» инцидент помечается соответствующим статусом, а часы вашего внутреннего SLA логируются отдельно от ожидания подрядчика;
• фиксируется номер обращения у вендора (для сверки с их SLA);
• ответственность за инцидент остаётся на вас (вы — единая точка для пользователя), даже пока чинит подрядчик.

Важный нюанс учёта: время ожидания ответа поставщика стоит выделять, чтобы честно понимать, где теряется SLA — у вас или у вендора. Это и материал для разговора с поставщиком, и защита команды от обвинений в чужих просрочках.

Реестр поставщиков и регулярные ревью

Минимальный артефакт практики — реестр поставщиков: кто, за какие услуги отвечает, контакты, реквизиты договора и UC, ключевые обязательства, даты окончания договоров. Без него знания о вендоре живут в голове одного человека (и уходят с ним).

Для стратегических и тактических поставщиков — регулярные ревью (QBR): разбор статистики инцидентов с их участием, соблюдение UC, планы. Это превращает отношения из «реактивных по сбоям» в управляемые. Сигналы для пересмотра: систематические нарушения UC, рост числа инцидентов по зоне вендора, приближение окончания договора (импортозамещение — частый триггер: иностранный вендор уходит, нужен план Б заранее).

Для российских реалий Supplier Management особенно актуален: санкционные риски делают зависимость от единственного зарубежного поставщика отдельной угрозой непрерывности (см. ITSCM), а переход на отечественные решения требует управляемой замены вендоров.