Как провалить проект автоматизации: пять самых популярных ошибок
![Как провалить проект автоматизации: пять самых популярных ошибок Как провалить проект автоматизации: пять самых популярных ошибок](/upload/iblock/7ec/xsebn076zcrj7gqyrqajyl9qywztbr2kh.jpg.pagespeed.ic.kVks_DXPnf.jpg)
время публикации: 10:00 12 августа 2024 года
@Freepic
![Роман Гнатко Как провалить проект автоматизации: пять самых популярных ошибок](/upload/medialibrary/ae4/xx4ob1e68euo1lll3lcym08xe1vuxsqp6.jpg.pagespeed.ic.JLPq8-_0_e.jpg)
На бизнес-мероприятиях все делятся успешными кейсами, а вот о провалах рассказывать не принято. Хотя согласно печальной статистике McKinsey, 70% проектов цифровой трансформации терпят неудачу.
Роман Гнатко, коммерческий директор компании НОРБИТ (входит в группу ЛАНИТ), называет пять самых популярных ошибок, допускаемых на проектах автоматизации, а также дает советы, как их избежать.
Любая автоматизация требует перестройки бизнес-процессов. Однако согласно исследованию NTT Data, 78% руководителей компаний рассматривают свою корпоративную культуру как препятствие для инноваций.
Производитель охлаждающих жидкостей для металлообрабатывающей промышленности, используя возможности ИИ, разработал систему, позволяющую с высокой точностью подбирать нужный тип хладагентов (веществ в холодильной машине) под специфический процесс. Раньше этим занимались эксперты компании, при этом точность составляла 50%, а затраты времени были просто колоссальными.
К сожалению, отличная идея так и не стала массовой. Руководство столкнулось с «итальянской забастовкой» своих же специалистов. Никто из них не оценил всех возможностей ноу-хау. Непосредственного участия в разработке они не принимали, а менеджмент компании не объяснил им, что новая умная система - не угроза для их будущего, а, наоборот, помощник, который избавит от рутины и позволит продавать больше.
В первую очередь нужно сосредоточить усилия на развитии внутри компании среды, которая будет поддерживать сотрудничество, любопытство и желание к исследованию, необходимые для успеха. Необходимо отказаться от автократии в принятии решений, когда право голоса имеет только топ-менеджмент. Также важно решить проблемы с ограниченным доступом к информации и ресурсам, которые препятствуют синергии команд, обмену экспертизой, вовлечению всех сотрудников в создание ценности для бизнеса.
В любом ИТ-проекте всегда есть несколько заинтересованных сторон с разными взглядами, приоритетами и уровнями знаний. Однако право принимать решения должно быть только у одного человека. Если это полномочие не зафиксировано, то возникает большой риск тупиковой ситуации - никто не захочет подписывать план, брать на себя ответственность за результат.
Российское подразделение международной компании запланировало внедрить у себя систему штрихкодирования. Так как компания уже использовала общую глобальную ERP, то сразу появился ряд ограничений при выборе решения. К тому же, для внедрения продукта требовались доработки и самой ERP-системы, поэтому к проекту подключились зарубежные сотрудники головного офиса.
Проблема заключалась в том, что к проекту подошли «демократично» - его лидировали двое: руководитель проекта от региона, в котором решили использовать новый инструмент, и представитель головного офиса. Камнем преткновения стал выбор подрядчика. Противоборство сторон продолжалось практически все шесть месяцев проекта. В итоге «сожгли» большую часть бюджета проекта, сорвали график, а руководителя проекта впоследствии отстранили.
Чтобы выйти из кризиса, решились на перезапуск. Выделили дополнительный бюджет, установили новые сроки. Команду пересобрали, для управления наняли российского менеджера проекта, а еще назначили прямых ответственных среди директората. Систему все-таки удалось реализовать: не в полном объеме и за более долгий срок, но формально все закончилось неплохо.
![Как провалить проект автоматизации: пять самых популярных ошибок Как провалить проект автоматизации: пять самых популярных ошибок](/upload/medialibrary/946/x5ejj4uqn6no3rq3yos61vs005j4nph3z.jpg.pagespeed.ic.8o2eL1u7QH.jpg)
@Freepic
Отсутствие поддержки со стороны руководства почти гарантированно приведет к краху, ведь от нее зависит финансирование, ресурсы и четкие цели. А еще это гарантия того, что проект будет связан с общей бизнес-стратегией компании. Поэтому стоит обеспечить такое лобби заранее, еще до того, как стартуют какие-то действия.
Опишу кейс, который даже не превратился в проект, а остался только на уровне инициативы – автоматизация работы с рекламациями (претензиями). Задача крайне важная, так как рекламации - болевая точка любого отдела закупок и снабжения. А еще ценный источник данных о том, как работают сотрудники, поставщики, логисты, а иногда и сами заявители. Так что желание отдела снабжения и бизнес-подразделения одной российской компании сделать процесс работы с рекламациями системным и прозрачным вполне логично.
Они проработали этапы бизнес-процесса, учли интересы и мнения всех вовлеченных, а их было действительно очень много. Параллельно решили использовать внутреннюю разработку на основе общедоступного инструмента, не требующего дополнительного лицензирования и с минимальными доработками для учетной системы. Казалось бы, все должно было «взлететь». Но руководство ИТ-подразделения попросило визу топ-менеджера, курирующего это направление, чтобы выделить своего разработчика.
Спойлер – визу получить не удалось, причины нерешительности также остались невыясненными. Процесс так и не был автоматизирован.
Читайте также: Законодательство, автоматизация бизнеса и маркетинг: как сегодня связаны эти сферы
Часто синхронизировать два этих масштабных и одинаково важных направления никто не планирует. Хотя гораздо эффективнее подход, при котором в ходе автоматизации основные положения регламента компании используются как функциональные требования и реализуются в системе. В ней они работают как ограничения или правила при организации бизнес-процессов. Если этого не сделать, регламент соблюдаться не будет и тому есть реальное подтверждение.
В крупной компании запланировали переход на новую версию учетной системы, за которым бы последовала оптимизация всех бизнес-процессов. Отдельная часть этого амбициозного проекта касалась управления снабжением. Был привлечен солидный исполнитель из состава «Большой четвёрки» (четыре крупнейшие компании, предоставляющих аудиторские и консалтинговые услуги: Deloitte, PricewaterhouseCoopers, Ernst & Young и KPMG), а также целая команда специалистов и консультантов. Определили спонсоров, написали устав, выделили бюджет.
Проект был долгий и очень сложный. Несмотря на все трудности, он благополучно завершился. Но вскоре после этого в компании вдруг выпустили новую политику по снабжению. Она определяла принципы, которыми должны были руководствоваться сотрудники, чтобы соблюдать экономичность, прозрачность и эффективность закупок. Однако правила, описанные в ней, частично противоречили тем, что использовались в учетной системе, или вообще не были в ней отражены.
Политика встретила жесточайшее сопротивление на местах. Рядовые сотрудники и руководители всех уровней порядочно натерпелись с первым проектом и совсем не были готовы еще к одному. Политика содержала много абстрактных положений, которые вне системы либо игнорировались сотрудниками, либо открыто обходились. Все случаи противоречий между системой и политикой трактовались в пользу первой. Никого не интересовало, какие риски это несет.
Чтобы обеспечить соблюдение политики потребовалось разработать целый сонм инструкций, шаблонов, костылей и заплаток, контроль за использованием которых осуществлялся в основном вручную.
Без чистых и структурированных данных о бизнес-процессах не может быть качественного управления. Именно они становятся краеугольным камнем принятия обоснованных стратегических решений. Однако получение и поддержание их высокого качества может быть сложной задачей из-за огромного объема и скорости, с которой они генерируются. Если верить статистике, почти у половины небольших и средних российских компаний данные все еще не подготовлены для цифровизации.
Проблема актуальна и для крупного бизнеса. Вполне жизненная история случилась с международной производственной компанией.
Развиваясь поэтапно, она активно разрасталась благодаря слияниям и поглощениям, а каждый из новых активов встраивался в общую ИТ-вселенную вместе со своими специфическими процессами и, конечно, данными. К определенному моменту номенклатура в справочниках достигла более полумиллиона позиций, но в заказах фигурировали лишь 20% из них. Очевидно, основная часть дублировалась или содержала ошибки. При этом объем данных продолжал стремительно расти.
Оценив неутешительные итоги решено было заняться чисткой и обогащением, а для этого нужны деньги и ресурсы. В бизнес-юнитах организовали свои локальные проекты, собрали команды, нашли внутренних и внешних исполнителей. Общий бюджет превысил миллион долларов.
В конце года с гордостью отчитались о достигнутых результатах. Однако в компании не было системы MDM (управления мастер-данными) – единого источника данных, где они централизуются и стандартизируются, а затем уже используются в различных процессах и приложениях. Поэтому по прошествии года (на следующий цикл очистки и обогащения данных) потратили более полумиллиона долларов, в следующий - еще столько же. Так продолжалось из года в год. Инициатива превратилась в настоящую черную дыру для бюджета.
Позаботьтесь о плане Б. Риск-менеджмент должен охватывать вопросы инициирования и планирования проекта, технические запросы и требования, оркестрацию вовлеченных сторон и команды, проблемы управления проектом. Будьте готовы к сложностям и заранее продумайте стратегию на случай непредвиденных обстоятельств.
Больше половины проектов по автоматизации в самых разных направлениях не приводят к результату. В компаниях не любят об этом рассказывать, ведь каждый такой безуспешный проект вскрывает серьезные административные ошибки или сбои в коммуникации между департаментами. Разберем 5 наиболее распространенных сценариев, когда система дала сбой.
![Роман Гнатко Как провалить проект автоматизации: пять самых популярных ошибок](/upload/medialibrary/ae4/xx4ob1e68euo1lll3lcym08xe1vuxsqp6.jpg.pagespeed.ic.JLPq8-_0_e.jpg)
На бизнес-мероприятиях все делятся успешными кейсами, а вот о провалах рассказывать не принято. Хотя согласно печальной статистике McKinsey, 70% проектов цифровой трансформации терпят неудачу.
Роман Гнатко, коммерческий директор компании НОРБИТ (входит в группу ЛАНИТ), называет пять самых популярных ошибок, допускаемых на проектах автоматизации, а также дает советы, как их избежать.
1. «Итальянская забастовка»: внутренняя культура компании не готова к инновациям
Любая автоматизация требует перестройки бизнес-процессов. Однако согласно исследованию NTT Data, 78% руководителей компаний рассматривают свою корпоративную культуру как препятствие для инноваций.
Производитель охлаждающих жидкостей для металлообрабатывающей промышленности, используя возможности ИИ, разработал систему, позволяющую с высокой точностью подбирать нужный тип хладагентов (веществ в холодильной машине) под специфический процесс. Раньше этим занимались эксперты компании, при этом точность составляла 50%, а затраты времени были просто колоссальными.
К сожалению, отличная идея так и не стала массовой. Руководство столкнулось с «итальянской забастовкой» своих же специалистов. Никто из них не оценил всех возможностей ноу-хау. Непосредственного участия в разработке они не принимали, а менеджмент компании не объяснил им, что новая умная система - не угроза для их будущего, а, наоборот, помощник, который избавит от рутины и позволит продавать больше.
В первую очередь нужно сосредоточить усилия на развитии внутри компании среды, которая будет поддерживать сотрудничество, любопытство и желание к исследованию, необходимые для успеха. Необходимо отказаться от автократии в принятии решений, когда право голоса имеет только топ-менеджмент. Также важно решить проблемы с ограниченным доступом к информации и ресурсам, которые препятствуют синергии команд, обмену экспертизой, вовлечению всех сотрудников в создание ценности для бизнеса.
2. Излишняя «демократичность» и разногласия в команде
В любом ИТ-проекте всегда есть несколько заинтересованных сторон с разными взглядами, приоритетами и уровнями знаний. Однако право принимать решения должно быть только у одного человека. Если это полномочие не зафиксировано, то возникает большой риск тупиковой ситуации - никто не захочет подписывать план, брать на себя ответственность за результат.
Российское подразделение международной компании запланировало внедрить у себя систему штрихкодирования. Так как компания уже использовала общую глобальную ERP, то сразу появился ряд ограничений при выборе решения. К тому же, для внедрения продукта требовались доработки и самой ERP-системы, поэтому к проекту подключились зарубежные сотрудники головного офиса.
Проблема заключалась в том, что к проекту подошли «демократично» - его лидировали двое: руководитель проекта от региона, в котором решили использовать новый инструмент, и представитель головного офиса. Камнем преткновения стал выбор подрядчика. Противоборство сторон продолжалось практически все шесть месяцев проекта. В итоге «сожгли» большую часть бюджета проекта, сорвали график, а руководителя проекта впоследствии отстранили.
Чтобы выйти из кризиса, решились на перезапуск. Выделили дополнительный бюджет, установили новые сроки. Команду пересобрали, для управления наняли российского менеджера проекта, а еще назначили прямых ответственных среди директората. Систему все-таки удалось реализовать: не в полном объеме и за более долгий срок, но формально все закончилось неплохо.
![Как провалить проект автоматизации: пять самых популярных ошибок Как провалить проект автоматизации: пять самых популярных ошибок](/upload/medialibrary/946/x5ejj4uqn6no3rq3yos61vs005j4nph3z.jpg.pagespeed.ic.8o2eL1u7QH.jpg)
@Freepic
3. Нет лобби со стороны руководства
Отсутствие поддержки со стороны руководства почти гарантированно приведет к краху, ведь от нее зависит финансирование, ресурсы и четкие цели. А еще это гарантия того, что проект будет связан с общей бизнес-стратегией компании. Поэтому стоит обеспечить такое лобби заранее, еще до того, как стартуют какие-то действия.
Опишу кейс, который даже не превратился в проект, а остался только на уровне инициативы – автоматизация работы с рекламациями (претензиями). Задача крайне важная, так как рекламации - болевая точка любого отдела закупок и снабжения. А еще ценный источник данных о том, как работают сотрудники, поставщики, логисты, а иногда и сами заявители. Так что желание отдела снабжения и бизнес-подразделения одной российской компании сделать процесс работы с рекламациями системным и прозрачным вполне логично.
Они проработали этапы бизнес-процесса, учли интересы и мнения всех вовлеченных, а их было действительно очень много. Параллельно решили использовать внутреннюю разработку на основе общедоступного инструмента, не требующего дополнительного лицензирования и с минимальными доработками для учетной системы. Казалось бы, все должно было «взлететь». Но руководство ИТ-подразделения попросило визу топ-менеджера, курирующего это направление, чтобы выделить своего разработчика.
Спойлер – визу получить не удалось, причины нерешительности также остались невыясненными. Процесс так и не был автоматизирован.
Читайте также: Законодательство, автоматизация бизнеса и маркетинг: как сегодня связаны эти сферы
4. «Моя твоя не понимать»: отсутствует связь между автоматизацией и регламентацией
Часто синхронизировать два этих масштабных и одинаково важных направления никто не планирует. Хотя гораздо эффективнее подход, при котором в ходе автоматизации основные положения регламента компании используются как функциональные требования и реализуются в системе. В ней они работают как ограничения или правила при организации бизнес-процессов. Если этого не сделать, регламент соблюдаться не будет и тому есть реальное подтверждение.
В крупной компании запланировали переход на новую версию учетной системы, за которым бы последовала оптимизация всех бизнес-процессов. Отдельная часть этого амбициозного проекта касалась управления снабжением. Был привлечен солидный исполнитель из состава «Большой четвёрки» (четыре крупнейшие компании, предоставляющих аудиторские и консалтинговые услуги: Deloitte, PricewaterhouseCoopers, Ernst & Young и KPMG), а также целая команда специалистов и консультантов. Определили спонсоров, написали устав, выделили бюджет.
Проект был долгий и очень сложный. Несмотря на все трудности, он благополучно завершился. Но вскоре после этого в компании вдруг выпустили новую политику по снабжению. Она определяла принципы, которыми должны были руководствоваться сотрудники, чтобы соблюдать экономичность, прозрачность и эффективность закупок. Однако правила, описанные в ней, частично противоречили тем, что использовались в учетной системе, или вообще не были в ней отражены.
Политика встретила жесточайшее сопротивление на местах. Рядовые сотрудники и руководители всех уровней порядочно натерпелись с первым проектом и совсем не были готовы еще к одному. Политика содержала много абстрактных положений, которые вне системы либо игнорировались сотрудниками, либо открыто обходились. Все случаи противоречий между системой и политикой трактовались в пользу первой. Никого не интересовало, какие риски это несет.
Чтобы обеспечить соблюдение политики потребовалось разработать целый сонм инструкций, шаблонов, костылей и заплаток, контроль за использованием которых осуществлялся в основном вручную.
5. Хаос в данных
Без чистых и структурированных данных о бизнес-процессах не может быть качественного управления. Именно они становятся краеугольным камнем принятия обоснованных стратегических решений. Однако получение и поддержание их высокого качества может быть сложной задачей из-за огромного объема и скорости, с которой они генерируются. Если верить статистике, почти у половины небольших и средних российских компаний данные все еще не подготовлены для цифровизации.
Проблема актуальна и для крупного бизнеса. Вполне жизненная история случилась с международной производственной компанией.
Развиваясь поэтапно, она активно разрасталась благодаря слияниям и поглощениям, а каждый из новых активов встраивался в общую ИТ-вселенную вместе со своими специфическими процессами и, конечно, данными. К определенному моменту номенклатура в справочниках достигла более полумиллиона позиций, но в заказах фигурировали лишь 20% из них. Очевидно, основная часть дублировалась или содержала ошибки. При этом объем данных продолжал стремительно расти.
Оценив неутешительные итоги решено было заняться чисткой и обогащением, а для этого нужны деньги и ресурсы. В бизнес-юнитах организовали свои локальные проекты, собрали команды, нашли внутренних и внешних исполнителей. Общий бюджет превысил миллион долларов.
В конце года с гордостью отчитались о достигнутых результатах. Однако в компании не было системы MDM (управления мастер-данными) – единого источника данных, где они централизуются и стандартизируются, а затем уже используются в различных процессах и приложениях. Поэтому по прошествии года (на следующий цикл очистки и обогащения данных) потратили более полумиллиона долларов, в следующий - еще столько же. Так продолжалось из года в год. Инициатива превратилась в настоящую черную дыру для бюджета.
Позаботьтесь о плане Б. Риск-менеджмент должен охватывать вопросы инициирования и планирования проекта, технические запросы и требования, оркестрацию вовлеченных сторон и команды, проблемы управления проектом. Будьте готовы к сложностям и заранее продумайте стратегию на случай непредвиденных обстоятельств.
Роман Гнатко,
коммерческий директор компании НОРБИТ (входит в группу ЛАНИТ).
Для NEW RETAIL
0