Istotne jest także, aby zachowana została spójność informacji pomiędzy perspektywami architektury procesów oraz realizacji procesów. Wymaga to zwłaszcza utrzymania zgodności na poziomie komunikacji pomiędzy procesami - komunikacja pomiędzy rolami, realizującymi prace w ramach współpracujących procesów; dzięki temu informacje uzyskane z lektury architektury procesów mogą być uszczegółowione (a nie zmienione) w modelu realizacji procesów. Przy dużych projektach ten sposób nawigacji pozwala na w miarę efektywne panowanie nad złożonością. Uzyskanie postulowanych cech w skali całego modelu (czyli w szczególności wielu projektów) wymaga, podobnie jak w przypadku poprzednich perspektyw, przyjęcia rygorystycznych zasad opracowywania przebiegów działań, jasno i precyzyjnie określających sposób zapisu informacji. Gdy nie ma tego typu standardów, z bardzo dużym prawdopodobieństwem nie zostanie uzyskany spójny, czytelny i jednoznaczny model, co w konsekwencji spowodować może nieosiągnięcie celów stawianych całemu przedsięwzięciu.

Procesy a reguły biznesowe

Rozwijająca się niezależnie od podejścia procesowego inżynieria reguł biznesowych jest obecnie często włączana w cykl opracowywania modelu procesowego. Głównym powodem jest chęć uniezależnienia przebiegu procesu od sposobu ewaluacji warunków, które determinują przebieg. Uzyskanie takiego podziału daje możliwość wprowadzania zmian w modelu w sposób naturalny oraz efektywny. Załóżmy, że weryfikacja oferty handlowej przez dyrektora oddziału wymaga sprawdzenia trzech rzeczy: zgodności oferty z kalkulacją, upoważnienia do podpisania umowy oraz gwarancji bankowych. Jeżeli którykolwiek z warunków nie jest spełniony, wówczas ofertę należy cofnąć do handlowca w celu dopełnienia wszelkich formalności. Opisane powyżej kryteria weryfikacji oferty można zapisać bezpośrednio na diagramie prezentującym przebieg realizacji procesu, w efekcie czego po działaniu związanym z weryfikacją nastąpiłyby zapewne trzy rozwidlenia, z których każde byłoby odpowiedzialne za ewaluację któregoś z wymienionych warunków. Mankamentem takiego rozwiązania jest m.in. konieczność zmiany diagramu prezentującego przebieg procesu w sytuacji, gdy zmieniają się jedynie kryteria, które należy sprawdzić (np. rozszerzenie weryfikacji oferty o konieczność upewnienia się, czy zostały dołączone do oferty oryginały wyników wizji lokalnej potwierdzonej przez reprezentanta klienta) poprzez dodanie kolejnego rozwidlenia. Wady tej pozbawione jest podejście, w którym reguły biznesowe są opisywane jako osobne byty i wiązane są z tymi miejscami, w których uczestnicy procesu muszą je brać pod uwagę. W przytaczanym przykładzie oznaczałoby to, że po kroku związanym z weryfikacją oferty na diagramie umieszczone byłoby jedno rozwidlenie prowadzące do akceptacji bądź odrzucenia oferty, natomiast z rozwidleniem tym byłyby związane wymienione cztery reguły biznesowe. Prócz niewątpliwej elegancji, zastosowanie explicite reprezentowanych reguł biznesowych sprzyja angażowaniu specjalistów dziedzinowych w proces budowy modelu procesowego oraz w dużym stopniu redukuje koszty przygotowywania oraz utrzymywania modelu. Wsparcie procesu zarządzania regułami biznesowymi dedykowanymi narzędziami (ang. Business Rule Management System - BRMS) jeszcze bardziej usprawnia proces budowy modelu oraz w znacznym stopniu może przyczynić się do usprawnienia prac nad przygotowywaniem architektury informatycznej wspierającej funkcjonowanie organizacji.

Zobacz również:

• 9 cech wielkich liderów IT
• CIO "bumerangi": liderzy IT awansują, powracając
• 6 znaków ostrzegawczych, na które CIO powinni zwrócić uwagę w 2024 roku

Procesy a informatyka

Truizmem jest stwierdzenie, że bez informatyki współczesnym firmom żyłoby się trudno. Nikt nie wątpi, że dobrze wdrożone rozwiązania informatyczne mogą przyczynić się do usprawnienia prac firmy, a skoro tak jest, powinny one być w jakiś sposób powiązane z tworzonym modelem procesowym organizacji. Model procesów biznesowych tworzony jest z myślą o możliwości zaprezentowania wartościowych z punktu widzenia biznesu informacji osobom za niego odpowiedzialnym. W związku z tym uwzględnione w modelu procesowym oczekiwania wobec infrastruktury IT powinny być opisane w sposób umożliwiający zrozumienie ich przez osoby spoza tak zwanej informatyki. Pominięcie wymagań biznesowych w modelu procesowym może z kolei doprowadzić do zafałszowania obrazu dotyczącego sposobu realizacji działań, objawiającego się np. niepoprawnymi danymi wolumetrycznymi, niepoprawnymi przebiegami, czy też niepoprawnie określonymi rolami reprezentującymi uczestników procesu biznesowego. Wzrastająca popularność (także wśród ludzi biznesu) koncepcji nazywanej powszechnie Service Oriented Architecture (SOA), organizacji infrastruktury informatycznej wokół samodzielnych, niedużych modułów oprogramowania komunikujących się ze sobą poprzez dobrze określone interfejsy, a także popularyzacja narzędzi wspierających (ale nie realizujących) zarządzanie procesami biznesowymi (ang. Business Process Management System - BPMS) wymaga wypracowania takich metod opisu pozwalającego na połączenie modelu organizacji oraz odpowiedniej funkcjonalności infrastruktury SOA oraz usług BPMS, by były one czytelne dla osób definiujących swoje oczekiwania wobec nich, ale jednocześnie stanowiły precyzyjnie postawione wymagania do zespołów realizujących je od strony technicznej. Należy przy tym pamiętać, że zarówno koncepcja SOA, jak i narzędzia BPMS są rozwiązaniami stricte informatycznymi i z punktu widzenia osób odpowiedzialnych za biznes powinny być one traktowane na tej samej zasadzie jak systemy klasy CRM, ERP czy finansowo-księgowe.

Artur Kasprzyk jest prezesem zarządu AION, ekspertemw dziedzinie modelowania procesów biznesowych oraz technikanalizy systemów informatycznych.

Martyn Ould jest niezależnym konsultantem z 35-letnim doświadczeniem w obszarze modelowania procesów biznesowych.

Artykuł jest zapowiedzią, organizowanej przez firmę AION konferencji Business Process Management Forum Business Rules Applied, która odbędzie się 27-28 maja 2008 roku we Wrocławiu.