Modelowanie rzeczywistości

Niezależnie od tego, czy narzędzia modelowania pochodzą od dużego dostawcy czy od mniejszego, specjalistycznego, ich głównym zadaniem jest opis procesów biznesowych w terminach elementarnych działań i zadań, zasobów wymaganych do wykonania takich zadań oraz łączących je reguł biznesowych - wszystko używając graficznej notacji zrozumiałej dla użytkowników biznesowych.

Modele odgrywają krytyczną rolę w zgraniu projektu procesu - poprzez symulację analityczną - z wyliczalnymi celami wydajności i oczekiwanymi rezultatami w zakresie optymalizacji. Poprzez przypisanie do każdej akcji procesu parametrów związanych z wydajnością, takich jak oczekiwany czas wykonania czy koszt zasobów, modele mogą być analizowane w różnorodnych scenariuszach, wykorzystując motor symulacji wbudowany w narzędzia modelowania. W zaawansowanych narzędziach modelowania, KPI, które są używane do mierzenia wydajności implementacji procesu, określają parametry wymagane w modelu i ostatecznie zamykają pętlę poprawiania wydajności. Wymaga to modelowania wychodzącego poza proste opisy schematów akcji i włączenia do modelowania zasobów organizacyjnych, przetwarzania danych i miar wydajności procesów.

Od lat takie możliwości były wyłączną domeną narzędzi modelowania procesów biznesowych wyspecjalizowanych dostawców, często jako część szerszych zestawów narzędzi dla przedsiębiorstw. Jednak dzisiaj dostawcy, jak np. IBM, implementują funkcje modelowania procesów w samych zestawach BPM. Jednocześnie dostawcy narzędzi modelowania ulepszają współdziałanie w ramach zestawów BPM poprzez wprowadzanie BPMN (Business Process Modeling Notation), standaryzowanej notacji z Object Management Group.

Standardy modelowania, takie jak BPMN, pozwalają na importowanie danych wyjściowych narzędzi modelowania do narzędzi projektowania z zestawów BPM i następnie wygenerowanie projektu szkieletu implementacji. Taki projektowy szkielet nie zawiera detali implementacyjnych, które mogłyby być natychmiast wykonywane, ale tworzy punkt startowy uwzględniający wymagania biznesowe.

Problem zamkniętego środowiska

Mimo stosowania standardowych języków projektowania BPM, takich jak BPEL, każde narzędzie projektowania procesu jest specyficzne dla jego własnego środowiska wykonawczego. Dzisiaj nie istnieją jeszcze możliwości projektowania procesów przenośnych, które mogą być wykonywane w dowolnie wybranym motorze procesu - chyba że nie bierze się pod uwagę akcji użytkowników, reguł biznesowych i kompleksowego odwzorowania danych, "zewnętrznych" dla projektu procesu biznesowego.

Większość dzisiejszych zestawów BPM zapewnia zunifikowane środowisko projektowe, które przykrywa złożoność kombinacji akcji użytkownika, integracji aplikacji, reguł biznesowych i zarządzania transakcjami w ramach pojedynczego wykonalnego projektu. Korzyści, jakie zapewnia traktowanie tych komponentów procesu jako niezależnych jednostek w stosie architektury przedsiębiorstwa, to wspólny model danych i wspólne zarządzanie stanami w ramach całego procesu.

Podobnie jak modelowanie, projektowanie procesu jest w znacznej mierze graficzne. Narzędzia te zapewniają całą gamę typów działań, z których projektant wybiera, konfiguruje i składa kroki procesu. Jeżeli nie muszą być tworzone akcje dostosowane, projektowanie procesu wymaga minimalnego programowania. Poza projektowaniem graficznym, narzędzie tworzy implementację wykonawczą procesu we właściwych dla danego zestawu BPM językach wykonawczych procesu.

W zestawach BPM opartych na architekturze workflow, taki język jest zazwyczaj rozwiązaniem własnym, ale zgodnym z XDPL (XML Process Definition Language), standardem Workflow Management Coalition. Działania w ramach procesu mogą być jednym lub kilkoma predefiniowanymi typami implementacyjnymi (web services, akcje użytkownika, działanie integrujące), z których każdy jest przydzielony do zasobów, takich jak rola użytkownika w organizacji lub adapter integracyjny.

Natomiast zestawy BPM oparte na aranżacji usług polegają na standardzie języka BPEL. Standard ten zapewnia pojedynczy typ działania (Invoke) do wywoływania web services, akcji użytkownika czy adapterów integracyjnych - wszystkie muszą być implementowane jako usługa z interfejsem opisanym przez WSDL. Jednak Invoke musi być adresowane do punktu końcowego usługi - tzn. URL, a nie zadania związanego z rolą. W wypadku akcji użytkownika to co wywołuje się przez BPEL, to nie jest samo zadanie użytkownika, ale usługa zarządzania zadaniem, która obsługuje detale przepływu zadań.

Inną różnicą jest to, że zestawy BPM oparte na przepływach zadań i dokumentów obsługują pojęcie subprocesu - fragmentu procesu wielokrotnego użytku, który współdzieli kontekst danych i zarządzanie stanem z wywołującym procesem nadrzędnym. BPEL nie przewiduje takiej koncepcji. Subproces w BPEL jest kolejnym procesem - współdzielenie danych i synchronizacja stanów musi być w sposób wyraźny zdefiniowana w logice procesu. W celu usunięcia takich ograniczeń świata realnego, firmy IBM i SAP zaproponowały w roku ubiegłym opcjonalne rozszerzenia standardu BPEL, ale specyfikacja nie jest jeszcze kompletna. Ostatecznie, niezależnie od architektury i różnic w kodowaniu, zestawy BPM wypełniają zazwyczaj ten sam zestaw funkcji podstawowych.

Aplikacje sterowane przez proces

Skompletowany projekt procesu jest wdrażany w motorze procesu. Każdą wyzwoloną instancję procesu motor "przepuszcza" przez zdefiniowaną sekwencję działań, integrujących zewnętrzne aplikacje, kierujących zadania do użytkowników i zarządzających nieprzekraczalnymi terminami oraz wyjątkami przez cały proces. W ofertach dostawców serwerów aplikacyjnych, takich jak IBM, Microsoft, Oracle czy SAP, motor procesu wpływa na unikalne możliwości serwera aplikacyjnego i związanej z nim warstwy pośredniczącej. Oferty specjalizowanych dostawców BPM pracują zazwyczaj na platformach serwerów aplikacyjnych wybranych przez użytkownika.

Motor procesu raportuje także migawki danych i stanów, zazwyczaj w formie zdarzeń, w celu zarządzania wydajnością. Komponent zarządzania wydajnością zestawu BPM gromadzi takie zdarzenia i używa ich do uaktualniania KPI i innych parametrów pomiarowych wydajności, zdefiniowanych w fazie modelowania. Pomiary są zazwyczaj agregowane w jednostki OLAP, które mogą być przedstawiane w postaci wykresów i kwerendowane przez użytkowników na tablicach rozdzielczych zarządzania. Zarządzanie wydajnością wykorzystujące OLAP zapewnia historyczne i bliskie czasu rzeczywistego raportowanie oraz dogłębną analitykę - w miarę wykonywania uaktualnień wynikających ze zmieniających się zestawów zebranych danych. Niektóre zestawy BPM, m.in. oferowane przez Adobe, FileNet, IBM, Intalio i Savvion, obsługują prawdziwy BAM, zapewniając uaktualnianie w czasie rzeczywistym wybranych KPI w zakresie alarmów wyzwalanych przez reguły i odpowiednich akcji.

Wielkości wyliczane z pracujących procesów mogą być używane do udoskonalania parametrów modelu używanych do generowania wartości oczekiwanych, czyniąc efekt zmian w procesach bardziej przewidywalnym i stymulując dodatkowe rundy ulepszania procesu.

Wybór BPM

Wybór właściwego zestawu BPM jest poważnym wyzwaniem. Chociaż większość dostawców promuje takie same listy możliwości w swoich broszurach i witrynach webowych, każda oferta jest faktycznie dostrajana do wymagań dość wąskiego zestawu typów procesów lub przypadków użytkownika.

Na przykład zestaw BPM zaprojektowany dla procesów transakcyjnych, obejmujących złożoną integrację aplikacji, ale niewielki zakres interwencji człowieka, może nie być najlepszym wyborem dla procesów obejmujących współdziałanie ludzi, z minimalną integracją aplikacji. Procesy ukierunkowane na dokumenty i procesy przepływu zadań produkcyjnych, gdzie pula użytkowników pobiera zadania ze współdzielonych kolejek, ma własne unikatowe wymagania adresowane przez niektóre, ale nie wszystkie zestawy BPM.

Mimo takich ubocznych komplikacji, BPM może zapewnić realny zwrot kosztów inwestycji dzisiejszemu użytkownikowi. Nowa generacja zintegrowanych zestawów BPM zapewnia nowy grunt pośredni dla współpracy biznesu z IT.

<hr>Wdrożenia BPM w Polsce

Waldemar Ziomek prezes zarządu, archITec

Rynek oprogramowania klasy BPM bardzo szybko się rozwija. Jeszcze trzy lata temu tylko pojedyncze firmy w Polsce korzystały z technologii BPM, obecnie jest to niemal jedna piąta przedsiębiorstw. Jak pokazują przeprowadzone przez nas badania, w ciągu najbliższego roku liczba ta może wzrosnąć nawet do 26%.

Narzędzia BPM wykorzystywane w Polsce można podzielić na dwa rodzaje:

• sztandarowe produkty zachodnie wdrażane przez integratorów (ok. 60% rynku);
• lokalne, polskie narzędzia napisane w kraju i wdrażane przez polskie firmy (ok. 40%).

Wśród polskich rozwiązań na wyróżnienie zasługują produkty Rodan System czy Newitech - niewielkie rozwiązania odpowiadające potrzebom małych i średnich firm. Dla dużych przedsiębiorstw bardziej odpowiednie są produkty BPM dużych światowych producentów, takich jak Documentum, FileNet, IBM Websphere, Staffware czy rozwiązania nadbudowane na główne produkty SAP (SAP NetWeaver), wdrażane przez samą firmę, jak też jej partnerów. Inni duzi integratorzy świadczący usługi wdrożeniowe w zakresie systemów BPM to archITec, Comarch, ComputerLand, Optix.

Według badań przeprowadzonych w lipcu 2006 r. na zlecenie korporacji FileNet w krajach Europy Zachodniej, ok. 70% respondentów przyznaje, że skuteczne zarządzanie procesami odgrywa kluczową rolę w dostarczaniu przez organizację najwyższej jakości obsługi klientów. W Polsce też możemy zaobserwować podobny trend, zdecydowana większość wdrożeń oprogramowania klasy BPM dotyczy procesów związanych z obsługą klienta. Wszędzie tam, gdzie występuje klient, dokumenty oraz kilkuetapowy proces zatwierdzania dokumentów i umów między obydwoma stronami, wykorzystuje się rozwiązania do zarządzania procesami biznesowymi. Z praktyki firmy archITec wynika, że najczęściej automatyzowane i integrowane procesy to: obsługa reklamacji, obsługa rozmów telefonicznych w Contact Center, rejestracja dokumentów i zwrotów w działach korespondencji, obsługa mass-mailingu oraz korespondencji seryjnej, archiwizacja faktur oraz billingów.

Kolejny duży obszar zastosowania technologii BPM to procesy administracyjne i księgowe. Tutaj niebywały sukces w Polsce i na świecie odnoszą systemy SAP, gdzie do sztandarowych modułów SAP (takich jak finanse, księgowość, logistyka) dodaje się kolejną funkcjonalność typu workflow i BPM. Rozwiązania BPM wdrażane w procesach administracyjno-księgowych są stosowane głównie do zatwierdzania faktur, zatwierdzania obiegu dokumentów logistycznych i magazynowych oraz wymiany tych dokumentów z partnerami handlowymi. W Polsce na takie rozwiązanie zdecydowała się jedna z największych firm paliwowych.

W podziale na branże, najczęściej wdrożenia BPM prowadzone są w sektorach bankowości i telekomunikacyjnym. Jeżeli zaś weźmiemy pod uwagę skalę rozwiązania to największe zamówienia na oprogramowanie klasy BPM składają banki i administracja państwowa (o ile je składa). Tutaj kilka zdań należałoby poświęcić właśnie administracji państwowej, która realizując liczne procesy, w ramach tych samych zapisów ustawowych z zakresu obsługi klienta-obywatela, teoretycznie powinna być rynkiem o bardzo dużym potencjale (tak jest w większości krajów wysoko rozwiniętych). W Polsce administracja publiczna nie jest w stanie wdrażać na większą skalę właściwie żadnych rozwiązań klasy BPM. Chociaż w całym kraju obowiązują te same przepisy - co ułatwiłoby znacznie zaprojektowanie mapy procesu - brakuje właściciela biznesowego, który byłby zainteresowany szybszą i sprawniejszą realizacją procesu obsługi. Nie ma również woli ze strony osób decyzyjnych, aby istniał jeden, zunifikowany proces obsługi, zatwierdzany w automatyczny sposób - o czym świadczy na przykład obecna obsługa deklaracji podatkowych. Dlatego w tym wypadku nie widzę dzisiaj możliwości zastosowania systemów BPM. Powoli jednak państwo polskie zaczyna być świadome konieczności wprowadzania tego rodzaju rozwiązań. Należy tutaj wspomnieć o pracach prowadzonych nad e-PITem, który byłby składany w urzędzie skarbowym drogą elektroniczną, a następnie zatwierdzany w systemie informatycznym urzędu.