Главное меню
Раз уж мы сегодня взялись говорить про ошибки, способные помешать вам достичь успеха на поприще цифровизации, в качестве отдельного блока хочется вынести разбор процесса подготовки. Потому что чем раньше допущена ошибка, тем сильнее ее вес и отрицательное влияние на проект. Подготовка – это основа. Если допустить ошибку здесь, дальше будет бесполезно расставлять стулья на тонущем Титанике.
Итак, на какие вопросы необходимо найти ответы, прежде чем идти в проект:
1. Зачем проект бизнесу?
Именно с такого вопроса нужно начинать подготовку к любому проекту. При этом важно понимать, что ответы должны быть не в терминах системы, а в терминах бизнес-эффектов. Не чтобы внедрить продукт N, а чтобы снизить себестоимость или сократить потери на производстве, или стандартизировать качество готовой продукции.
2. Каково функциональное наполнение проекта?
Здесь нужно провести ревизию функций системы: понять, как они организованы сейчас, какие есть проблемы и какие требуются изменения. Это позволяет выделить фокусные для проекта точки внимания, которые потом на протяжении всего проекта помогают не отклоняться от цели.
3. Какие системы потребуются?
Здесь нужно думать не только о том, какие системы нужны для решения задач данного проекта, но и о том, как они впишутся в общий ИТ ландшафт предприятия, какие интеграции необходимо будет настроить.
4. Какие организационные изменения потребуются?
Проект цифровизации неизбежно влечет за собой изменения: перераспределение функций между людьми или отделами. Возможно добавление новых отделов, функций, людей, возможна замена каких-то сотрудников. На этом этапе важно честно ответить себе на вопрос: вы готовы к этим изменениям или нет? И если по тем или иным причинам ответ отрицательный, идти в проект не надо до тех пор, пока не будут устранены останавливающие факторы. Если понадеяться на «авось» и закрыть глаза на проблемы, скорее всего они потопят ваш проект. Об этом нужно помнить.
5. Какое требуется техническое обеспечение?
Если мы говорим про проекты оперативного учета, это может быть цеховое оборудование («киоски», весы, сканеры и т.д.) Здесь же нужно оценить, какие вам могут понадобиться вспомогательные инструменты (например, системы для управления требованиями к интеграционным потокам).
6. Какой план выполнения проекта(ов)?
Я придерживаюсь мнения, что универсального плана не существует. Но можно говорить про виды работ, которые нужно делать в проекте и из которых компонуется индивидуальный план проекта.
Начинать проект цифровизации без вовлеченного бизнес-заказчика, означает, закопать его уже на старте.
Пример из практики: проект автоматизации бухучета на ERP. Клиент крупный. Финансовая служба сказала ИТ специалистам: «Настройте систему». На этом их вовлеченность закончилась. Формально проект был завершен вовремя и работоспособность системы была подтверждена. Но целей достигнуто не было. Например, закрытие периода выполнялось с опозданием в 3 месяца.
Вовлекать бизнес заказчика в проект – это отдельная задача. На мой взгляд, это функция руководителя проекта со стороны заказчика или ИТ директора, одной из важных компетенций которого как раз является умение вести переговоры с бизнесом на одном языке.
Речь здесь идет в первую очередь не про деньги, а про смещение ответственности.
Любой ИТ проект – это подмножество бизнес-проектов. ИТ система внедряется для достижения целей бизнеса. С этой точки зрения подрядчик обеспечивает компетенции, которых не хватает вам внутри. За достижение бизнес-результата все-таки отвечает команда заказчика.
Обеспечение партнерских отношений в команде проекта – это отдельная функция управления проектом. Такой подход позволяет трезво формировать ожидания и избегать перекладывания ответственности.
Как я уже писал, проект цифровизации может потребовать изменений в процессах. Однако, увлечение настройкой функционала под новые процессы и реализация неопробованных гипотез чаще всего не приводит ни к чему, кроме потери времени, денег и сил.
Рекомендую сначала менять процессы (без или с минимумом автоматизации). Под изменяющиеся/новые процессы внедрять MVP-продукта. (А дошлифовывать их уже в постпроектной эксплуатации).
Автоматизировать лучше уже устоявшиеся процессы. В простом варианте нужен прототип, на котором вы получите опыт эксплуатации этой системы. Лайфхак: отмоделировать новый процесс не в системе, а, например, в Excel, которая описывает целевую логику. Поработать какое-то время в ней, а уже потом переносить в комплексную автоматизированную систему.
Многие, сталкиваясь с необходимостью изменений, начинают жалеть «нажитое непосильным трудом»: писали-писали 15 лет, и что теперь с этим делать? Но если функции уже не используются – зачем оно вам надо?
Перенос функциональных историзмов в логику/функционал новой системы не несет в себе ни грамма пользы, а только вредит. Помните, что методологическая целостность новой системы почти всегда важнее сложившихся привычек.
Совет, хоть и банальный, но без него никуда. Это как сесть в автомобиль, где за рулем новичок, и поехать с ним сразу в гущу мегаполиса. Хотите? Вряд ли… Так же и с проектом. Цифровизация – сложная и требующая массы отточенных навыков наука. Можно, конечно, и с новичком, но неизвестно, за сколько времени вы доедите и сколько денег потребуется потом на ремонт.
Вовлечение ключевых участников проекта – это боль каждого первого проекта, в котором мне приходилось работать. Очень сложно точно спрогнозировать объем нагрузки заранее. Поэтому эту задачу всегда приходится дорешивать уже внутри проекта. Причем разными способами. В простом варианте это увеличение команды. В более сложном – спасение перегоревших людей.
Что делать? Тут у вас есть четыре помощника:
· Прозрачность результатов (проекта и личных).
· Прозрачность роли и границ ответственности и полномочий.
· Система материальной мотивации.
· Достаточный ресурс времени на проект! (Пусть не на 100% точно, но старайтесь оценивать этот параметр заранее).
В крупных проектах, где есть холдинговая структура, нужно учитывать интересы большого количества людей и смежных подразделений. История с переобуваниями в процессе может стать главной проблемой проекта. Поэтому здесь:
· Важно иметь не только технологию выработки и принятия решений, но и технологию удержания этих решений.
· Регулярные (еженедельные или максимум ежедвухнедельные) координационные встречи по проекту – это не прихоть, а необходимость.
· Ведение актуального списка рисков и планирование, как действовать в случае их реализации, на определенном этапе может спасти проект от поражения.
· Администрирование рабочих встреч и протоколирование договоренностей поможет избежать разночтений.
1. Важна подготовка к проекту: бизнес-цель, функциональный «крестный отец» и ИТ-директор, фокусные процессы, требующие изменений и др.
2. Важны обеспеченность и вовлеченность людей
3. Партнёрские отношения в команде – функция управления проектом
4. Экономьте на работе со специалистами с отраслевой экспертизой
Источник: MilkLife.ru по материалам компании Константа