Procesy pracy ( workflows )

1. Procesy pracy (workflows) Tematy badawcze Kazimierz Subieta IPI PAN PJWSTK Politechnika Łódzka

2. Co to są “procesy pracy” (PP)? • Nie istnieje definicja, która byłaby satysfakcjonująca dla wszystkich. “Procesy pracy” integrują wiele pojęć. Jedna z wielu definicji: • Komputerowe wspomaganie pracy zespołów ludzkich poprzez porządkowanie, organizowanie, automatyzowanie, przekazywanie i śledzenie prac wykonywanych przez te zespoły. Zarządzanie procesami prac Zarządzanie procesami biznesowymi Specyfikacja i odwzorowanie procesów biznesowych Reinżynieria procesów biznesowych (BPR) Automatyzacja procesów biznesowych Specyfikacja procesów pracy Implementacja procesów pracy Automatyzacja procesów pracy Zarządzanie procesami pracy, systemy Metodyki analizy i projektowania procesów pracy

3. Definicje procesów pracy • Sterowanie i ulepszanie procesów biznesowych, automatyzacja, śledzenie, sterowanie, oraz umożliwienie/usprawnienie współpracy zespołów. • Organizacja operacyjnych aspektów biznesu - sekwencji zadań oraz organizacja podmiotów je wykonujących. Sterowanie procesem informacji wspomagającej realizację tych zadań; mechanizmy śledzenia i raportowania, pomiary i kontrola wykonania zadań. • Oprogramowanie procesów pracy ma za zadanie usprawnić procesy biznesu poprzez automatyzację następujących aspektów: • przekazywanie czynności do wykonania przez personel w ramach danego procesu, zgodnie z określoną ich sekwencją; • zapewnienie dostępu do danych i dokumentów wymaganych przez te czynności; • śledzenie wszystkich aspektów związanych z wykonaniem procesu. • Głównym celem narzędzi do zarządzania procesem pracy jest wyodrębnienie logiki procesów wykonywanych w przedsiębiorstwie z wszystkich funkcji realizowanych w ramach aplikacji użytkowych.

4. PP: Problemy badawczo-rozwojowe (1) • Opracowanie uniwersalnego, standardowego języka umożliwiającego odwzorowanie procesów pracy i dowolnych zależności w procesach pracy. • Środki dla użytkowników końcowych, umożliwiające sprawne definiowanie, modyfikowanie, symulowanie, śledzenie, sterowanie procesami pracy. • Współdziałanie: dostęp do federacyjnych baz danych, integracja schematów, hurtownie danych, standardy współdziałania, standardyzacja współdziałania. • Dostępność i skalowalność: możliwość budowy efektywnych aplikacji dla tysięcy użytkowników rozproszonych geograficznie. • Współbieżność: długie transakcje, transakcje kompensujące, transakcje których nie można cofnąć. • Zarządzanie zasobami: ludźmi, dokumentami, czasem, pieniędzmi, obciążeniem komputerów, obciążeniem sieci, użyciem infrastruktury, itd.

5. PP: Problemy badawczo-rozwojowe (2) • Obsługa wyjątków: należy przyjąć jako regułę, że zaprojektowany proces PP będzie podlegał zakłóceniom. Systemy PP powinny zapewniać deklarowanie wyjątków oraz ich obsługę. • Odporność na błędy: przy dużej liczbie komponentów jest dość prawdopodobne, że niektóre z nich ulegną awarii. System powinien być na takie sytuacje w maksymalnym stopniu niewrażliwy. • Wydajność: sprawne metody optymalizacji wykonania przebiegów PP. • Skalowalność: niewrażliwość na znaczące rozszerzenia objętości bazy danych, liczby równolegle działających procesów, liczby użytkowników i uczestników. • Metodyki projektowania: sprawne metody i techniki przejścia od wymagań, do analizy, projektu i konstrukcji.

6. Zastosowanie systemów procesów pracy ost.30.X • Administracyjne procesy pracy: obejmują powtarzalne, przewidywalne procesy, z prostymi regułami koordynacji zadań, np.: • przesyłanie komunikatów pomiędzy działami • obieg i akceptacja zestawienia wydatków • obsługa i akceptacja delegacji służbowych • Procesy pracy ad hoc: procesy włączające elementy bieżącej koordynacji i zarządzania, np.: • koordynacja działalności osób • wspólne podejmowanie decyzji • dokumentowanie produktu • przetwarzanie ofert sprzedaży • Procesy pracy w zarządzaniu produkcją: obejmują powtarzalne, przewidywalne procesy biznesowe. Wymagają współdziałania z rozproszonymi, heterogenicznymi, autonomicznymi syst. inform. • obsługa procesu udzielania kredytu • obsługa żądania wypłaty ubezpieczenia Proste Złożone

7. Przykłady dość wymagających procesów pracy Analiza i akceptacja wniosku kredytowego w banku: wymaga skoordynowanie zadań wykonywanych przez poszczególnych pracowników banku, takich jak przyjęcie wniosku, analiza ryzyka, kontrola zabezpieczeń, planowanie, sporządzanie i analiza zestawień, raportów, bilansów, statystyk, tendencji. Wspomaganie dla obsługi pacjenta w ośrodku zdrowotnym: wymaga koordynacji zadań takich jak rejestracja pacjenta, ustalenie wizyt u lekarzy, rejestracji wyników badań, planowanie zabiegów, planowanie badań laboratoryjnych i użycia aparatury, rozliczenia finansowe, sporządzanie i analiza zestawień, statystyk, itd.

8. Koncepcje techniczne procesów pracy (1) • Obieg pracy • Zdefiniowanie z góry kolejności czynności niezbędnych do wykonania danego zadania. • Automatyczne przekazywanie sterowania i dokumentów do następnej czynności po zakończeniu poprzedniej. • Dynamiczny podział pracy • Przypisanie prac do wykonania w elastyczny sposób, np. w zależności od obciążenia pracowników. • Pracę przypisuje się do ról, a nie do konkretnych osób. • Przypisanie osób do ról może zmieniać się dynamicznie. • Ustalanie priorytetów prac • Jeżeli od wykonania konkretnych prac zależy uruchomienie innych prac, dotrzymanie terminu, lub ocena, to konieczne jest bieżące nadawanie priorytetów dla poszczególnych prac. • Dynamiczna zmiana procesu/procesów pracy dla uwzględnienia nieprzewidzianych wcześniej okoliczności przy ich realizacji.

9. Koncepcje techniczne procesów pracy (2) • Śledzenie pracy • Sprawne uzyskiwanie informacji o przebiegu i aktualnym stanie wykonania zadania lub zadań: przestojach, opóźnieniach, braku obciążenia pracowników, zbyt długich kolejkach prac do wykonania. • Umożliwienie dynamicznej reakcji na w/w zakłócenia w przebiegu pracy. • Raporty dla administracji i kierownictwa • Rejestracja zdarzeń następujących w czasie wykonania pracy, sporządzanie zestawień, ocena efektywności, rozliczenia pracy, badania statystyczne, ustalanie wąskich gardeł. • Monitorowanie wykonywanych zadań: • ustalanie i rozstrzyganie nieprawidłowości (np. zakleszczeń), • stanu zużycia czasu i innych zasobów; stanu obciążeń infrastruktury biurowej i komputerowej; • prognozy, wspomaganie planowania zasobów niezbędnych w przyszłości; • Symulacja procesów pracy, np. celem zbadania ich poprawności przed uruchomieniem.

10. Procesy pracy i zadania wykonawców Lista zadań 2 Lista zadań 3 Wykonawca 2 Wykonawca 3 PP1 PP2 PP3 PP4 PP5 Lista zadań 1 Wykonawca 1

11. Śledzenie i monitorowanie procesów pracy Które procesy uległy zakleszczeniu? Jaki procent budżetu został zużyty w tym miesiącu? Administrator Analityk PP1 PP2 PP3 PP4 PP5 W jakim stanie znajduje się PP2? Który proces przetwarza teraz dokument D459? Kierownik Kierownik

12. Workflow Management Coalition (WFMC) Model Interfejs 1 Mechanizm(y) procesów pracy Mechanizm(y) procesów pracy Mechanizm(y) procesów pracy Mechanizm(y) procesów pracy Mechanizm(y) procesów pracy Interfejs 4 Mechanizm(y) procesu pracy Interfejs 5 Interfejs 2 Interfejs 3 Aplikacje klienta PP Wołane aplikacje Narzedzia do definicji procesów API dla Procesów Pracy, wymienne formaty Narzędzia do administrowania i monitoriowania Inne środki realizacji PP Środki realizacji PP

13. Workflow jako najbardziej zewnętrzna warstwa eGov-Bus

14. Metamodel i język zapytań • Metamodel – reprezentacja wszystkich bytów w środowisku workflow: • definicji procesów • definicji instancji procesów • definicji aktywności • instancji aktywności • definicji zasobów • instancji zasobów • ról i wykonawców • dokumentów i aplikacji • Definicja powiązań pomiędzy bytami (dziedziczenie, asocjacje, zawieranie się) • Język zapytań – np. SBQL (określony w pracy M.Momotki jako BPQL) • Generyczne procedury, funkcje, perspektywy, metody, aplikacje i serwisy, które mogą być wołane z języka zapytań. • Integracja języka zapytań z językiem definicji procesów • Np. XPDL

15. Metamodel i język zapytań

16. Metamodel i język zapytań

17. Metamodel i język zapytań

18. Metamodel i język zapytań

19. Nowe spojrzenie na workflow • W dotychczasowym spojrzeniu centralnym pojęciem jest sterowanie procesu. • To sprowokowało licznych „teoretyków” do „badań” nad workflow przy użyciu sieci Petriego. Genezą „badań” jest czysto wizualna analogia pomiedzy grafami procesów i grafami sieci Petriego. • Moim zdanie, sam cel i potencjalne rezultaty tych „badań” są pseudo-teoretyczną bzdurą, nie mającą szans na najdrobniejszy wpływ na cokolwiek praktycznego w systemach workflow. • W systemach workflow aspekt sterowania nie jest najważniejszy i może być dla większości z nich całkowicie pominięty. • Ludzie mając do wykonania pewien zestaw zadań nie ustawiają ich od początku w szereg – wykonują to, co jest w tej chwili konieczne, ma najwyższy priorytet w danej chwili, ma odpowiednie zasoby do realizacji, itd. • Ustawianie czynności w sieć a la Petri lub PERT powoduje zniszczenie głównych czynników które mogą wpłynąć na kolejność i kompletność wykonania całości pracy. • Powoduje także utratę możliwości lub zasadnicze trudności przy nanoszeniu dynamicznych zmian do struktury i zestawu zadań do wykonania.

20. Workflow jako hierarchia zadań zadanie 2 zadanie 4 zadanie 5 zadanie 6 • Workflow przede wszystkim powinien być postrzegany jako hierarchiczna organizacja zadań do wykonania. Proces (zadanie 1) zadanie 3

21. Powiązania do klasy (klas) Powiązania do obiektów zewnętrznych Proces Obiekty publiczne (atrybuty) Obiekty prywatne Powiązania z obiektów zewnętrznych Kod warunku początkowego Kod procesu Proces Proces Proces .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... Proces Proces Proces Proces Proces .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... .....>><<.... Kod warunku końcowego

22. Założenia workflow jako hierarchii zadań • Zadania mogą być dynamicznie wrzucane do środka zadań • Może to odbywać się ręcznie albo w rezultacie refleksji (zadanie generuje zadanie i wrzuca je do środka innego zadania) • Wszystkie zadania są traktowane jako równoległe procesy (bardzo ważne w sytuacji rozproszenia) • Wszystkie zadania są traktowane jako obiekty (bardzo ważne z punktu widzenia języka zapytań i manipulacji) • Zadania mogą być uruchomione (wykonane), jeżeli zachodzą warunki wstępne jego uruchomienia. • Zadanie jest zakończone, jeżeli zachodzą warunki końcowe jego zakończenia • Warunki wstępne i końcowe wyznaczają oczywiście sterowanie zadaniami, ale nie odbywa się to explicite i może podlegać dowolnym dynamicznym zmianom • Warunek końcowy dla zadania złożonego może być tak skonstruowany, że nie wszystkie podzadania będą uruchomione. • Zadania mogą zawierać lokalne obiekty (stan) i mogą korzystać z dowolnych obiektów globalnych. • Zadania mogą istnieć w postaci definicji (używanej w momencie instancjacji procesu). • Zadania mogą podlegać kontroli typologicznej: • czy wszystkie podzadania są w momencie inicjcji • czy wszystkie niezbędne podzadania zostały wykonane

23. Co to daje? • Inherentną równoległość, bez wprowadzania idiotycznych synchronizatorów typu join i split. • Elastyczność w zakresie dynamicznych zmian procesów • Sprawne możliwości śledzenia i monitorowania przy użyciu języka zapytań • Możliowość wykonania slitów na nieograniczoną liczbę podprocesów (np. faktura)