Семь антикейсов цифровизации предприятий

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

Почему именно я?

  • Уже 8 лет работаю в продажах и реализации ИТ-проектов.

  • За это время обработал больше тысячи различных запросов от клиентов.

  • Был участником более чем 80 проектов автоматизации (внедрение ERP, MES, WMS, CRM и прочих решений).

  • Четко знаю, с какими позициями  люди приходят в начале и что получается в конце. Как раз об этом и поговорим.

Статью построю в формате антикейсов. Разберу установку на входе (с чем приходит клиент), расскажу, к чему это приводит, дам рекомендации.

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

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

Антикейс 1.

Установка на входе: работаем в одной базе (например, УПП) – надо сделать в ERP тоже «всё в одной базе».

Можно много рассуждать – одна база или несколько. Сейчас речь не об этом. Речь о том, что мы привыкли работать в одной базе и хотим дальше продолжать работать в одной базе.

Результат:

  • Очень болезненные обновления.

  • Оперативный учет за рамками системы (например, в Excel).

Какой из этих двух результатов мы получим, зависит от того, кто победит. Если победит финансовая служба завода, которой важны обновления системы, она не даст сильно доработать оперативный учет, и поэтому весь оперативный учет будет где-то за скобками. В лучшем случае он будет в старой системе (хотя планировали в новой). В худшем – вообще где-нибудь в Excel, потому что в старой системе работать запретили.

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

Рекомендации:

  • Определить цель проекта (как бы это банально не звучало). Тут, как правило, есть две ветки: проект или технический (надо перейти на новую платформу, потому что старая не поддерживается), или бизнесовый. Если технический, то вторая рекомендация:

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

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

Антикейс 2.

Установка на входе: в ERP есть всё.

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

Результат:

  • Продукт внедряется в части регламентированного учета и финансового контроллинга.

  • Оперативный учет вообще не работает в этой системе либо работает только для обеспечения целей регламентированного учета.

У нас был случай, когда в одном из проектов клиент даже документ «Заказы» не внедрил, а делал только первичную документацию – «Реализации».

Рекомендации:

Не смотрите в ERP как в программу. Посмотрите на проект как минимум из четырех контуров:

  • регламентированный учет;

  • производственный учет;

  • клиентский сервис;

  • логистика.

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

Антикейс 3.

Установка на входе: сделать так же, как в старой системе, только на новой платформе.

Особенно часто такая установка бывает у предприятий, которые идут на проект не по собственному желанию, а вынужденно – под влиянием тех или иных внешних факторов (например, отмена поддержки программного продукта). То есть люди уже привыкли работать определенным образом и для чего нужны изменения, им непонятно. Желания что-то менять, соответственно, у них нет. Отсюда и подход: «хотите – меняйте платформу, но не ломайте мою работу, сделайте всё как в старой». Ситуация, когда люди неспособны слушать, слышать и меняться, очень пагубна для проекта.

Результат:

  • 100% «исковерканная» архитектура, которую невозможно обновлять или обновления длятся по полгода. Чаще всего в таких случаях через какое-то время происходит перевнедрение системы.

  • Как работает система, знают только те, кто просил «сделать так же». И не дай Бог, они куда-нибудь денутся,  – потом проще будет не разобраться в этой системе, а опять же переделать всё заново.

Рекомендации:

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

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

Антикейс 4.

Установка на входе: внедрение системы – ответственность ИТ-специалистов.

Ну это прямо-таки мое любимое. Долго описывать не буду. Думаю, каждый и так понимает, о чем речь (особенно сами ИТ-специалисты). Расскажу лучше, к чему приводит такая установка.

Результат:

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

  • Получили нечто «около работающее». Когда руководство, например, настояло на своем и как-то административно повлияло на людей без их желания.

  • Конфликт между функциональными заказчиками и ИТ-службой. Потому что: «Чего они пришли со своей системой? У нас и так всё хорошо, а тут надо что-то еще и делать». Естественно, в такой парадигме качественного результата добиться очень сложно.

Рекомендации:

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

Антикейс 5.

Установка на входе: мы нашли интегратора, который обещал всё сделать в очень короткие сроки.

Бывает, когда понадеялись на русское «авось». Либо очень долго принимали решение: делать или не делать. Либо требование регулятора сверху упало нежданно-негаданно. В общем, дотерпели, и не делать уже нельзя. И вот находится интегратор, который говорит: «Ну да, сроки сжатые, конечно, но мы готовы помочь».

Результат:

  • Лучший случай – как-то работает.

  • Худший случай – не работает вообще (необходимо перевнедрение).

  • В 100% случаев – испорченные отношения с интегратором.

Рекомендации:

  • Включать в процедуру выбора минимум 3-4 интеграторов, и если большинство из них говорят, что «сроки слишком сжаты», – верьте большинству.

  • Делать минимум, с пониманием общей архитектуры. Выделяем MVP-продукт и внедряем его. Но, что очень важно: внедряем с пониманием дальнейшего развития всей архитектуры. Чтобы то, что мы делаем сегодня, не противоречило тому, что мы будем делать завтра. 

Антикейс 6.

Установка на входе: выберем самое дешевое предложение.

Здесь много писать не буду. Благо сейчас (видимо, уже на опыте) рынок стал понимать, что самое дешевое – не есть хорошее.

Результат:

  • Бесплатный сыр – только в мышеловке.

Рекомендации:

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

Антикейс 7.

Установка на входе: дайте нам того, кто хорошо знает продукт, мы сами обогатим команду отраслевым опытом.

Сразу скажу, что эта установка зачастую работает. Иногда такие проекты бывают более чем успешными. Но тут важно понимать: в случае когда у вас в ИТ-команде нет отраслевого опыта, вы его компенсируете за счет подключения бизнес-заказчика.  

Результат:

  • Требуется кратно больший объем времени на привлечение бизнес-заказчиков. В зависимости от сложности проекта на старте бизнес-заказчикам придется уделять ему 50-60% своего времени. Вопрос: есть ли у них это время?

Рекомендации:

  • С самого начала обогащайте внедренческую команду отраслевой экспертизой. Чтобы снизить риск, ищите интеграторов с отраслевым опытом.

Опубликовано 05.09.2023

Похожие статьи