Как определить объём услуг при передаче функции подрядчику

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

Почему важен точный объём услуг

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

• формирования цены и графика платежей;
• определения показателей эффективности (KPI) и штрафов за невыполнение;
• минимизации споров о том, что входит в работу, а что — нет;

планирования внутренних ресурсов заказчика (кого привлекать для взаимодействия, какие данные предоставлять).

Если объём описан расплывчато, подрядчик может интерпретировать его в свою пользу, а заказчик — получить неполный или избыточный набор услуг.

Этап 1: Сформулировать бизнес‑цель передачи функции

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

• снижение операционных расходов;
• доступ к специализированным компетенциям, которых нет внутри компании;
• повышение гибкости (возможность быстро масштабировать услугу);
• фокус внутренних ресурсов на core‑деятельность.

Чётко записанная цель помогает позже отсечь те действия, которые не влияют на её достижение.

Этап 2: Выделить границы функции

Функция — это набор взаимосвязанных действий, которые вместе дают определённый результат. Чтобы определить её границы, задайте себе вопросы:

• Какой входной материал или информация поступает в функцию?
• Какие преобразования выполняются над этим входом?
• Какой конечный продукт, услуга или результат выдаётся на выходе?
• Какие взаимодействия с другими подразделениями или системами необходимы?

Ответы позволят нарисовать «карту» функции и увидеть, где она начинается и заканчивается.

Этап 3: Разбить функцию на логические блоки (work packages)

Полученную карту следует декомпозировать наmanageable части. Каждый блок должен соответствовать одному из следующих критериев:

• имеет чёткий вход и выход;
• может быть оценён по времени, стоимости или ресурсам;
• логически завершён (не зависит от выполнения другого блока, кроме как через определённые handoff‑точки).

Пример: при передаче функции «поддержка ИТ‑инфраструктуры» блоки могут выглядеть так:

1. Мониторинг состояния оборудования и сетей;
2. Обработка инцидентов первого уровня;
3. Выполнение плановых профилактических работ;
4. Управление изменениями и релизами;
5. Отчётность и анализ показателей доступности.

Каждый блок далее описывается отдельно.

Этап 4: Определить результаты и измеримые показатели для каждого блока

Для заказчика важен не только процесс, но и то, что он получит в конце. На этом шаге формулируются:

• конкретные deliverables (документы, отчёты, настроенные системы, выполненные задачи);
• критерии приемки (какие свойства должны иметь deliverables, например, время восстановления после инцидента ≤ 30 мин);
• уровни сервиса (SLA) — время ответа, время решения, процент доступности и т.д.;
• частоту предоставления результатов (ежедневно, еженедельно, по событию).

Измеримость позволяет объективно контролировать исполнение и применять штрафы или бонусы.

Этап 5: Указать предположения, ограничения и исключения

Чтобы избежать споров о том, что «входит» в услугу, в описании объёма необходимо прописать:

• предположения о входных данных (например, заказчик предоставляет доступ к системе мониторинга в течение 2 часов после запроса);
• ограничения по географии, времени работы, объёму обращений;
• исключения — действия, которые явно не выполняются подрядчиком (например, закупка нового оборудования, разработка кастомного ПО без отдельного согласования).

Эти пункты защищают обе стороны от неожиданных расходов и недоразумений.

Этап 6: Согласовать формат и частоту взаимодействия

Объём услуг включает не только то, что делает подрядчик, но и как он взаимодействует с заказчиком. Нужно определить:

• каналы связи (email, портал, телефон, мессенджер);
• роли и ответственные лица с обеих сторон (менеджер проекта, технический эксперт, служба поддержки);
• регулярность совещаний и отчётов (еженедельный статус, ежемесячный KPI‑дайджест);
• процедуры эскалации при возникновении проблем.

Чётко прописанное взаимодействие снижает задержки и повышает прозрачность.

Этап 7: Документировать всё в едином источнике

Итоговый объём услуг фиксируется в разделе «Предмет договора» или «Техническое задание». Рекомендуемая структура:

1. Введение — ссылка на бизнес‑цель передачи функции;
2. Общее описание функции и её границ;
3. Перечень work packages с кратким содержанием;
4. Для каждого блока: входы, выходы, deliverables, KPI/SLA, предположения, ограничения;
5. График предоставления результатов и отчётности;
6. Порядок взаимодействия и эскалации;
7. Процедура изменения объёма (change control).

Такой документ служит базой для контроля исполнения и внесения корректировок.

Типичные ошибки при определении объёма услуг

Осознание распространённых промахов помогает их избежать.

1. Слишком высокий уровень абстракции

Фразы вроде «обеспечить бесперебойную работу ИТ» не дают критериев приемки. Нужно разбить на конкретные измеримые действия.

2. Отсутствие исключений

Если не указать, что подрядчик не отвечает за обучение конечных пользователей, позже могут возникнуть претензии по поводу недостаточной подготовки персонала.

3. Неучет входных данных

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

4. Отсутствие процедуры изменения объёма

Бизнес меняется, и без чёткого механизма внесения правок любые корректировки ведут к спорам и простою.

5. Перегрузка деталями

Слишкомgranularный список задач делает документ непрактичным и затрудняет контроль. Лучше сосредоточиться на результатах и уровнях сервиса.

Практический чек‑лист для заказчика

Перед финальным утверждением объёма услуг пройдитесь по следующему списку:

• Бизнес‑цель передачи функции сформулирована и записана?
• Границы функции определены (входы, преобразования, выходы)?
• Функция разбита на логические блоки с чёткими входами/выходами?
• Для каждого блока указаны deliverables, критерии приемки и уровни сервиса?
• Прописаны предположения о предоставляемых заказчиком ресурсах и ограничения подрядчика?
• Оговорены исключения — что точно не входит в объём?
• Определены каналы связи, ответственные лица и частота взаимодействия?
• Включена процедура внесения изменений в объём услуг?
• Документ написан понятным языком, без жаргона, который может быть истолкован по‑разному?

Если хотя бы один пункт вызывает сомнения — вернитесь к соответствующему этапу и уточните детали.

Что делать дальше

После того как объём услуг согласован и закреплён в договоре:

1. Организуйте kick‑in‑встречу с подрядчиком, где каждый блок будет разъяснён и подтверждён;
2. Настройте систему мониторинга KPI (дашборд, автоматические отчёты);
3. Запланируйте первые контрольные точки (например, после первого месяца) для сверки фактического исполнения с заявленным объёмом;
4. При возникновении вопросов используйте процедуру изменения объёма, а не неформальные договорённости.

Таким образом, чётко определённый объём услуг становится не просто формальным разделом договора, а рабочим инструментом управления отношениями с подрядчиком.