Неуправляемый проект автоматизации бизнес-процессов: почему он обречен

Проекты по автоматизации бизнес-процессов в компаниях, редко проваливаются из-за технологий.

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

Такой проект можно назвать неуправляемым.

Что такое неуправляемый проект

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

• какие результаты должны быть получены в целом;
• из каких очередей (этапов) состоит проект;
• какие задачи входят в каждую очередь;
• какие зависимости существуют между задачами;
• как связаны сроки, бюджет и ожидаемый эффект.

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

Заблуждение №1: методология сама решит проблему

Один из самых распространенных мифов — вера в то, что выбор методологии автоматически делает проект управляемым.

Agile часто воспринимается как способ «начать делать, а там разберемся». Водопад — как гарантия порядка за счет формального плана. При этом многие компании, реализующие автоматизацию на базе 1С, опираются на прикладные «технологии внедрения» — например, на 1С:ТКВ (технологию корпоративного внедрения) и другие рекомендованные 1С форматы организации работ.

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

Методология — это инструмент. Но инструмент не заменяет управленческое мышление. Без четкого ответа на вопрос «что именно мы хотим получить» ни спринты, ни этапы, ни регламенты внедрения не спасут проект.

Заблуждение №2: достаточно руководителя проекта со стороны заказчика

Второе распространенное заблуждение — убеждение, что наличие руководителя проекта у заказчика решает проблему управления.

Чаще всего этот человек:

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

В результате руководитель проекта превращается в «точку согласования», а не в источник управления. Он согласует документы, участвует во встречах, принимает поставленные перед ним решения, но не формирует целостную картину проекта.

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

Корень проблемы — отсутствие понимания результата

Главная причина неуправляемости — отсутствие у заказчика ясного представления о результате всего проекта.

Часто звучат формулировки:

• «Нужно автоматизировать процесс»,
• «Хотим внедрить систему»,
• «Нужно, чтобы работало лучше».

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

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

Экспертный взгляд и этап проектного дизайна как точка начала управления

Контроль над проектом не начинается с плана. Он начинается с экспертного взгляда на текущую ситуацию у заказчика — и оформляется в этап проектного дизайна.

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

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

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

1) Метрики: переводим намерения в измеримые цели и результаты

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

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

2) Требования к процессам: без формализации «что делаем» невозможно управлять «как делаем»

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

Инструментом здесь выступает сбор требований и интервьюирование ключевых владельцев бизнес-процессов. Именно интервью с владельцами (а не только с «пользователями» и не только с ИТ) позволяют:

• синхронизировать ожидания разных подразделений;
• выявить скрытые противоречия и «дырки» в процессах;
• договориться о границах автоматизации и критериях приемки;
• заложить реалистичную декомпозицию задач и зависимостей.

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

План как следствие понимания, а не формальность

Когда появляется целостное понимание ситуации и целей, можно сформировать план — не формальный документ, а дорожную карту проекта.

Такая дорожная карта:

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

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

Но в любом случае план становится инструментом управления, а не иллюзией контроля.

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

Неуправляемый проект — это не проблема методологии и не следствие «плохих исполнителей». Это управленческая проблема, которая начинается с отсутствия понимания результата и структуры проекта у заказчика.

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

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

И только после этого автоматизация начинает работать на бизнес, а не против него.