Обследовать закупки или проектировать систему?

На рынке под термином «предпроектное обследование» могут предлагаться две совершенно разные услуги. Разница не в глубине детализации, а в предмете: в первом случае обследуется функция закупок, во втором — проектируется будущая система. Стоимость, подход и результат у них разные.

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

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

Шаг 1. Как должна быть устроена функция закупок

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

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

Шаг 2. Что должна уметь система

Здесь предмет — не процесс, а его отражение в системе: объекты и статусные модели, маршруты и условия переходов, ролевая модель, интеграции, данные и миграция, нефункциональные требования. И по каждому требованию — решение: закрывается типовой функциональностью, настройкой или разработкой.

В идеале к началу второго шага результаты первого должны быть уже известны и утверждены. Но простым переносом в другой формат второй шаг не является. Вот почему.

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

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

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

Последний вопрос особенно показателен. В регламенте задача решается одной фразой: «дробление не допускается». В системе за ней стоит алгоритм контроля с настраиваемыми параметрами, ложными срабатываниями, владельцем исключений и порядком разбора спорных случаев. Управленческое решение верное, но подхода к реализации оно не содержит. Цена пропущенного шага известна — по данным PMI, 47% неуспешных проектов не достигают целей из-за некачественной работы с требованиями — это главная причина, опережающая и превышение бюджета, и нарушение плановых сроков. А исследование 1 471 ИТ-проекта, опубликованное в Harvard Business Review, показало: средний перерасход бюджета — 27%, но каждый шестой проект превышает бюджет в среднем на 200%, а сроки — на 70%.

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

Традиционное распределение: анализ функции — консалтинг, требования к системе — вендор или интегратор. Распределение разумное, проблема в том, что между двумя шагами образуется разрыв: два исполнителя, два договора, два подхода и языка описания.

Контекст рынка. После ухода SAP Ariba и других западных систем российский рынок SRM за пять лет вырос почти вчетверо — с 0,9 до 3,5 млрд рублей по итогам 2025 года. В исследовании Сколково и TAdviser участвовали 18 вендоров, а всего на рынке больше 30 систем. При этом, по оценке экспертов на РБК, SRM-решениями пользуется меньше трети закупщиков. Иначе говоря: выбор большой, опыта у покупателей мало, и цена ошибки в постановке задачи высока. TAdviser отмечает, что в 2025-м рынок вышел из режима экстренной замены и сместил фокус на управляемость контура, качество данных и измеримый эффект — то есть ровно на то, что решается на первом шаге.

Какая экспертиза нужна на втором шаге

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

Что даёт предметная экспертиза автору ТЗ: он пишет требования на уровне, где разные вендоры оценят их одинаково. «Система поддерживает согласование заявок» — разброс оценок в разы, каждый понял своё. «Маршрут согласования настраивается по типу закупки, лимиту и ЦФО силами администратора заказчика; изменение маршрута не затрагивает заявки в работе» — оценивается сопоставимо.

Автор ТЗ — самый информированный участник. Пусть участвует

Тот, кто написал ТЗ, провёл семинары, видел выгрузки и знает, где у вас проблемы в процессе. Никто на рынке не понимает вашу задачу лучше. Исключать его из конкурса — значит убрать самого подготовленного участника и заодно сделать написание честного ТЗ коммерчески бессмысленным: зачем интегратору вкладываться в нейтральный документ, по которому его же и не пустят.

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

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

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

• По каждому требованию — способ реализации (коробка / настройка / разработка) и часы по ролям.
• По каждому предложению — допущения и исключения одним листом. Сравнение допущений обычно информативнее сравнения часов: там видно, кто что не понял или не захотел понять.
• Пять–семь сквозных сценариев на данных заказчика, которые все участники показывают в одном формате. Так «коробка» в оценке проверяется на демо, а не на словах.

И условие, без которого такой подход не работает: единый пакет для всех — ТЗ, формы для заполнения функциональных и нефункциональных требований, прямая связь пунктов ТЗ и реестра ФТ и НФТ.

Как проверить экспертизу на входе

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

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

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

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

Запросите реестр процедур и договоров за 12–24 месяца, журнал согласований с типовым временем исполнения, справочники контрагентов и номенклатуры. Посчитайте простые вещи: сколько на самом деле маршрутов согласования, какова медиана и 90-й перцентиль срока от заявки до договора, какая доля объёма прошла без сравнения предложений, сколько дублей в справочнике по ИНН. После этого интервью проходят иначе: вы приходите не с вопросом «как у вас устроено», а с наблюдением «по этой категории 60% объёма ушло без конкурса — почему?».

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

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

Признак, что вы добрались до реальности

Команда может объяснить, почему процесс устроен именно так: какое событие или конфликт интересов породили этот шаг. Пока ответ звучит как «так исторически сложилось», до причины не дошли — и в целевой модели этот шаг либо воспроизведут без нужды, либо уберут, не заметив, что он что-то закрывал.

Требования не выводятся из текущего состояния — только из решения о целевом. Если решение не принято явно, его молча принимает аналитик, исходя из своих представлений о правильном. Так и получаются ТЗ, которые с высокой точностью автоматизируют текущий беспорядок.

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

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

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

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

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

Причина одна: попытка одновременно менять функцию и проектировать систему. У этих работ разные цели и разный уровень решений. Первая — про оргструктуру, это уровень директора и первого лица. Вторая — про объекты и маршруты, это владельцы процессов и ИТ.

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

Схем три:

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

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

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

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

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