W jednym z poprzednich artykułów na temat ERP 4.0 napisałem, że automatyzacja, elastyczność i podział ma moduły, to główne wyznaczniki nowej odsłony standardu. Tym razem chciałbym się skupić na pierwszym elemencie tej listy, na automatyzacji, oraz jej wpływie na UI systemów ERP.

Klasyczne podejście do interakcji człowieka z systemem informatycznym można symbolicznie ująć tak:

Nowe UI

System wykonuje polecenia użytkownika oraz udostępnia swój stan wewnętrzny w formie prezentacji danych (dostarczania informacji). Inicjatywa w tej dwustronnej relacji leży głównie po stronie użytkownika, to on odgrywa wiodącą rolę w obu sposobach interakcji np. „Zatwierdź dokument KP” czy „Pokaż listę zamówień oczekujących na realizację”. W konsekwencji interfejsy użytkownika (UI) były i wciąż są przygotowane do obsługi dokładnie takiego sposobu współpracy. Warto zauważyć, że przyszło (idzie) nowe, i sytuacja uległa częściowej, ale bardzo wyraźnej zmianie. Nie twierdzę, że ten schemat jest całkowicie nieaktualny, to nie prawda, ale prawdą jest, że nowe wymagania mocno go rozbudowały i to na tyle, że planując nowe systemy, nowe wersje systemów, nie możemy nie być tego świadomi. Jak to zatem wygląda w nowoczesnym systemie? Można to ująć tak:

Nowe UI

Definiuje – użytkownik definiuje strukturę (np. oddziały, magazyny, słowniki, definicje dokumentów, zespoły, market-place’y) oraz procesy (np. jak przebiega obsługa zamówienia, reklamacji, rekrutacji, pozyskania lead’ów). Aktywność w tym zakresie będzie wzrastać. Systemy będą „robić” coraz więcej, coraz węcej będziemy im zlecać, na razie jeszcze nie, ale docelowo poprzez definiowanie potrzeb i oczekiwań.

Inicjuje – większość procesów inicjowanych jest automatycznie (czasowo, albo na podstawie zdarzeń w systemie) lub w reakcji na sygnał z zintegrowanych systemów zewnętrznych, ale wciąż, także sam użytkownik inicjuje procesy (np. rekrutacja po telefonie, wgranie nowej wersji, planowanie wizyty referencyjnej). Aktywność w tym zakresie będzie maleć. Procesy będą inicjować się automatycznie, bez wyraźnego udziału człowieka.

Decyduje – użytkownik musi podejmować decyzje tam gdzie automatyzacja systemu nie umie jej podjąć autonomicznie. Może to być czysta decyzja (np. przyznanie limitu kredytowego, lub nie, uznanie lub nie reklamacji) albo pozyskanie i uzupełnienie informacji potrzebnej do podjęcia decyzji automatycznie w dalszym etapie procesu (np. ocena stanu zwracanego towaru, opinia przełożonego o pracowniku). Aktywność w tym zakresie będzie maleć. Systemy będą umiały zdecydować o wszystkim.

Monitoruje – użytkownik monitoruje stan systemu. W zautomatyzowanych systemach dużo dzieje się „samo” i jakby „bez wiedzy” użytkowników. Co prawda użytkownicy definiują automatyzację, w ten sposób mając nad nią pełną kontrolę, ale efekty jej działania nie zawsze są oczywiste. Monitorowanie stanu systemu w wszystkich jego aspektach od technicznych (np. ile procesów kończy się błędem, jaki procent e-mail’i dochodzi do klientów) po biznesowe (np. jaka jest sprzedaż w ujęciu rok do roku) jest kluczowe do pozyskania wiedzy o stanie systemu a także organizacji, którą ten system odzwierciedla. Aktywność w tym zakresie będzie wzrastać. To prawda, aczkowiek tylko w najbliższej perspektywie. Coraz większy zakres automatyzacji da coraz większy obszar do monitorowania. W dalsej perspektywie to systemy będą monitorowały systemy.

Wykonuje – pomimo wszechobecnej automatyzacji wciąż jeszcze użytkownik wykonuje pracę na rzecz systemu, główne przyczyny tego stanu, to niedostatki automatyzacji oraz problemy na styku świat rzeczywisty – system. Nie zawsze umiemy automatycznie i bez udziału człowieka odczytać stan fizyczny (np. co naprawdę leży na wskazanej półce w magazynie, ile naprawdę jest palet na przyczepie i jakie mają kody, jaki jest poprawny adres klienta skoro ten jest błędny). Nie zawsze umiemy automatycznie wpływać na stan fizyczny (np. umieść karton na palecie, spakuj zakupy klienta, podaj klientowi paragon). Aktywność w tym zakresie będzie maleć. System będzie potrafił sam wykonać wszystko.

Tak wyglądają aktywne zachowania użytkownika na styku z systemem. Patrząc od strony systemów to właśnie dzięki automatyzacji zyskały one zdolność do inicjowania, aranżowania interakcji z użytkownikiem. I tak, system:

Pyta – wszędzie tam gdzie mechanizmy automatyzacji są zbyt słabe lub brakuje im danych, a także w tych miejscach gdzie decyzje wiążą się z odpowiedzialnością za ich skutki a nie potrafimy jeszcze tej odpowiedzialności delegować, system musi przekazać decyzję do użytkownika. Aktywność w tym zakresie będzie maleć. Sytem nie będzie miał potrzeby pytać o cokolwiek.

Zleca – to system posiada najlepszy obraz sytuacji i to system jest w stanie przekazać polecenia wykonania jakiejś pracy użytkownikowi, której sam nie umie wykonać. Aktywność w tym zakresie będzie maleć. System sam zrobi wszystko, udział człowieka nie będzie konieczny.

Informuje – to także system zna najlepiej swój stan i jest w stanie zidentyfikować te informacje, które stanowią jakąś formę odstępstwa od stanu typowego, oczekiwanego, a automatyka systemu nie umie sobie z tym poradzić, więc należy je przekazać do użytkownika aby zwrócił na nie uwagę. Aktywność w tym zakresie będzie maleć. Systemy będą miały coraz mniej nam do powiedzenia. Jednak zgadzam się, że jest tu pole do dyskusji, gdyż informowanie przez system może być emanacją aktywności użytkownika z zakresu czynności „Monitoruje” a tam prognozujemy „Aktywność w tym zakresie będzie wzrastać”.

Taki stan mamy obecnie, różnej klasy systemy lepiej lub gorzej radzą sobie z realizacją tego schematu. Szczególnie interesujący jest wektor tych zmian, w sensie, jak to będzie wyglądało w przyszłości? Weźmy pod uwagę tylko te aspekty styku człowiek-system, które (subiektywnie oczywiście) oznaczyłem jako „Aktywność w tym zakresie będzie wzrastać”. Są wyłącznie dwa:

Definiuje i Monitoruje

Gdy uznać wyniki tych rozważań za poprawne, to właśnie pod takie zastosowania (użytkownik będzie określał czego oczekuje i weryfikował wyniki) należy tworzyć/modyfikować nowe architektury interfejsów użytkownika w systemach klasy ERP.

Krzysztof Olszewski

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania

Krzysztof Olszewski

Krzysztof Olszewski

Dyrektor Technologii i Architektury Oprogramowania