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

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

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

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

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

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

Антикейс №2

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

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

Результат:

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

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

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

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

• регламентированный учет;
• производственный учет;
• клиентский сервис;
• логистика.

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

Антикейс №3

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

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

Результат:

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

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

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

Антикейс №4

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

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

Результат:

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

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

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

Антикейс №5

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

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

Результат:

1. Лучший случай – «как-то работает».
2. Худший случай – не работает вообще (перевнедрение).
3. В 100% случаев – испорченные отношения с интегратором.

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

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

Антикейс №6

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

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

Результат:

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

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

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

Антикейс №7

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

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

Результат:

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

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

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

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