Idee

Przystępując do konstrukcji systemów informatycznych stawiamy mnóstwo pytań. To dobrze. Pytamy o to: „co ma  zostać zbudowane?” tj. „jakie wymagania funkcjonalne ma  spełniać oprogramowanie?” oraz o to: „jak podejść do prac konstrukcyjnych?” tj. „z jakich skorzystać nowoczesnych technologii informatycznych i  telekomunikacyjnych?” i rzadziej „jakie zastosować metody wytwórcze i wdrożeniowe?”. Zagadnieniem, które jednak często pomijamy jest pytanie o to: „dlaczego w ogóle chcemy mieć taki a nie inny program komputerowy?”. Nie posiadając na  tę kwestię właściwej odpowiedzi otrzymujemy rozwiązania, które być może i są nowoczesne, ale za to obrośnięte grubym tłuszczem funkcji, które nigdy nie zostaną przez nikogo wykorzystane^[1] oraz rozwiązania zazwyczaj dużo spóźnione^[2]. Cóż, za wszystko to musimy też płacić.

Stawianie pytania „dlaczego?” w sposób bezpośredni, nie przynosi jednak dobrych efektów – jakaś odpowiedź, w stylu „jest to  potrzebne Departamentowi Prawnemu”, zawsze się znajdzie. Powinniśmy być bardziej dociekliwi, pytając jeszcze raz „dlaczego?”, tym razem w odniesieniu do właśnie uzyskanego uzasadnienia. I tak w sposób rekurencyjny, aż do momentu, gdy dotrzemy do stwierdzenia: „ponieważ to jest właśnie rzeczywista wartość, jaką organizacja nasza oferuje swoim klientom”. Aby jednak uzasadnienie miało sens, musi to być wartość widziana oczami tego klienta, nie zawsze bowiem to, co my sami chcemy dostarczać ma dla niej/niego jakieś znaczenie.

Zapisując wymagania na system w sposób tradycyjny („system powinien / musi / będzie robić to czy tamto”), i zamieszczając przy każdym z tych wymagań uzasadnienie, moglibyśmy otrzymać materiał imponujących rozmiarów^[3]. Z takiego podejścia również wynieślibyśmy pewne realne korzyści — pobożne życzenia, dla których nie udałoby się znaleźć satysfakcjonujących potwierdzeń moglibyśmy całkiem wyeliminować. W wielu miejscach musielibyśmy jednak powtórzyć te same dowody, a to, ponieważ wiele funkcji systemu przeważnie wspiera ten sam cel, jakim jest dostarczenie rzeczywistej wartości klientowi.

Rozwiązaniem problemu dobrego uzasadnienia dla inwestycji w  informatykę jest poprzedzenie zwyczajowo pojmowanej analizy wymagań na  system, analizą procesów biznesowych organizacji. Dużo lepiej jest jednak o  tym myśleć, jak o projektowaniu nowego sposobu funkcjonowania organizacji z wykorzystaniem środków informatycznych. Oto, co dzięki temu zyskujemy:

• Posiadamy wykaz wszystkich wymagań na system, choć jeszcze nie ich pełną specyfikację. Pytanie o kompletność specyfikacji („czy aby niczego nie pominęliśmy?” lub „czy na pewno wyspecyfikowaliśmy już wszystko co jest nam niezbędne?”), należy do tych, które często spędzają sen z powiek, szczególnie tym, którzy są przyzwyczajeni do kontraktów typu: stały zakres — stała cena — stały czas^[4].

• Na liście wymagań na system znajdują się tylko te wymagania, które są rzeczywiście niezbędne. Każde wymaganie posiada swoje uzasadnienie, którego nie trzeba jednak zapisywać bezpośrednio przy nim. Uzasadnienie to wynika z kontekstu umieszczenia danego wymagania w całym procesie dostarczania wartości.

I w końcu, przede wszystkim:

• Dysponujemy spójnym opisem funkcjonowania organizacji, pozwalającym na publiczną dyskusję zastosowania konkretnych rozwiązań, a  w efekcie szansę na pozyskanie propozycji konkretnych ulepszeń o  charakterze globalnym. Optymalizacje lokalne, wprowadzane na  poszczególnych stanowiskach pracy, bez wiedzy o przebiegu całego procesu, często prowadzą do globalnego pogorszenia efektywności.

Najwyższy już czas, aby przyjrzeć się bliżej procesom.

Definicji pojęcia proces jest wiele, ponieważ o procesach i podejściu procesowym ukazuje się na rynku wydawniczym coraz więcej opracowań. Jedną z  popularniejszych definicji, usankcjonowanych instytucjonalnie, jest definicja pochodząca z norm Międzynarodowej Organizacji Standaryzacyjnej ISO z roku 2000, odnoszącej się do systemów zarządzania jakością [ISO9000]. W swojej podstawowej formie mówi ona, że: „proces” to „zbiór działań wzajemnie powiązanych lub wzajemnie oddziałujących, które przekształcają wejścia w wyjścia”. Definicja ta została przez autorów wzbogacona jeszcze o trzy uwagi:

Z innych definicji normy ISO 9000:2000, powiązanych z definicją procesu w sposób bezpośredni lub pośredni dowiadujemy się, że: „wyrób” to wynik „procesu”, a  „klient” to „organizacja lub osoba, która otrzymuje wyrób”. Dodatkowa uwaga zamieszczona przy tej ostatniej definicji mówi nam, że „Klient może być wewnętrzny lub zewnętrzny w stosunku do  organizacji”.

Składając te wszystkie definicje w jedną całość, oraz dokładając do  nich pewne zasady zarządzania jakością pochodzące również z omawianych tu  norm: „a) orientacja na klienta” oraz „d) podejście procesowe” — otrzymujemy materiał zbliżający do sedna sprawy. Problem jednak w tym, że nie wszyscy mamy czas, chęci i natchnienie do tak szczegółowych analiz norm, a czytając poszczególne zapisy, w oderwaniu od  siebie i w sposób literalny, zostajemy po lekturze z jeszcze większym mętlikiem w głowie niż przed przystąpieniem do niej. Z niektórymi zapisami nie sposób się jednak zgodzić w ogóle.

Organizacja istnieje, ponieważ produkty, które dostarcza (w tym również usługi) potrzebne są jej klientom^[5] i to, zgodnie z nomenklaturą ISO, tym zewnętrznym. To właśnie ci klienci i przez nich uznawane wartości, jakie nasza organizacja może zaoferować powinny być brane pod uwagę w pierwszej kolejności i wszystko co  robimy powinno być właśnie im podporządkowane. Aby doprowadzić do  dostarczenia tych wartości musimy wykonać pewną usystematyzowaną względem siebie grupę czynności. Tradycyjnie, czynności takie wykonywane są przez pracowników rozmieszczonych w różnych jednostkach organizacyjnych instytucji, a często również w różnych instytucjach.

Ten skrajny przypadek można zobrazować przykładem uzyskiwania przez osobę fizyczną zezwolenia na rozpoczęcie prowadzenia działalności gospodarczej^[6]. To czego chce klient — w tym przypadku osoba fizyczna — to  prowadzenie własnej firmy. Aby było to możliwe musi dopełnić szeregu formalności, które same w sobie, każda z osobna nie mają dla niego żadnego znaczenia, poza tym, że umożliwiają przejście do następnego kroku. Dopóki nie zdobędzie ostatniego niezbędnego kwitu nie może wystawić swojej pierwszej faktury, swojemu pierwszemu klientowi. I tak przechodzi pomiędzy kolejnymi instytucjami zaczynając od właściwego Urzędu Gminy, przez odpowiedni Urząd Statystyczny, stosowny Urząd Skarbowy i należyty Oddział Zakładu Ubezpieczeń Społecznych. Nie może też zapomnieć o odwiedzinach wybranego przez siebie banku, w którym musi otworzyć prawnie wymagany rachunek, firmy zajmującej się wytwarzaniem pieczątek, no i jeszcze kilku instytucji, w których będzie mógł dokonać niezbędnych opłat (np. za  uzyskanie wpisu w ewidencji działalności gospodarczej oraz wpisu w rejestrze płatników podatku VAT). Jest to proces od strony klienta, jednak, to nie proces klienta interesuje, a wartość powstająca w wyniku tego procesu. Dla klienta powinien on być czarną skrzynką, do której w jednym miejscu wrzuca swój wniosek^[7] wraz z niezbędnymi opłatami, i z której następnie, najlepiej bezzwłocznie wyciąga odpowiednie potwierdzenie. Wydaje się, że taki przebieg procesu, jaki ma miejsce dziś na przeważającym obszarze kraju, mógł powstać i może być utrzymywany tylko w warunkach monopolu^[8].

Potraktowanie procesu z powyższego przykładu jako zbioru mniejszych procesów, z których każdy daje w wyniku (na wyjściu) jakiś wyrób, stanowiący materiał posiłkowy (na wejściu) kolejnego procesu – satysfakcjonuje definicję ISO, jednak na pewno nie daje zadowolenia klientowi, które jest przecież jednym z postulowanych przez ISO mierników jakości. Prowadzi to  również do nieefektywnego gospodarowania — te same dane, choćby imię, nazwisko i adres, są ileś razy weryfikowane i wprowadzane do kolejnych baz danych, przez urzędników zatrudnianych przez Państwo.

Czy są wobec tego jakieś lepsze definicje? TAK! Znacznie lepszą definicją jest definicja zaproponowana przez twórcę pojęcia reengineering’u, Michaela Hammer’a, mówiąca, że „proces to zorganizowana grupa wzajemnie powiązanych czynności, które muszą zostać wykonane w celu dostarczenia wyniku, stanowiącego konkretną wartość” [Hammer2001]. Zbieżna z tą definicją jest definicja stosowana przez propagatora procesów odchudzonych, Jamesa Womack’a: „Proces to  sekwencja kroków, jakie muszą zostać podjęte w określonej kolejności w celu dostarczenia wartości klientowi” [Womack2002]. Ten ostatni, dużo chętniej zastępuje samo słowo proces, własnym synonimem: „strumień wartości”, podkreślając w ten sposób, że w procesie musi chodzić o sekwencję takich czynności, które mają znaczenie dla jego ostatecznego wyniku.

Pytanie takie często męczy tych, którzy zaczynają się zastanawiać nad podejściem procesowym^[9]. Odpowiedź zależy oczywiście od tego, jak będziemy rozumieli pojęcie procesu. Jeżeli będziemy koncentrować się na przekształcaniu wejść w  wyjścia, możemy potraktować każdą parę działań, na każdym stanowisku pracy, jako proces. Wówczas każdy nasz pracownik będzie sam realizował kilka procesów i całkowita ich liczba może być bliska nawet pięciu tysiącom. Kiedy podejdziemy do problemu w sposób bardziej tradycyjny, mówiąc o procesach zachodzących w poszczególnych departamentach, działach, oddziałach, itp.^[10], liczba procesów może być liczona w setkach.

W przypadku skoncentrowania uwagi na rzeczywistych potrzebach klientów możemy mówić najwyżej o dziesiątkach procesów, i to wówczas, gdy cele naszej organizacji są bardzo rozbudowane. W tym przypadku, często będziemy mieć raczej do czynienia z fragmentami procesów, realizowanymi w kooperacji z  zewnętrznymi względem nas podwykonawcami lub niezależnymi od nas organizacjami współpracującymi. To właśnie ma miejsce w przykładowym procesie umożliwiającym podjęcie działalności gospodarczej i klient tego procesu doskonale sobie zdaje z tego sprawę. Sytuacja podobna ma miejsce w  przypadku procesu wydatkowania środków Funduszu Pracy, choć tu, klienci stykający się jedynie z Powiatowymi Urzędami Pracy oraz instytucjami finansowymi, nie wiedzą przez ile różnych organizacji proces przebiega.

Informatyka jest na usługach organizacji, a te realizują swoje procesy w celu dostarczenia wartości swoim klientom. Każdy proces złożony jest z  pewnej liczby czynności — kroków, z których jedne wykonywane są w sposób manualny, inne zaś są wspierane lub w pełni automatyzowane przez maszyny, w  tym komputery wyposażone w odpowiednie oprogramowanie. Jeżeli w którymś miejscu przebiegu procesu jego uczestnik korzysta z jakiegoś programu komputerowego, to tylko dlatego, że ma to znaczenie dla efektu finalnego — zaspokojenia potrzeby klienta, w sposób najprostszy albo też jakikolwiek inny możliwy. To jednak pewna idealizacja, ponieważ pracownicy nie znający swojego miejsca w procesie najczęściej nie zdają sobie sprawy z tego, czemu tak naprawdę ich praca służy. Co więcej, często nie zdają sobie z tego sprawy nawet reprezentanci kierownictwa, poumieszczani w organizacji na  czele tradycyjnych jednostek organizacyjnych w ramach struktury funkcjonalnej.

Informatyka ma służyć pomocą, ale uwaga … nie chodzi o to, aby wszystko zautomatyzować wdrażając systemy komputerowe, jak to się przeważnie robi. Nie chodzi więc o to, aby wszyscy uczestnicy procesów, którzy dotychczas robili coś w sposób manualny teraz robili to samo, tyle, że ze  wsparciem nowoczesnych narzędzi informatycznych. Dysponując opisem bieżących przebiegów procesów, zanim przystąpimy do ich automatyzacji, warto zastanowić się czy:

• Czegoś, co jest obecnie wykonywane nie można zaniechać w ogóle. James Womak podkreśla znaczenie eliminacji marnotrawstwa, a to oznacza wszelkiej działalności, która wymaga nakładów pracy, a nie tworzy wartości [Womack2001]^[11].

• Czegoś nie można robić w zupełnie inny sposób. Charles Babbage, wynalazca mechanicznej, programowalnej maszyny analitycznej w pierwszej połowie XIX wieku, opracował też metodę analizowania złożonych systemów. To właśnie tę metodę a nie swoje maszyny zastosował do ulepszeń brytyjskiego systemu pocztowego [Rheingold2003]^[12].

Komórki organizacyjne typu departament czy też biuro informatyki są osadzone w zarządzaniu funkcjonalnym, które stanowi przeciwieństwo zarządzania procesowego. Zarządzanie funkcjonalne to właśnie zamki Dr. M. Hammera. W zarządzaniu procesowym chodzi natomiast o odcięcie się od  podziału na jednostki skupione wokół zadań tego samego typu, tworząc w  zamian zespoły w pełni dedykowane procesom. Na czele takich zespołów stoją właściciele procesów, będący osobami znającymi swoje procesy od początku do  końca i odpowiedzialnymi za ich nieustające doskonalenie.

Ta koncepcja jest najtrudniejsza do zaakceptowania i tam gdzie podejmuje się wyzwania związane z procesowym spojrzeniem na organizację najczęściej tworzy się strukturę macierzową, w której niestety szefowie procesów mają mniejsze znaczenie od szefów komórek organizacyjnych^[13], lub też, gdy nie wiadomo, który z kierowników jest ważniejszy ujawniają się wszelkie problemy związane z dwuwładzą.

Przeniesienie odpowiedzialności z szefów komórek na właścicieli procesów nie przekreśla jednak całkowicie potrzeby istnienia jednostek o  charakterze funkcjonalnych. Właściciel procesu nie jest alfą i  omegą i nie może się znać, w obecnym, jakże złożonym świecie, na  wszystkim. W zarządzaniu swoim zespołem, w codziennych jego posunięciach, jest nieoceniony w porównaniu z ludźmi mającymi pojęcie tylko o swoich działkach. Kiedy jednak chodzi o kolejne przybliżenie procesu do ideału potrzebuje wielu doradców, w tym np. specjalistów z dziedziny prawa, czy też specjalistów z dziedziny informatyki. Ulepszenia w procesach biznesowych wprowadza się dziś w głównej mierze dzięki zdobyczom informatyki, a zatem i  rola doradców ds. informatyki zyskuje na znaczeniu.

Administracja państwowa nie jest jednak kuźnią programistów i nie powinna się szczycić utrzymaniem specjalistów o takiej specjalności.

Rozwiązania informatyczne rekomendowane właścicielom procesów przez ich doradców ds. informatyki, oraz wdrażane pod ich nadzorem, nie muszą być wprowadzane w jednym posunięciu, w stylu wielkiego wybuchu — dziś nie mamy nic, a jutro już wszystko! Niemal wszyscy współcześni teoretycy i praktycy zajmujący się metodami wytwarzania oprogramowania postulują podejścia iteracyjne, polegające na częstym dostarczaniu małych pakietów funkcjonalnych, stanowiących kolejne przyrosty systemu. Wdrażanie tych kolejnych przyrostów to stopniowe ulepszanie procesów, wspieranych przez oprogramowanie.

Przy takim podejściu pojawia się kolejne pytanie: „które z  wymagań na system powinny być zrealizowane w ramach kolejnego przyrostu?”. Metodyki polecają pozostawienie tej kwestii do  rozstrzygnięcia zamawiającym. A cóż mogą zrobić zamawiający? Ci, którzy są wciąż związani hierarchicznymi strukturami organizacyjnymi mogą rozpocząć informatyzację wychodząc z założeń ważności kierowników, co nie zawsze, a  może nawet rzadko idzie w parze z istotnym wpływem na dostarczanie wartości klientom. Ci, którzy dysponują opisami — projektami — swoich nowych procesów, mogą najlepszą kolejność wprowadzania ulepszeń wyczytać wprost z  tych specyfikacji.

Załóżmy, że do opisu procesów biznesowych zastosujemy metodę scenariuszową, znaną informatykom jako analiza przypadków użycia [Jacobson1992], [Cockburn2001], [Adolph2003]. Technika ta przychodzi ze świata informatyki i jest wykorzystywana do specyfikowania wymagań na systemy informatyczne, jednak bez wątpienia, z jedynie nieznacznymi modyfikacjami, może zostać wykorzystana do opisu procesów^[14].

Tworzenie opisu procesów biznesowych (przypadków użycia biznesu lub też przypadków użycia na poziomie opisu organizacji) można podzielić na  kilka etapów:

• Określenie klientów (w terminologii związanej z analizą przypadków użycia zwanych aktorami),

• Określenie wartości, jakie organizacja ma dostarczać klientom — najlepiej zgodnie z zasadami określonymi przez autorów pozycji [Womack2001], [Cockburn2001].

• Określenie ścieżek podstawowych (podstawowych przebiegów procesów lub głównych scenariuszy gwarantujących osiągnięcie sukcesu) prowadzących do dostarczenia wartości klientom, tzw. strumieni wartości [Womack2001], z zachowaniem zasad opisanych w [Cockburn2001] i [Adolph2003].

• Określenie odstępstw i niestandardowych uzupełnień do ścieżek podstawowych procesów, w sposób specyficzny dla analizy przypadków użycia [Cockburn2001], [Adolph2003].

Już na samym początku można stwierdzić, które z procesów powinny być ulepszane w pierwszej kolejności. W przypadku organizacji biznesowych powinny być to te procesy, dzięki którym organizacja dostarcza wartości przynoszące jej największe zyski. W przypadku administracji publicznej taki miernik jednak nie istnieje, ale wydaje się, że należałoby zacząć od tych procesów, których cele są związane z eliminacją najważniejszych problemów społecznych. Kiedy uda się już ustalić ważność procesów, powinniśmy skoncentrować się na optymalizacji ich ścieżek podstawowych. Ścieżki te  powinny być przechodzone w sposób możliwie najszybszy i możliwie najtańszy oraz w taki sposób, aby odejścia na bok od głównego strumienia wartości były jak najmniej prawdopodobne. Ostatnia rzecz to już optymalizacja samych odstępstw i niestandardowych uzupełnień (panów awaryjnych). Jeśli już takie w ogóle wystąpią, powinny być również załatwiane możliwie najszybciej i  najtaniej, generalnie jednak lepiej jest do nich nie dopuszczać (zapobiegać przyczynom) niż optymalizować (leczyć skutki). Kolejność zajmowania się poszczególnymi sytuacjami wyjątkowymi wyznacza prawdopodobieństwo ich wystąpienia. Czasami, niestety, sytuacje wyjątkowe w procesach zachodzą tak często, że mogłoby się wydawać, że stanowią one element głównego przebiegu.