Програмне забезпечення OEE: як обрати та впровадити без розчарувань

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Програмне забезпечення OEE фіксує простої, швидкість і брак для кожного верстата. Дізнайтеся, як його обрати, протестувати, підключити до ERP і старих верстатів та уникнути typових пасток.

Automatically translated with AI from the original post. Read the English original

Програмне забезпечення OEE фіксує, що робить верстат у запланований час виробництва: коли він працює, коли зупиняється, якою є швидкість і скільки деталей виходить придатними. Далі ці дані перетворюються на доступність, продуктивність, якість і загальний показник OEE. Ця стаття адресована керівникам виробництва в виробництві, які мають обрати інструмент, протестувати його та домогтися його прийняття в цеху. Стаття розглядає вибір і впровадження, а не саму формулу. Якщо спочатку потрібні формула та шість великих втрат, спершу ознайомтеся з OEE, а потім поверніться сюди.

Головне

• Програмне забезпечення OEE автоматизує те, що паперовий журнал робить вручну: фіксує час роботи, зупинки, швидкість і браковані вироби для кожного верстата та перетворює їх на доступність, продуктивність і якість.
• Lean.org визначає OEE як доступність, помножену на продуктивність і на якість, тож перевірте, що формула інструменту, а також його налаштування зупинок і ідеальної швидкості відповідають визначенню, яке використовує ваше виробництво.
• Обирайте насамперед за способом збору даних, адже панель показників є чесною лише настільки, наскільки чесні кількість, стани та причини простоїв, що лежать в її основі.
• Проведіть пілот на одному обмежувальному верстаті з власними даними та порівняйте показники інструменту з ручним журналом, перш ніж довіряти будь-якому графіку.
• Плануйте підключення до ERP і Power BI заздалегідь та уточніть, як інструмент передає дані, адже Microsoft припиняє створення потокових семантичних моделей після 31 жовтня 2027 року.

Що насправді має робити інструмент?

Три завдання, у такому порядку.

1. Зібрати дані. Стан верстата (працює, зупинений, простоює), кількість деталей, браковані вироби і, найголовніше, причину кожної зупинки. Це найскладніша частина, і від неї залежить, чи варто взагалі розглядати все інше.
2. Розраховувати показники завжди однаково. Lean.org визначає OEE як міру ефективності використання обладнання: доступність, продуктивність і якість, перемножені між собою. Доступність враховує простої через збої та переналагодження. Продуктивність враховує втрати швидкості, зокрема дрібні зупинки. Якість враховує брак і переробку. Приклад самого Lean.org: множення 90%, 95% і 99% дає 84,6%.
3. Показувати результати потрібним людям вчасно. Оператору потрібна поточна зміна на екрані біля верстата. Наглядачу — останні кілька годин. Керівнику виробництва потрібні тенденції, а не число, яке весь час стрибає.

Усе інше зі списку функцій, як-от мобільні застосунки, сповіщення, модулі технічного обслуговування та додатки зі штучним інтелектом, є другорядним. Якщо перше завдання виконано погано, ці додатки лише прикрашають неправильні цифри.

Чим це відрізняється від MES або ERP?

Межі між ними розмиті, тому чітко усвідомлюйте, що саме ви купуєте.

Систему MES (Manufacturing Execution System) використовують для управління виробництвом і фіксації результатів за виробничими замовленнями: що саме виготовлено, з якого матеріалу і на якій станції. ERP-система зберігає замовлення, номенклатуру, маршрути виробництва та собівартість. Програми для OEE зосереджені на часі роботи обладнання та його втратах. Багато продуктів OEE частково перетинаються з MES, а деякі MES мають вбудовані екрани OEE.

Простий тест: вам потрібно довести, який матеріал пішов у який виріб, або контролювати рух виробничих замовлень? Це зона MES. Вам потрібно зрозуміти, чому ваш верстат-обмеження втрачає час, зміна за зміною? Це питання OEE. Якщо потрібні обидва, запитайте, як ці дві системи мають спільні дані замовлень, щоб оператори не вводили одну й ту саму інформацію двічі.

Як вибрати ПЗ для OEE, не покладаючись на рейтинг постачальників?

Користуйтеся критеріями, які можна перевірити, і запишіть їх до першої демонстрації. Ось набір, який підходить для більшості виробництв.

Збір даних

• Чи може система зчитувати стани та лічильники безпосередньо з контролера верстата, з доданих датчиків чи з обох джерел? Яке з цього потрібно вашому обладнанню?
• Як система працює з верстатами, які взагалі не мають цифрового виходу?
• Як оператор вказує причину простою? На сенсорному екрані, двома дотиками, зі списком, який можуть редагувати керівники? Список із п'ятдесяти причин на нічній зміні не використовуватимуть.
• Чи система автоматично виявляє короткі простої, чи лише ті, які хтось вводить вручну?

Розрахунки та налаштування

• Де задається ідеальна швидкість і хто має право її змінювати?
• Як система трактує планові зупинки, перерви та переналагодження? Чи можна бачити їх як окремі категорії?
• Чи можна переглянути сирі події, що стоять за показником, а не лише відсоток?
• Формула відповідає визначенню Lean чи стандарту ISO 22400-2? ISO описує цей стандарт як такий, що визначає ключові показники ефективності для управління виробничими операціями, кожен із власною формулою, елементами, часовою поведінкою та одиницею вимірювання. Назви та часові бази можуть відрізнятися між джерелами, тож попросіть постачальника точну формулу та порівняйте її з вашою.

Використання на виробничій ділянці

• Чи читається екран з відстані двох метрів, у рукавичках, у шумному цеху?
• Чи може оператор побачити поточну зміну без входу в повноцінний застосунок?
• Чи працює інструмент під час збою мережі та чи надолужує він дані згодом?

Інтеграція та володіння даними

• Які дані можуть виходити із системи і в якому вигляді? Чи можна експортувати сирі події, чи лише звіти?
• Як система під'єднується до вашої ERP, MES та інструментів звітності?
• Хто володіє даними, де вони зберігаються і хто має до них доступ?
• Що в договорі сказано про вихід із сервісу: експорт, видалення, строки повідомлення?

Вартість у часі

• Скільки коштують ліцензії за верстат, за користувача чи за майданчик і що змінюється, коли ви додаєте лінію?
• Яке апаратне забезпечення потрібне кожному верстату і хто його встановлює та обслуговує?
• Яку частину роботи потрібно виконувати постачальнику, а яку можуть зробити ваші власні фахівці?

Оцініть кожного кандидата за цим списком у невеликій команді: хтось із виробництва, технічного обслуговування, ІТ і один оператор. Думка оператора щодо екрана важить більше, ніж більшість керівників очікує.

Як протестувати інструмент, перш ніж прийняти рішення?

Демонстрація на зразковій ділянці постачальника нічого не покаже про вашу. Попросіть пілотний запуск на вашому верстаті та проведіть його як експеримент.

1. Оберіть один верстат. Візьміть обмеження або верстат, який відомо як джерело втрат часу. Стаття IndustryWeek про правильне використання OEE рекомендує зосередитися на обмеженні та застерігає від порівняння змін, підрозділів чи заводів за цим показником.
2. Визначте терміни письмово. Плановий час виробництва, ідеальний цикл, що вважається придатною деталлю, що вважається простоєм. Одна сторінка, затверджена виробництвом і відділом якості.
3. Запустіть інструмент і ручний журнал паралельно. Нехай оператор або керівник зміни фіксує зупинки на папері за той самий період. Порівняйте лічильники, час зупинок і причини.
4. Дивіться на розбіжності, а не на показник. Якщо інструмент пропускає короткі зупинки або зараховує переналагодження як виробництво, з'ясуйте причину, перш ніж рухатися далі.
5. Проводьте короткий щотижневий огляд. Візьміть найбільші втрати, обговоріть їх з операторами і вирішіть одну дію. Якщо пілот не дає жодних дій, ви лише збираєте цифри.
6. Приймайте рішення за чек-листом. Чи збіглися підрахунки? Чи користувалися оператори системою без нагадувань? Чи призвели результати до змін? Чи може ІТ-підтримка забезпечити з'єднання?

Ось гіпотетичний приклад, вигаданий лише для того, щоб показати метод. Лінія пакування показує в інструменті 82% доступності, а ручний журнал натякає на 74%. Різниця виявляється в правилі, яке зараховує кожну зупинку коротшою за п'ять хвилин як час роботи. На панелі це ніхто б не помітив. Помітив журнал, що вели поруч. Виправлення цього правила коштує більше, ніж будь-яка нова діаграма.

Як під'єднати це до ERP, старих верстатів і Power BI?

Старі верстати

На заводах рідко стоїть саме нове обладнання. Для старих верстатів зазвичай обирають між читанням контролера, додаванням датчиків стану роботи та лічильників або шлюзом, який перекладає між протоколами. Типовою цільовою мовою тут є OPC UA. OPC Foundation описує його як передачу даних від пристроїв заводського та технологічного контролю до корпоративних систем з акцентом на безпеку, надійність і роботу на різних платформах, і зазначає, що у 2011 році він став стандартом IEC 62541. Запитайте постачальника, які протоколи він підтримує, і перевірте в пілотному проєкті свій найстаріший верстат, а не найновіший.

ERP

Потрібно, щоб замовлення та дані про продукцію надходили в систему, аби інструмент знав, що виготовляється, і запланованої швидкості, а фактичні кількості та зведення простоїв поверталися туди, де вони допомагають плануванню. Визначте, хто відповідає за майстер-дані про позиції, маршрути та норми часу. Якщо інструмент і ERP-система ведуть власні копії, за місяць вони почнуть суперечити одна одній.

Power BI та звітність

Багато заводів хочуть бачити показники OEE поруч із даними про продажі, якість і технічне обслуговування в Power BI. Запитайте, як інструмент OEE передає дані: через базу даних, експорт, API або push у семантичну модель. Спосіб має значення з двох причин.

По-перше, живі екрани і живі звіти — не одне й те саме. Microsoft документує автоматичне оновлення сторінок звітів за фіксованим інтервалом або з виявленням змін і перелічує, які режими зберігання це підтримують. Режим імпорту не підтримується. На спільній ємності мінімальний фіксований інтервал становить 30 хвилин, а виявлення змін там недоступне. Виділена ємність дозволяє коротші інтервали, які задає адміністратор. Якщо хтось обіцяє «живий» звіт Power BI, запитайте, який режим оновлення й яка ємність для цього потрібні.

По-друге, порівняйте план постачальника з планом Microsoft. На сторінці про потокову передачу в реальному часі зазначено, що створення push- та потокових семантичних моделей залишатиметься увімкненим до 31 жовтня 2027 року, після чого нові створювати не можна. Наявні моделі це не зачіпає, а Microsoft як альтернативу називає Real-Time Intelligence у Microsoft Fabric. Постачальник, чиє підключення до Power BI залежить від потокових семантичних моделей, має пояснити, як це зміниться.

Тримайте розподіл обов'язків. Екран на виробничій ділянці має працювати без Power BI. Power BI призначений для трендів, порівнянь і управлінської звітності, а не для живого огляду оператора.

Як змусити операторів користуватися системою?

Програмне забезпечення не покращує OEE. Покращують люди, які бачать цифри і можуть на їх основі діяти.

• Залучайте операторів до купівлі. Нехай вони випробують екран. Якщо він їм не сподобається, вони знайдуть способи його обійти.
• Тримайте список причин простоїв коротким. Почніть з кількох причин, що базуються на ваших шести великих втратах, і уточніть їх через місяць.
• Використовуйте дані під час передачі зміни. Якщо ніхто не обговорює цифри, система перетворюється на додаткову роботу.
• Ніколи не використовуйте OEE, щоб шукати винних. Один опублікований посібник із впровадження OEE формулює це прямо: OEE — це інструмент для пошуку втрат, а не картка показників, яку треба обіграти. Якщо оператори відчувають покарання, вони перестають точно фіксувати дані.
• Призначте відповідального за кожну втрату. По одній людині на верстат або лінію, яка щотижня дивиться на головну втрату.

Типові помилки

• Купівля за демонстрацією панелі та тестування збору даних наостанок.
• Запуск одразу на всіх верстатах, тож жодна команда не може навчитися на першій лінії.
• Дозвіл постачальнику визначати ідеальну швидкість без перевірки того, чого машина фактично досягає.
• Сприйняття планових зупинок і переналагоджень як неминучих та виключення їх з аналізу.
• Порівняння OEE між різними верстатами, продуктами чи заводами так, ніби один показник означає одне й те саме скрізь.
• Пропуск ручної перевірки під час пілотного проєкту.
• Відкладання підключення до ERP і звітності до моменту після покупки.
• Збирання даних протягом місяців без жодних дій щодо найбільших втрат.

Де місце Polaris

OEE-програми дивляться назад, на час роботи обладнання. Якщо ваші питання стосуються також плану, наприклад, які замовлення запізняться або що змінить переведення на інші зміни для випуску продукції, стане в пригоді погляд на планування. iFAKT описує Polaris як ШІ та цифровий двійник для виробництва, що працює з даними ERP. Його модуль Polaris Analyzer зводить KPI з модулів Polaris на дашбордах, наприклад, терміни виконання, завантаження та вузькі місця, і порівнює плани з фактичними показниками. Це інше завдання, ніж фіксація стану верстатів за допомогою датчиків, тому перш ніж вважати, що один інструмент покриває обидва завдання, перевірте, які джерела даних потрібні для показників на рівні обладнання.

Пов'язані теми для вивчення

• Підключення даних OEE до ERP: які замовлення та кількості мають рухатися в кожному напрямку і хто відповідає за майстер-дані.
• Модернізація старих верстатів: датчики, доступ до контролерів і шлюзи протоколів для обладнання без цифрового інтерфейсу.
• OEE для малих і середніх заводів: як почати з паперового журналу та одного верстата і що має вміти інструмент, щоб масштабуватися згодом.
• Від OEE до першопричини: як пов'язати втрати зі змінами, партіями матеріалів і переналагодженнями за допомогою простого аналізу, перш ніж додавати прогнозні інструменти.
• Сповіщення про профілактичне обслуговування: які дані потрібні, щоб машинне навчання давало перевагу над простими граничними значеннями.

Наступний крок

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