Procesy pracy ( workflows )

Tematy badawcze

Kazimierz Subieta IPI PANPJWSTKPolitechnika Łódzka

Procesy pracy (workflows)

K.Subieta. Workflow – tematy badawcze Folia 2 6 kwiecień 2005

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 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

Zarządzanie procesami prac

Co to są “procesy pracy” (PP)?


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.


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.


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.


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

Zastosowanie systemów procesów pracy ost.30.X


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.

Przykłady dość wymagających procesów pracy


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.

Koncepcje techniczne procesów pracy (1)


Ś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.

Koncepcje techniczne procesów pracy (2)


Procesy pracy i zadania wykonawców

PP1

PP2

PP3

PP4

PP5

Wykonawca 1

Lista zadań 1

Wykonawca 2

Lista zadań 2

Wykonawca 3

Lista zadań 3


Śledzenie i monitorowanie procesów pracy

PP1

PP2

PP3

PP4

PP5

Kierownik

W jakim stanie znajduje się PP2?

Administrator

Które procesy uległy zakleszczeniu?

Analityk

Jaki procent budżetu został zużyty w tym miesiącu?

Kierownik

Który proces przetwarza teraz dokument D459?


Narzedzia do definicji procesów

Narzędzia doadministrowaniai monitoriowania

Aplikacjeklienta PP

Wołaneaplikacje

Mechanizm(y)procesu pracy

Mechanizm(y)procesów pracy


Środki realizacji PP

API dla Procesów Pracy,wymienne formaty

Interfejs 1

Interfejs 2 Interfejs 3

Inte

rfej

s 4

Inte

rfej

s 5 Mechanizm(y)

procesów pracy



Inne środki realizacji PP

Workflow Management Coalition (WFMC) Model


Workflow jako najbardziej zewnętrzna warstwa eGov-Bus


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



ProcessInstState

ObjectTypeSpec

ActivityInstState

ParticipantAsgn

ParameterDef

ApplicationCallSpec

ApplicationCall

AtomicActivity

ContainerAttributeDef

ContainerAttribute

Parameter

Parameter

ParameterDef

TransitionInst

OR Split

OR Join

XOR Join

AND Split

XOR Split

AND Join

Routing Activity

ParameterMapping

Compound Activity

Activity

Transition

Performer

ProcessInst

ActivityInst

ObjectRef

ProcessDef

InstantiatedAs

1..*InstantiatedAs

InstantiatedAs 0..*

InstantiatedAs 0..*

InstantiatedAs

0..*

PerformedBy

0..1

ExecutedAs

0..1

OperatesOn

0..*

InstantiatedAs0..*

InstantiatedAs0..*

InstantiatedAs1..*

InstantiatedAs0..*

ConsistsOf

2..*ProcessedIn

1..*

OperatesOn

0..*

ConsistsOf

2..*

ProcessedIn

1..*

Has

0..*

Has

0..*

Has

0..*

Has

0..*

From0..*

DefinedAs0..*

To0..*

PerformedBy

CalledWith

0..*

From0..*

To

0..*

Has

0..*

VersionOf0..*

Has

0..*

ExecutedAs0..1



ObjectTypeSpec

WfM System

IT System

ParticipantAsgnApplicationCallApplicationCallSpec

Service Declaration

Service ObjectType

Process

Object

ObjectRef

Resource Definition

Resource

Performer

User

Agent

IT Data IT ResourceIT Service

Uses

0..*

Uses

0..*

Provides

1..*

PerformedBy

1..*

InstantiatedAs 1..*InstantiatedAs

Uses

0..* InstantiatedAs1..*

InstantiatedAs0..*

Uses

0..*

InstantiatedAs

0..*

InstantiatedAs

0..*

Uses

0..*

Uses

0..*

DefinedAs DefinedAs RepresentedAs

0..*

DefinedAsRepresentedAs

0..*

RepresentedAs

0..*

RefersTo RefersTo RefersTo RefersTo RefersTo RefersTo

Manages

1..*

Processes1..*



-documentation : String

-duration : TimeStamp

-validFromDate : Date

-creationDate : Date

-description : String

-validToDate : Date-owner : Resource

-currState : String

-name : String-version : int

-priority : int

-id : String

ProcessDef

Activity

-postCondition : WfExpression-preCondition : WfExpression

-waitingTime : TimeStamp

-documentation : String

-deadline : TimeStamp-duration : TimeStamp


-name : String

-priority : int-cost : float

-id : String

ContainerAttributeDef

-refreshable : boolean-retrieveExpr

ParticipantAsgn

-assignment : WfExpression-cardinality : int-mode : int

-id : String

ParameterMapping

-valueExpr : WfExpression-parName : String-id : String

Transition

-condition : WfExpression-id : String

ParameterDef

-mode : ParameterMode

ParameterDef


ApplicationCallSpec


-name : String-url : String

-id : String

-description : String-name : String-id : String

ObjectTypeSpec

Routing Activity

Compound Activity

WfAttributeDef

-multiplicity : String

-name : String-type : String

-id : String

AND Split

OR Join

OR Split

XOR Split

XOR Join

AND JoinAtomicActivity

-PerformedBy

-AssignedTo

-OperatesOn

-SpecifiedFor

0..*

-From-To 0..*

-ExecutedAs -DeclaredFor

0..1

-HasParam -BelongsTo 0..*-CalledWith

-SpecifiedFor 0..*

-Has -BelongsTo

0..*-DefinedAs 0..*

-Represents

-ConsistsOf

-BelongsTo 2..*

-To

-From 0..*

-Has -SpecifiedFor

0..*

-Parent

-Child0..*



-currState : ActivityInstState


-creationDate : Date

-parameters : String

-type : ActivityType

-finishDate : Date-startDate : Date

-priority : int

-cost : float

-id : String

ActivityInst

ProcessInst

-currState : ProcessInstState


-creationDate : Date-finishDate : Date

-priority : int

-cost : float

-id : String

ActivityInstState

-qoSViolated : boolean

-opSuperState : String

-qoSCritical : boolean


-opState : String

-id : String

Parameter


Parameter


ProcessInstState

-qoSViolated : boolean

-opSuperState : String


-opState : String

-id : String

TransitionInst

-creationDate : Date-id : String

WfAttribute

-name : String

-value : String

-type : String-count : long

-id : String

ApplicationCall

-id : String

Performer

-name : String-id : String

ObjectRef

-id : String

ContainerAttribute

-ProcessedIn

-RefersTo 1..*

-ProcessedIn

-RefersTo 1..*

-BelongsTo

0..*

-Has

-ConsistsOf

-BelongsTo

2..*

-BelongsTo 0..*

-HasParam

-ExecutedAs

-CalledFor 0..1

-Has

-EvaluatedFor

0..*

-PerformedBy

-Performs 0..1

-From 0..* -To

-From

-To 0..*

-OperatesOn

-UsedFor 0..*


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.


Proces (zadanie 1)

Workflow jako hierarchia zadań

Workflow przede wszystkim powinien być postrzegany jako hierarchiczna organizacja zadań do wykonania.

zadanie 2zadanie 3

zadanie 4

zadanie 5zadanie 6


Proces

Obiekty publiczne (atrybuty)

Obiekty prywatne

Kod warunku początkowego

Kod procesu

Kod warunku końcowego

Powiązania do obiektów zewnętrznych

Powiązania z obiektów zewnętrznych

Powiązania do klasy (klas)

Proces

.....>><<....

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....

Proces

.....>><<....

.....>><<....

.....>><<....


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


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)

Documents

Procesy pracy ( workflows )