Почему оценки сроков и бюджетов автоматизации различаются втрое
Материал подготовлен совместно с партнером комьюнити Digital4food, компанией «Константа».
Представьте: вы автоматизируете логистику сырья или внедряете MES-систему. Три подрядчика дают оценки: 3 месяца, 6 и более 9. Бюджеты на внедрение различаются даже количеством нулей. Как разобраться, кто врет о сроках, жадничает и завышает бюджет?
Куда смотрит эксперт, когда говорит, что на вашем заводе обучение сотрудников займет в два раза больше времени, чем у конкурента? Ответ кроется в скрытых особенностях вашего проекта. Именно их видят опытные специалисты
Прошёл путь от программиста «1С» до руководителя более 300 проектов. Знает, где скрыты «грабли с топором». Спасает проекты автоматизации до их начала — проверяет, как люди и процессы переживут изменения.
Почему нельзя просто прийти и поставить программу как у всех?
Можно, если это изначально простой и понятный проект — например, если нужно поставить систему бухучета небольшой торговой компании. Сама область бухучета достаточно формализована, и масштаб предприятия небольшой, значит, там нет ничего специфического. Все данные уже есть, все процессы стандартные, нормативка единая для всех, да и бухгалтеры — дисциплинированные пользователи, которые быстро освоят новую программу и будут пользоваться ей строго по инструкции. Просто, как ездить на велосипеде.
Загвоздка в том, что 90% проектов автоматизации в пищевой промышленности — это как летать на самолете, каждый раз на разном. Для того чтобы он «взлетел», нужен эксперт — специалист, который делал похожие проекты, который понимает, что в пищепроме высокая вариативность процессов, разные каналы продаж, знает, что новая система не будет автономной, так как ее нужно будет встроить в сложный ИТ-ландшафт и состыковать с другими системами.
Этапы внедрения системы (диагностика, формирование требований, разработка и настройка, подготовка к запуску (включая обучение), запуск) одинаковы для любого проекта, но каждый нужно адаптировать под ваши процессы, людей и текущий уровень цифровизации. И вот здесь начинается разброс в оценках по срокам работы и бюджету в зависимости от насмотренности эксперта.
Этапы базовой технологии проекта
0. Концепт проекта — определение целей, границ, окружения, подходов и плана выполнения проекта.
1. Формализация требований к процессам и системе.
2. Моделирование учета в системе.
3. Настройка и доработка (дополнительного) функционала системы.
4. Разработка и настройка интеграций и обменов.
5. Подготовка и перенос начальных данных.
6. Обучение пользователей работе в системе.
7. Подготовка к запуску системы.
8. Запуск и поддержка промышленной эксплуатации системы.
Что влияет на срок и бюджет реализации проекта: смотрим глазами эксперта
Пять стартовых параметров вашего предприятия, которые двигают срок внедрения (больше срок = больше бюджет)
Нажмите на любой из параметров — вам откроется табличка, по которой вы сможете оценить время внедрения проекта (t). Если видите +2t, значит, смело умножайте срок реализации этапа на два, например с месяца до двух. Соответственно, сумму на этот этап тоже придется удвоить. Это неприятный процесс.
Если вам в какой-то момент начнет казаться, что вы раздуваете смету на пустом месте, просто представьте, что будет с проектом, когда он запустится с недостаточным финансированием и необъективными сроками внедрения. Это намного болезненнее. Выбить дополнительное финансирование уже не получится, а маховик времени все еще не изобрели.
Выдохните и вернитесь к объективным расчетам.
1. Исходный уровень автоматизации
Не автоматизирован: учет в тетрадях
Если у вас производственный учет ведется вручную (на бумаге или в разрозненных файлах), это самый сложный стартовый контекст из возможных. Кажется, что это археологическая редкость, но так тоже бывает: данные в цеху записывают в тетрадку, а потом относят в экономическую службу, где их вбивают в какую-то табличку.
В этом случае есть два сценария внедрения: первый — ставим «коробку» (стандартный функционал); второй — привлекаем функционального эксперта с похожего производства. Например, опытного технолога или начальника производства с такого же мясоперерабатывающего завода, у которого есть опыт постановки требований к MES-системе. Он понимает особенности технологического процесса, задачи. Он говорит на одном языке с вашими мастерами и технологами и уже прошел путь постановки учета с нуля. Он понимает не только особенности технологического процесса (температура, влажность, время созревания, точки контроля качества), но и то, какие именно данные нужно начинать фиксировать в первую очередь, чтобы уже через неделю получить первые цифры для сокращения потерь. Он не настраивает программу — он помогает построить процессы. Он проводит аудит, задает неудобные вопросы: «А почему сыр здесь лежит пять часов, а не четыре? Как вы сейчас учитываете брак? Куда деваются обрезки?» Он знает, какие KPI действительно работают на таком производстве, и поможет разработать формы отчетов, которые будут полезны не только бухгалтерии, но и начальнику смены прямо здесь и сейчас.
В любом случае процесс подготовки технологической производственной документации будет сложным и долгим, ведь предприятие никогда не вело эти данные. Обучение пользователей нужно закладывать в двойном-тройном размере. Запуск в промышленную эксплуатацию будет длинным, мучительным, болезненным.
Базовый учет: данные есть, но скопом
Представьте: на производстве уже не тетради. Мастера участков или начальники смен в конце дня/недели собирают данные по участкам и вбивают их куда-то, пусть даже в простую табличку или устаревшую систему. Учет есть, но он обобщенный, скопом, без детализации по переделам или операциям. Предприятие уже чувствует боль: данные недостаточно оперативны, не все критические точки (где теряются деньги) охвачены, точность хромает. Запрос на MES-систему для перехода к детальному, попередельному, оперативному учету здесь осознанный.
Что меняется в оценке эксперта:
- Формализация требований (глубже и сложнее). Эксперту придется копать глубже, чтобы понять, какие именно детализации нужны бизнесу для сокращения потерь и контроля качества. Этот этап потребует значительного времени вашего функционального заказчика (начальника производства, главного технолога) для совместной проработки.
- Моделирование (чаще пропускаем). Показывать, как это работает в типовом виде, бессмысленно, потому что предприятию нужен конкретный функционал под его задачи. Эксперт обычно предлагает сразу переходить к настройке/доработкам, минуя длительные демонстрации «из коробки».
- Настройка/Доработка (ключевой этап). Типовым функционалом не обойтись. Запросы бизнеса есть, значит, нужно закладывать дополнительное время на адаптацию системы. Опытный эксперт предложит делать это итерационно: прототип → обсуждение → доработка → следующий прототип.
- Обучение (все еще много!). Раньше учет вели 1−3 человека (мастера, начальники). Теперь систему будут использовать непосредственно на линии — операторы, аппаратчики. Нужно не просто научить их кнопки нажимать, а объяснить им, зачем это нужно, что от них теперь требуется, и добиться дисциплины ввода. Объем обучения — выше базового.
- Запуск (поэтапно, иначе сломаемся). Запустить всех пользователей разом в сложной MES — гарантированный хаос. Эксперт заложит поэтапный ввод по технологическим участкам (цех за цехом).
Высокая автоматизация. Система есть, но не тянет (перевнедрение)
Это когда MES (или другая система) уже работает, но недотягивает. Технология изменилась, появились новые продукты, требования к аналитике выросли — старая система не справляется. Нужно не просто обновление, а переезд на новую платформу/решение с сохранением нужного и добавлением недостающего.
Фокус эксперта смещается:
- Формализация требований (точечно и глубоко). Здесь точно знают, чего не хватает и что нужно изменить. Эксперт сосредоточится на детальной проработке именно этих болевых точек и новых требований. Для неизменяемых процессов можно взять текущую реализацию как основу, экономя время.
- Настройка/Доработка (фокус на развитии). Так как есть запрос на новые возможности, этот этап становится ключевым и ресурсоемким. Задача — не просто перенести старое, а сделать лучше под новые задачи.
- Перенос начальных данных (боль). Наследование данных из старой системы в новую — это отдельный проект со звездочкой. Глубина аналитики, нормативная база — все может различаться. Требуются дополнительные конвертации, ручные доработки, проверки. Время на этот этап закладывается с большим запасом.
- Обучение (точечное, но оно важно). Пользователи в целом знакомы с подобными системами. Усиливать нужно обучение только по новым функциям или сильно измененным процессам.
2. Наличие запросов на изменение процессов
Что мы делаем: переносим существующие процессы как есть на новую систему или меняем сами процессы, используя новую систему как инструмент для улучшений.
Просто переезд. Например, мы уходим с устаревшей УПП на современную ERP в торговле
Процессы клиентского сервиса (заказы, цены) переносим без революций. Это значит, что можно использовать готовые шаблоны процессов. Зато моделированию нужно уделить больше внимания, чтобы пользователи увидели свои старые процессы в новой системе. Это будет частью их адаптации.
Меняем процессы
Например, внедряем CRM, чтобы запустить новые стандарты продаж и сервиса. Это проект высокого риска:
- Формализация. Ключевой и самый долгий этап. Нужно глубоко погружаться с бизнес-владельцем, проектировать новые процессы, формулировать требования к системе под них. Требует много времени функционального заказчика.
- Моделирование. Критически важно. Через демонстрацию типового и адаптированного функционала договариваться, какие изменения процессов приемлемы с учетом возможностей системы. Без этого — бесконечные доработки или непринятие нового.
- Настройка. Объем зависит от того, насколько новые процессы отличаются от «коробки». Чем больше кастомных решений, тем выше риски и длиннее сроки.
- Обучение. Максимальный объем. Меняются и инструмент, и правила работы. Нужно не просто научить, а переучить.
- Запуск. Требует повышенного внимания. Двойной удар по пользователям: новая система + новые процессы. Риски срыва высоки.
3. Степень соответствия типового функционала
Насколько «коробочное» решение закрывает ваши потребности?
Логично, что ставить «коробку» быстрее, чем делать кастом. Самый сложный сценарий — когда заказчик понимает, что хочет получить, но непонятно, как новые требования лягут на типовой функционал. В таком случае честный эксперт предложит не оценивать весь проект сразу, а сначала провести диагностику, формализацию требований и моделирование. Это даст четкое понимание, попадем в «коробку» или в разработку. Только потом можно давать адекватную оценку внедрению. Это страхует и заказчика, и подрядчика.
4. Уровень вовлеченности функционального заказчика
Есть ли у проекта настоящий «хозяин» от бизнеса — тот, кто понимает, зачем это нужно, готов тратить время, принимать решения и нести ответственность за результат со своей стороны?
- Есть (вовлеченный и компетентный). Идеал. Проект идет по базовой или адаптированной технологии. Сроки предсказуемы.
- Нет (формальный или отсутствует). Книжные методики утверждают: «Нет функционального заказчика — нет проекта». Без него начинается игра вслепую. Выход из такой ситуации — создать гибридную команду из своих экспертов, подрядчика и представителя заказчика. Формализация требований станет мучительно долгой. Придется вытягивать требования, выступая и бизнес-аналитиком, и «адвокатом бизнеса». Запуск будет сложным.
5. Дисциплинированность пользователей
Готовы ли люди следовать регламентам? Или творчество и «авось» в крови? То, насколько интенсивно пользователи сопротивляются внедрению системы, напрямую влияет не только на эксплуатацию, но и на сроки внедрения.
- Высокая (бухгалтерия, финансы). Люди привыкли к порядку, но и тревожны. Им нужно четкое понимание изменений:
- Моделирование. Обязательно. Дает им уверенность, что все продумано.
- Обучение. Нужно подробное, по регламенту. Они будут учиться.
- Запуск. Обычно гладкий, если их хорошо подготовили.
- Низкая (продажники, некоторые производства). Не любят «формальности», «правила — для слабаков». С ними сложно:
- Моделирование. Нужно эксперту для фиксации договоренностей («Вот что обязаны делать в системе»).
- Обучение. Экономить! Они не любят учиться. Делать акцент на том, как это поможет им. Часть обучения переносить в опытную эксплуатацию.
- Запуск. Делать поэтапно, с активной поддержкой. Риски саботажа или некачественного ввода данных высоки.
Итог: где прячутся настоящие сроки?
Опытный эксперт, глядя на ваш проект через призму этих пяти параметров (и десятка других нюансов), увидит не абстрактные этапы, а конкретные точки приложения усилий.
Он понимает, что:
- На этапе формализации с тетрадками или при смене процессов придется провести не две недели, а два месяца.
- Перенос данных с устаревшей системы — это не копипаст, а отдельный подпроект.
- Обучение цеховых операторов займет в разы больше времени, чем обучение бухгалтеров.
- Запуск MES на голом производстве будет долгим и болезненным, и его нужно будет дробить на этапы.
Как выбрать не цифру, а результат
Итак, разброс в оценках — это не признак некомпетентности рынка. Это точный диагностический прибор, который показывает сложность вашего проекта. Цифры в три раза отличаются не потому, что кто-то врет, а потому, что разные специалисты с разной глубиной увидели ваши «грабли с топором», спрятанные в цехах, процессах и головах сотрудников.
Самая опасная оценка — не самая высокая, а самая оптимистичная. Она как билет на самолет, в который забыли залить топливо на весь путь: взлететь получится, а вот добраться до конечной точки — вряд ли. Проект, стартовавший с неадекватным бюджетом и в сжатые сроки, обречен на хронический стресс, бесконечные доработки «на коленке» и в итоге — на провал. Выбить деньги второй раз — невозможно, отыграть время — не на чем.
Поэтому, выбирая подрядчика, сравнивайте не итоговые цифры в коммерческих предложениях, а логику их появления.
_
Задайте каждому претенденту простые вопросы:
- «Какое время вы заложили на обучение наших мастеров, с учетом того что они сейчас работают с тетрадями?»
- «Какой запас по срокам вы заложили на этап формализации требований, видя, что наши процессы явно потребуют изменений?»
- «Как вы планируете работать с низкой дисциплиной продажников?»
Ответы на эти вопросы покажут, кто продает вам «коробку» с посредственной установкой, а кто действительно готов вести ваш сложный, уникальный «самолет» к цели.
_
Хорошее заключение — это не просто сумма этапов. Это стратегия, основанная на честности перед самим собой.
Сложные проекты автоматизации — это всегда марафон, а не спринт. И единственный способ его пробежать — это стартовать с тем запасом прочности (времени, денег и нервов), который диктует не красивая презентация, а суровая реальность вашего производства.
Вкладывайтесь в этап диагностики и формализации требований. Потратьте время и деньги до начала проекта, чтобы увидеть все риски и оценить их настоящую стоимость. Это единственный способ превратить тройной разброс в оценках в одну, но точную и реалистичную цифру — цифру вашего будущего успеха.
