Как обосновать и спланировать закупку услуг для корпоративного проекта: пошаговый алгоритм

Любая закупка услуг в корпоративном проекте начинается не с поиска подрядчика, а с ответа на вопрос: «Почему мы не можем сделать это своими силами и действительно ли нам это нужно?». Пропуск этого этапа приводит к раздутым бюджетам, несовпадению ожиданий и конфликтам на стадии приёмки. Материал ниже — алгоритм, как структурированно пройти от идеи «нужно нанять кого-то» до утверждённого технического задания и бизнес-кейса, которым не стыдно показать финансовому директору.

Зачем нужен формальный процесс определения потребности

В зрелых организациях закупка услуг проходит через стадию инициирования потребности (demand identification). Это не бюрократия, а фильтр, который отсекает:

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

Результатом этапа должен стать документ — Обоснование потребности в закупке (Procurement Justification / Business Need Document). В простейшем случае это страница в Confluence или раздел в проектном чартере. Без него закупка не попадает в план-закупки и не получает бюджетный код.

Этап 1. Сбор и структурировка требований

Начните с вопроса: какой бизнес-результат мы ожидаем получить? Не «нужен разработчик», а «нужно запустить интеграцию с CRM к 1 ноября, чтобы продажи видели лиды в реальном времени». Разница в детализации определяет, купите вы услугу или нанятете стажера.

Источники требований

• Проектный чартер / бизнес-кейс проекта — цели, KPI, ограничения по срокам и бюджету.
• Интервью со стейкхолдерами — продуктовый владелец, технический лидер, безопасность, юристы, финансы, будущие пользователи сервиса.
• Текущая архитектура и каталог сервисов — какие API, платформы, контракты уже есть в компании.
• Реестр рисков проекта — что может пойти не так, если услуга не будет закуплена вовремя или будет выполнена плохо.

Чек-лист минимального набора атрибутов требования к услуге

Атрибут	Что проверить	Почему это важно
Наименование услуги	Краткое, понятное бизнес-описание (не техническое)	Единое понимание заказчиком, закупщиком и юристами
Ожидаемый результат (deliverable)	Что именно передаётся: отчёт, код, настроенный стенд, обученная модель, отчёт об аудите	Основа критериев приёмки и ТЗ
Критерии приёмки (acceptance criteria)	Измеримые параметры: SLA, точность модели, время отклика, покрытие тестами	Защита от споров при сдаче
Сроки: старт, промежуточные точки, дедлайн	Жёсткие даты vs желательные, зависимости от других этапов проекта	Планирование закупки и штрафные санкции
Ограничения и зависимости	Доступы, сертификаты, работа в контуре заказчика, используемые стеки, GDPR/152-ФЗ	Отсечение нерелевантных поставщиков на ранней стадии
Приоритет (MoSCoW)	Must / Should / Could / Won’t	Управление скоупом при дефиците бюджета или сроков

Совет: зафиксируйте требования в виде User Stories с приёмочными критериями или в формате ТЗ-лайт (1–2 страницы). Полноценное ТЗ пишется позже, часто вместе с потенциальным поставщиком на стадии предварительных переговоров (RFI), но каркас должен быть сейчас.

Этап 2. Анализ Make-or-Buy: свои силы или рынок

Это ключевое решениe. Не принимайте его интуитивно — используйте структурированную матрицу.

Критерии оценки

• Страгическая значимость — является ли компетенция ядром бизнеса или поддерживающей функцией? Ядро держать внутри, поддержку — выносить.
• Наличие и загрузка внутренних ресурсов — есть ли люди с нужным скиллом, свободны ли они в нужные даты, какова альтернативная стоимость их времени (opportunity cost).
• Скорость мобилзации — внутренний перевод занимает 2–4 недели (HR, доступы, онбординг), подрядчик может стартовать за 3–5 дней после подписания договора.
• Требуемый уровень экспертизы — разовая задача высокой сложности (например, аудит ИБ, миграция на Kubernetes, внедрение ML) дешевле купить у специализированной команды, чем растить эксперта.
• Риски ключевого человека — если внутренний сотрудник уволится посередине, проект встанет. У подрядчика есть замена по контракту.
• Повторяемость и масштабируемость — если услуга нужна регулярно (поддержка, мониторинг, аутстаффинг), выгоднее построить внутренний процесс или долгосрочный рамковый договор.
• Требования к конфиденциальности / регуляторике — некоторые данные не могут выходить за контур компании (гостайна, ПДн критической инфраструктуры). Это жесткое ограничение на аутсорс.
• Совокупная стоимость владения (TCO) — не только часовая ставка, но и накладные расходы: управление, контроль качества, коммуникации, правовое сопровождение, налоги.

Практический тест: «Тест на 3 вопроса»

1. Можем ли мы сделать это сами за те же сроки и с тем же качеством, не жертвуя критическими внутренними проектами?
2. Будет ли стоимость внутреннего выполнения (с учётом накладных) ниже рыночной цены плюс 20–30% на управление подрядчиком?
3. Есть ли у нас компетенция оценить качество результата без внешнего эксперта?

Если на все три ответа «нет» — закупка обоснована. Если хотя бы на один «да» — углубите анализ.

Этап 3. Оценка объёма и стоимости (Rough Order of Magnitude)

На стадии обоснования нужна оценка «по порядку величины» (ROM, ±30–50%). Она нужна для:

• получения бюджетного одобрения;
• понимания, подходит ли закупка под упрощённые процедуры (до определенного порога — часто 1–3 млн руб. в зависимости от регламента компании);
• формирования лотов при закупке.

Методы оценки без рынка

• Аналогия — сколько стоили похожие закупки в компании за последние 12–18 месяцев. Корректируйте на инфляцию и сложность.
• Экспертная оценка внутренних архитекторов / техлидов — в человеко-днях, переведённых в ставку рынка.
• Параметрическая модель — для типовых услуг: «аудит ИБ = N систем × M дней», «разработка микросервиса = K сторипоинтов × ставка».
• RFI (Request for Information) — неформальный запрос к 3–5 потенциальным поставщикам: «Примерная стоимость и сроки для такого скоупа». Не является офертой, но даёт реалистичную вилку.

Важно: в оценку включите скрытые затраты заказчика — время ПМ на управление, время архитекторов на ревью, время юристов на договор, время безопасности на аудит поставщика, коммуникационные накладные расходы (обычно 15–25% от стоимости контракта).

Этап 4. Работа со стейкхолдерами и получение мандата

Обоснование потребности — это документ для согласования. Минимальный набор согласующих:

• Спонсор проекта / Продуктовый владелец — подтверждает бизнес-необходимость и приоритет.
• Технический директор / Главный архитектор — подтверждает архитектурную приемлемость, безопасность, отсутствие дублей.
• Финансы / Контроллер — подтверждает наличие бюджета, корректность кода статьи затрат, соответствие лимитам.
• Юридический / Комплаенс — предварительная оценка рисков договора, требований к данным, субъекта закупки (ИП / ООО / физлицо).
• Информационная безопасность — если услуга затрагивает инфраструктуру или данные.
• Закупки (Procurement) — подтверждает, что закупка попадает в план, определяет процедуру (конкурс, аукцион, единственный источник, запрос котировок).

Совет: собирайте согласование параллельно, а не последовательно. Используйте единый документ с комментариями и дедлайном отзыва (обычно 3–5 рабочих дней). Если стейкхолдер молчит — считается согласовано (при условии, что это зафиксировано в регламенте).

Этап 5. Оценка рисков закупки и план митигации

Риски закупки услуг отличаются от рисков закупки товаров: результат неосязаем, качество субъективно, сроки часто сдвигаются из-за неясного скоупа.

ТЗ содержит фразы «и т.д.», «по согласованию сторон», «оптимизация» без метрик

Предложение строится на имени конкретного эксперта

Поставщик не имеет сертификата ISO 27001, не проходит аудит СБ

Результат привязан к закрытой платформе, нет экспорта данных

Поставщик ждёт доступы, данные, согласования более 20% времени

Цена контракта не включает настройку окружения, обучение, поддержку после приёмки

Риск	Индикатор / Триггер	Меры митигации на стадии обоснования
Размытый скоуп (scope creep)	Зафиксировать в обосновании: «Скоуп зафиксирован в приложении А. Любые изменения — через Change Request с пересчётом стоимости и сроков»
Зависимость от ключевых сотрудников поставщика	Требовать в контракте: замена равнозначного специалиста за 5 дней, штраф за простой, передача знаний (knowledge transfer) в составе доставки
Несоответствие уровню безопасности / комплаенсу	Включить в критерии отбора поставщика (PQQ) обязательные требования к сертификатам, политикам, страхованию ответственности
Вендор-локин / проприетарные форматы	Прописать в ТЗ: открытые форматы, доступ к исходникам, документация, права ИП на результаты
Срыв сроков из-за зависимостей от заказчика	В контракте: календарный план с обязанностями заказчика (RACI), штрафы за простой исполнителя по вине заказчика, эсклация
Скрытые затраты на интеграцию / сопровождение	В ROM заложить 15–25% на «внутренние затраты», в ТЗ вынести пост-проектную поддержку отдельным лотом или опцией

Этап 6. Выбор стратегии закупки и формирование лотов

От стратегии зависит сроки, конкуренция и качество предложений.

Типовые стратегии для услуг

• Единый лот (Turnkey) — одна компания «под ключ». Плюс: единая ответственность, простое управление. Минус: выше цена, риск вендор-локина, сложнее найти компетенцию по всему стеку.
• Разбивка по функциональным лотам — отдельно дизайн, отдельно бэкенд, отдельно тестирование, отдельно ПМ. Плюс: лучшие эксперты в каждом, конкуренция. Минус: интеграционные риски, накладные расходы на управление множеством договоров, «перекладывание вины».
• Рамковое соглашение / Динамическая закупка — для повторяющихся услуг (аутстаффинг, поддержка, аудиты). Один конкурс — потом заказ-наряды. Плюс: скорость повторных закупок, фиксированные ставки. Минус: нужно точно описать каталог услуг и единицы измерения.
• Двухэтапная: RFI → RFP — сначала уточняем рынок и ТЗ с 3–5 игроками (неофициально), потом официальный конкурс. Плюс: реалистичное ТЗ, меньше уточнений на аукционе. Минус: +2–3 недели к срокам.

Критерии отбора поставщика (PQQ — Pre-Qualification Questionnaire)

Включите в обоснование минимальный набор требований к участнику:

• Юридическое лицо / ИП с опытом не менее N лет.
• Кейсы: минимум 3 проекта сопоставимой сложности за последние 2 года (с контактами заказчиков для референсов).
• Наличие штатных сотрудников с нужными сертификатами (не только фрилансеры).
• Финансовая устойчивость: нет банкротства, налоговой задолженности, выручка > 3× от ожидаемого контракта.
• Политика ИБ, обработки ПДн, страхование профессиональной ответственности (Professional Indemnity) от N млн руб.
• Готовность подписать NDA и DPA (Data Processing Agreement) до начала работ.

Этап 7. Формирование пакета документации для запуска закупки

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

1. Обоснование потребности (этот документ).
2. Техническое задание / ТЗ-лайт с приёмо-сдаточными критериями.
3. Проектный план закупки: даты публикации, приёма заявок, оценки, подписания договора, старта работ.
4. Критерии оценки предложений (если не аукцион по цене): техническая часть (вес 60–70%), цена (30–40%), дополнительные критерии (сроки, методология, команда).
5. Проект договора (типовый шаблон компании с заполненными приложениями: ТЗ, календарный план, SLA, штрафы, права ИП, конфиденциальность, порядок сдачи-приёмки, условия расторжения).
6. Бюджетное заявление с кодом статьи затрат и распределением по кварталам/месяцам.

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

Типичные ошибки и как их избежать

Обязательный шаг: проверка каталога внутренних сервисов, опрос архитекторов, поиск в реестре компетенций

ИБ и юристы — обязательные согласующие на этапе обоснования, а не после победы поставщика

Если скоуп неясен — используйте Time & Materials с потолком (Cap) или поэтапную фиксацию: Discovery (фикс) → Delivery (фикс по итогам Discovery)

В контракте: формат передачи артефактов, сроки передачи, обязанность поставщика оказать содействие при переходе к другому исполнителю

Ошибка	Последствие	Правильная практика
Закупка «ресурса» (человека) вместо результата	Оплачивается присутствие, а не исход; нет критериев качества; сложно заменить исполнителя	Формулируйте закупку как услугу с deliverable: «Разработка модуля X по ТЗ», а не «Java-разработчик на 3 месяца»
Отсутствие критериев приёмки	Бесконечные правки, споры при сдаче, невозможность применить штрафы	Приёмо-сдаточные критерии (Acceptance Criteria) — обязательный раздел ТЗ. Каждый критерий измерим и проверяем автоматически или экспертно
Игнорирование внутренних альтернатив	Дублирование, недовольство внутренних команд, потеря навыков
Закупка без участия ИБ и юристов на ранней стадии	Отказ в доступе к данным, переработка договора на 2–3 недели, риск утечки
Фиксированная цена при нефиксированном скоупе	Поставщик закладывает риски в цену ×2–3 или делает минимально допустимое качество
Отсутствие плана выхода (Exit Strategy)	Невозможно уйти от поставщика без потери данных и знаний

Сценарии: как действовать в типичных ситуациях

Сценарий А: «Нужно вчера, скоуп размыт, бюджет есть»

Действуйте через RFI + поэтапный контракт. Неделя 1: RFI к 3–5 проверенным поставщикам с описанием проблемы (не решения). Неделя 2: совместные сессии по уточнению скоупа (Discovery). Неделя 3: фиксированное ТЗ и цена на первый этап (MVP). Подписываете договор на этап 1 с опцией на этап 2. Риск цены выше, но скорость старта максимальна.

Сценарий Б: «Регулярная потребность: аудит, поддержка, аутстаффинг»

Проводите разовый конкурс на рамковое соглашение на 12–24 месяца. Опишите каталог услуг (Service Catalog) с единицами измерения (чел-день, аудит одного приложения, инцидент 1-й линии). Фиксируйте ставки, SLA, процедуру заказ-нарядов. Экономит месяцы на повторных закупках.

Сценарий В: «Уникальная экспертиза, на рынке 1–2 игрока»

Обоснуйте закупку у единственного источника (согласно 44-ФЗ / 223-ФЗ / корпоративному регламенту). Понадобится: обоснование уникальности, письма от других игроков об отказе / невозможности, заключение эксперта. Подготовьтесь к аудиту — это самая проверяемая процедура.

Сценарий Г: «Внутренняя команда может, но загружена на 120%»

Сравните стоимость отсрочки внутреннего проекта (упущенная выгода, штрафы, репутация) vs стоимость аутсорса. Если отсрочка критична — закупаете «ускорение»: подрядчик делает рутину (вёрстка, тесты, документация), внутренняя команда — архитектуру и сложную логику. Пропишите в ТЗ зоны ответственности и точки интеграции.

Практический чек-лист: готово ли обоснование к согласованию

• [ ] Бизнес-цель и ожидаемый результат сформулированы на языке бизнеса (не IT).
• [ ] Собраны требования от всех ключевых стейкхолдеров, приоритеты расставлены (MoSCoW).
• [ ] Проведена проверка внутренних альтернатив — результат зафиксирован.
• [ ] Пройден Make-or-Buy анализ с заполненной матрицей критериев.
• [ ] Получена ROM-оценка стоимости (+/- 30%) с разбивкой: контракт + внутренние затраты.
• [ ] Определена стратегия закупки (лоты, процедура, сроки).
• [ ] Составлен реестр рисков закупки с митигациями.
• [ ] Подготовлен проект ТЗ / ТЗ-лайт с приёмо-сдаточными критериями.
• [ ] Сформирован проект договора с ключевыми условиями (ИП, конфиденциальность, SLA, штрафы, выход).
• [ ] Определены критерии отбора поставщика (PQQ) и критерии оценки предложений.
• [ ] Получены предварительные согласования ИБ, юристов, финансов, архитектуры.
• [ ] Документ оформлен по корпоративному шаблону, версияция и история изменений ведётся.

Следующие шаги после согласования

После подписания обоснования всеми стейкхолдерами:

1. Передайте пакет в отдел закупок с заявленным сроком «Дата старта работ».
2. Назначьте ответственного за приёмку (Technical Owner / Product Owner) — лицо, которое будет подписывать акты и управлять скоупом.
3. Согласуйте с закупками график процедуры и зафиксируйте его в проектном плане как внешнюю зависимость.
4. Подготовьте пакет для кик-оффа с поставщиком: доступы, репозитории, контакты, архитектурные диаграммы, стандарты кодирования / безопасности — чтобы не терять время после подписания договора.
5. Настройте еженедельный статус с поставщиком и ежемесячный steering committee со стейкхолдерами.

Материал носит информационный характер и отражает общие практики управления закупками в корпоративных проектах. Конкретные пороги сумм, обязательные процедуры, требования к документам и порядок согласований определяются внутренними регламентами вашей организации, отраслевыми стандартами и действующим законодательством (44-ФЗ, 223-ФЗ, ГК РФ и др.). Перед запуском закупки сверьтесь с актуальными локальными нормами и проконсультируйтесь с юридическим и закупочным департаментами.

Качественное обоснование потребности — это не бумага для отчёта, а инструмент управления ожиданиями и рисками. Инвестиция 2–3 дня аналитика на этом этапе экономит недели переделок и миллионы рублей на этапе исполнения. Начните с бизнес-результата, зафиксируйте критерии приёмки и не бойтесь сказать «нет» закупке, если внутренний ресурс может справиться быстрее и дешевле.