До 60% проектов по реинжинирингу бизнес-процессов проваливаются или выходят за рамки бюджета на 40–100% из-за некорректного ТЗ. Ошибка заказчика обычно заключается в попытке купить «результат» вместо «методологии», что превращает оптимизацию в бесконечный цикл правок без измеримого профита.
Запрос на «оптимизацию всего» вместо конкретных узких мест
Самая дорогая ошибка — формулировка «хотим навести порядок в процессах и повысить эффективность». Для подрядчика это сигнал к раздуванию сметы. В среднем, размытое ТЗ увеличивает стоимость проекта на 30–50%, так как консультанты закладывают риски на бесконечные интервью и уточнения. Вместо этого нужно указывать конкретный KPI: например, «сократить цикл обработки заказа с 48 до 12 часов при сохранении текущего штата в 5 человек».
Кейс: компания из сферы логистики заказала «оптимизацию склада». Итог — оплаченные 1,5 млн руб. за красивые схемы в Visio, которые не работали. Если бы ТЗ звучало как «снизить процент ошибок при комплектации с 4% до 0,5%», фокус сместился бы с рисования схем на внедрение WMS и переделку зонирования.
Вывод: ТЗ должно начинаться с боли в цифрах, а не с желания «стать лучше».
Игнорирование стоимости владения и внедрения
Заказчики часто фокусируются на стоимости услуг консультанта, забывая о стоимости реализации. В нише оптимизации стоимость лицензий ПО и оплаты работы внутренних интеграторов обычно составляет от 2 до 5 стоимоностей самого консалтинга. Если в ТЗ не прописано требование учитывать бюджет на софт (например, переход с Excel на BPM-систему стоимостью 500к+ руб./год), проект заглохнет на этапе внедрения.
Пример: оптимизация отдела продаж через внедрение CRM. Стоимость консалтинга — 300 000 руб., но стоимость доработки API и обучения персонала составила 1,2 млн руб., что не было учтено в первоначальном запросе. В итоге проект был заморожен на 70% готовности.
Вывод: Требуйте от подрядчика разделения сметы на стоимость проектирования и оценочную стоимость реализации.
Отсутствие определения критериев приемки (Acceptance Criteria)
Типичная ошибка — отсутствие четких метрик завершения этапа. Без них вы попадаете в ловушку «бесконечных итераций». Правильное ТЗ содержит формулу расчета ROI или конкретный список документов (AS-IS, TO-BE, регламенты, матрица ответственности RACI). Без этого вы не сможете аргументированно отказаться от оплаты последнего транша, если результат вас не устроил.
Сравнение: в модели Fixed Price без четких критериев приемки вы получите минимально жизнеспособный продукт, который формально соответствует ТЗ, но не решает проблему. В модели Time and Materials вы рискуете переплатить за избыточный перфекционизм консультанта.
Вывод: Описывайте не процесс («провести аудит»), а результат («карта процесса TO-BE, согласованная с руководителями трех департаментов и подтвержденная тестом на одной группе заказов»).
Перекладывание ответственности за сбор данных на подрядчика
Многие пишут в ТЗ: «Подрядчик должен самостоятельно выявить все проблемы и описать процессы». Это фатальная ошибка. Внешний эксперт тратит 70% времени на поиск людей, готовых говорить правду, а не на оптимизацию. Это затягивает сроки реализации этапов аудита с нормативных 2–4 недель до 2–3 месяцев.
Кейс: внедрение KPI в производственной компании. Подрядчик пытался собрать данные сам, столкнулся с саботажем линейных менеджеров, и проект затянулся на полгода. При наличии в ТЗ пункта о назначении внутреннего «владельца процесса» со стороны заказчика, срок сократился бы до 4 недель.
Вывод: В ТЗ должен быть зафиксирован объем ресурсов со стороны заказчика (количество часов интервью, доступ к логам CRM/ERP, выделенный менеджер проекта).
Смешение функциональных требований с бизнес-целями
Ошибка — диктовать подрядчику, *как* делать (например, «внедрить Kanban-доску»), вместо того чтобы сказать, *зачем* («сократить время ожидания согласования договора с 5 до 2 дней»). Когда вы ограничиваете инструмент, вы лишаете эксперта возможности предложить более дешевое или эффективное решение. Часто «желаемый» инструмент стоит в 3 раза дороже, чем альтернатива, дающая тот же эффект.
Пример: запрос на «автоматизацию через Python-скрипты» стоил 200 000 руб. при сроке разработки 1 месяц. Эксперт предложил No-code решение, которое стоило 40 000 руб. и внедрилось за неделю, полностью закрыв потребность в автоматизации отчетов.
Вывод: Описывайте желаемый эффект в деньгах или часах, а выбор инструментов оставляйте профессионалу, зафиксировав это в этапах работы компании по оптимизации бизнес-процессов: от аудита до внедрения KPI.
Вывод
Чтобы проект не стал сливом бюджета, откажитесь от общих формулировок в пользу жестких метрик. Начните с фиксации текущего убытка в рублях или часах, определите желаемый KPI и четко разграничьте стоимость консалтинга и стоимость внедрения. Избегайте Fixed Price для сложных, неструктурированных задач — выбирайте T&M; с жестким лимитом бюджета (Cap), чтобы сохранить гибкость. Лучшая стратегия: ставить задачу через «результат в цифрах» и требовать от подрядчика детальный план реализации с указанием всех зависимостей от вашего персонала.