Подручный сталевара берёт пробу химсостава металла на установке печь-ковш
Привет с Новолипецкого металлургического комбината! В крупном проекте самое ценное — данные. В нашем случае — технологические карты производства и параметры всех изделий и агрегатов: как и что мы делаем, на чём, как долго, и какие параметры каким образом влияют на результат.
Производство — живая система: возникают новые процессы, изменяются существующие, перестраиваются агрегаты, меняется код. Мы построили процесс так, что, когда что-то начинает производиться, все актуальные данные уже есть в системе. Код и данные не отстают, не опережают, а идут рука об руку.
У нас есть два гипермозга:
- Календарное планирование играет в оптимизацию на стороне клиентов. Оно знает, что нужно производить и когда, чтобы отгрузить заказы максимально оперативно и вовремя.
- Графикователи же пытаются из этих условий собрать оптимальную загрузку оборудования и, возможно, произвести ещё что-то, что можно присоединить к имеющимся сериям. Они отвечают за максимальную эффективность производства в коротком горизонте.
Обе системы используют огромный модуль маршрутизации технологических процессов. Там хранятся все возможные маршруты всей продукции, технология производства по агрегатам — в общем, путь со всеми переделами, который проделывает металл от входа в сталеплавильное производство до попадания в вагон, который поедет к заказчику. Для этого модуля нам пришлось собрать все данные о производстве, привести их к единому виду, установить общие протоколы обмена данными и договориться со всеми-всеми, что они будут вводить, хранить и использовать данные именно так, как в них указано.
Оцифровка завода из бумажного вида заняла год. Пришлось многое переформатировать, чтобы оно уложилось в понятную логику таблиц и данных. Это было основным и очень трудным челленджем, который вырос в непрерывный процесс и продолжается до сих пор.
Проба металла
Для чего нужен маршрутизатор
В верхнеуровневой системе КПиГ (календарное планирование и графикование) на входе — следующие данные:
- Сбытовые позиции, то есть то, что мы хотим произвести. Каждая позиция при попадании в систему должна получить слоты на каждом агрегате, где будет производиться, резервы материалов со складов, времени рабочих и так далее. То есть образуется диаграмма Ганта с тем, кто, на чём и когда будет работать с этим заказом. Для этого каждый заказ проходит через генератор маршрутов и получает свой собственный производственный маршрут.
- С генератора маршрутов приходит много мастер-данных в сторону системы планирования. Это таблицы знаний, описания складов, их уровней хранения (целевых и максимальных), правил и ограничений планирования. Есть материал (маршрут и уставки на нём: производительность, расход, последовательность операций, разрешённое оборудование и т. п.) и его данные.
- Отдельно на вход поступает план ремонтов оборудования.
- Также на входе — график входящих поставок материалов, которые нужны как компоненты. Если внутри календарного планирования до такого-то горизонта краска недоступна, то планировать покрытие ею нельзя.
- Квоты на производство (это коммерческие параметры стратегического уровня).
То есть календарное планирование проверяет не только то, что мы можем произвести заказ в такой-то срок, а прямо непосредственно выбирает способ производства и «бронирует» время и материалы по всем переделам от выплавки до отгрузки.
Маршрутизатор позволяет перейти от мыслей в духе «завод позволяет производить в среднем столько-то тонн продукции в месяц» к конкретным числам, что можно и что нельзя произвести.
Пример цепочки
Вот хороший пример цепочки:
Тут есть несколько способов произвести готовую продукцию, но генератор не выбирает и не предлагает вариантов, а просто действует по ограничениям производства: в нормативной документации указан приоритетный путь получения продукции, и маршрутизация идёт по нему, если это возможно.
На практике цепочки выглядят чуточку сложнее:
Вот один из участков крупнее, чтобы было понятнее, что именно тут за блоки:
Внедрение
Сама система маршрутизации не хранит результатов, а просто проверяет возможность что-то сделать и рассказывает другим системам, как и что для этого нужно.
Естественно, что первые шаги внедрения были достаточно интересными. Итак, пользователь создаёт заказ. Дальше он может получить несколько типов ошибок: например, что это невозможно выполнить либо в принципе непонятно, как это выполнять. И проблемы здесь как на нашей стороне, так и на стороне пользователя. На нашей поначалу часто были дыры в нормативной документации, когда было не до конца понятно, как производить ту или иную продукцию. В этом случае приходили аналитики и разбирались, какого куска информации и для какого участка не хватает. А у пользователя — когда он не мог точно ввести в систему, что именно нужно произвести.
Чтобы генератор сформировал маршрут, ему нужно знать, что именно производить, а дальше он уже учтёт техдокументацию и производственные ограничения. В какой-то момент нам даже пришлось делать вспомогательную систему — сочинитель заказов, — чтобы пользователь мог нормально указывать, что же ему требуется. Вот пример заказа до появления сочинителя:
Как видите, раньше было много вольностей по примечаниям: три обязательных поля и целое сочинение в поле примечаний. Вроде бы требования формализованы, но не там, где хотелось бы.
Чтобы минимизировать ошибки, всё это нужно раскидать по разным полям ввода. Вот так это выглядит формализованно:
И вот ещё пример. Было:
Стало:
До появления маршрутизатора и базы знаний нормативно-справочной информации (НСИ) в инструкциях, указаниях, распоряжениях и других документах использовались разные термины для одинаковых вещей. Мы прошлись по всему производству и добились приведения всего этого к единому образцу, чтобы все системы имели данные о том, что происходит, в однозначном виде.
Кость обрастала мясом по ходу проекта.
Но по мере понимания, как всё будет работать, к НСИ появлялись всё новые и новые требования, разрабатывались таблицы на базе документации, что-то обобщали, где-то приходили в подразделения и просили структурировать и формализовать данные, чего вообще не было на бумаге до этого.
К счастью, ещё когда все техкарты были на бумажных носителях, мы уже правильно их структурировали: были примерно одинаковые структура, правила наполнения и тип хранения данных. Это нам помогло распространить их формат на все документы такого типа и положить всё это в систему НСИ.
Вот пример техкарты узла:
Формирование системы НСИ и её наполнение постоянно находятся в процессе работы. В частности, сейчас к системе подключаются крупные проекты, которым необходимо подтягивать данные о маршрутах производства: в этом году мы подключаем несколько новых агрегатов.
Нам надо завести новые таблички данных, добавить их в алгоритмы и дописать правила.
НСИ можно использовать как поисковый движок по нормативной документации. Условно говоря, если тебе нужна какая-то табличка со свойствами металлов, то приходят в НСИ. Если тебе нужен маршрут в привязке к заказу, то приходят в генератор. Это позволяет очень удобно собирать документацию при разработке новой продукции: удобно искать наличие подходящей технологии.
Иногда пользователи ставят генератор маршрутов в тупик, размещая заказ с параметрами, с которыми мы никогда не работали. В этом случае нужно доуточнять технологию и только тогда брать в работу.
Стандартные продукты
Очень многие технологические маршруты не нуждаются в каком-то особенном полуфабрикате, а могут использовать стандартный. Это то, чего в нашем портфеле заказов обычно очень много.
Вот возьмём прокат с полимерным покрытием. Его обычно делают из оцинкованного проката путём окраски. С точки зрения заказа важно, какие там краска, фактура поверхности, вид эмали и так далее. Но если отойти всего на шаг назад к полуфабрикату, то выяснится, что 90 % этих заказов имеет общий маршрут до оцинковки. Просто берётся лист и красится. То есть для сотни видов готовой продукции полуфабрикат — один и тот же. И логично сразу «схлопывать» все такие заказы в короткую цепочку «из оцинкованного проката в прокат с полимерным покрытием», а не создавать сотни и тысячи цепочек для каждого заказа. А затем достаточно будет добавить всего несколько цепочек производства оцинкованного проката. Это точка превращения в стандартный продукт, и наш генератор умеет оптимизировать такие точки.
Маршруты — наше всё
Генератор маршрутов должен работать безупречно. Его цель — отдать маршруты. При этом нужно точно понимать требования клиентов и держать то, что хранится в НСИ, в актуальном состоянии.
Условно нужно добиться оптимального сочетания нескольких параметров. Сначала проходит этап «сборки костяка» (construction), когда задаётся несколько случайных стартовых условий.
Потом — «улучшения» (improvement), когда идут перебор и оптимизация вариантов. А затем генератор маршрутов отдаёт свои маршруты в систему планирования: календарное планирование и графикование.
Маршруты — это основная история в работе систем планирования и производства продукции.
Они помогают на этапе принятия заказов, избавляя нас от ненужных действий, и на входе отсекают то, чего мы реально не можем произвести. А ещё исключают человеческий фактор: если человек ошибся, то система ему об этом скажет.
Работа генератора очень важна, потому что от неё условно зависит всё. Некорректные маршруты могут привести к большим рискам произвести некачественную продукцию. Или получить плохой план, где неправильно задействованы наши мощности.
Автор: Андрей Болотов
