Грабли и лайфхаки управления проектами цифровизации
Текстовая версия выступления с конференции DIGITAL4FOOD'23

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

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

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


Итак, на какие вопросы необходимо найти ответы, прежде чем идти в проект:

1. Зачем проект бизнесу?
Именно с такого вопроса нужно начинать подготовку к любому проекту. При этом важно понимать, что ответы должны быть не в терминах системы, а в терминах бизнес-эффектов. Не чтобы внедрить продукт N, а чтобы снизить себестоимость или сократить потери на производстве, или стандартизировать качество готовой продукции.

2. Каково функциональное наполнение проекта?
Здесь нужно провести ревизию функций системы: понять, как они организованы сейчас, какие есть проблемы и какие требуются изменения. Это позволяет выделить фокусные для проекта точки внимания, которые потом на протяжении всего проекта помогают не отклоняться от цели.

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

4. Какие организационные изменения потребуются?
Проект цифровизации неизбежно влечет за собой изменения: перераспределение функций между людьми или отделами. Возможно добавление новых отделов, функций, людей, возможна замена каких-то сотрудников. На этом этапе важно честно ответить себе на вопрос: вы готовы к этим изменениям или нет? И если по тем или иным причинам ответ отрицательный, идти в проект не надо до тех пор, пока не будут устранены останавливающие факторы. Если понадеяться на «авось» и закрыть глаза на проблемы, скорее всего они потопят ваш проект. Об этом нужно помнить.

5. Какое требуется техническое обеспечение?
Если мы говорим про проекты оперативного учета, это может быть цеховое оборудование («киоски», весы, сканеры и т.д.) Здесь же нужно оценить, какие вам могут понадобиться вспомогательные инструменты (например, системы для управления требованиями к интеграционным потокам).

6. Какой план выполнения проекта(ов)?
Я придерживаюсь мнения, что универсального плана не существует. Но можно говорить про виды работ, которые нужно делать в проекте и из которых компонуется индивидуальный план проекта.

ИТ-проект – это проект ИТшников
Начинать проект цифровизации без вовлеченного бизнес-заказчика, означает, закопать его уже на старте.
Пример из практики: проект автоматизации бухучета на ERP. Клиент крупный. Финансовая служба сказала ИТ специалистам: «Настройте систему». На этом их вовлеченность закончилась. Формально проект был завершен вовремя и работоспособность системы была подтверждена. Но целей достигнуто не было. Например, закрытие периода выполнялось с опозданием в 3 месяца.
Вовлекать бизнес заказчика в проект – это отдельная задача. На мой взгляд, это функция руководителя проекта со стороны заказчика или ИТ директора, одной из важных компетенций которого как раз является умение вести переговоры с бизнесом на одном языке.

Заказчик «платит» – подрядчик «танцует»
Речь здесь идет в первую очередь не про деньги, а про смещение ответственности.
Любой ИТ проект – это подмножество бизнес-проектов. ИТ система внедряется для достижения целей бизнеса. С этой точки зрения подрядчик обеспечивает компетенции, которых не хватает вам внутри. За достижение бизнес-результата все-таки отвечает команда заказчика.
Обеспечение партнерских отношений в команде проекта – это отдельная функция управления проектом. Такой подход позволяет трезво формировать ожидания и избегать перекладывания ответственности.

Настройка системы под новые/несуществующие процессы
Как я уже писал, проект цифровизации может потребовать изменений в процессах. Однако, увлечение настройкой функционала под новые процессы и реализация неопробованных гипотез чаще всего не приводит ни к чему, кроме потери времени, денег и сил.
Рекомендую сначала менять процессы (без или с минимумом автоматизации). Под изменяющиеся/новые процессы внедрять MVP-продукта. (А дошлифовывать их уже в постпроектной эксплуатации).
Автоматизировать лучше уже устоявшиеся процессы. В простом варианте нужен прототип, на котором вы получите опыт эксплуатации этой системы. Лайфхак: отмоделировать новый процесс не в системе, а, например, в Excel, которая описывает целевую логику. Поработать какое-то время в ней, а уже потом переносить в комплексную автоматизированную систему.

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