Грабли и лайфхаки управления проектами цифровизации

1. Зачем проект бизнесу?
   Именно с такого вопроса нужно начинать подготовку к любому проекту. При этом важно понимать, что ответы должны быть не в терминах системы, а в терминах бизнес-эффектов. Не чтобы внедрить продукт N, а чтобы снизить себестоимость или сократить потери на производстве, или стандартизировать качество готовой продукции.
2. Каково функциональное наполнение проекта?
   Здесь нужно провести ревизию функций системы: понять, как они организованы сейчас, какие есть проблемы и какие требуются изменения. Это позволяет выделить фокусные для проекта точки внимания, которые потом на протяжении его реализации помогают не отклоняться от цели.
3. Какие системы потребуются?
   Здесь нужно думать не только о том, какие системы нужны для решения задач данного проекта, но и о том, как они впишутся в общий IT-ландшафт предприятия, какие интеграции необходимо будет настроить.
4. Какие организационные изменения потребуются?
   Проект цифровизации неизбежно влечет за собой изменения: перераспределение функций между людьми или отделами. Возможно добавление новых отделов, функций, людей, возможна замена каких-то сотрудников. На этом этапе важно честно ответить себе на вопрос: вы готовы к этим изменениям или нет? И если по тем или иным причинам ответ отрицательный, начинать проект не надо до тех пор, пока не будут устранены останавливающие факторы. Если понадеяться на «авось» и закрыть глаза на проблемы, скорее всего, они потопят ваш проект. Об этом нужно помнить.
5. Какое требуется техническое обеспечение?
   Если мы говорим про проекты оперативного учета, это может быть цеховое оборудование («киоски», весы, сканеры и т.д.) Здесь же нужно оценить, какие вам могут понадобиться вспомогательные инструменты (например, системы для управления требованиями к интеграционным потокам).
6. Какой план выполнения проекта?
   Я придерживаюсь мнения, что универсального плана не существует. Но можно говорить про виды работ, которые необходимы и из которых компонуется индивидуальный план проекта.

Источник: сайт Freepik, автор a href 

Грабли выполнения проектов

IT-проект – это проект IT-специалистов. Начинать проект цифровизации без вовлеченного бизнес-заказчика означает закопать его уже на старте.

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

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

Источник: сайт Freepik, автор macrovector

Заказчик «платит» – подрядчик «танцует»

Речь здесь идет в первую очередь не про деньги, а про смещение ответственности.

Любой IT-проект – это подмножество бизнес-проектов. IT-система внедряется для достижения целей бизнеса. С этой точки зрения подрядчик обеспечивает компетенции, которых не хватает вам внутри. За достижение результата, все-таки, отвечает команда заказчика.

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

Настройка системы под новые/несуществующие процессы

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

Рекомендую сначала менять процессы (без или с минимумом автоматизации). Под изменяющиеся/новые процессы внедрять MVP-продукта (а дошлифовывать их уже в постпроектной эксплуатации).

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

Источник: сайт Freepik, автор tirachardz

«Сделайте как было в старой системе»

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

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

Еще несколько советов от «бывалого»

1. Привлекайте специалистов с опытом выполнения подобных проектов.
Совет, хоть и банальный, но без него никуда. Это как сесть в автомобиль, где за рулем новичок, и поехать с ним сразу в гущу мегаполиса. Хотите? Вряд ли… Также и с проектом. Цифровизация – сложная и требующая массы отточенных навыков наука. Можно, конечно, и с новичком, но неизвестно, за сколько времени вы доедете, и сколько денег потребуется потом на ремонт.

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

Что делать? Тут у вас есть четыре помощника:

• прозрачность результатов (проекта и личных);
• прозрачность роли и границ ответственности и полномочий;
• система материальной мотивации;
• достаточный ресурс времени на проект (пусть не на 100%, но старайтесь оценивать этот параметр заранее).

3. Обеспечивайте гигиену регулярного проектного менеджмента.

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

Поэтому здесь:

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

Итак, в качестве резюме еще раз подчеркну. Прежде всего, важна подготовка к проекту: бизнес-цель, функциональный «крестный отец» и IT-директор, фокусные процессы, требующие изменений и др. Кроме того, большую роль играет обеспеченность и вовлеченность людей. Партнерские отношения в команде – функция управления проектом. А вот сэкономить без последствий вы можете на работе со специалистами с отраслевой экспертизой. Успехов в проектах цифровизации!