Tydzień temu wyjaśniłem, co należy rozumieć pod pojęciem groupware. Dzisiaj nieco więcej szczegółów o możliwych reprezentacjach workflow.

Dla przypomnienia: każdy z modeli workflow jest oparty na kilku architektonicznie niezależnych paradygmatach:

- implementacji formularzowej

- implementacji komunikacyjnej (poczta elektroniczna)

- implementacji proceduralnej.

Implementacja formularzowa

Na produkty tego typu można patrzeć z różnych stron, w zależności od tego, czyjego oprogramowania używa się i z jakimi produktami pracownicy chcieliby pracować.

Implementacja formularzowa jest oparta na technologii obiektowej, która zapewne działa już w większości biur, a nawet w domach. Dla przykładu rozważmy notatnik leżący przy telefonie. Z reguły używa się go do zapisania nazwiska i numeru telefonu osoby, która dzwoniła oraz informacji, czego rozmowa dotyczyła. Ponieważ pola ma się już w głowie (nazwisko, numer telefonu i temat), nie ma specjalnego powodu do ponownego ich zapisywania podczas tworzenia notatek.

Rysunek obok ilustruje różne implementacje formularzowe, włączając w to EDI (Electronic Data Interchange) oraz aplikacje graficzne.

Wypełnianie formularzy ma określony tok przebiegu. Po wpisaniu danych formularz trzeba dostarczyć do osoby, która się nim dalej zajmie lub też zostawić w określonym miejscu, skąd odbierze go odbiorca.

W najprostszej implementacji elektronicznej (grupie roboczej), formularz jest przekazywany od jednej osoby do drugiej, prawdopodobnie za pomocą oprogramowania z którym dane są "stowarzyszone". W grupie roboczej typu "groupware" adresy zarejestrowanych użytkowników aplikacji stają się adresami przeznaczenia, tak że można obejrzeć przepływ czynności od, powiedzmy, osoby A do osoby B.

Inna technika, także czerpiąca swoje korzenie z papierowych formularzy, to administracyjny przepływ czynności. W tym przypadku koncepcja sprowadza się wyłącznie do śledzenia administracyjnych statystyk, np. ile odwołań dotyczy konkretnych formularzy. W tym scenariuszu, gdy nowy formularz jest ściągany przez użytkownika, to jego atrybuty - odbiorca, liczba odwołań na godzinę itd. - są wypełniane przez rezydentny program statystyczny.

Implementacja formularzowa jest zdecydowanie obszarem niejednorodnym. Czy formularz jest formularzem czy też pocztą elektroniczną? A może dokumentem? Nie zmniejsza to jednak powszechności jej stosowania, jako że każdy z nas ma z nią do czynienia najczęściej.

Implementacja komunikacyjna (E-mail)

Implementacje oparte na formularzach są nadal popularne. Jednak gdy odległości między pracownikami rosną, to implementacja formularzowa zaczyna ustępować miejsca implementacji komunikacyjnej. Podstawowa różnica między nimi, to liczba używanych aplikacji.

Implementacja oparta na poczcie elektronicznej używa sieci w celu połączenia się z oddalonymi użytkownikami - zupełnie inaczej niż robi się to za pomocą groupware czy formularzy. Podstawowa aplikacja odwołuje się bowiem do specyficznej aplikacji (lub programu poczty elektronicznej) w celu wysłania wiadomości do innego użytkownika. Jego adres jest pobierany z bazy danych i wiadomość jest wysyłana za pomocą interfejsu poczty elektronicznej.

Workflow traktuje tę operację jako zdalne, a nie lokalne dostarczenie poczty. Implementacja ta nabiera więc nowego aspektu: zalegalizowania alternatywnych dróg przesyłania. Dostarczanie przesyłek przestaje być związane z programem użytkownika wychodząc tym samym poza koncepcję grupy roboczej.

W przypadku grupy roboczej proste dzielenie katalogu może być wszystkim, co jest niezbędne pojedynczemu użytkownikowi w celu uzyskania dostępu do dokumentu, notatnika lub formularza wspólnego dla całej grupy.

Niestety, inteligentne wykonywanie zadań nie zaczyna się i nie kończy na adresowaniu. W przykładzie o tworzeniu notatek z rozmowy telefonicznej zakłada się, że operator potrafi poprawnie zapisać wiadomość i skierować ją w odpowiednie miejsce. Innymi słowy, praca nieodłącznie wiąże się z inteligencją operatora związaną ze zbieraniem danych, adresowaniem wiadomości i kierowaniem ich do właściwych osób.

W przypadku systemu papierowego inteligencja ta jest związana z człowiekiem. W przypadku formularzy elektronicznych i poczty elektronicznej, sterowanie jest przesunięte do programu, co może zaburzać konkretny system E-mail. Dlatego też implementacja komunikacyjna wysyła zawartość formularza na adres E-mailowy użytkownika. Stąd też oddzielna technologia przejmuje faktyczne dostarczenie wiadomości czy jest ona formularzem, czy też nie.

W rzeczywistości proces przepływu czynności wymaga listy potencjalnych adresów. Jeden z nich jest wybierany przez program i rozpoczyna się proces dostarczania. Proces ten zna adres E-mailowy potencjalnego odbiorcy wiadomości. Musi także znać interfejs E-maila, format wiadomości i jej parametry. Dysponując tymi informacjami proces autonomicznego dostarczania może przejąć elementarną operację pocztową (tzn. bez alternatyw).

Jako specyficzny paradygmat przepływu czynności, E-mail oferuje mnogość alternatyw do rozważenia przez administratora sieci: czy powinien używać techniki "store and forward" (przechowaj i wyślij dalej)? Czy powinien połączyć ją z istniejącymi technologiami pocztowymi? A możliwość połączenia implementacji komunikacyjnej z dwiema pozostałymi jest godna polecenia.

Na zakończenie nieco więcej o problemach. Jedna architektoniczna trudność z pocztą elektroniczną polega na reagowaniu na sytuację braku potwierdzenia, gdy potwierdzenie jest niezbędne do rozpoczęcia trasmisji. Przykładowo, jak program może policzyć liczbę wiadomości E-mailowych bez odpowiedzi po 20 min i ponownie przesłać je bez duplikowania? W świecie papierowych dokumentów odpowiada to próbie powstrzymania Kowalskiego od powrotu do biura i odpowiedzi na wiadomość, którą właśnie do niego skierowała Kwiatkowska.

Można ten problem rozwiązać poprzez przypisanie wspólnego adresu ludziom odpowiadającym na telefony. Jednakże wspólne mailboxy naruszają zasadę poufności informacji! Poczta elektroniczna ze swojej natury jest wysoce strukturalna: jeden odbiorca to jeden adres. Replikowanie komunikatów poczty elektronicznej do wielu mailboxów w rozległej sieci jest niezwykle trudne. I na odwrót, użytkownicy mający wiele skrzynek muszą przeglądać mnóstwo poczty. Zamieszanie staje się totalne.

Badając ten przypadek dogłębniej widać, że podstawowy paradygmat workflow może zawieść w sytuacjach, gdzie komunikaty stają się niepoprawne albo gdy muszą być ponownie przesłane. I poczta nie jest tu winna. Raczej sam model i mechanizm reakcji wymagają zestrojenia.

Implementacja proceduralna

Poza koncepcjami proceduralnymi umożliwiającymi wykonywanie procedur (jak to opisano poniżej), przepływ czynności musi być postrzegany jako metodologia elektronicznego reprezentowania i zatwierdzania istniejących procedur, zarówno administracyjnych jak i produkcyjnych.

Przykładowo rozważmy ręcznie wykonywaną procedurę biurową, taką jak udanie się do kartoteki i wyszukanie dokumentu. Przepływ czynności powinien być w stanie opisać tę procedurę (wraz z graficzną jej prezentacją) zarówno jako proces ręczny (spacer i pobranie), jak i jako elektroniczny ekwiwalent procesu (taki jak baza danych obrazów dokumentów).

Pierwszym źródłem nieporozumień jest to, co robi workflow z procedurami. Koncepcje workflow związane z reprezentację (grafiką) i działaniami są często łączone, gdy tak naprawdę, powinny być postrzegane oddzielnie. Workflow powinien dbać zarówno o graficzną reprezentację porządku, zbieranie danych statystycznych i zarządzanie, jak i stosownie wskazywać, które akcje mają być wykonane i określać ich kolejność, odbiorcę i wymagane potwierdzenie.

Na koniec implementacja proceduralna powinna radzić sobie z symulacjami (co jeśli?). Dla przykładu, co się stanie, gdy liczba wiadomości telefonicznych wzrośnie dwa razy? Czy czas reakcji aplikacji przestanie być akceptowalny? Workflow powinien symulować zarówno wzrost, jak i spadek aktywności, pozwalając administratorom na dokonywanie prognoz w ramach modelowania procesu. W przypadku produktu grupowego, pozwala to np. na sprawdzenie jak pakiet radzi sobie z 10 i 100 użytkownikami więcej, zanim dokona się zakupu. Prawdziwy workflow musi być w stanie modelować i symulować aktywność.

W każdym przypadku technologia workflow nie powinna być mylnie odbierana, jako tylko procedura (pobranie dokumentu), narzędzie do wyszukiwania dokumentów czy oprogramowanie. Technologia ta powinna być rozpatrywana jako metodologia pozwalająca instrukcjom interakcyjnie wykonywać żądania oparte na listach akcji. Żądania te mogą dotyczyć manualnych procesów (gdy są niezbędne) lub elektronicznie uruchamianych aplikacji.

W firmie workflow musi być czymś więcej, niż tylko pojedynczą metodą (jak wysyłanie E-maila) do duplikowania ręcznej lub związanej z komputerem aktywności. Powinien zajmować się całym spektrum procedur biurowych, nawet tymi, które nie mogą lub nie będą elektronicznie zautomatyzowane. Metody te można zaliczyć do implementacji proceduralnej. Wszystkie one mają jedną przewagę właśnie wtedy, gdy ktoś potrzebuje zautomatyzować środowisko produkcyjne bazujące na procedurach. Z ich użycia wynika, że większość, jeśli nie wszystkie procesy produkcyjne będą modelowane i zarządzane w sieci. Sieciowa implementacja jest tu po prostu koniecznością.

Bliżej sieci

Co wspólnego ma z sieciami technologia przepływu czynności, poza oczywistym faktem, że nie implementuje się dobrze poza światem połączonych na wzajem użytkowników?

Wiele uwag dotyczy administratora sieci. Po pierwsze, tradycyjna praca nie pozwala na automatyczne zbieranie statystyk, modelowanie procesu pracy czy symulacje. Po drugie, workflow istotnie zwiększa ruch w sieci, szczególnie dzięki komunikacji między oddziałami i wykorzystaniu serwera. Po trzecie, implementacja workflow może być złożona. Jeśli jednak technologia ta ma odnieść sukces na rynku, to produkty muszą być proste.

Ostatnie słowo ostrzeżenia do członków grup roboczych: uwzględniaj czynnik skalowalności, ponieważ zmiany są nieuniknione. Produkty typu groupware nie wykazują obecnie elastyczności przy integrowaniu nowych i/lub zewnętrznych procedur. Produkty te mogą nie dać się dopasować do rozmiaru konkretnej firmy. Groupware to nie workflow.

Wnioski

W dużych sieciach środowisko aplikacji jest przemieszane na wielu poziomach. Trudno uwierzyć, że pracownicy z produkcji będą migrowali od akceptowalnej funkcjonalności do większej za pomocą implementacji przepływu czynności. Będzie to możliwe dopiero wtedy, gdy workflow będzie integrował się z różnorodnymi platformami aplikacji, nawet tymi heterogenicznymi.