Dedykowane rozwiązania IT: 7 sygnałów, że obecny system ogranicza Twoją produkcję

Dedykowane rozwiązania IT możesz rozważyć wtedy, gdy obecne narzędzia przestają obsługiwać ważny fragment procesu, a zespół nadrabia braki arkuszami, ręcznym przepisywaniem danych albo dodatkowymi procedurami. Nie zawsze oznacza to budowę nowego systemu. Po przeczytaniu tego poradnika łatwiej ocenisz, czy problem wymaga integracji, rozszerzenia obecnego środowiska, aplikacji dedykowanej czy pełnego systemu tworzonego na zamówienie.

Jeśli odpowiadasz za produkcję, operacje albo cyfryzację zakładu, najważniejsza decyzja zapada jeszcze przed wyborem technologii. Ustal, gdzie dokładnie proces przestaje działać tak, jak powinien. Wtedy dedykowane rozwiązania IT można potraktować jako odpowiedź na konkretną stratę czasu, ryzyko błędu albo brak informacji potrzebnej do decyzji.

W zakładzie produkcyjnym oprogramowanie na zamówienie może być niewielką aplikacją operatorską, modułem rozszerzającym ERP, integracją między MES i systemem nadrzędnym albo osobnym systemem obsługującym proces, którego standardowe narzędzia nie odwzorowują wystarczająco dobrze.

Dedykowane rozwiązania IT obejmują znacznie więcej niż pełny system. W obszarze oprogramowania dedykowanego dla produkcji znajdziesz zarówno budowę nowych aplikacji, jak i rozwój istniejących platform, moduły oraz integracje między ERP, MES, SCADA, maszynami i bazami danych. Jeżeli źródłem problemu jest przepływ informacji między działającymi systemami, dokładanie kolejnej aplikacji może tylko zwiększyć liczbę miejsc wymagających utrzymania.

Dobrym punktem odniesienia przy porządkowaniu architektury jest ISA-95. Standard opisuje modele i wymianę informacji między funkcjami biznesowymi i produkcyjnymi, w tym interfejs między systemami poziomu 3 i 4. Szczegóły można sprawdzić w oficjalnym opisie standardu ISA-95. Dla projektu oznacza to prostą rzecz: przed wyborem technologii trzeba ustalić, gdzie powstają dane, który system jest ich źródłem i dokąd mają trafić.

Arkusz kalkulacyjny sam w sobie nie świadczy o problemie. Sygnałem ostrzegawczym staje się, gdy przejmuje logikę ważnego procesu. Lider zmiany prowadzi w nim aktualny status zleceń, jakość zapisuje wyniki poza systemem, a planista łączy kilka eksportów, żeby przygotować obraz produkcji.

Dedykowane rozwiązania IT warto przeanalizować, jeśli taki plik stał się nieformalną aplikacją biznesową, czyli jest potrzebny do decyzji, zawiera własne reguły i trudno go zastąpić bez wiedzy kilku osób. Najpierw spisz, jakie dane trafiają do arkusza, kto je wprowadza, co jest na ich podstawie obliczane i gdzie wynik jest później wykorzystywany. Ta mapa pokaże, czy potrzebna jest aplikacja, integracja, czy wystarczy zmiana konfiguracji obecnego systemu.

Zlecenie powstaje w ERP, później jego numer trafia do arkusza, operator wpisuje go na stanowisku, a po zakończeniu ktoś przenosi wynik wykonania z powrotem do systemu nadrzędnego. Każde ręczne przekazanie zwiększa liczbę punktów, w których informacja może zostać wpisana inaczej, trafić za późno albo w ogóle nie wrócić.

Tu dedykowane rozwiązania IT często powinny zacząć się od integracji, a nie od nowej aplikacji. Jeżeli oba systemy mają potrzebne dane i można jednoznacznie ustalić ich znaczenie, dedykowane rozwiązania IT mogą po prostu automatyzować przepływ. W explitia znajdziesz taki model przy synchronizacji danych z ERP: do produkcji mogą trafiać informacje o zleceniach i operacjach, a do ERP wracać między innymi wykonane ilości, statusy, zużycie materiałów, braki, przestoje czy wyniki kontroli jakości.

ERP może poprawnie prowadzić plan i rozliczenia, SCADA zbierać sygnały z maszyn, a MES rejestrować realizację. Kłopot zaczyna się wtedy, gdy każdy system opisuje fragment tej samej produkcji, lecz między fragmentami brakuje uzgodnionej wymiany danych. Status z hali nie wraca do planisty, identyfikator partii ma inną postać w dwóch miejscach albo raport trzeba skleić ręcznie.

W tej sytuacji dedykowane rozwiązania IT powinny zacząć się od ustalenia właścicieli danych. Dla zlecenia, produktu, partii, operacji, wyniku jakościowego czy czasu postoju trzeba wskazać system źródłowy oraz zasady wymiany. Samo API nie rozwiązuje problemu znaczenia danych. Więcej znajdziesz w materiale o API w przemyśle i integracji ERP, MES oraz SCADA: technicznie poprawnie przesłana wartość nadal może zostać źle zinterpretowana, jeśli systemy inaczej rozumieją status, jednostkę albo zdarzenie.

Nie zawsze brakuje danych, bo czasem są dostępne, ale trzeba je zebrać z kilku miejsc, sprawdzić i ręcznie przeliczyć. Kierownik produkcji dostaje podsumowanie po zmianie, chociaż informacja o odchyleniu była potrzebna podczas jej trwania. Planista poznaje rzeczywisty postęp dopiero po aktualizacji pliku.

Dedykowane rozwiązania IT mają wtedy sens, jeśli skracają konkretną drogę od zdarzenia do reakcji. Zakres może obejmować automatyczne pobieranie danych, walidację, regułę alarmową i ekran pokazujący wybranej roli tylko informacje potrzebne do decyzji. Dedykowane rozwiązania IT oceniaj według tego, czy zmniejszają opóźnienie informacyjne, a nie według liczby funkcji zapisanych w specyfikacji.

Wiele procesów można standaryzować, jeżeli jednak sposób pracy wynika z technologii produkcji, wymagań klienta, traceability, kontroli jakości albo określonej logiki planowania, dopasowanie procesu do ograniczeń programu może stworzyć nowy problem.

Dedykowane rozwiązania IT są warte analizy, gdy standardowa konfiguracja nie pozwala odwzorować reguły potrzebnej do poprawnego prowadzenia procesu. Trzeba przy tym odróżnić rzeczywiste wymaganie od przyzwyczajenia organizacji. Argument „u nas zawsze robiło się to inaczej” nie wystarcza. Dobra kwalifikacja powinna wskazać konsekwencję: co stanie się z jakością, terminem, identyfikowalnością produktu, rozliczeniem albo pracą operatora, jeśli reguła zostanie pominięta.

W takim miejscu dedykowane rozwiązania IT mogą chronić logikę potrzebną procesowi, a elementy typowe pozostawić standardowym narzędziom.

Nowy wariant produktu, zmiana marszruty, dodatkowa kontrola jakości albo uruchomienie kolejnego stanowiska wymaga aktualizacji kilku systemów i plików. Jedną część wykonuje IT, kolejną automatyk, a pozostałe zmiany są rozproszone po lokalnych arkuszach. Nawet mała zmiana biznesowa zaczyna przypominać osobny projekt.

Zanim powstaną dedykowane rozwiązania IT, trzeba sprawdzić źródło tej sztywności. Źródłem może być architektura starego systemu, wielokrotne przechowywanie danych albo brak jasnego właściciela konfiguracji. Dedykowane rozwiązania IT powinny usuwać właśnie tak rozpoznane ograniczenie. Jeśli firma potrafi wskazać, która część procesu zmienia się regularnie i kto powinien móc nią zarządzać, można zaprojektować moduł oddzielający zmienną logikę biznesową od reszty środowiska.

Proces oparty na jednym arkuszu może działać na pojedynczej linii. Przy kolejnych gniazdach pojawiają się kopie pliku, lokalne wersje instrukcji i różne sposoby rejestrowania tej samej informacji. Podobny efekt daje uruchomienie następnego zakładu albo rozszerzenie produkcji o nowe grupy wyrobów.

Tu trzeba policzyć koszt powielania problemu, a nie tylko koszt obecnego obejścia. Dedykowane rozwiązania IT mogą ujednolicić proces i pozwolić wdrażać go w kolejnych obszarach według tych samych zasad. Dedykowane rozwiązania IT skalują się sensownie dopiero wtedy, gdy wiadomo, które elementy procesu są wspólne, a gdzie potrzebna jest własna konfiguracja.

Najdroższy błąd koncepcyjny powstaje wtedy, gdy firma rozwiązuje niewłaściwy problem. Dedykowane rozwiązania IT nie naprawią procesu z niejasnymi odpowiedzialnościami. Integracja nie pomoże, jeśli systemy przechowują sprzeczne dane. Pełne oprogramowanie na zamówienie będzie przesadą, gdy brakuje jednej dobrze zdefiniowanej funkcji.

Jeżeli Twoja decyzja dotyczy wyboru między produktem z półki a własnym rozwiązaniem, osobny artykuł porównuje oprogramowanie dedykowane i gotowy system IT. Ten poradnik zatrzymuje się krok wcześniej: pomaga ocenić, czy dedykowane rozwiązania IT są w ogóle właściwym kierunkiem.

Na początku nie potrzebujesz dokumentu z setką wymagań. Znacznie więcej daje jeden dobrze opisany przebieg rzeczywistego zlecenia lub operacji. Zaznacz, gdzie informacja powstaje, kto ją wpisuje, kto później jej używa, gdzie jest przepisywana i w którym miejscu trzeba czekać na potwierdzenie.

Do tego dołóż listę systemów i urządzeń uczestniczących w procesie oraz dostępne sposoby komunikacji. Przy integracji znaczenie ma nie tylko istnienie API. Trzeba uzgodnić model danych, kierunek wymiany, identyfikatory, obsługę błędów i zachowanie systemów, gdy jeden z nich jest chwilowo niedostępny. ISA-95 porządkuje obszar wymiany informacji między funkcjami przedsiębiorstwa i sterowania produkcją.

Dla dedykowanych rozwiązań IT najważniejsze są mierzalne kryteria powodzenia. Zamiast zapisywać „usprawnić raportowanie”, określ, kto ma przestać przygotowywać raport ręcznie, jaka informacja ma być dostępna wcześniej, które dane mają wracać do ERP albo jaki błąd ma zostać wykryty przed zatwierdzeniem operacji.

W rozmowie powinien uczestniczyć właściciel biznesowy procesu, osoba znająca środowisko IT/OT i użytkownicy wykonujący daną pracę. Przy procesie jakościowym, magazynowym czy utrzymaniowym potrzebny będzie też przedstawiciel odpowiedniego działu. Taki skład pozwala zestawić wymagania biznesowe z technicznymi ograniczeniami i szczegółami codziennej pracy.

Jeśli diagnoza każdego problemu prowadzi do propozycji napisania nowego systemu, warto wrócić do początku analizy. Na stronie oprogramowania dedykowanego dla produkcji zobaczysz, że przed wyborem kierunku sprawdza istniejące systemy, a rozwiązaniem może być osobny moduł, rozwój obecnego środowiska albo nowa aplikacja.

Dedykowane rozwiązania IT mają sens wtedy, gdy ich zakres wynika z ograniczenia procesu, a efekt można później sprawdzić. Jeśli przed decyzją chcesz uporządkować proces, źródła danych, straty i zależności między systemami, takim etapem może być Warsztat 360 explitia, który zaczyna się od analizy pracy zakładu przed wyborem systemu lub modułu.

Najbezpieczniejsza zasada brzmi: najpierw nazwij problem i wskaż dane, które go potwierdzają. Dopiero potem wybieraj technologię. Dedykowane rozwiązania IT powinny być konsekwencją tej diagnozy, a nie jej zastępstwem.

Nie. Dedykowane rozwiązania IT mogą przyjąć formę nowej aplikacji, modułu, rozszerzenia istniejącego systemu albo integracji między używanymi już narzędziami. Taki zakres opisujemy również w ofercie oprogramowania dedykowanego dla produkcji.

Nie. Na pierwszym etapie bardziej użyteczny jest opis procesu, użytkowników, źródeł danych, wyjątków i oczekiwanego rezultatu. Na tej podstawie można określić wymagania i dopiero później przejść do architektury rozwiązania.

Gdy potrzebne dane już istnieją w działających systemach, a głównym problemem jest ich ręczne przenoszenie albo opóźniona wymiana. Wtedy warto najpierw sprawdzić możliwość połączenia systemów i uzgodnienia znaczenia danych, zanim powstanie kolejna aplikacja.

Osoba odpowiedzialna biznesowo za proces, który ma się zmienić. IT lub IT/OT powinno współuczestniczyć w projekcie ze względu na architekturę, integracje, bezpieczeństwo i utrzymanie, ale rezultat powinien być rozliczany wobec procesu, nie samego wdrożenia technologii.