Четыре месяца работы и команда из 11 человек дали результат, который бизнесу обычно показывать не хочется: система производственного планирования увеличила цикл в три-четыре раза. Для российской IT-аудитории это не курьез, а наглядный разбор того, как проект с очевидной на вид автоматизацией ломается о реальные данные и неформализованную экспертизу.
Habr Карьера опубликовал материал о внедрении планировщика на предприятии, чьи детали частично скрыли из-за соглашения о неразглашении. История знакомая любому, кто видел ERP-проекты: есть производственная программа, оборудование, технологические этапы, нормативы и ограничения по последовательности операций. На бумаге задача выглядела вполне инженерной. В цехе все оказалось сложнее.
Что хотели автоматизировать
До старта проекта технологи вручную собирали план за три-четыре часа и уверенно смотрели максимум на двое суток вперед. От системы ждали хотя бы устойчивый план на трое суток. В пике над проектом работали три технолога, два аналитика, четыре разработчика и два тестировщика.
Модель должна была распределять операции между 30 рабочими центрами семи типов. Формально первая версия справлялась: не падала, раскладывала операции по центрам и соблюдала последовательность переделов. Но технологам хватило нескольких минут, чтобы признать такой план бесполезным.
Почему формально правильный алгоритм сломал реальный процесс
Проблема была не в коде и не в интеграции. Алгоритм не видел, как ведет себя производство вживую. В графике возникали окна: оборудование уже освободилось, а следующая партия еще не готова. Если такой разрыв превышал допустимый интервал, по регламенту запускали дополнительную мойку или обслуживание. После этого линия простаивала еще дольше.
Один сдвиг на 30 минут на подготовительном этапе превращался в четыре-шесть часов потерь дальше по цепочке. Технолог вручную переставлял одну операцию, и линия снова входила в ритм. Объяснить выбор формулой он не мог. По сути, решение держалось на опыте, который не попал ни в требования, ни в модель.
Но это только половина истории.
Главная ошибка случилась не в разработке, а в постановке задачи. Команда изначально считала, что основной риск сидит в интеграции, а логика планирования достаточно понятна. Технологи предупреждали об обратном: производственные программы почти не повторяются, меняются номенклатура, объемы и последовательность операций. Каждый новый план приходится собирать заново. Этот сигнал слишком долго воспринимали как осторожность экспертов, а не как признак того, что ключевое решение пока не формализовано.
Как команда проверяла, можно ли спасти проект
После неудачной демонстрации проект едва не закрыли: бизнес уже оплатил несколько месяцев работы над системой, которая планировала хуже Excel. Вместо просьбы о новом бюджете команда выбрала дешевую и правильную проверку: понять, повторяются ли причины, по которым технологи вмешиваются в план вручную.
Логика была простой. Если каждая корректировка уникальна и зависит от слишком большого числа разовых обстоятельств, автоматизацию в текущем виде нужно останавливать. Если признаки повторяются, значит, у экспертизы есть структура, которую можно перенести в код. Аналитики не пытались сразу описать весь процесс целиком. Они разбирали реальные планы: где технолог вмешался, почему отверг альтернативы и каких последствий пытался избежать.
Что это значит для рынка
Для российских компаний это хороший холодный душ. Excel часто выигрывает не потому, что таблицы волшебные, а потому, что внутри процесса сидит человек, который держит в голове ограничения, не попавшие в систему. Для руководителей проектов вывод еще жестче: сырой, но проверяемый прототип нужно показывать как можно раньше, особенно если проект строится на экспертной логике. Иначе можно месяцами аккуратно собирать продукт, который безупречно реализует неверную гипотезу.
Следующий шаг в таких проектах всегда один и тот же: сначала доказать, что за интуицией эксперта стоит повторяемая схема принятия решений, и только потом масштабировать автоматизацию.