GIGO a procesy

Wyobraźmy sobie, że w opisanych przeze mnie wcześniej procesach:

• generowania raportu na podstawie danych źródłowych (opisywanego we wpisach o metodzie 5W2H oraz marnotrawstwie.
• raportowania (we wpisie w kontekście entropii informacyjnej).

na wejściu do procesu trafiły błędne, niespójne lub niesprawdzone dane, czyli tzw. “śmieci” na wejściu (ang. garbage in) – skrócie GI. Same procesy możemy uogólnić jak to przedstawiono na poniższym diagramie.

W pierwszym procesie dane zostaną przetworzone, przeanalizowane a następnie zostanie wygenerowany raport. Załóżmy, że dane źródłowe składały się z wymieszanych danych z różnych lat, a generowany raport dotyczy podsumowania roku. Porównując takie informacje z zeszłym rokiem otrzymujemy raport, który nie odpowiada rzeczywistości. Działanie procesu jest takie samo, a na wyjściu otrzymujemy nieużyteczne informacje, czyli tzw. “śmieci” na wyjściu (ang. garbage out) – w skrócie GO.

W drugim procesie z kolei, możemy przeprowadzić analogiczną analizę. Załóżmy, że pierwszy z uczestników procesu, usłyszał o samolocie i bez sprawdzenia tej informacji (czy taki lot jest) przekazał dalej albo podobne zachowanie nastąpiło na późniejszym etapie. Można powiedzieć, że gdy wejście do danego kroku procesu nie jest prawdziwe, w wyniku realizacji tego kroku, ta sytuacja się nie zmieni, jeżeli ten krok zakłada korzystanie z informacji i wykonanie kolejnych zaplanowanych działań. W efekcie podjęte działania nie są adekwatne do sytuacji, czyli racjonalnie patrząc powinny zostać spisane na straty. Co niektórzy powiedziliby, że powinny trafić do kosza.

Wiele procesów przetwarza dane wejściowe w konkretne informacje, decyzje (a to może mieć różne konsekwencje, o czym można się przekonać przeglądając różne artykuły dostępne w sieci). Patrząc na uogólniony diagram, gdy wejście będzie niepoprawne, decyzja nie będzie prawidłowa/nieadekwatna (poprzez porównanie do sytuacji, gdy dane byłyby poprawne). W skrócie GIGO (ang. garbage in, garbage out).

Reklama

BPMN – dalsza analiza procesu

Wśród pojęć w metamodelu zostały wymienione między innymi następujące:

• [punkt 1.] Zadanie Wejścia/Wyjścia (ang. Task I/O)
• [punkt 3.] Cechy jakości (ang. Quality Attributes)
• [punkt 5.] Strumień kontroli (ang. Control Flow)
• [punkt 6.] Kierowanie danymi (ang. Data Handling)
• [punkt 8.] Role (ang. Roles)
• [punkt 9.] Zdarzenia (ang. Events)
• [punkt 13.] Dane statystyczne (ang. Statistical Data)

Niektóre z nich – 1, 5, 6, 8, 9 – zostały wykorzystane na zamieszczonych diagramach podczas prezentacji warstwy implementacyjnej – cały proces oraz podproces.

Przykładowo:

• „Zadanie wejścia/wyjścia” to „ProduktDostarczony”
• „Strumień kontroli” to połączenie między krokami „Potwierdzenie zamówienia” a „Analiza danych zamówienia”
• „Kierowanie danymi” to połączenie między „Złożenie zamówienia” a „Przygotowanie zamówienia”
• „Role” to obiekt „Wykonanie: Pracownik”
• „Zdarzenia” to „Produkt dostępny”

Biorąc pod uwagę drugi z diagramów – tzn. podproces – można dodać do niego kolejne informacje: „Cechy jakości” oraz „Dane statystyczne”. Są to informacje, które można zebrać analizując wykonanie całego procesu. Istotne jest jednak to, aby w odpowiednich miejscach została zachowana informacja, która pozwoli na późniejszą analizę. Mogą to być następujące informacje:

• „data/czas rozpoczęcia” i „data/czas zakończenia” poszczególnych kroków;
• „oczekiwany czas wykonania określonych kroków” – aplikacja wspierająca wykonanie procesu może przypominać o zbliżających się terminach, bądź opóźnieniu;
• „wyjątki”/”niezaplanowane zdarzenia” – np. brak papieru w drukarce, wygaśnięcie umowy z pośrednikiem. Mogą to być bardziej lub mniej trywialne zdarzenia.

Są to informacje, które mogą się znaleźć w szczegółowym opisie danego procesu, aby nie przepełniać podstawowego diagramu. W momencie zapisu daty/czasu może nastąpić porównanie z założonymi czasami realizacji procesu. Takie elementy zostały zaprezentowane na poniższym diagramie.