Oprogramowanie OEE i Power BI: Łączenie danych produkcyjnych z Twoim środowiskiem BI

Power BI jest platformą Business Intelligence wybieraną przez wiele organizacji produkcyjnych, szczególnie tych opartych na stosie technologii Microsoft. Oprogramowanie OEE generuje dane o wydajności produkcji, dostępność maszyn, wskaźniki wydajności, metryki jakości, zdarzenia przestojów i wskaźniki OEE, które zyskują znaczną wartość, gdy zostaną połączone z danymi produkcyjnymi, finansowymi i dotyczącymi utrzymania ruchu z innych systemów w środowisku Power BI.

Połączenie między OEE a Power BI przekształca narzędzie do monitorowania produkcji w podstawę danych dla raportowania wydajności produkcji w całym przedsiębiorstwie.

Oprogramowanie OEE łączy się z Power BI za pomocą trzech głównych metod: bezpośrednich połączeń API (gdy Power BI odpyta API platformy OEE podczas odświeżania), konektorów baz danych (gdy Power BI łączy się bezpośrednio z bazą danych leżącą u podstaw platformy OEE) lub eksportów danych (pliki CSV lub Excel odświeżane według harmonogramu). Połączenia API są preferowane w większości wdrożeń korporacyjnych, ponieważ utrzymują platformę OEE jako źródło autorytatywne, egzekwują granice bezpieczeństwa oraz obsługują przyrostowe odświeżanie danych, pobierając tylko nowe dane od ostatniego odświeżenia zamiast za każdym razem zaciągać całe historyczne zestawy danych.

Decyzja o częstotliwości odświeżania ma duże znaczenie dla pulpitów OEE w Power BI. Pulpity w czasie rzeczywistym lub zbliżonym do rzeczywistego (odświeżające się co 5–15 minut) są przydatne dla kierowników zmian monitorujących bieżącą produkcję, ale standardowa funkcja odświeżania danych w Power BI odświeża maksymalnie 8 razy dziennie w darmowym planie.

Dla pulpitów produkcyjnych w czasie rzeczywistym lepszymi opcjami niż zaplanowane odświeżanie są strumieniowe zestawy danych Power BI lub architektura Power BI Embedded z push API, ponieważ obsługują one ciągłe aktualizacje danych zamiast aktualizacji wsadowych.

Skuteczne pulpity OEE w Power BI organizują metryki na trzech poziomach odbiorców: streszczenia dla kadry zarządzającej (trendy OEE na poziomie zakładu, porównania miesiąc do miesiąca, najważniejsze możliwości poprawy), widoki zarządzania operacyjnego (OEE na poziomie linii według zmian, Pareto przestojów wg kategorii, trendy wskaźnika jakości) oraz widoki operacyjne na poziomie zmiany (OEE bieżącej zmiany, aktywne zdarzenia przestoju, pozostałe cele produkcyjne). Tworzenie pulpitów dla wszystkich trzech poziomów na podstawie jednego modelu danych OEE, wykorzystując zabezpieczenia na poziomie wiersza w Power BI oraz nawigację między stronami raportu, zapewnia każdej grupie odpowiednią szczegółowość bez konieczności budowania oddzielnych raportów. Najbardziej wpływowe metryki OEE, które warto włączyć do Power BI poza standardowym wynikiem OEE, to: MTBF (średni czas między awariami) i MTTR (średni czas naprawy) według urządzenia, łączenie danych o dostępności OEE z metrykami wydajności utrzymania ruchu; wskaźnik jakości według produktu i zmiany, identyfikowanie, które produkty i warunki eksploatacji generują najwyższe wskaźniki wad; wskaźnik wydajności w zależności od pory dnia, ujawnianie systematycznych spadków prędkości związanych z rozruchem zmiany, zmianami załogi lub warunkami środowiskowymi; oraz wykresy wodospadowe OEE pokazujące rozkład strat (wkład dostępności, wydajności i jakości), które jasno wskazują, na którym składniku skupić wysiłki poprawcze. Łączenie danych OEE z danymi ERP w Power BI tworzy najbardziej strategicznie wartościowe pulpity. Gdy dane OEE o wolumenie produkcji są łączone z kosztami zleceń produkcyjnych z D365 lub SAP, można obliczyć koszt na jedną dobrą jednostkę według linii i zmiany, ujawniając, które konfiguracje produkcyjne są z punktu widzenia kosztów najbardziej i najmniej efektywne.

Gdy zdarzenia utrzymania ruchu OEE są łączone z kosztami zleceń utrzymania z CMMS, można obliczyć całkowity koszt posiadania dla urządzeń. Takie połączone analizy są możliwe tylko w środowisku BI, które łączy wiele źródeł danych, a Power BI z integracją API OEE jest praktycznym sposobem ich realizacji.

Prawdziwie używane przez zespoły produkcyjne pulpity Power BI dotyczące OEE opierają się na jednej zasadzie projektowej: prezentują informacje umożliwiające podjęcie działań, zamiast jedynie wyświetlać dane. Pulpit pokazujący OEE bieżącej zmiany jest użyteczny; pulpitu pokazującego OEE bieżącej zmiany wraz z prognozą, czy zmiana osiągnie cel produkcyjny, oraz trzema głównymi przyczynami przestojów wpływającymi na ten cel, pozwalają na konkretne działania.

Dodatkowy kontekst, prognoza i czynniki wpływające na wynik, skłania kierowników do korzystania z pulpitu jako narzędzia decyzyjnego, a nie jedynie jako wyświetlacza stanu. Skuteczne wdrożenie pulpitu Power BI dla OEE przebiega w czterech krokach.

Po pierwsze: określ decyzje, które każdy pulpit ma wspierać, nie metryki, które ma pokazywać, lecz konkretne wybory operacyjne, które lepsze dane poprawią (decyzje dotyczące obsady zmiany, priorytetyzacja prac konserwacyjnych, planowanie przezbrojeń). Po drugie: zidentyfikuj dane potrzebne do wsparcia tych decyzji, co często wymaga łączenia danych OEE z danymi z systemów ERP, CMMS lub systemów harmonogramowania. Po trzecie: zbuduj prototyp z prawdziwymi danymi i zwaliduj go z docelowymi użytkownikami przed finalnym projektem.

Po czwarte: ustal regularny rytm przeglądów, w którym wnioski z pulpitu napędzają spotkania produkcyjne, bez ustrukturyzowanego procesu przeglądu nawet dobrze zaprojektowane pulpity są ignorowane po wygaśnięciu początkowego entuzjazmu. Warstwa zarządzania (governance) dla pulpitów Power BI dotyczących OEE jest często niedoinwestowana.

Gdy dane OEE się zmieniają, na przykład linia zostaje przemianowana, kategorie przyczyn przestojów zostają przegrupowane lub dodana zostaje nowa maszyna, model danych w Power BI musi być zaktualizowany równolegle. Wyznaczenie właściciela pulpitu, który utrzymuje model danych przy zmianach konfiguracji OEE i komunikuje te zmiany użytkownikom pulpitu, zapobiega erozji zaufania do danych, która pojawia się, gdy metryki nagle się zmieniają, ponieważ struktura danych uległa zmianie bez uprzedzenia.