Wytwarzanie przez „citizen developerów” to praktyka, w której operatorzy hali produkcyjnej, technicy i kierownicy linii tworzą własne aplikacje no-code lub low-code, aby rozwiązywać problemy produkcyjne, nie czekając, aż dział IT napisze kod. Uzbrojeni w narzędzia typu drag-and-drop, bazy danych przypominające arkusze kalkulacyjne i kreatory formularzy mobilnych, osoby najbliżej maszyn mogą teraz przemienić zapisane na kartce prowizoryczne rozwiązanie w działające narzędzie cyfrowe w jedno popołudnie. Ta szybkość jest naprawdę potężna, ale jednocześnie cicho tworzy nową kategorię niezarządzanego oprogramowania działającego w twojej fabryce. Ten artykuł przedstawia zrównoważone spojrzenie na obie strony, abyś mógł wykorzystać korzyści bez odziedziczenia bagnistego zbioru kruchych, niedokumentowanych aplikacji.
Przez dekady każde narzędzie cyfrowe na hali produkcyjnej musiało przejść przez centralny zespół IT lub automatyki. Kolejka zleceń była długa, zbieranie wymagań powolne, a zanim narzędzie zostało wdrożone, proces, który miało wspierać, często ulegał zmianie. Platformy no-code przełamały to wąskie gardło. Planista utrzymania, który rozumie prawdziwy powód, dla którego zlecenia robocze utknęły, może teraz zbudować dokładnie taki formularz, jakiego technicy faktycznie będą używać.
Typowa pierwsza fala aplikacji tworzonych przez citizen developerów skupia się wokół kilku obszarów o wysokim tarciu:
To dokładnie te przepływy pracy, które formalne systemy często pozostawiają niepokryte, dlatego operatorzy sięgają po narzędzie do budowania. Jeżeli jest to dobrze zrobione, jest to bezpośrednie przedłużenie kultury autonomicznego utrzymania: osoby, które są właścicielami procesu, są też właścicielami narzędzi, które go wspierają.
Najmocniejszym argumentem za citizen development jest to, że skraca dystans między problemem a jego rozwiązaniem. Gdy osoba odczuwająca ból sama buduje naprawę, wymagania są poprawne za pierwszym podejściem, a adopcja jest niemal automatyczna, ponieważ nikt nie narzucił narzędzia z góry.
Istnieje też efekt kumulacyjny dla ciągłego doskonalenia. Dobrze prowadzony cykl PDCA lub projekt DMAIC często zatrzymuje się na etapie „kontrola” lub „działanie”, ponieważ nie ma taniego sposobu na utrwalenie nowego standardu. Szybka lista kontrolna w no-code może stać się tym mechanizmem kontroli w tym samym tygodniu, w którym uzgodniono usprawnienie, zamiast dopiero po kilku miesiącach.
Weźmy linię, która pracuje jedną zmianę, 8 godzin dziennie, 20 dni w miesiącu. Operatorzy obecnie zapisują mikroprzestoje na papierze, i w przybliżeniu 40 procent krótkich postojów nigdy nie jest rejestrowane, ponieważ ich zapisanie przerywa proces przywracania. Załóżmy, że linia ma średnio 45 minut niezarejestrowanych mikroprzestojów na zmianę.
Kierownik buduje aplikację no-code typu „tap-to-log”: dwa stuknięcia, by zarejestrować powód postoju. Rejestracja krótkich postojów skacze z 60 procent do 95 procent. To uwidacznia dodatkowe 35 procent z 45 minut, czyli około 16 dodatkowych minut widocznego przestoju na zmianę. W skali miesiąca to 16 minut razy 20 zmian, co daje 320 minut, czyli w przybliżeniu 5,3 godziny wcześniej niewidocznych strat, które teraz można policzyć.
Te nowo widoczne dane trafiają bezpośrednio do rzetelnego wskaźnika OEE (Overall Equipment Effectiveness) i właściwej analizy Pareto przyczyn postojów. Aplikacja stworzona przez citizen developera nie naprawiła maszyny, ale sprawiła, że największych strat nie dało się zignorować. Jednak haczyk jest taki: te 5,3 godziny wglądu żyje teraz w aplikacji osobistej jednego kierownika, na jednym koncie, bez kopii zapasowej i bez właściciela, jeśli on odejdzie.
Każda niezarządzana aplikacja to małe zobowiązanie, które rośnie wraz z użytkowaniem. Ryzyka nie są hipotetyczne i zwykle ujawniają się w najgorszym możliwym momencie.
To klasyczne shadow IT: oprogramowanie, które obsługuje rzeczywiste operacje, ale nie figuruje w żadnym inwentarzu, przeglądzie ani cyklu życia. Przydatnym modelem myślowym jest krzywa wanienkowa. Aplikacje tworzone przez citizen developerów są tanie w uruchomieniu, lecz niosą rosnące ryzyko awarii wraz ze starzeniem się bez nadzoru, a w przeciwieństwie do maszyny nikt nie zaplanował ich konserwacji.
Celem nie jest zakazanie citizen development. Zakazanie go tylko pogrzebie aplikacje pod ziemią. Celem jest lekkie ogrodzenie, które pozwoli użytecznym narzędziom rozkwitać, a kruche wystawi na światło dzienne. Praktyczne podejście:
Tak traktowane, citizen development staje się warstwą szybkiego prototypowania, która odkrywa potrzeby ludzi, podczas gdy trwały, zakładowy zapis mieszka gdzieś odpowiedzialnym miejscu.
Najzdrowszy wzorzec, który obserwujemy, to aplikacje citizen dla bałaganu na krawędziach procesów oraz zarządzany system źródłowy dla wszystkiego, co musi być zaufane, porównywane lub audytowane. Fabrico jest zbudowane jako taki system źródłowy. Dostarcza monitorowanie produkcji i OEE w czasie rzeczywistym, dzięki czemu przestoje i mikroprzestoje są rejestrowane spójnie na każdej linii przy użyciu jednej wspólnej terminologii, a nie dziesięciu prywatnych arkuszy. Jego gotowy do zastosowania w terenie CMMS obejmuje zlecenia pracy, zasoby, harmonogramowanie prewencyjne i części zamienne, dając listom kontrolnym i formularzom zamówień, które operatorzy lubią, stały, należący do organizacji dom zamiast osobistego logowania.
Ponieważ Fabrico wykorzystuje widzenie komputerowe do odczytu maszyn, które nie mają PLC, zespoły mogą zdigitalizować starszy sprzęt bez projektu integracyjnego na zamówienie, co często jest dokładną luką, którą aplikacja citizen próbowała załatać papierowo. Jako platforma stworzona w UE z lokalizacją danych w UE, odpowiada też na obawy dotyczące bezpieczeństwa i jurysdykcji, które darmowe narzędzia konsumenckie cicho kreują. Krótko mówiąc, Fabrico to fundament danych w czasie rzeczywistym, wokół którego twoi citizen developerzy mogą budować, tak żeby ich szybkość składała się na spójny obraz, a nie fragmentację. Możesz zobaczyć, jak przechwytuje dane z hali w przeglądzie monitorowania produkcji i OEE.
Niekoniecznie. Citizen development staje się shadow IT tylko wtedy, gdy aplikacje działają poza jakimkolwiek rejestrem, przeglądem lub strukturą własności. Zatwierdzony citizen development, z prostym inwentarzem aplikacji i progami ryzyka, daje korzyści szybkości bez niezarządzanego ryzyka. Różnica to nadzór, a nie samo narzędzie.
Traktuj to jako obszar wysokiego ryzyka. Zapisy jakości i zgodności wymagają walidacji, zablokowanych śladów audytu i identyfikowalności, których większość narzędzi no-code domyślnie nie wymusza. Bezpieczniej jest pozwolić aplikacjom citizen prototypować przepływ pracy, a następnie migrować wszystko, co powiązane ze specyfikacjami, planem kontroli lub identyfikowalnością klienta, na zarządzany system źródłowy.
Ustandaryzuj słownictwo, zanim ustandaryzujesz narzędzia. Jeśli wszyscy używają tych samych kodów przyczyn przestojów, nazw zasobów i kategorii defektów, nawet niezależnie zbudowane aplikacje będą generować porównywalne dane. Połącz tę wspólną taksonomię z centralną platformą czasu rzeczywistego, która stanie się jedynym miejscem, do którego to wszystko spływa, a fragmentacja w dużej mierze sama się rozwiąże.
Gotowy, by dać swojej hali produkcyjnej zarządzany, działający w czasie rzeczywistym fundament danych, wokół którego citizen developerzy mogą budować zamiast obchodzić system? Umów się na demo Fabrico i zobacz, jak OEE w czasie rzeczywistym i gotowy do użycia w terenie CMMS zamieniają rozrzucone aplikacje operatorów w jeden wiarygodny obraz twojego zakładu.
Zaloguj
Blog