Jak mawiał mój dawny profesor filozofii: „Gdy dwóch mówi to samo, to już nie jest to samo”. To, co nazywamy „zwinnym podejściem”, coraz częściej polega na uznaniu nieskuteczności procesu zbierania wymagań i obronie przed zobowiązywaniem się przez dostawcę do dostarczenia konkretnych rozwiązań.

Rozwiązania, nie wymagania

MDA (Model Driven Architecture), architektura bazująca na modelowaniu), MDE (inżynieria bazująca na modelowaniu), notacje BPMN, UML, SysML, SoaML i im podobne, posługujące się rysunkami technicznymi na wysokim poziomie abstrakcji, to zbiory metod nieraz ratujące zagrożone projekty informatyczne. Metody te pozwalają radzić sobie z rosnącą złożonością inżynierii jako całości. To narzędzia, które powstają i są rozwijane od ponad 20 lat.

Złożonego oprogramowania – podobnie zresztą jak choćby konstrukcji nowoczesnego tramwaju – nie da się już rzetelnie i precyzyjnie opisać z pomocą słownej listy wymagań zebranych w trakcie spotkań warsztatowych. Podzielenie wymagań na funkcjonalne i pozafunkcjonalne również nie wprowadza dodatkowej wartości do takiej listy. Ta technika specyfikowania (830-1998 - IEEE Recommended Practice for Software Requirements Specifications) ma swoje początki ponad 30 lat temu, czyli w czasach relatywnie nieskomplikowanych aplikacji z bardzo prostym interfejsem użytkownika. Obecnie na stronie publikatora standard ten jest oznaczony jako „wygaszany”.

W listopadzie ub. r. w serwisie internetowym Business Analyst Times ukazał się ciekawy artykuł pt. „Requirements Are Dead, Long Live the Solution”. Tekst dotyczy rosnącej złożoności wymagań i oprogramowania w czasach, w których szybkie zmiany na rynku przekładają się na sukcesywne skracanie czasu wdrożeń. Autor zwraca uwagę, że do procesu zbierania wymagań nie powinno się angażować interesariuszy; obciążanie ich odpowiedzialnością za udokumentowanie wymagań nazywa cynizmem. W branży IT przez długi czas funkcjonowało założenie, że interesariusze muszą umieć określić swoje wymagania – to jednak nie działa. Popularne słowo „elicitation” oznacza „uzyskiwanie, wydobywanie” wymagań. Pytanie, skąd interesariusze mają wiedzieć, jak opisać oprogramowanie, skoro nie znają się na tym? Nie wolno zapominać, że zamawiający nie jest inżynierem, a co za tym idzie, może formułować i zrozumieć wyłącznie „wymagania biznesowe” i nic ponadto. Tak sformułowane wymagania nie przekładają się tymczasem na konkretne wymagania wobec inżynierskiej pracy, jaką w ramach projektu ma wykonać deweloper (czyli inżynier).

Nie należy zapominać, że każdy biznesowy udziałowiec projektu ma inne zadania do realizacji, więc wskazane przez niego wymagania biznesowe to nic innego jak cele wynikające z tych zadań. W tym momencie pojawia się pierwsze kluczowe pytanie: kogo w takim razie pytać o wymagania dotyczące np. oprogramowania wspomagającego sprzedaż – prezesa firmy czy jego walczących o prowizję sprzedawców mających nadzieję, że ktoś złoży im propozycję lepiej płatnej pracy? Sponsorem projektów są zarządy firm, które oczekują terminów, nazw i opisów, a nie nadziei.

Obecnie główną miarą projektów staje się parametr „time-2-market’, czyli czas od powstania koncepcji produktu do wprowadzenia go na rynek. Tu nasuwa się drugie pytanie: czego oczekuje biznes – wyniku czy produktu? Czy rozumiemy różnicę między efektem projektu (dla organizacji) a jego produktem? Efekt realizacji projektu to zmiana, jaka zajdzie w organizacji i którą odczują jej udziałowcy. Produktem projektu jest z kolei to, co dostarczy zespół projektowy. To ten produkt ma być zgodny z wymaganiami.

Konkluzja jest następująca: wymagania nie są ostatecznym produktem. To co nim jest? Popatrzmy na proces tzw. analizy systemowej:

Gdzie w tym procesie znajduje się faza zbierania wymagań w rozumieniu „elicitation”? To w zasadzie dopiero sformułowanie problemu, czyli początek drogi. Następnie należy zbadać środowisko problemowe, tzn. przeprowadzić badanie organizacji (analizę biznesową) i opracować jej model (mapy procesów biznesowych, struktury informacyjne). Kolejny krok to interpretacja wyników badania i rekomendacje. Czym są rekomendacje? To sugerowane sposoby rozwiązania problemu: oprogramowanie, zmiany organizacyjne, a najczęściej jedno i drugie.

Stwierdzenie „powinniście sobie kupić jakieś oprogramowanie ERP i poprawić organizację” nie jest jednak rozwiązaniem. Właściwe rozwiązanie (czyli rekomendacja) to wskazanie struktury i logiki działania oprogramowania, które wspiera zarządzanie. Dopiero na tym etapie wskazane jest dopuszczenie dewelopera.

Nikogo w biznesie nie interesuje tak naprawdę suchy spis problemów, powstały w wyniku zebrania wymagań wśród pracowników. Biznes jest zainteresowany czymś, co można nazwać, kupić i wdrożyć w określonym czasie, bo tylko to pozwala na oszacowanie korzyści z takiej inwestycji.

Rynek dynamicznie się zmienia, więc z uwagi na czas nie ma sensu szczegółowe projektowanie czegokolwiek. Ryzyko, że taki projekt stanie się nieaktualny, jest zbyt duże. Nikt rozsądny nie namawia dzisiaj do kaskadowej (waterfall) realizacji projektów. Co więc zrobić? Dla dużych projektów należy tworzyć architekturę, opisywać mechanizmy działania, politykę rozbudowy i opis cyklu życia – czyli to, co pozwoli rozwijać rozwiązanie metodą iteracyjno-przyrostową, a w razie potrzeby umożliwi łatwe przeprojektowanie. Takie rozwiązanie nadal będzie spójne, ale jednocześnie pozwoli dostosowywać się do zmiennych warunków rynkowych bez konieczności wymiany całości.

Można w tym miejscu zaryzykować tezę, że nie ma czegoś takiego jak „inżynieria wymagań”. Czym bowiem jest inżynieria wymagań i co jest jej produktem? Uporządkowany spis życzeń? Na pewno natomiast istnieje coś takiego jak inżynieria systemów. Systemami są organizacje, a także narzędzia, jakich używają, np. oprogramowanie.

Dobry model: rozwiązania zgodne z logiką działania organizacji

Jednym z istotnych obszarów zarządzania złożonością w projektach wdrożeniowych jest modelowanie procesów biznesowych, gdyż modele te są podstawą analizy i specyfikowania wymagań na oprogramowanie. Są także materiałem wyjściowym do tworzenia planów ewentualnych reorganizacji poprzedzających te wdrożenia. Częstym problemem takich modeli jest ich nadmierna szczegółowość.

Podstawowe pytanie brzmi: ile jest poziomów modelowania procesów? Często spotykam się z tym zagadnieniem w projektach i w literaturze. Można spotkać modele z numerowanymi procesami: procesy główne 0.1; 0.2 itd., procesy pierwszego poziomu: 1.1; 1.2; 1.3, dalej 2.2.4 itd. Na czym polega problem z takimi modelami? Po pierwsze, proces archiwizacji dokumentu może się pojawić na każdym z poziomów, jaki wtedy nadać mu numer? Po drugie, pewne obszary działania nie są złożone, i możliwe, że wystarczy jeden „poziom”; inne bywają „złożone” i do ich opisania potrzeba będzie czterech poziomów.

Elementarny proces może pojawić się wszędzie, niezależnie od poziomu, np. realizacja zobowiązania finansowego może oznaczać zapłatę zarówno za fakturę wystawioną przez kancelarię prawną w procesie negocjowania umowy handlowej (wysoko w hierarchii ważności), jak i w procesie regulowania zobowiązań za dziurkacze (raczej nisko).

Dla porządku przypomnijmy dwie kluczowe definicje, np. za normą terminologiczną ISO 9000 (jakość zarządzania):

Proces to każde działanie, które przekształca wejście (dane wejściowe) na wyjście (dane wyjściowe). Proces może zawierać zbiór różnych operacji (działań) wzajemnie ze sobą powiązanych i na siebie oddziałujących.

Procedura to określony sposób realizacji działań lub procesów.

Powyższa definicja jest często stosowana i łatwa do przyjęcia, zarazem jednak zbyt uboga – pojęcie procesu jest w tym ujęciu nazbyt pojemne, by stanowiło podstawę do formalnego modelowania organizacji. Przytoczę pełniejszą definicję:

Proces biznesowy stanowi zbiór powiązanych ze sobą czynności ukierunkowanych na realizację określonego celu biznesowego na podstawie wykorzystywanych zasobów. Proces biznesowy jest sterowany poprzez strategię organizacji definiującą cele oraz produkty tworzone przez procesy (źródło: Stanisław Wrycza, Informatyka ekonomiczna. Podręcznik akademicki, Polskie Wydawnictwo Ekonomiczne, Warszawa 2010, str. 431).

Przeglądając literaturę przedmiotu (w tym wyżej wskazane źródło), można dojść do następującej definicji procesu biznesowego:

Proces biznesowy – czynność lub logicznie powiązany chronologiczny łańcuch czynności, przekształcający stan wejścia procesu w stan jego wyjścia, mający wartość dla odbiorcy. Proces do wykonania, wymaga określonych zasobów, sposób jego realizacji może być ograniczony (opracowanie własne).

Do modelowania procesów obecnie używa się najczęściej notacji BPMN (tzw. standard de facto). Z tej perspektywy proces definiowany jest następująco:

A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN Process is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flows that define finite execution semantics. Processes can be defined at any level from enterprise-wide Processes to Processes performed by a single person. Low-level Processes can be grouped together to achieve a common business goal (źródło: www.bpmn.org/).

Warto zwrócić uwagę na fakt, że z perspektywy notacji proces to sekwencja aktywności w organizacji, której celem jest dostarczenie określonego efektu. Dalej: proces jest obrazowany za pomocą grafu złożonego z elementów o określonej semantyce (mających sztywno określone znaczenia). Proces może być definiowany na dowolnym poziomie. Procesy na najniższym poziomie mogą być grupowane np. wspólnym celem. Tyle notacja. Definicja procesu w BPMN jest zgodna z ISO.

Tak więc procesem jest każdy przepływ pracy, zaś procesem biznesowym są te przepływy, których granice (początek i koniec) wyznaczają produkty biznesowe (określone obiekty inicjujące proces i będące jego produktem, cele biznesowe).

Co to w praktyce oznacza? Skoro celem biznesowym jest np. wystawienie faktury za dokonaną sprzedaż, zaś przygotowanie samej treści faktury jest jedynie jednym z etapów jej tworzenia (krok), procesem biznesowym jest wystawienie faktury, ale nie jest nim samo jej zredagowanie (krok, kolejne zadanie), bo poza redagowaniem mamy także czynności sprawdzenia, księgowania i wydruku. Tak więc na najniższym poziomie hierarchii mamy proces fakturowania, z kolei dalsze szczegóły wystawienia faktury to procedura jej tworzenia, składająca się z kolejnych kroków (zadań do wykonania), nieraz będących specyfiką konkretnego przypadku.

Fakturowanie jako proces biznesowy może być (i z reguły jest) częścią nadrzędnego procesu, np. realizacji zamówienia. Pierwszym produktem tego procesu jest gotowe do wykonania zamówienie, jego elementy to np. sekwencja rejestracji zamówienia i jego weryfikacja. Cały proces realizacji zamówienia ma więc dwa podprocesy: rejestrację zamówienia oraz następujący po nim proces biznesowy – fakturowanie. Produktem pierwszego procesu jest zatwierdzone zamówienie, a produktem drugiego wystawiona faktura sprzedaży.

Poszczególne wewnętrzne kroki obu procesów nie tworzą produktu, np. zarejestrowane, ale niesprawdzone zamówienie nie ma wartości biznesowej; to krok, który należy wykonać, ale nie samodzielny proces biznesowy.

Na diagramie metodologii BPM wymienione są trzy kluczowe poziomy procesowego opisu organizacji. Na samym dole znajdują się zasoby, ludzie i ich umiejętności wspierane procedurami i narzędziami pracy; to warstwa realizacji, która w każdej niemalże organizacji jest udokumentowana jako zakresy obowiązków, procedury i zarządzenia.

Najwyższa warstwa to kluczowe elementy strategii, architektura najważniejszych procesów. Na tym poziomie można mówić o tzw. procesach end-2-end, czyli o tym, jak organizacja reaguje na bodźce zewnętrzne (np. na każde zapytanie ofertowe odsyłana jest oferta). Ten poziom także jest prawie zawsze udokumentowany – jako strategia i plan marketingowy.

Warstwa środkowa, procesy biznesowe, to z kolei abstrakcja opisująca (modelująca) logikę działania organizacji – jej wewnętrzny łańcuch wartości.

Mamy więc trzy poziomy modelowania organizacji: najwyższy, obejmujący strategię i procesy end-2-end; najniższy, odnoszący się do procedur i instrukcji stanowiskowych (implementacji), a także środkowy – abstrakcję (model procesowy) opisującą, w jaki sposób dwa powyższe poziomy wchodzą ze sobą w interakcję.

Dwie kwestie wymagają tutaj zwrócenia uwagi. Po pierwsze, w zasadzie każda organizacja ma udokumentowany poziom najwyższy (strategia) i najniższy (procedury, zarządzenia, instrukcje). Po drugie, warstwa środkowa jest tworzona (dokumentowana) wtedy, gdy chcemy zrozumieć wewnętrzne zależności, których może być dużo i które mogą być złożone. To, ile poziomów powstanie w warstwie środkowej, zależy wyłącznie od stopnia złożoności danej organizacji – rzadko jednak pojawiają się więcej niż dwa.

Własną specyfikę ma trzeci, najniższy poziom modelowania organizacji. Badania pokazują, że ludzie spędzają tylko 40% czasu na wykonywaniu prac ustrukturalizowanych (np. realizowanie procedur) i poddających się automatyzacji. Pozostałe 60% czasu pracy to każdorazowa inwencja wykonawcy w sposobie realizacji (specyfika) danego zadania (źródło: Business Proces Flexibility and Decision – Aware Modeling, Knut Hinkelmann, Editors: Dimitris Karagiannis, Heinrich C. Mayr, John Mylopoulos). Z tego powodu na najniższym poziomie operujemy pojęciami: kompetencji, procedur, zakresów obowiązków, zarządzeń i reguł biznesowych. Modelowanie tego poziomu za pomocą diagramów mija się z celem, gdyż często prowadzi do monstrualnej liczby wariantów lub rozbudowanych modeli ocierających się szczegółowością o algorytmizację organizacji, ta zaś jest niemożliwa;wspomniane wyżej 60% czasu pracy obejmuje czynności, których dokumentowanie nie ma sensu z uwagi na ich zmienność. Taki model nigdy nie będzie w pełni opisywał wykonanej pracy, a niepełny model jest nieprzydatny. W tym momencie przyznać należy, że pewne prace wykonywane są „zawsze inaczej”, choć zawsze ich efektem jest powstanie tego samego produktu (konkretnego dokumentu).

Modelowanie procesów biznesowych nie polega na rysowaniu diagramów. To tworzenie modeli, które poddają się walidacji i testowaniu zgodności z rzeczywistością. Poprawne modele pozwalają przewidywać reakcję organizacji na planowane zmiany.

Model, czyli dokumentowanie faktów

Modne ostatnio projekty modelowania procesów biznesowych z reguły dostarczają jako produkt niezliczone ilości „map procesów”, które kończą swój żywot na zakurzonych półkach, bo powstawały zbyt dużym kosztem, by wyrzucić je do kosza. Ich stałe utrzymanie i aktualizowanie bywa nieraz kosztowniejsze od wytworzenia i najczęściej się tego nie robi.

Modelowanie procesów biznesowych nigdy nie powinno odbywać się bez ich uprzedniego określenia i pełnego zrozumienia wpływu na organizację. Procesy modeluje się po to, by zrozumieć, jak działa organizacja, oraz po to, aby przewidzieć, jak się zachowa, jeżeli któreś z nich zostaną zmienione. Czasem może się okazać, że nie warto wdrażać zmian, ponieważ skutki będą niewspółmierne do nakładu pracy.

Modelowanie procesów biznesowych nie polega na obrazkowym zapisie tego, co wiemy od pracowników tej czy innej firmy. To trudny proces odkrywania prawdziwej logiki działania organizacji, nie polega na dokumentowaniu zwyczajów jej pracowników. Logika działania organizacji to z kolei łańcuch powstających w niej produktów, także pośrednich, które są udokumentowanymi faktami, np. fakturą czy protokołem dostawy. Istotne są powiązania między tymi faktami (dokumentami). To, w jaki sposób pracownicy je dostarczają, nie jest tak ważne, ponieważ można oczekiwać, że potrafią robić to, do czego zostali zatrudnieni. Z kolei to, jak wykonują pracę, zostało zawarte w ich umowach o pracę.

Z tej perspektywy wdrożenia systemów informatycznych polegają „tylko” na przekazaniu do użytku narzędzi wspomagających tworzenie konkretnych produktów (udokumentowanych faktów) i zarządzanie nimi. Właściwie opisane wymagania oznaczają więc zachowanie zgodności narzędzia z logiką działania organizacji.

Autor jest niezależnym analitykiem IT i projektantem systemów wyspecjalizowanym w modelowaniu procesów biznesowych, analizie wymagań i pomocy wdrożeniowej.