Рекомендации по цифровизации молочного предприятия

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

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

Результат:

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

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

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

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

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

• Определить цель проекта (как бы это банально не звучало)

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

• Делать только то, что нужно делать, и не ломать того, что работает. 

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

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

2. Установка на входе: 

В ERP есть все 

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

Результат: 

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

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

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

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

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

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

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

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

• логистика 

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

3. Установка на входе: 

Сделать так же, как в старой системе, только на новой платформе

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

Результат: 

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

• Как работает система, знают только те, кто просил «сделать так же». 

И не дай Бог они куда-нибудь денутся. Потом проще будет не разобраться в этой системе, а опять же переделать все заново.

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

• Разобрать/пересобрать процесс (часто случается, что он не оптимален) 

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

• Привлечь консультантов со знанием нового продукта для моделирования этого процесса в новой системе 

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

4. Установка на входе: 

Внедрение системы – ответственность ИТ-специалистов

Ну это прямо-таки мое любимое

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

Результат: 

• Не внедрили совсем

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

• Получили нечто «около работающие»

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

• Конфликт между функциональными заказчиками и ИТ службой

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

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

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

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

5. Установка на входе: 

Мы нашли интегратора, который обещал все сделать в очень короткие сроки

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

Результат: 

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

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

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

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

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

• Делать минимум, с пониманием общей архитектуры 

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

6. Установка на входе: 

Выберем самое дешевое предложение 

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

Результат: 

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

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

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

7. Установка на входе: 

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

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

Результат: 

• Требуется кратно бóльший объем времени на привлечение бизнес-заказчиков.

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

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

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

Чтобы снизить риск, ищите интеграторов с отраслевым опытом.