Proof of concept (POC) dla oprogramowania OEE ma jeden cel: zmniejszyć ryzyko, że system, który kupią Państwo, nie będzie działał tak, jak dostawca obiecał w Państwa konkretnym środowisku produkcyjnym.
Dobrze zaprojektowany POC odpowiada na trzy pytania, na które nie dają odpowiedzi odpowiedzi na RFP ani demonstracje: Czy oprogramowanie zbiera dane dokładnie z Państwa konkretnych maszyn i sterowników PLC? Czy oblicza OEE w sposób zgodny z rozumieniem wydajności przez Państwa zespół produkcyjny? I czy operatorzy potrafią z niego korzystać bez intensywnego, stałego wsparcia?
Najczęstszym błędem przy POC jest zbyt szeroki zakres. Producenci, którzy próbują przeprowadzić pilotaż oprogramowania OEE obejmujący wiele linii, wiele zmian i wiele rodzajów produktów w 30-dniowym oknie, kończą z niejednoznacznymi wynikami, zbyt wiele zmiennych, zbyt dużo pracy konfiguracyjnej i za mało czasu, aby osiągnąć stabilną jakość danych.
Skoncentrowany POC na 1, 3 liniach produkcyjnych, obejmujący 2, 3 tygodnie stabilnej produkcji po tygodniowym okresie przygotowawczym, dostarcza bardziej wiarygodnych dowodów niż rozległy pilotaż, który nigdy nie osiąga stanu ustalonego.
Określ zakres POC na piśmie przed jego rozpoczęciem. Dokument zakresu powinien określać: które linie są objęte jaka metoda zbierania danych będzie użyta (integracja z PLC, doposażenie w czujniki lub ręczny zapis jako rozwiązanie zapasowe) jaki wolumen produkcji i jaka mieszanka produktów jest spodziewana w okresie POC
które integracje z ERP i CMMS będą aktywne podczas POC (jeśli w ogóle) oraz jakie wsparcie ze strony dostawcy jest zapewnione w okresie POC. Dostawca, który nie zgodzi się na pisemny dokument zakresu przed rozpoczęciem POC, najprawdopodobniej zmieni zakres po jego zakończeniu.
Pomiar POC powinien obejmować cztery wymiary: dokładność zbierania danych, wiarygodność obliczania OEE, przyjęcie przez operatorów oraz wydajność systemu. Najważniejsza jest dokładność zbierania danych: porównaj odczyty platformy OEE z istniejącymi źródłami danych (liczniki produkcji, dzienniki zmian, system SCADA) dla tych samych zmian.
Różnica przekraczająca 2, 3% w liczbie wyprodukowanych sztuk lub ponad 5 minut na zmianę w czasie przestojów sugeruje problem z konfiguracją zbierania danych, który podważy zaufanie do danych OEE po pełnym wdrożeniu.
Wiarygodność obliczania OEE ocenia się przez uzgodnienie wyników OEE z platformy z ręcznymi obliczeniami na tych samych surowych danych. Wybierz 5, 10 zmian z okresu POC, pobierz dane źródłowe, oblicz OEE ręcznie i porównaj z wynikiem platformy.
Różnice powinny dać się wyjaśnić udokumentowanymi wyborami metodologicznymi (sposób traktowania planowanych przestojów, klasyfikacja mikroprzestojów), niewyjaśnione rozbieżności sygnalizują błąd logiki obliczeniowej w platformie, który będzie powodował trwałe problemy z wiarygodnością w oczach kierowników produkcji dobrze znających swoje linie.
Pomiary przyjęcia przez operatorów podczas 30-dniowego POC koncentrują się na zgodności kategoryzacji przestojów: jaki procent zdarzeń przestoju został skategoryzowany przez operatorów (w porównaniu z pozostawionymi jako „niezaklasyfikowane”) oraz jak długo po zdarzeniu trwała kategoryzacja? Celem POC jest co najmniej 80% kategoryzacji w ciągu 2 godzin od zdarzenia.
Poniżej tego poziomu system wygeneruje analizę Pareto zdominowaną przez przestoje „niezaklasyfikowane”, co niweczy podstawowy cel oprogramowania. Jeśli wskaźniki kategoryzacji są niskie w trakcie POC, zdiagnozuj, czy przyczyną jest złożoność interfejsu operatora, niewystarczające szkolenie czy niewłaściwa lista przyczyn przestojów, i sprawdź, czy dostawca może rozwiązać przyczynę źródłową w trakcie okresu POC.
Decyzja go/no-go dotycząca proof of concept (POC) oprogramowania OEE powinna opierać się na wcześniej zdefiniowanych kryteriach uzgodnionych przed rozpoczęciem POC, a nie na post hoc ocenie, czy relacja z dostawcą wydaje się pozytywna.
Zdefiniuj kryteria „go” jako mierzalne progi: dokładność zbierania danych w granicach ±3% względem stanu rzeczywistego dla ponad 90% zmian; wskaźnik kategoryzacji przestojów przez operatorów powyżej 75%; przynajmniej jedno pomyślne przesłanie danych integracji z ERP (jeśli jest w zakresie); zerowe zdarzenia utraty danych podczas normalnej produkcji; oraz dostępność systemu (uptime) powyżej 99%.
Decyzja o niekontynuowaniu (no-go) również powinna być jednoznaczna. Jeśli dokładność zbierania danych zawodzi w ponad 20% zmian, albo jeśli system wymaga ponad 2 godzin wsparcia od dostawcy tygodniowo, aby utrzymać stabilną pracę, albo jeśli operatorzy aktywnie unikają korzystania z systemu pomimo szkolenia, są to sygnały, że platforma ma zasadniczy problem dopasowania do waszego środowiska, którego dłuższe wdrożenie prawdopodobnie nie rozwiąże.
Pomiędzy czystym „go” a wyraźnym „no-go” większość POC-ów daje wynik „go z warunkami”, system działa akceptowalnie, ale istnieją konkretne problemy wymagające rozwiązania przed pełnym wdrożeniem. Udokumentuj te warunki wprost w raporcie końcowym POC: jakie problemy zidentyfikowano, co dostawca zobowiązał się z tym zrobić i do jakiego terminu.
Przekształcenie tych warunków w zobowiązania kontraktowe w umowie zakupu zamienia warunkowe „go” w decyzję chronioną, jeśli warunki nie zostaną spełnione, masz podstawy do działań naprawczych lub wyjścia z umowy. Bez tej dokumentacji problemy wynikające z warunków zazwyczaj utrzymują się po zakupie, ponieważ pilność dostawcy w ich rozwiązaniu zanika po podpisaniu umowy.
Zaloguj
Blog
