Как провалить проект автоматизации: пять самых популярных ошибок

@Freepic

На бизнес-мероприятиях все делятся успешными кейсами, а вот о провалах рассказывать не принято. Хотя согласно печальной статистике McKinsey, 70% проектов цифровой трансформации терпят неудачу. 

Роман Гнатко, коммерческий директор компании НОРБИТ (входит в группу ЛАНИТ), называет пять самых популярных ошибок, допускаемых на проектах автоматизации, а также дает советы, как их избежать. 

1. «Итальянская забастовка»: внутренняя культура компании не готова к инновациям

Любая автоматизация требует перестройки бизнес-процессов. Однако согласно исследованию NTT Data, 78% руководителей компаний рассматривают свою корпоративную культуру как препятствие для инноваций. 

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

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

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

2. Излишняя «демократичность» и разногласия в команде

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

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

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

Чтобы выйти из кризиса, решились на перезапуск. Выделили дополнительный бюджет, установили новые сроки. Команду пересобрали, для управления наняли российского менеджера проекта, а еще назначили прямых ответственных среди директората. Систему все-таки удалось реализовать: не в полном объеме и за более долгий срок, но формально все закончилось неплохо.


@Freepic

3. Нет лобби со стороны руководства

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

Опишу кейс, который даже не превратился в проект, а остался только на уровне инициативы – автоматизация работы с рекламациями (претензиями). Задача крайне важная, так как рекламации - болевая точка любого отдела закупок и снабжения. А еще ценный источник данных о том, как работают сотрудники, поставщики, логисты, а иногда и сами заявители. Так что желание отдела снабжения и бизнес-подразделения одной российской компании сделать процесс работы с рекламациями системным и прозрачным вполне логично. 

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

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

---

Читайте также: Законодательство, автоматизация бизнеса и маркетинг: как сегодня связаны эти сферы

---

4. «Моя твоя не понимать»: отсутствует связь между автоматизацией и регламентацией

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

В крупной компании запланировали переход на новую версию учетной системы, за которым бы последовала оптимизация всех бизнес-процессов. Отдельная часть этого амбициозного проекта касалась управления снабжением. Был привлечен солидный исполнитель из состава «Большой четвёрки» (четыре крупнейшие компании, предоставляющих аудиторские и консалтинговые услуги: Deloitte, PricewaterhouseCoopers, Ernst & Young и KPMG), а также целая команда специалистов и консультантов. Определили спонсоров, написали устав, выделили бюджет. 

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

Политика встретила жесточайшее сопротивление на местах. Рядовые сотрудники и руководители всех уровней порядочно натерпелись с первым проектом и совсем не были готовы еще к одному. Политика содержала много абстрактных положений, которые вне системы либо игнорировались сотрудниками, либо открыто обходились. Все случаи противоречий между системой и политикой трактовались в пользу первой. Никого не интересовало, какие риски это несет. 

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

5. Хаос в данных

Без чистых и структурированных данных о бизнес-процессах не может быть качественного управления. Именно они становятся краеугольным камнем принятия обоснованных стратегических решений. Однако получение и поддержание их высокого качества может быть сложной задачей из-за огромного объема и скорости, с которой они генерируются. Если верить статистике, почти у половины небольших и средних российских компаний данные все еще не подготовлены для цифровизации.

Проблема актуальна и для крупного бизнеса. Вполне жизненная история случилась с международной производственной компанией. 

Развиваясь поэтапно, она активно разрасталась благодаря слияниям и поглощениям, а каждый из новых активов встраивался в общую ИТ-вселенную вместе со своими специфическими процессами и, конечно, данными. К определенному моменту номенклатура в справочниках достигла более полумиллиона позиций, но в заказах фигурировали лишь 20% из них. Очевидно, основная часть дублировалась или содержала ошибки. При этом объем данных продолжал стремительно расти. 

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

В конце года с гордостью отчитались о достигнутых результатах. Однако в компании не было системы MDM (управления мастер-данными) – единого источника данных, где они централизуются и стандартизируются, а затем уже используются в различных процессах и приложениях. Поэтому по прошествии года (на следующий цикл очистки и обогащения данных) потратили более полумиллиона долларов, в следующий - еще столько же. Так продолжалось из года в год. Инициатива превратилась в настоящую черную дыру для бюджета.

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

Роман Гнатко, 
коммерческий директор компании НОРБИТ (входит в группу ЛАНИТ).

Для NEW RETAIL