Автоматизация промышленного производства
Разработка ERP-системы и личного кабинета для оптимизации бизнес-процессов промышленного предприятия и организации электронного документооборота
Технологический стек
Front-end
- JavaScript
- React (react-redux)
Back-end
- JavaScript
- React (react-redux)
Проблема
Процесс термообработки и сварки соединительных деталей трубопроводов и деталей различного назначения строго регламентирован законодательством, подразумевает жесткий контроль на всех этапах производства — от принятия заготовок до сертификации конечного продукта. В изготовлении одной детали могут принимать участие сразу множество специалистов и производственных цехов, расположенных в разных локациях. Помимо организации производственных процессов необходимо обеспечить удобный механизм контроля, исследований и сертификации продукции.
Производство гнутых отводов и сопутствующей продукции происходит в несколько этапов, каждый из этапов сопровождается обязательной проверкой в соответствии с техническими условиями (ТУ/ГОСТ) изготовления продукции предъявляемыми заказчиками: проводятся испытания механических и химических свойств металла, качество сварных соединений, и прочие параметры входящих заготовок и готовой продукции. Совокупно, проверка проходит более чем по 100 параметрам. На каждом из этапов происходит подготовка соответствующего документа о соответствии изделия заявленным характеристикам.
Не смотря на обилие законодательных регламентов, представленный процесс термообработки является достаточно уникальным и далеко не в каждом регионе России существует подобное производство. В следствии чего программные решения для организации подобного производства на рынке отсутствуют. Производители вынуждены самостоятельно организовывать производственные и бизнес-процессы. Зачастую, для этого производители используют Excel-формы и произвольно составленные документы.
Такой подход позволял компании успешно работать при небольшом количестве заказов, но при увеличении объемов производимой продукции, компания столкнулась с серьезным перерасходом входящих заготовок, сложностями планирования производства и с недостатком документов соответствия изделий заявленным характеристикам.
Задача
Была поставлена Задача по разработке системы, которая позволит структурировать все этапы производство в единой системе управления, автоматизировать процесс постановки технического задания на производство, создание и хранения актов проводимых испытаний, прием входящих заготовок и контроль готового продукта.
Первые шаги
Самым очевидным решением данной задачи является попытка доработки программного продукта «1С: Управление предприятием» с помощью собственных уникальных модулей. Именно к данному подходу прибег производитель, используя для этого штатных специалистов. Но в ходе выполнения проекта начали появляться некоторые проблемы. Во-первых, внутренние особенности и ограничения платформы «1С» не позволяли реализовать управление и контроль за производственными процессами в том виде, как того хочет производитель. Во-вторых, окружение 1С не имело подходящих интерфейсов для организации работы ключевых сотрудников: инженеров, лаборантов, мастеров цехов.
После нескольких попыток внедрения проекта он был заморожен и производитель обратился в нашу компанию для того, чтобы мы взялись за развитие данного проекта.
Изучение
В первую очередь мы взялись за изучение примеров всех документов, которые формируются в процессе производства продукции. После этого мы посетили само производство для того, чтобы структурировать всю полученную информацию и составить «карту технологических и документарных процессов». Мы визуализировали все этапы производственного процесса, ключевых сотрудников, входящие документы, а также документы, формируемые в процессе производства. Выделили взаимосвязи и определили процессы, которые могут выполняться параллельно, а также определили возможные вариации тех или иных этапов производства, возможности и причины для возврата на предыдущие этапы (отбраковка, замена заготовок и т.д.).
После изучения стало очевидным, что информация, находящаяся в 1С, по факту никак не участвует в самом производственном процессе, либо требует дополнительных уточнений. От чего использование программного продукта «1С: Управление предприятием» в качестве платформы будущего проекта является не целесообразным.
Мы подготовили прототип будущей системы в виде набора блок-схем и начали совместную корректировку производственных процессов совместно с производителем.
Разработка системы
После того, как описанные с помощью блок-схем производственные процессы стали корректными, понятными и прозрачными, мы приступили к разработке информационной системы.
Первый этап
Первым этапом разработки необходимо было выделить предметную область, в которой будет работать разрабатываемая система. Для этого, пользуясь языком заказчика и нормативными документами, были созданы основные сущности системы, участвующие в производственных процессах. Это очень важный этап, поскольку позволяет разработчику не терять связи с предметом автоматизации, а также общаться на общем языке с заказчиком, не погружая его в сложные технические термины.
Второй этап
Вторым этапом мы принялись за создание функционального прототипа интерфейса системы и проектирования серверной части. Ранняя разработка интерфейса была необходима по нескольким причинам:
- Молниеносная обратная связь о разрабтываемом интерфейсе
- Гибкость в внесения изменений, скорость разработки
- Возможность оценки того или иного интерфейсного решения с точки зрения «простоты и понятности», что являлось одним из критериев разработки интерфейса
Для ускорения разработки интерфейса была также использована библиотека готовых компонентов antd, а независимость интерфейса системы от серверной часть была обеспечена набором инструментов react.
Параллельно с разработкой интерфейса системы было начато проектирование серверной части. О выборе языка программирования не шло и речи — был выбран Typescript, сохранивший в себе гибкость JavaScript без его изъянов, а система типов позволяет писать по-настоящему надёжные системы. В качестве «клея» между модулями системы, а также как экосистема инструментов, был использован NestJS. Один из модулей данной библиотеки позволил нам не тратить время на ручное написание схем OpenAPI, а просто сгенерировать их из кода, написанного в процессе проектирование API-интерфейса. Это позволило нам сократить время интеграции серверной части с интерфейсом системы почти до нуля благодаря «эмуляции» работы серверной части с помощью Prism.
Третий этап
К моменту перехода к третьему, и самому активному, этапу разработки, мы уже имели полностью функционирующий интерфейс системы, спроектированную предметную область объекта автоматизации и API-интерфейс для интеграции серверной части с интерфейсом системы.
Оставалось самое сложное — вдохнуть жизнь в интерфейс системы, реализовав бизнес-логику на сервере.
На третьем этапе мы сконцентрировались на реализации функционала разрабатываемой системы, заполнении «пустых реализаций», оттачивании API и подборе правильных инструментов для решения задач документооборта.
Первый этап
Первым этапом разработки необходимо было выделить предметную область, в которой будет работать разрабатываемая система. Для этого, пользуясь языком заказчика и нормативными документами, были созданы основные сущности системы, участвующие в производственных процессах. Это очень важный этап, поскольку позволяет разработчику не терять связи с предметом автоматизации, а также общаться на общем языке с заказчиком, не погружая его в сложные технические термины.
Второй этап
Вторым этапом мы принялись за создание функционального прототипа интерфейса системы и проектирования серверной части. Ранняя разработка интерфейса была необходима по нескольким причинам:
- Молниеносная обратная связь о разрабтываемом интерфейсе
- Гибкость в внесения изменений, скорость разработки
- Возможность оценки того или иного интерфейсного решения с точки зрения «простоты и понятности», что являлось одним из критериев разработки интерфейса
Для ускорения разработки интерфейса была также использована библиотека готовых компонентов antd, а независимость интерфейса системы от серверной часть была обеспечена набором инструментов react.
Параллельно с разработкой интерфейса системы было начато проектирование серверной части. О выборе языка программирования не шло и речи — был выбран Typescript, сохранивший в себе гибкость JavaScript без его изъянов, а система типов позволяет писать по-настоящему надёжные системы. В качестве «клея» между модулями системы, а также как экосистема инструментов, был использован NestJS. Один из модулей данной библиотеки позволил нам не тратить время на ручное написание схем OpenAPI, а просто сгенерировать их из кода, написанного в процессе проектирование API-интерфейса. Это позволило нам сократить время интеграции серверной части с интерфейсом системы почти до нуля благодаря «эмуляции» работы серверной части с помощью Prism.
Третий этап
К моменту перехода к третьему, и самому активному, этапу разработки, мы уже имели полностью функционирующий интерфейс системы, спроектированную предметную область объекта автоматизации и API-интерфейс для интеграции серверной части с интерфейсом системы.
Оставалось самое сложное — вдохнуть жизнь в интерфейс системы, реализовав бизнес-логику на сервере.
На третьем этапе мы сконцентрировались на реализации функционала разрабатываемой системы, заполнении «пустых реализаций», оттачивании API и подборе правильных инструментов для решения задач документооборта.
Назад
Далее