Юлий Минькин.
Мы привыкли думать, что главный риск в проекте — это недооценка бюджета или техническая некомпетентность исполнителя. Но часто бывает, что самые большие проблемы приходят с той стороны, которую принято считать "данностью": со стороны заказчика. Когда крупный проект, особенно по внедрению сложных ИТ-систем, затягивается и начинает тонуть, причина часто кроется в отсутствии или непроработанности методологии — той самой внутренней логики, по которой живет организация.
Что такое методология, и почему она важна
Методология в контексте внедрения систем — это не просто набор документов. Это внутренняя конституция компании: четкие бизнес-правила, описанные процедуры, утвержденные учетные политики. Это ответ на вопрос "Как именно мы работаем?".
Когда команда приходит внедрять новую ERP-систему, она не создает правила. Она должна автоматизировать существующие правила. Система — это всего лишь инструмент, который обязывает компанию следовать установленным процедурам. Если эти процедуры существуют только в головах старожилов, если они противоречат друг другу или вообще отсутствуют, система внедрения моментально превращается в проект по разработке методологии.
Это критический сдвиг. Команда, нанятая для установки программы, внезапно вынуждена решать глубинные организационные проблемы заказчика. Они тратят время, чтобы понять, "как учитывать запасы", "как проводить согласование заявок" или "как распределять косвенные расходы". И вот тут начинается цепная реакция, которую невозможно остановить.
Цепная реакция хаоса
Отсутствие проработанной методологии порождает две главные проблемы, которые бьют прямо по срокам и бюджету исполнителя: паралич принятия решений и феномен "вечного согласования".
Когда команде нужно настроить процесс в системе, она обращается к клиенту за правилами. А правил нет. Или их много, и они конфликтуют. Начинаются долгие, многократные внутренние совещания на стороне заказчика. Проектная команда, по сути, выступает катализатором или невольным участником: она заставляет клиента впервые в жизни договориться о том, как он работает.
По каждому, даже самому простому процессу, запускается серия внутренних "битв" и "круглых столов" внутри организации заказчика. Команда исполнителя вынуждена ждать. Они фиксируют простои, которые не зависят от их технической работы. При этом они продолжают нести свои расходы.
В нашем Telegram-канале мы часто разбираем реальные кейсы из IT-проектов — почему сбой в коммуникациях обходится дороже кода, как заказчики «размывают» ответственность и что делать, если хаос стал нормой. Подписывайтесь, чтобы не просто тушить пожары, а управлять ими.
Паралич принятия решений означает, что сроки, которые были заложены на "настройку системы", уходят на "согласование того, что настраивать". Это не просто задержка, это непредвиденная работа для исполнителя, которую он вынужден выполнять за свой счет.
Цена невидимых рисков
Опытные проектные менеджеры знают: риски, связанные с организационной незрелостью клиента, должны быть либо исключены из проекта, либо учтены в цене. Но часто, под давлением сделки или по причине собственной неопытности, эти риски недооцениваются.
Руководство, подписывающее договор, должно понимать: если в теле проекта заложены работы, которые зависят от способности заказчика быстро предоставить утвержденные бизнес-правила, а этих правил нет, — проект обречен. Каждая неделя внутреннего спора у клиента — это неделя простоя для исполнителя.
Исполнитель, который не зафиксировал этот риск в договоре, платит дважды:
- Простой: Команда не может продвигаться по плану, ожидая решения клиента.
- Эмоциональные и ресурсные потери: Члены команды вынуждены участвовать в чужих внутренних конфликтах, тратя свой ресурс на модерацию споров вместо технической работы.
Это классический пример того, как недооценка организационных проблем клиента может разрушить финансовую модель проекта.
Что делать, если риск уже проявился: тактика защиты
Если отсутствие или непроработанность методологии на стороне клиента обнаружилось, когда проект уже идет, команда должна немедленно перейти к тактике защиты своих финансовых и временных границ. Уступчивость здесь равносильна добровольному принятию убытка.
- Протоколирование и фиксация:
Немедленно формализуйте проблему. Документируйте все запросы к клиенту, которые остались без ответа или привели к внутреннему спору.
Фиксируйте время простоя команды (например, "Ожидание утверждения учетной политики по складу с 15:00 01.10.25 по 10:00 03.10.25"). Указывайте, что эти простои вызваны неготовностью внутренних правил клиента.
Обязательно фиксируйте трудозатраты на посредничество или консультирование клиента по их внутренним правилам (т.е. на ту работу, которая не является внедрением). - Запуск процедуры изменения объема работ (Change Request):
На основе собранных данных подготовьте официальное уведомление. Четко разделите: работа по внедрению (согласно договору) и работа по разработке/согласованию методологии (непредвиденная работа).
Предложите дополнительный бюджет и срок для выполнения этой непредвиденной работы. Подчеркните, что без утвержденной методологии дальнейшее продвижение по внедрению невозможно. - Перезаключение обязательств:
Если изменение бюджета невозможно, требуйте пересмотра сроков с включением "буферного времени" на внутренние согласования клиента.
Установите четкие внутренние дедлайны для клиента. Например: "Если правила не будут утверждены в течение 5 рабочих дней, работы по соответствующему модулю будут приостановлены, что приведет к задержке всего проекта". - Вовлечение высшего руководства клиента:
Эскалируйте проблему на уровень руководителя проекта и высшего руководства клиента. Четко покажите, что убытки и задержки вызваны их организационным, а не техническим риском. Это заставит клиента принимать внутренние решения быстрее.
Уроки формализма
Отсутствие методологии — это не просто неудобство, это скрытая, но самая дорогая работа в проекте. Оно заставляет исполнителя бесплатно взять на себя функцию консультанта по управлению и организационному развитию.
Прежде чем входить в проект по внедрению, необходимо не только проверить техническую готовность, но и провести аудит организационной зрелости клиента. Если клиент не может ответить на вопрос "Как именно вы работаете?", нужно либо включить эту работу в бюджет, либо не начинать проект. Иначе исполнитель будет платить за чужой внутренний беспорядок.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Подробнее о наших курсах — на сайте