Почему оценки сроков и бюджетов автоматизации различаются втрое

Не автоматизирован: учет в тетрадях

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

В этом случае есть два сценария внедрения: первый — ставим «коробку» (стандартный функционал); второй — привлекаем функционального эксперта с похожего производства. Например, опытного технолога или начальника производства с такого же мясоперерабатывающего завода, у которого есть опыт постановки требований к MES-системе. Он понимает особенности технологического процесса, задачи. Он говорит на одном языке с вашими мастерами и технологами и уже прошел путь постановки учета с нуля. Он понимает не только особенности технологического процесса (температура, влажность, время созревания, точки контроля качества), но и то, какие именно данные нужно начинать фиксировать в первую очередь, чтобы уже через неделю получить первые цифры для сокращения потерь. Он не настраивает программу — он помогает построить процессы. Он проводит аудит, задает неудобные вопросы: «А почему сыр здесь лежит пять часов, а не четыре? Как вы сейчас учитываете брак? Куда деваются обрезки?» Он знает, какие KPI действительно работают на таком производстве, и поможет разработать формы отчетов, которые будут полезны не только бухгалтерии, но и начальнику смены прямо здесь и сейчас.

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

Базовый учет: данные есть, но скопом

Представьте: на производстве уже не тетради. Мастера участков или начальники смен в конце дня/недели собирают данные по участкам и вбивают их куда-то, пусть даже в простую табличку или устаревшую систему. Учет есть, но он обобщенный, скопом, без детализации по переделам или операциям. Предприятие уже чувствует боль: данные недостаточно оперативны, не все критические точки (где теряются деньги) охвачены, точность хромает. Запрос на MES-систему для перехода к детальному, попередельному, оперативному учету здесь осознанный.

Что меняется в оценке эксперта:

• Формализация требований (глубже и сложнее). Эксперту придется копать глубже, чтобы понять, какие именно детализации нужны бизнесу для сокращения потерь и контроля качества. Этот этап потребует значительного времени вашего функционального заказчика (начальника производства, главного технолога) для совместной проработки.
• Моделирование (чаще пропускаем). Показывать, как это работает в типовом виде, бессмысленно, потому что предприятию нужен конкретный функционал под его задачи. Эксперт обычно предлагает сразу переходить к настройке/доработкам, минуя длительные демонстрации «из коробки».
• Настройка/Доработка (ключевой этап). Типовым функционалом не обойтись. Запросы бизнеса есть, значит, нужно закладывать дополнительное время на адаптацию системы. Опытный эксперт предложит делать это итерационно: прототип → обсуждение → доработка → следующий прототип.
• Обучение (все еще много!). Раньше учет вели 1−3 человека (мастера, начальники). Теперь систему будут использовать непосредственно на линии — операторы, аппаратчики. Нужно не просто научить их кнопки нажимать, а объяснить им, зачем это нужно, что от них теперь требуется, и добиться дисциплины ввода. Объем обучения — выше базового.
• Запуск (поэтапно, иначе сломаемся). Запустить всех пользователей разом в сложной MES — гарантированный хаос. Эксперт заложит поэтапный ввод по технологическим участкам (цех за цехом).

Высокая автоматизация. Система есть, но не тянет (перевнедрение)

Это когда MES (или другая система) уже работает, но недотягивает. Технология изменилась, появились новые продукты, требования к аналитике выросли — старая система не справляется. Нужно не просто обновление, а переезд на новую платформу/решение с сохранением нужного и добавлением недостающего.

Фокус эксперта смещается:

• Формализация требований (точечно и глубоко). Здесь точно знают, чего не хватает и что нужно изменить. Эксперт сосредоточится на детальной проработке именно этих болевых точек и новых требований. Для неизменяемых процессов можно взять текущую реализацию как основу, экономя время.
• Настройка/Доработка (фокус на развитии). Так как есть запрос на новые возможности, этот этап становится ключевым и ресурсоемким. Задача — не просто перенести старое, а сделать лучше под новые задачи.
• Перенос начальных данных (боль). Наследование данных из старой системы в новую — это отдельный проект со звездочкой. Глубина аналитики, нормативная база — все может различаться. Требуются дополнительные конвертации, ручные доработки, проверки. Время на этот этап закладывается с большим запасом.
• Обучение (точечное, но оно важно). Пользователи в целом знакомы с подобными системами. Усиливать нужно обучение только по новым функциям или сильно измененным процессам.

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

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

Меняем процессы
Например, внедряем CRM, чтобы запустить новые стандарты продаж и сервиса. Это проект высокого риска:

• Формализация. Ключевой и самый долгий этап. Нужно глубоко погружаться с бизнес-владельцем, проектировать новые процессы, формулировать требования к системе под них. Требует много времени функционального заказчика.
• Моделирование. Критически важно. Через демонстрацию типового и адаптированного функционала договариваться, какие изменения процессов приемлемы с учетом возможностей системы. Без этого — бесконечные доработки или непринятие нового.
• Настройка. Объем зависит от того, насколько новые процессы отличаются от «коробки». Чем больше кастомных решений, тем выше риски и длиннее сроки.
• Обучение. Максимальный объем. Меняются и инструмент, и правила работы. Нужно не просто научить, а переучить.
• Запуск. Требует повышенного внимания. Двойной удар по пользователям: новая система + новые процессы. Риски срыва высоки.

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

Есть ли у проекта настоящий «хозяин» от бизнеса — тот, кто понимает, зачем это нужно, готов тратить время, принимать решения и нести ответственность за результат со своей стороны?

• Есть (вовлеченный и компетентный). Идеал. Проект идет по базовой или адаптированной технологии. Сроки предсказуемы.
• Нет (формальный или отсутствует). Книжные методики утверждают: «Нет функционального заказчика — нет проекта». Без него начинается игра вслепую. Выход из такой ситуации — создать гибридную команду из своих экспертов, подрядчика и представителя заказчика. Формализация требований станет мучительно долгой. Придется вытягивать требования, выступая и бизнес-аналитиком, и «адвокатом бизнеса». Запуск будет сложным.

Готовы ли люди следовать регламентам? Или творчество и «авось» в крови? То, насколько интенсивно пользователи сопротивляются внедрению системы, напрямую влияет не только на эксплуатацию, но и на сроки внедрения.

• Высокая (бухгалтерия, финансы). Люди привыкли к порядку, но и тревожны. Им нужно четкое понимание изменений:

1. Моделирование. Обязательно. Дает им уверенность, что все продумано.
2. Обучение. Нужно подробное, по регламенту. Они будут учиться.
3. Запуск. Обычно гладкий, если их хорошо подготовили.

• Низкая (продажники, некоторые производства). Не любят «формальности», «правила — для слабаков». С ними сложно:

1. Моделирование. Нужно эксперту для фиксации договоренностей («Вот что обязаны делать в системе»).
2. Обучение. Экономить! Они не любят учиться. Делать акцент на том, как это поможет им. Часть обучения переносить в опытную эксплуатацию.
3. Запуск. Делать поэтапно, с активной поддержкой. Риски саботажа или некачественного ввода данных высоки.