Управление поставщиками

Записаться

Управление поставщиками

Управление поставщиками — последний рассматриваемый процесс. В нём нет ничего специфического именно для ИТ-услуг или ИТ-ресурсов. Это обычный процесс управления поставщиками услуг и ресурсов, который применяется в любой организации, если у неё есть поставщики.

Общая логика

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

Стратегия сорсинга

Кто и когда решает, что для услуги будут использовать поставщиков? Ответ: это определяется стратегией сорсинга (sourcing strategy) — компонентом бизнес-стратегии. Она описывает, какие задачи организация решает самостоятельно, какие всегда передаёт поставщикам, а какие — в зависимости от ситуации. Для каждой услуги стратегия сорсинга показывает, какие виды деятельности зарезервированы для поставщиков. Тогда начинается поиск поставщика.

Все активности и процессы управления поставщиками должны возникать из стратегии сорсинга. Она определяет:

• какие работы выполняют поставщики;
• как искать поставщиков;
• какие контракты заключать;
• как контролировать качество работ;
• как действовать при нарушении контрактных обязательств.

Это позволяет не решать заново каждый конкретный случай.

Роли и взаимодействие

На схеме поставщики 1–6 поставляют услуги. С ними работают менеджеры по поставщикам (supplier managers). Они взаимодействуют с менеджером по контрактам (contract manager) — по сути юристом, который контролирует соблюдение стратегии сорсинга, нормативных требований и подходов к управлению поставщиками. Все вместе они взаимодействуют с владельцем процесса (process owner) управления поставщиками.

Менеджеры по поставщикам работают с контрактами. Конкретные методы их работы могут различаться, но важно общее управление. Они подчиняются ограничениям от менеджера по контрактам. Менеджер по контрактам, в свою очередь, следует правилам финансов, закупок и юридическим требованиям организации.

Активности и политика

Среди активностей процесса — соблюдение корпоративной политики работы с поставщиками и поддержка системы управления контрактами. Корпоративная политика описывает требования к поставщикам, процесс выбора, контроль, составление договора, согласование, утверждение и подписание. Но не всё ясно: как применять политику к простым контрактам? Разумный подход — упрощать стандартные действия, если контракт не сложный, не важный и не на большую сумму. Это и есть соблюдение корпоративной политики.

Поддержка системы управления контрактами с поставщиками тоже неоднозначна: если это организационная система, кто её поддерживает? Если информационная, то почему это в процессе управления поставщиками? Возможно, речь об ИТ-услуге, которая обрабатывает инциденты или проблемы, связанные с поставщиками.

Предконтрактная оценка рисков должна учитывать финансовые, репутационные и операционные риски. Сама схема процесса прямолинейна:

1. Стратегии и политики работы с поставщиками.
2. Определение нового поставщика и требований к контракту.
3. Оценка новых поставщиков и контрактов.
4. Выбор поставщиков и контрактов.
5. Управление поставщиками и производительностью контрактов.
6. Обновление или завершение контрактов.

Всё это связано с информационной системой управления поставщиками и контрактами, но её роль и устройство не раскрыты.

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

Полезный элемент, хотя он заимствован из классических руководств, а не создан специально для ITIL 2011. Поставщиков делят по двум параметрам:

• риск, связанный с поставщиком, и его влияние на бизнес;
• ценность и важность поставщика для бизнеса.

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

В ITIL 2011 по этим категориям можно было бы дать рекомендации по SLA (Service Level Agreement, соглашение об уровне услуг), UC (Underpinning Contract, поддерживающий контракт) и другим контрактам. Но кроме общих слов и повторения самой категоризации там мало конкретики.

Краткие итоги

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

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

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

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