Pokazy oprogramowania OEE to przygotowane z góry prezentacje. Dostawcy prezentują swoją platformę w najlepszym świetle, ze wstępnie załadowanymi, „czystymi” danymi, w idealnych scenariuszach produkcyjnych i w środowiskach demonstracyjnych, gdzie każda funkcja działa płynnie.
Czego nie pokazują, to jak system radzi sobie z nieporządkiem rzeczywistych warunków: operatora, który zapomina zamknąć zdarzenie przestoju; sterownika PLC wysyłającego niejednoznaczne sygnały stanu; zlecenia produkcyjnego trwającego przez zmianę; albo raportu, który wymaga połączenia danych z trzech różnych linii o różnych strukturach produktów.
Rozbieżność między wynikami w demie a wynikami w rzeczywistości to najczęstsze źródło żalu nabywców oprogramowania OEE. Producenci, którzy kupują na podstawie dopracowanych demonstracji, nie testując przypadków brzegowych, często odkrywają po wdrożeniu, że system obsługuje ich konkretne scenariusze produkcyjne inaczej, niż sugerowało demo.
Sposobem na zniwelowanie tej luki jest przyniesienie własnych scenariuszy na dema, wymaganie od dostawców pokazania, jak ich system radzi sobie ze specyficznymi przypadkami brzegowymi i przebiegami pracy występującymi w zakładzie, a nie z idealnymi przypadkami, dla których zbudowano środowisko demonstracyjne.
Strukturyzowanie oceny demo wokół stałej listy kontrolnej scenariuszy sprawia też, że porównanie dostawców jest bardziej miarodajne. Jeśli każdy dostawca zaprezentuje te same 25 scenariuszy, można porównać ich podejścia obok siebie, zamiast konfrontować u jednego dostawcy funkcję „zarządzania przestojami” z u innego funkcją „analizy strat”, które były demonstrowane na różnych danych i w różnych przebiegach pracy.
Lista kontrolna wymusza spójność porównań, której w przeciwnym razie doświadczonym oceniającym przyszłoby utrzymywać ręcznie podczas wielu sesji.
Scenariusze zbierania danych: (1) Pokaż, jak zmiana stanu maszyny jest rejestrowana bez działania operatora, zademonstruj łańcuch przetwarzania sygnału z PLC do stanu OEE w czasie rzeczywistym. (2) Pokaż, co się dzieje, gdy sygnał z PLC jest niejednoznaczny lub czujnik rozłączy się na krótko, jak system radzi sobie z lukami w danych?
(3) Zademonstruj operatora dodającego przyczynę przestoju 2 godziny po zdarzeniu, czy możliwa jest kategoryzacja wsteczna i czy istnieje ścieżka audytu? (4) Pokaż przebieg produkcji przekraczający północ, jak system obsługuje granice zmian? (5) Zademonstruj przezbrojenie produktu trwające 90 minut, czy przezbrojenie jest śledzone oddzielnie od czasu postoju z powodu awarii?
Scenariusze obliczania OEE: (6) Pokaż OEE dla linii produkującej dwa produkty o różnych czasach cyklu w tej samej zmianie, jak obsługiwane są cele dla poszczególnych produktów? (7) Pokaż, jak planowana konserwacja w godzinach produkcji wpływa na dostępność (Availability), czy jest wyłączona z obliczeń OEE, czy pokazana jako planowany przestój?
(8) Zademonstruj obliczanie wskaźnika jakości, skąd pochodzą dane o odrzutach i jak ponowna obróbka jest rozróżniana od złomu? (9) Pokaż, co się dzieje, jeśli wynik OEE dla zmiany wynosi 0%, czy system obsługuje przypadki brzegowe bez błędów? (10) Zademonstruj agregację OEE dla trzech linii z różnymi harmonogramami zmian, jak obliczane jest OEE wieloliniowe?
Scenariusze raportowania i użyteczności: (11) Pokaż wykres Pareto przyczyn przestojów za ostatnie 30 dni, czy można go filtrować według zmiany, produktu i kategorii urządzeń? (12) Zademonstruj tworzenie niestandardowego raportu, ile czasu zajmuje stworzenie nowego raportu od podstaw bez pomocy dostawcy?
(13) Pokaż aplikację mobilną na rzeczywistym urządzeniu w pomieszczeniu, czy to aplikacja natywna, czy widok mobilnej strony? (14) Zademonstruj wyzwolenie alertu i jego otrzymanie przez przełożonego, jakie jest rzeczywiste opóźnienie? (15) Pokaż masowy eksport danych za 12 miesięcy przestojów, ile to trwa i w jakim formacie dane są eksportowane?
Scenariusze integracji i administracji: (16) Pokaż na żywo demo systemu OEE odbierającego dane z testowego PLC przez OPC-UA, nie symulacja, rzeczywiste połączenie. (17) Zademonstruj tworzenie konfiguracji nowej linii produkcyjnej bez udziału dostawcy, jak złożone jest to ustawienie? (18) Pokaż, jak tworzy się nowego użytkownika i przypisuje go do konkretnej linii i roli.
(19) Zademonstruj konfigurację logowania jednokrotnego (Single Sign-On) dla twojego dostawcy tożsamości. (20) Pokaż, jak lista kodów przyczyn przestojów jest aktualizowana, gdy zmienia się taksonomia. (21) Pokaż system działający podczas symulowanego przerwania sieci, czy buforowanie na krawędzi (edge buffering) działa? (22) Zademonstruj API, wykonaj na żywo wywołanie API, aby pobrać dane OEE z ostatnich 24 godzin.
(23) Pokaż, jak system wygląda po 2 latach gromadzenia danych, czy występuje degradacja wydajności? (24) Poproś dostawcę, aby pokazał ci zgłoszenie do wsparcia klienta z ostatnich 6 miesięcy i sposób jego rozwiązania. (25) Pokaż proces aktualizacji, jak wdrażane są nowe wydania i jaki przestój jest wymagany?
Wyślij dostawcom listę kontrolną 25 scenariuszy tydzień przed demonstracją i poproś ich, aby przygotowali się do zaprezentowania każdego z nich. Uważnie obserwuj ich reakcję, dostawcy, którzy kwestionują konkretne scenariusze („nie możemy tego pokazać w środowisku demonstracyjnym”), sygnalizują lukę w możliwościach. Dostawcy, którzy podejmują wyzwanie i przychodzą przygotowani, mają większą pewność co do rzeczywistej wydajności swojej platformy.
Podczas demonstracji oceniaj każdy scenariusz w prostej skali 0, 2: 0 (nie zaprezentowano lub funkcja niedostępna), 1 (zaprezentowano z poważnymi zastrzeżeniami lub obejściami), 2 (zaprezentowano czysto i wiarygodnie). Zapisuj konkretne dowody dla każdej oceny, co pokazał dostawca, jakie wymieniono ograniczenia oraz pytania uzupełniające. Notatki te tworzą zapis oceny demonstracji, który można udostępnić członkom zespołu oceniającego, którzy nie mogli uczestniczyć w całej sesji.
Po demonstracji dopytaj o wszystkie scenariusze, które nie zostały zaprezentowane, żądając pisemnej odpowiedzi, poproś dostawcę o udokumentowanie na piśmie, w jaki sposób ich system obsługuje dany scenariusz.
Pisemne odpowiedzi dotyczące braków w demonstracji tworzą punkty odniesienia w umowie: jeśli dostawca na piśmie twierdzi, że jego system obsługuje scenariusz w określony sposób, a po wdrożeniu tak nie jest, masz dokumentację wprowadzenia w błąd. Taka dokumentacja także skupia zespół sprzedażowy dostawcy na dokładności zamiast optymizmu, co zazwyczaj poprawia wiarygodność ich odpowiedzi.
Zaloguj
Blog
