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

Два уровня решений — одна цель

Цель у заказчика одна — улучшить закупки. Но путь к ней проходит через два уровня решений: управленческий и проектный.

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

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

Стремление пройти оба уровня одновременно и становится причиной большинства сложностей на проектах.

Почему нельзя просто «переложить» процесс в систему

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

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

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

Риски при пропуске шага будут вполне конкретными. Так, по данным ежегодного отчета Project Management Institute (PMI) Driving Success in Complex Projects: From Navigating Tasks to Navigating Systems (Обеспечение успеха в сложных проектах: от навигации по задачам к навигации по системам), 47 % неуспешных проектов не достигают целей из-за некачественной работы с требованиями. Это ключевая причина, опережающая и превышение бюджета, и нарушение плановых сроков. А авторы исследования «The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution», в котором приняли участие 5 392 ИТ-проекта выяснили, что есть много проектов с небольшим превышением бюджета, но есть и те (порядка 17 %), где перерасход был просто катастрофическим — от 200 % до 400 %.

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

С какой задачей приходят заказчики и где ошибаются

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

Типичные формулировки запросов на входе:

• Хотим автоматизировать закупки — с чего начать?
• Нам нужна SRM-система, помогите выбрать и внедрить.
• У нас хаос в закупках, наведите порядок.
• Нужно предпроектное обследование.
• Хотим посчитать экономию и понять, где теряем деньги.
• Директор сказал, что к концу года должна быть система.

За каждой из этих фраз стоит разная задача. И почти никогда та услуга, которую в итоге продают. Самые типичные сценарии:

1. Нужна система

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

Итог: точная автоматизация текущего беспорядка. Система работает, деньги потрачены, а закупки не улучшились. Через год выясняется, что половина маршрутов не используется, справочники забиты дублями, а экономию никто не считает.

В чем проблема: не хватило первого шага, так как никто не спросил, каким должен стать процесс до того, как его оцифровали.

2. Хотим порядок

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

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

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

3. Нужно провести обследование

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

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

Вопросы, которые нужно задать до старта

Прежде чем подписывать договор на «обследование», заказчик должен ответить себе на три вопроса, которые помогут сэкономить и время, и бюджет.

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

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

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

Кто должен заниматься реализацией

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

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

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

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

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

Рабочих схем три:

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

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

НОРБИТ: от целевой модели до работающей системы

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

НОРБИТ успешно работает на обоих уровнях. У компании есть собственное SRM-решение на low-code платформе BPMSoft, это закрывает второй шаг: требования, маршруты, ролевая модель, интеграции. Но главное — экспертиза в закупках, которая позволяет пройти и первый шаг.