Контролен списък за IIoT на производствения цех: 12 елемента, които определят дали проектът ще се изплати

Ключови изводи

• Проект IIoT = внедряване на индустриалния интернет на нещата, доставящо данни от производствения под към по-висши системи.
• Повечето IIoT проекти не постигат очакваното, защото пропускат основите: ясен случай на използване, качество на данните, сигурност, план за интеграция.
• 12-точковият контролен списък налага честност относно цялата работа, която доставчикът на технологията няма да свърши вместо вас.
• Заводите, които преминават през контролния списък преди подписване на договори, имат значително по-високи проценти на успех на проектите.
• Успешният IIoT носи измеримо подобрение в OEE или поддръжката, а не само информационни табла.

Кратък отговор: Повечето IIoT проекти не постигат очакваното, защото пропускат основите. Контролен списък от 12 точки налага честност относно обхвата, случая на използване, качеството на данните, сигурността, интеграцията и собствеността преди подписване на договор. Преобразява въпроса от „дали технологията може да работи“ в „дали оперативната промяна ще се случи“. Последното е по-трудно и по-важно. Вижте също Качество на данните от производствения под.

Контролен списък от 12 точки

1. Конкретен случай на използване. Какво решение ще позволят тези данни, което днес не е възможно?
2. Измерим резултат. Кое число — OEE, MTBF или разходи — трябва да се промени и с колко?
3. Идентифицирани източници на данни. Кои ПЛК, сензори и ръчни въвеждания захранват системата?
4. План за качество на данните. Как ще проверите дали данните са точни?
5. Архитектурата е определена. Edge, шлюз или облак — с посочени причини.
6. Покритие на мрежата. Таблетите и устройствата имат покритие там, където им е необходимо.
7. План за сигурност. Сегментиране на мрежата, удостоверяване, криптиране.
8. План за интеграция. Как това се свързва с OEE, CMMS, ERP?
9. План за приемане от потребителите. Кой използва данните и как ги усвоява?
10. Оперативен собственик. Кой е отговорен за резултата?
11. Обхват на пилота. Какво е минималното жизнеспособно внедряване?
12. План за разширяване. Как се преминава от пилот към целия завод?

Най-често пропусканите елементи

Яснота на случая на използване (точка 1). Много проекти започват с „имаме нужда от IIoT“ без конкретно решение, което данните да позволят. Доставчикът доставя данни; стойността никога не се появява.

Качество на данните (точка 4). Сензорите са инсталирани; данните текат; никой не проверява точността. Аналитиките надолу по веригата, базирани на лоши данни, се провалят.

План за приемане (точка 9). Информационни табла са внедрени; никой не променя поведението си. Стойността не се появява.

Оперативен собственик (точка 10). Проектът остава в IT; операциите не притежават резултата. В резултат проектът губи посоката си.

Защо проектите се провалят без контролния списък

Три често срещани начина на провал:

1. Мислене „технологията на първо място“. „Нека внедрим IIoT.“ Резултатът никога не е уточнен.

2. Пилот, който не се мащабира. Пилотът работи; при разширяване се разкриват проблеми в архитектурата.

3. Пропуск при приемането. Данните съществуват; поведението не се променя.

Контролният списък принуждава всяка от тези точки да бъде разгледана предварително.

Отговорности: доставчик срещу клиент

Доставчиците обикновено поемат:

• Хардуер.
• Софтуерна платформа.
• Стандартни интеграции.
• Обучение (обикновено само начално).

Клиентите трябва да осигурят:

• Дефиниция на случая на използване.
• Поемане на оперативната отговорност за резултата.
• Проверка на качеството на данните.
• Приемане и промяна на културата.
• Потребителски интеграции към наследени системи.
• Постоянни операции.

Повечето провали са от страната на отговорностите на клиента. Доставчикът е изпълнил; клиентът не е.

Как изглежда „успехът“

• Измеримо подобрение в OEE, MTBF или разходите.
• Операторите и супервизорите активно използват данните.
• Взимат се решения по различен начин от преди.
• Устойчиво подобрение в продължение на месеци и години.
• Разширяване извън пилотния етап.

Пилотният капан

Пилотите успяват, защото всички обръщат внимание. При разширяване вниманието отслабва и провалът е вероятен.

Планирайте разширяването още от пилотната фаза. Направете планът за разширяване част от критериите за успех на пилота.

Чести грешки

1. Пропускане на дефиницията на случая на използване. Най-често срещаната причина за провал.

2. Липса на план за качество на данните. Лоши данни в аналитиката.

3. Липса на оперативен собственик. Собственост само в IT води до табла, които никой не използва.

4. Успехът на пилота ≠ успех при мащабиране. Необходими са ясни планове за разширяване.

Как да използвате контролния списък

Преди да подпишете договор с доставчик, преминете през всичките 12 точки. Ако някоя е неясна или липсва — решете я преди ангажиране. Повечето фабрики откриват, че преминаването през списъка или забавя проекта (защото излизат наяве реални проблеми), или го убива (защото случайът на използване не е реален). И двете са по-добри от подписването и провала.

Как модерна OEE платформа подкрепя IIoT

Модерна OEE платформа се интегрира с IIoT източници на данни, предоставя измерване на резултатите (OEE, MTBF, разходи) и поддържа работни потоци, насочени към приемането, които правят IIoT рентабилен.

Модулът за OEE на Fabrico се интегрира с IIoT данни, предоставя измерване на резултатите и поддържа работни потоци за оператори и ръководство, които превръщат IIoT данните в оперативна промяна.

Вижте как Fabrico улавя това автоматично — разгледайте OEE за производство или заявете демонстрация.

Свързано четене

• Качество на данните от производствения под
• Проектиране на Wi‑Fi за производствения под
• Контролен списък с функции на OEE софтуер
• Gemba Walk срещу Floor Walk

Често задавани въпроси

Защо повечето IIoT проекти не постигат очакваното?

Пропусната дефиниция на случая на използване, слабо качество на данните и липса на план за приемане са най-големите причини.

Кой трябва да притежава IIoT проекта?

Отговорно е звеното по експлоатация, с подкрепата на IT и инженерния отдел.

Колко време отнема пилотът?

Типично 3–6 месеца. По-малко от 3 месеца пропуска вариабилността в реални условия.

Кога да добавим ML?

След като качеството на данните е доказано и случаите на използване са ясни. ML върху лоши данни се проваля.

Кой е най-често пропусканият елемент?

Оперативният собственик. Без явна отговорност проектът губи посоката си.