Artykuły

BPMstandard.pl używa cookies.

Brak zmiany ustawienia przeglądarki oznacza Twoją zgodę.

Zrozumiałem
05Sty2016

RE@BPM - inżynieria wymagań w zarządzaniu procesami biznesowymi

re bpmW tytule proponuję trudne do zaakceptowania połączenie skrótów. „RE” to skrót od angielskiej nazwy inżynierii wymagań (requirements engineering), a BPM, jak doskonale wiecie, to skrót angielskiej nazwy zarządzania procesami biznesowymi (business process management). Na pozór, w codziennej praktyce, te dziedziny nie mają ze sobą wiele wspólnego, nawet nazwy zdają się należeć do różnych światów: „inżynieria wymagań” może kojarzyć się z inżynierią, programowaniem, czy nawet mechaniką, podczas gdy „procesy biznesowe” brzmią, niczym wysokopoziomowe cele, rozważane na równie wysokopoziomowych zebraniach zarządów spółek.

W rzeczywistości i w praktyce, obie te dziedziny łączą się ze sobą bardzo blisko, a ci, którzy jako pierwsi to dostrzegą i będą umieli wykorzystać, osiągną znaczną przewagę.

Kilka słów wprowadzenia do inżynierii wymagań

Inżynieria wymagań, to – według definicji ISO/IEC/IEEE 29119 – dziedzina interdyscyplinarna, zajmująca się metodami pozyskiwania, analizy, modelowania i konsolidacji wymagań, czyli założeń, które ma realizować konstruowany system informatyczny. Z nieznanych bliżej przyczyn, przemysł IT tej nazwy nie lubi, zamiast niej posługując się chętniej określeniami takimi, jak „analiza biznesowa” oraz „analiza systemowa”, podczas gdy w świecie akademickim dominuje jednak „inżynieria wymagań”.

Niezależnie od preferowanej nazwy, większość przyzna, że to dziedzina często zdumiewająco zaniedbywana, a dokładniej – realizowana jakby cichaczem, dyskretnie, ukryta za plecami innych. „Inżyniera wymagań” w projekcie zwykle nie ma, analityk – bywa, ale jakże często słyszy się, że nie zawsze jest czas, aby swoje zadanie wykonał, zanim do pracy przystąpią deweloperzy i testerzy. Jakim cudem wobec tego sukcesem, czy choćby względnym sukcesem, kończy się jakikolwiek projekt? Otóż rolę analityka, lepiej lub gorzej, wykonują inni: kierownicy projektów, którzy muszą przecież choć w przybliżeniu znać cel działań, które nadzorują; programiści, mający niezwykły dar zarówno trafnego domyślania się, jak i talent do przeinaczania zleconych im do realizacji wymagań; wreszcie testerzy, których zadaniem, kiedy wszyscy inni zawiedli, jest zarówno zdobycie wymagań, jak i sprawdzenie, na ile testowany system je spełnia. Ponadto, wbrew obiegowym opiniom, przypisującym podejściu agile chaotyczność, to agile, np. realizowane w formie agile scrum, jest pod względem wymagań ogromnie zdyscyplinowane, tyle że używa zupełnie fantastycznego nazewnictwa: specyfikacja wymagań, to „rejestr produktu” (product backlog), a główny analityk – to „właściciel produktu” (product owner), co nie ułatwia porozumienia.

Gdzie w BPM jest inżynieria wymagań?

Definiowanie procesów „as is”

Pierwszy krok BPM, czyli opis, czy diagnoza, aktualnego procesu biznesowego (as is), to niemal dokładnie ta sama czynność, którą analiza / inżynieria wymagań nazywają „pozyskiwaniem i wymagań”. W każdym projekcie IT, trzeba od klienta, któremu zamarzył się nowy system IT, dowiedzieć się, co ten system właściwie ma robić i do czego jest potrzebny. To zwykle nie jest łatwe, a niekiedy nagabywany o to klient wręcz niecierpliwi się i zdecydowanie odmawia wyjaśnień, argumentując „nie mamy na to czasu, a zresztą to wy znacie się na informatyce, nie ja”. Żeby radzić sobie z tym wyzwaniem, inżynieria wymagań dopracowała się szeregu skutecznych metod, jak mimo wszystko te wymagania zdobyć. To są rozmaite techniki zadawania pytań, przez ankiety oraz przez wywiady, rozbudowane i zróżnicowane metody obserwacji, prototypowanie, a także sposoby poszukiwania istniejących, ale zapomnianych przez ludzi reguł poprzez tak zwaną „archeologię systemową” i wiele innych. W szczególności, interesujące dla BPM mogą być stosowane przez inżynierię wymagań metody polowania z nagonką na reguły biznesowe J, głęboko ukryte w dżungli organizacji, która sama nie wie, jak właściwie działa.

W porównaniu z typowymi projektami IT, przedsięwzięcia BPM są w luksusowej sytuacji. Po pierwsze, decyzje o podjęciu BPM podejmowane są zwykle na wysokich szczeblach zarządzania, więc mają zasoby i poparcie, o których twórcy pojedynczych aplikacji mogą sobie tylko bezskutecznie pomarzyć. Po drugie, istota BPM to właśnie analiza procesów biznesowych, więc nie można się od niej wymigiwać pod pretekstem, że „nie mamy na to czasu, budujcie system, bo inaczej znajdziemy sobie innego wykonawcę”. Ciężej doświadczana inżynieria wymagań zahartowała się w ogniu walki, a jej metody mogą znakomicie usprawnić opisywanie obecnych procesów, które uprawia BPM.

Negocjowanie wymagań

W inżynierii wymagań nie zapominamy, że różni interesariusze systemu IT zwykle mają także zróżnicowane poglądy na wymagania dla tego systemu – niekiedy wręcz przeciwstawne. Proces osiągania porozumienia, grzęznący często w tańcach, które kojarzymy raczej ze światem dyplomacji, niż informatyki, inżynieria wymagań nazywa „negocjowaniem” lub „konsolidacją” wymagań, bywa w tym dobra, i chętnie podzieli się swymi umiejętnościami z BPM.

Definiowanie procesów „to be”

Drugi obszar, gdzie technologie inżynierii wymagań mogą przydać się w zarządzaniu procesami biznesowymi, to projektowanie nowych, lepszych procesów, procesów zwanych przez BPM „które mają być”, czyli „to be”. Tak bowiem dzieje się w niejednym projekcie informatycznym, że kiedy klientowi przyjdzie do głowy, aby wesprzeć swój biznes jakąś aplikacją, systemem, to podczas zamawiania, a nawet – niestety - o wiele później, okazuje się, że tak naprawdę nie bardzo wiadomo, jakie procesy ten system ma wspomagać, albo że wymagają one przeróbek, poprawienia. Informatycy tego oczywiście nie lubią, tak jak nie lubiliby budowniczowie domu, żeby w trakcie wylewania fundamentów zmieniać projekt budynku.

Czyli w praktyce, inżynieria wymagań zajmuje się nie tylko odkrywaniem, jak wygląda proces, który trzeba wesprzeć technologią, ale także często współtworzy i modyfikuje ten proces. Tak, informatycy nauczyli się jakoś funkcjonować w sytuacji, która dla budowniczych jest nie do pomyślenia, że projekt konstrukcji, nawet jej cele i obszar zastosowania, tworzy się jednocześnie z samym budowaniem – z tej potrzeby wzięły się metodyki iteracyjne, przyrostowe i zwinne.

Także tutaj inżynieria wymagań dopracowała się wielu przydatnych metodyk, takich jak techniki kreatywności, prototypowanie, projektowanie zorientowane na użytkownika (ang. „user-centred design”) i inne. Warto zacząć je systematycznie stosować także w świecie BPM.

Od wymagań do Javy w mgnieniu oka

Celem większości przedsięwzięć BPM jest najpierw zbudowanie, a potem modyfikowanie, ilekroć zajdzie potrzeba, kompleksowego, zintegrowanego systemu IT sterującego procesami biznesowymi, zwanego „BPMS” (Business Process Management System). Droga od modelu procesu, zapisanego w graficznym języku BPMN, do działającego systemu, prowadzi przez język BPEL (business process execution language, odmiana XML) do serwera, na którym skrypty BPEL są wykonywane, zwanego czasem „motorem BPEL” (BPEL engine). Takie serwery kupuje się od zewnętrznych dostawców. Wykonywane skrypty BPEL nie zastępują jednak już wcześniej istniejących a firmie programów – one je tylko odpowiednio synchronizuję i koordynują tak, jak wymaga tego proces biznesowy. Często też wdrożenie BPMS wymaga przerobienia niektórych starszych aplikacji i dodania wielu nowych – także mobilnych. Ich zaprogramować w BPEL-u nie można… trzeba więc wrócić na ścieżkę tradycyjną, skonstruować oprogramowanie w języku takim jak Java, C#, czy jednym w wielu innych. Opisując wymagania dla tych aplikacji, zwykle nie posługujemy się ani BPMN, ani BPEL, tylko – o zgrozo – językiem naturalnym, lub innymi językami modelowania, zwykle należącymi do rodziny UML. W tym momencie, konstruktor procesów, przyzwyczajony już do wygody projektowania graficznego przy pomocy BPMN, z którego skrypty BPEL można albo wygenerować automatycznie, albo dość szybko wystukać palcami zręcznymi palcami programisty w BPEL-u, pewnie jęknie głucho, bojąc się konieczności powrotu do powolnej, tradycyjnej drogi od wymagań do funkcjonującego kodu. Ale nie traćmy nadziei – oto pojawiło się trochę rozwiązań, pozwalających na znaczne przyśpieszenie tej żmudnej procedury. Ich opisanie przekracza znacznie możliwe rozmiary tego artykułu, więc tylko je zasygnalizuję: książkę „From Requirements to Java in a Snap. Model-Driven Requirements Engineering in Practice” autorstwa profesora Politechniki Warszawskiej, Michała Śmiałka, oraz np. narzędzie ReDSeeDS (redeeds.eu), dostępne za darmo, powstałe w wyniku współpracy kilku europejskich uczelni technicznych.

Nie tylko RE@BPM, ale także BPM@RM

Potencjalne korzyści współpracy idą w obu kierunkach. IT cierpi od początku swego istnienia, więc już blisko 70 lat, na problem z niejasnymi, niejednoznacznymi, często niespójnymi wymaganiami. Jest wiele przyczyn tego stanu rzeczy, ale głównym ich źródłem jest, moim zdaniem, nasze przywiązanie do języka naturalnego jako medium do porozumiewania się. Według wielu antropologów, powstanie języków wśród naszych przodków 100 – 50 tysięcy lat temu służyło głównie utrzymywaniu spójności grup hominidów, czyli relacjom, wzajemnemu „iskaniu się”, jak zabawnie wyrażają to badacze naczelnych. Możliwość przekazywania językiem komunikatów rzeczowych, dotyczących nie świata relacji, lecz otaczającego nas świata fizycznego, też okazała się przydatna, ale jednak drugorzędna. Dlatego język naturalny tak dobrze służy nam do wygłaszania napuszonych, pięknych, ale treściowo wątpliwych komunikatów. Dlatego nikt przy zdrowych zmysłach nawet nie próbuje opisać wymagań dla urządzeń technicznych słowami, posługując się zamiast nich diagramami, rysunkami, schematami. Jednak w IT wciąż opis wymagań w formie modeli jest niepopularny, napotyka na bierny opór tych z nas, którzy wolą mówić ładnie i przekonująco, niż precyzyjnie i jednoznacznie, czyli… wszystkich.

W tym kontekście, opisywanie procesów biznesowych w formie modeli BPMN jest wielkim krokiem naprzód, który – miejmy nadzieję – kiedyś nastąpi także w inżynierii wymagań, gdzie opisy „słowno-muzyczne” wciąż dominują.

Jakość procesów

Podejście BPM zwykle – jeśli nawet nie w teorii, to w praktyce – bardzo wąsko widzi optymalizację procesów, którą stara się zrealizować na drodze od „as is” do „to be”. Dominuje nacisk na redukcję kosztów, którą zwykle osiąga się poprzez wyeliminowanie rzekomo zbędnych kroków i zadań procesu, zmniejszenie liczby uczestniczących w nim osób, lub likwidację czasowych wąskich gardeł.

Nie negując, że czasem procesy zawierają zbędne kroki czy zbędne zawiłości, aż proszące się o eliminację, to koszty są wyłącznie jednym z wielu atrybutów jakości procesu. Tutaj BPM może nauczyć się od inżynierii wymagań szczególnie dużo. Inżynieria wymagań określa, jaki ma być produkt. „Jaki”, czyli nie tylko co ma robić, ale również jak: jak szybko, jak niezawodnie, jak wygodnie dla użytkownika… Dla produktów IT, mamy normę ISO 25010 (dawniejsza wersja: ISO 9126) „System and Software Quality Requirements”, która pomaga nam nie zagubić się w dżungli rozmaitych „atrybutów jakości”.

Równie dobrze, można niemal identyczne kryteria stosować dla procesów, choć nikt prawie dotąd tego nie robił. Nadal „optymalizacja procesów”, to przede wszystkim usiłowania ich przyspieszania, tudzież odchudzania, ograniczania ich kosztów. To bardzo wąskie podejście. To wybór tylko jednego z wielu możliwych rozwiązań. Tom DeMarco w swojej książce „Luz” rozprawia się z prostackim mitem, że wąsko rozumiana optymalizacja, cięcie kosztów, przekłada się na sukces biznesowy. Bardzo często, efekt jest wręcz przeciwny: przemęczeni, zestresowani, bierni pracownicy, niezadowoleni klienci, wzrastające ryzyko pomyłek i złych decyzji. Pamiętamy, jak we wczesnej erze komputeryzacji (na świecie: w latach 1970-1980, w Polsce – na początku lat 90-ych), komputery, zamiast usprawniać, powodowały mnóstwo pomyłek, zmuszały do nienaturalnego, niewygodnego trybu pracy, bardziej przeszkadzały, niż pomagały.

Dlatego BPM, aby przynosić zyski, aby spełniać pokładane w nim nadzieje, musi przede wszystkim nauczyć się patrzyć na ulepszanie procesów szerzej: żeby były, na przykład… mniej stresujące, bardziej przyjazne dla klientów, mniej podatne na ludzkie pomyłki, łatwiejsze do zmiany i modyfikacji, łatwiej poddające się przenoszeniu na nowe platformy sprzętowe. Rozwój w tym kierunku może BPM ułatwić inżynieria wymagań, od dawna specjalizująca się w tym, co dziś modnie bywa nazywane „user experience” (UX).

Trochę zapomniana została, stworzona w pierwszych latach internetowej eksplozji, w połowie lat 90-ych, szkoła zwana „re-inżynierią procesów biznesowych” (BPR). Bardzo myląca to nazwa, bo – w przeciwieństwie do BPM, skoncentrowanego na ulepszaniu i optymalizacji, BPR kładło nacisk na potrzebę i możliwość, radykalnej zmiany procesów biznesowych. „Don’t automate, obliterate” – brzmi sztandarowe hasło BPR. Nie zawsze ma to sens, ale – nie traćmy z oczu tej możliwości, grzęznąc w finezyjnym świecie drobnych ulepszeń, realizowanych na ścieżce BPMN → BPEL → BPMS.

Ulepszanie procesów w IT

Stare przysłowie „szewc bez butów chodzi”, w odniesieniu do procesów IT sprawdza się w 100%. Z jednej strony, IT dostarcza technologii, pozwalających na szybkie, elastyczne zmiany, na ulepszanie i automatyzację najbardziej nawet tradycyjnych procesów. Jednocześnie, swoje własne procesy, procesy wytwarzania oprogramowania, zwykle traktuje metodami z epoki kamienia łupanego. Standardy i sylabusy, popularne i autentycznie przydatne: PMI, PRINCE 2, ITIL, IPMA, IIBA, IREB, ISTQB, ISO 12207 – opisują swoje procesy… słowami. Rozbudowane metodyki oceny dojrzałości – np. CMMI, SixSigma, ISO 15504 („SPICE”), TMMi czy TPI oferują „jedynie słuszne” kryteria jakości procesów, ignorując potrzebę ich dostosowania do kontekstu. Nawet rodzina metodyk agile, choć akceptuje fakt, że wzorcowy proces nie musi, nie powinien nawet być zbyt szczegółowy, lecz oferować raczej minimalistyczne rusztowanie (framework), całą tematykę ulepszania procesów załatwia jednym, pozornie magicznym słowem „retrospektywy”, ale nie wypowiada się w kluczowej kwestii, jak podczas retrospektyw identyfikować słabości procesów i jak projektować ich ulepszanie.

Nie ułatwia sprawy dodatkowa, trudna okoliczność, że IT cierpi na syndrom lekceważenia procesów. Na swoje usprawiedliwienie ma to, że faktycznie robienie oprogramowania nie jest produkcją taśmową, że jeden program od drugiego różni się na tyle, że marzenie o idealnym procesie produkcyjnym jest po prostu nierealne. Henry Ford, twórca produkcji taśmowej, spróbował jej zasady zastosować do produkcji artykułów w gazecie, której był właścicielem – z kiepskim skutkiem. Jednak to dobre usprawiedliwienie jest ogromnie nadużywane – nie ma, poza IT, drugiej branży, gdzie nieustanne „debugowanie” zawsze przesłania potrzebę usprawniania procedur tak, aby… robić znacznie mniej bugów.

Pod tym względem BPM jest narzędziem, które – zastosowane do procesów samego IT – może stać się motorem jakże potrzebnej w IT zmiany.


bogdan berezaBogdan Bereza, absolwent studiów informatycznych (Szwecja) oraz psychologii organizacji (Wielka Brytania), ma wieloletnie doświadczenie z IT w wielu branżach i wielu krajach: od krytycznych dla bezpieczeństwa systemów wbudowanych, poprzez systemy IT, aż do gier i innych aplikacji rozrywkowych na urządzenia mobilne; od Malagi blisko Gibraltaru, po poligon doświadczalny Vidsel w północnej Szwecji. Był i bywa programistą, testerem, wykładowcą i szkoleniowcem, kierownikiem projektów, inżynierem wymagań, specjalistą analizy biznesowej i optymalizacji procesów, autorem książek. W kontekście tego artykułu, Bogdana dogodnie jest postrzegać jako inicjatora i wiceprezesa Stowarzyszenia Inżynierii Wymagań (wymagania.org.pl), oraz wieloletniego współpracownika Rady IREB (International Requirements Engineering Board, www.ireb.org/landingpage/pl oraz www.ireb.org/en/people-profiles/bereza ).