Операционная рентабельность выше 50% и запуск в срок — это не удача и не «хороший заказчик», а следствие нескольких простых закономерностей. Индустрия внедрения 1 С:ERP выработала их через годы удачных и провальных проектов, хотя редко проговаривает вслух. Ниже — семь опор, на которых держится рентабельный проект, и то, что они дают на практике.

Где проекты теряют деньги

У внедренческого проекта всего два ресурса: часы команды и календарь. Деньги заказчика уже зафиксированы в договоре, поэтому любая потеря времени превращается в потерю маржи один к одному.

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

Там, где эти правила соблюдаются, операционная рентабельность крупных проектов стабильно держится на уровне 50–55% при бюджетах 60–80+ млн ₽, а запуск проходит в плановую дату — даже в проектах, принятых в кризисе, вплоть до полного замещения SAP.

Опора 1. Границы фиксируются в ТКП, а не на обследовании

Проект планируется на конкретный объём работ. Если объём растёт, а ресурсы нет, команду растаскивает, и сроки срываются — это закон, а не риск. Поэтому основная работа РП начинается не на обследовании, а при расчёте ТКП.

Фиксируются два вида рамок.

• Интеграционные: все системы, участвующие в проекте, и все интеграции. Забытая на старте система — самый дорогой сюрприз на разработке.

• Функциональные — по иерархии «контур → блок → бизнес‑процесс → ключевые требования».

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

Рамки закрепляются в договоре, а если это невозможно — в подписанном уставе проекта. Расширение допускается только через изменение с дополнительным бюджетом и дополнительными людьми. Это звучит жёстко, но именно это позволяет потом выполнить всё обещанное.

Опора 2. Юнит — атом проекта

Основа управляемости проекта — технология юнитов. Юнит — неделимая единица работы, равная одному бизнес‑процессу: «формирование заказа поставщику», «выпуск продукции по этапу», «закрытие месяца». Сколько процессов в рамках, столько юнитов.

Каждый юнит матрично проходит одни и те же стадии:

1. Обследован: подписан протокол с требованиями, описанием и функциональными разрывами.

2. Смоделирован: в системе сделан контрольный пример, подписана функциональная модель.

3. Принят заказчиком в составе сквозного процесса.

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

Условная выручка как прогноз рентабельности

Каждому юниту назначается вес, каждой стадии — процент. Зная стадию всех юнитов, РП в любой момент знает процент выполнения этапа и условную выручку. Это вариация метода освоенного объёма (EVM), но расчёт через юниты делает его понятным и заказчику, и консультанту.

Дальше простая арифметика. Проект стоит 1 млн ₽, выполнено 50% — условная выручка 500 тыс. Потрачено 250 тыс. ФОТ с налогами — прогноз рентабельности 50%. Считаем еженедельно.

Здесь работает известный «конус неопределённости»: в начале прогноз шумный, но примерно после первой трети срока он становится объективным. Именно в этот момент видно, будет ли проблема с маржой и датой запуска, и ещё есть время её решить.

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

Опора 3. Никто не ждёт

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

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

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

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

Заказчик: не тестируешь — согласовываешь ТЗ. Нечего согласовывать — проходишь обучение.

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

Наложение подчиняется одному правилу: к началу следующего этапа закрыто приоритетное, периферия догоняет параллельно. В разработку нормально идти при примерно 70% смоделированного, если ключевое закрыто. Ни одна задержка не должна сдвигать дату запуска.

Опора 4. Вперёд идёт то, без чего нельзя запуститься

Приоритизация в рентабельном проекте всегда отвечает на один вопрос: можно ли без этого начать работать в системе? Порядок почти не меняется от проекта к проекту: интеграция; товародвижение в производстве и оперконтуре; кастомные элементы себестоимости; НСИ.

Отсюда определение MVP для запуска. Он состоит из трёх вещей:

• работает интеграция;

• пользователи ведут товародвижение, настроены АРМы, без которых работать физически нельзя;

• считается себестоимость и закрывается период.

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

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

Разработка: контроль по часам без микроменеджмента

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

Но сигнал не равен наказанию. Оценка по требованиям всегда субъективна: где‑то недооценили, где‑то переоценили, и работает закон больших чисел. Двукратный перерасход на отдельном разрыве при общей рентабельности 50+% — норма. Ориентир — проект в целом, максимум — рентабельность по сотруднику.

Опора 5. Эксплуатация измеряется, а не ощущается

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

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

1. Начали работать.

2. Работают, осваивают, задают вопросы.

3. Освоено: создано несколько экземпляров, вопросов нет, работа штатная.

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

Точка невозврата — закрытие первого периода. По реестру проверяется полнота учёта: все ли покупки, продажи, перемещения и деньги отражены. Затем закрытие месяца ведётся как отдельный мини‑проект: список ограничений, план их снятия, ежедневный статус с заказчиком.

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

Опора 6. Реестр развития: «да, но позже»

Жёсткие границы порождают очевидный вопрос: а что делать с пожеланиями, которые пользователи генерируют каждый день? Отказывать — портить отношения. Соглашаться — не запуститься или запуститься с нулевой маржой.

Ответ — реестр развития. Всё, чего нет в функциональной модели, получает ответ «будет обязательно, но позже» и записывается в отдельный перечень. К запуску там обычно набирается ещё около 30% функциональных разрывов от исходного объёма. За те же деньги это не делается: после закрытия первого периода по реестру заключаются новые договоры, очередями.

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

1. MVP. Все в шоке, насколько непривычно и неудобно.

2. MLP. Функциональная модель реализована, напряжение спадает, но многого по‑прежнему не хватает.

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

Без реестра проект формально сделан, а заказчик недоволен: объём модели не удовлетворяет его никогда. С реестром развитие становится «золотым временем» — спокойный ритм, хорошая маржа и плюс 30–50% к сумме проекта. Для проекта с бюджетом около 80 млн ₽ это порядка 30 млн ₽ сверху.

Опора 7. Инфраструктура, которая снимает рутину

Confluence как память проекта. В пространстве проекта лежит всё: записи и транскрипции встреч, устав, протоколы, модели, ТЗ, доступы, контакты и зоны ответственности людей заказчика. Фредерик Брукс сформулировал закон: добавление людей в опаздывающий проект только задерживает его. Во многом он верен из‑за затрат на ввод в контекст. Когда у проекта есть полная структурированная память, новому консультанту назначаются юниты, даётся ссылка и администратор для ориентации — и он даёт результат с первого дня.

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

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

Стиль руководителя

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

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

Вместо вывода

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

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

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