Использование Low Code и IoT для оптимизации запасов запасных частей

Создание новых приложений с использованием платформ разработки с низким кодом может привести к инновационным решениям старых проблем, например, как лучше управлять запасами запасных частей.

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

Инвентаризация запасных частей имеет точки соприкосновения с несколькими отделами. Группы обслуживания, ремонта и эксплуатации (ТОиР) явно заинтересованы в этом. Им нужны запасные части, чтобы оборудование работало. Но управление запасами запасных частей влияет и на другие группы.

См. также: Low Code:сокращайте теневые ИТ, помогайте разработчикам в цехах

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

Цифровая трансформация с минимальным кодом

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

В течение многих лет производители использовали календарное техническое обслуживание, основанное на предоставленной поставщиком информации о сроке службы детали или элемента оборудования и истории ремонта. Группы ТОиР будут планировать проверки, обслуживание и замену деталей на основе среднего времени наработки на отказ (MTTF) и данных об окончании срока службы. Запасные части были заказаны в соответствии с графиком замены поставщика устройства.

В этом подходе есть два недостатка. Во-первых, что произойдет, если деталь сломается или перестанет работать раньше, чем оценка MTTF поставщика детали? Другой вопрос, что делать, если часть может дать больше, чем оценка срока службы? Традиционный способ справиться с обеими ситуациями заключался в том, чтобы запастись запасными частями на случай непредвиденной поломки. И заменяйте детали в сроки, установленные поставщиком, даже если они продолжали нормально функционировать.

Такое не элегантное решение решило насущные проблемы, но за это пришлось заплатить. Проблемы с затовариванием включают:

• Требуется больше места для хранения, которое во многих производственных средах имеет большое значение.
• Запчасти могут устаревать по мере того, как поставщики обновляют линейки продуктов.
• Деньги, потраченные на дополнительные детали, хранящиеся на складе, можно использовать в другом месте.

Проще говоря, для улучшения ситуации можно сделать больше. Разработка кода Enterlow и IoT. Производители используют данные IoT от оборудования на своих заводах, чтобы отказаться от традиционного обслуживания на основе календаря. Платформы разработки с низким кодом позволяют им использовать эти данные и создавать приложения, которые дополняют и расширяют возможности диспетчерского управления и сбора данных (SCADA) и других систем OT.

В частности, производители перешли от исправления, когда оно нарушает режим работы, к режимам реагирования, упреждения и прогнозирования/предупреждения.

Реактивный режим может принимать данные IoT о состоянии устройства и данные систем OT, такие как оповещения и аварийные сигналы, и запускать действие MRO. Например, отметив, что некоторая часть работает с превышением рекомендуемой производителем пиковой рабочей температуры, специально разработанное сервисное приложение MRO, использующее эти данные, может автоматизировать создание заявки на устранение неполадок и обращение в службу поддержки.

В упреждающем режиме может использоваться приложение, которое берет данные с устройств и систем OT и применяет аналитику, чтобы выявлять возникающие проблемы и устранять их до того, как они приведут к простою. Например, в то время как устройство может работать в соответствии со спецификациями поставщика, аналитика в приложении MRO может использоваться, чтобы заметить, например, что критический двигатель работает на все более и более высоких скоростях для выполнения одного и того же объема работы. Это полученное понимание может быть использовано для начала проверки этой части. После осмотра сотрудник ТОиР может прийти к выводу, что лучше заменить деталь, чем рисковать ее поломкой.

Прогностический/превентивный режим идет еще дальше. Приложение MROservice может быть разработано с использованием искусственного интеллекта, машинного обучения или других передовых методов аналитики для получения выводов на основе деталей и машинных данных. Такая предиктивная аналитика данных могла бы найти что-то очень конкретное. Когда рабочая температура детали А этого поставщика повышается на 20 % за 15 минут, это означает, что через три дня она выйдет из строя. Вооруженный такой информацией в сервисном приложении MRO, технический специалист может быть отправлен для замены детали в упреждающем порядке, чтобы избежать сбоя.

Связывание всего с оптимизацией складских запасов запасных частей

Платформа разработки с низким кодом также может использоваться для создания приложения, объединяющего идеи и действия системы MRO с системой ERP, используемой для заказа деталей.

Преимущество объединения решений профилактического и профилактического обслуживания с ERP заключается в том, что оно позволяет более эффективно использовать существующие детали. Старый подход к замене деталей, основанный на среднем рекомендуемом сроке службы, приводит к выводу из эксплуатации некоторых деталей, которые могли бы продолжать работать еще много дней, месяцев или лет. Организация теряет тот дополнительный полезный срок службы, который она могла бы получить от детали, и сжигает больше запасов, чем необходимо.

Такая система обеспечит наличие необходимых запасных частей на складе, когда это необходимо, что позволит избежать ненужных простоев в ожидании отправки критической детали. Это также гарантирует отсутствие избыточных запасов запасных частей, что снижает потребность в избыточных складских площадях для размещения деталей. Это также снижает вероятность наличия устаревших деталей.

По сути, создание новых приложений с использованием платформ с низким уровнем разработки кода и Интернета вещей может привести к инновационным решениям старых проблем. В случае запасов запасных частей производители могут разработать подход «точно в срок» к запасным частям. В результате получается более оптимизированный метод управления запасами.