Analiza biznesowa jest wieloaspektową dziedziną, która odgrywa istotną rolę w usystematyzowanym procesie wytwarzania oprogramowania. W pewnym uproszczeniu można powiedzieć, że działania analityczne obejmują pozyskiwanie, opracowywanie i zarządzanie informacjami (wymaganiami) uzyskanymi za pomocą różnych technik od poszczególnych interesariuszy. Efektem prac analityka jest zatem wytworzenie dokumentacji, która w szczegółowy sposób systematyzuje zidentyfikowane potrzeby (problemy) użytkowników i przekuwa je we właściwe opisy różnego rodzaju wymagań oraz rozwiązań pozwalających owe potrzeby zaspokoić.
Wymagania te są kluczowe, ponieważ ich odpowiednie sformułowanie pozwala dostarczyć produkt rozwiązujący wskazane wcześniej problemy biznesowe. Określają poszczególne funkcjonalności, które powinny być zaimplementowane przez zespół wdrożeniowy i nieraz potrafią być bardzo rozbudowane. Obejmują bowiem nie tylko ogólne (szczególnie z perspektywy Klienta) aspekty, ale także wiele innych istotnych obszarów – na przykład integracje z systemami zewnętrznymi czy kwestie związane z bezpieczeństwem.
Każde kolejne wymaganie powoduje wzrost złożoności całego projektu, co przekłada się na zwiększenie stopnia rozbudowania dokumentacji funkcjonalnej. Z kolei im bardziej rozbudowana jest dokumentacja, tym trudniej zadbać o jej czytelność i sformułować tak, by była przystępna dla różnych grup interesariuszy. Ich perspektywa jest bardzo istotna – w końcu to oni są odbiorcami dokumentacji oraz mają wpływ na kluczowe decyzje projektowe w kontekście finalnego produktu. Materiały dostarczane interesariuszom powinny zatem nie tylko zachowywać zgodność z ogólnie przyjętymi standardami, ale też być jednoznaczne i proste w odbiorze.
Podstawowym sposobem radzenia sobie z opisanymi powyżej problemami jest zastosowanie języka, który będzie z jednej strony przystępny (uproszczony), a z drugiej zrozumiały (uniwersalny) dla wszystkich uczestników wieloetapowego procesu wytwarzania oprogramowania, jakim jest SDLC (System Development Life Cycle). Należy jednak wyraźnie podkreślić, że opisane w dalszej części artykułu zagadnienia mają zastosowanie nie tylko w projektach stricte informatycznych. Wytwarzanie oprogramowania traktujemy tu jako najbardziej naturalny i przez to najczęściej stosowany punkt odniesienia.
Potężnym wsparciem w zakresie opracowywania wyczerpującej, a przy tym zrozumiałej, dokumentacji są tak zwane techniki modelowania. Ich zastosowanie pozwala analitykom biznesowym (i nie tylko) precyzyjnie modelować procesy i systemy, zachowując równocześnie maksymalną czytelność dokumentacji – a co za tym idzie – jej przystępność.
Procesy i modele biznesowe
Zgodnie z najczęściej stosowaną definicją procesem biznesowym nazywamy sekwencję uporządkowanych czynności, których głównym celem jest wytworzenie określonego dobra (np. informacji, towaru czy usługi). Zakres ten nieco rozszerza specyfikacja konsorcjum standaryzacyjnego OMG (Object Management Group), procesem biznesowym nazywając sekwencję lub przepływ czynności w organizacji, których celem jest wykonanie określonej pracy. Rozwinięcie definicji związane było z potrzebą podkreślenia, że procesem biznesowym może być kilka różnych czynności: muszą jednak być zawsze wykonywane w taki sam sposób. Należy również podkreślić, że zaproponowana przez OMG charakterystyka nie jest skupiona na „produkcie” procesu, ale raczej stwierdza, że jest on (ostateczny efekt, np. wspomniany produkt) związany z wykonaniem pewnej „pracy”.
Szczegółowa analiza tych procesów ma zasadnicze znaczenie przy dokładnym określaniu potrzeb (problemów) poszczególnych grup interesariuszy oraz tego, w jaki sposób można je zaspokoić (rozwiązać). Modelowanie informacji (wymagań) uzyskanych w trakcie klasycznych analiz pozwala przedstawić rezultaty w przystępniejszej formie, co w zdecydowanej większości przypadków przyśpiesza wykrycie potencjalnych sprzeczności, ułatwia znalezienie uproszczeń, a ponadto umożliwia ogólną optymalizację docelowego rozwiązania.
Czym jednak jest model?
Najogólniej mówiąc, model to uproszczenie rzeczywistości, które w ustandaryzowanej formie graficznej przedstawia kroki, jakie należy podjąć, aby ukończyć proces określony uzyskanymi wcześniej wymaganiami. Warto tu zwrócić uwagę, że modelowanie nie musi ograniczać się wyłączanie do typowych procesów i może przedstawiać wybrane cechy, zasady lub warunki działania jakiegoś obiektu, zjawiska czy – mówiąc najogólniej – systemu.
Standardy notacji
Modele – podobnie jak wszystkie inne techniki reprezentacji uzyskanych wymagań – są elementami wspierającymi komunikację. Proces wymiany informacji jest skuteczny wtedy, kiedy wszystkie zaangażowane w niego strony mówią tym samym językiem oraz rozumieją zapisy danej notacji. Tworzenie kolejnych symboli, strzałek czy innych oznaczeń może spowodować, że osoby czytające tak przygotowane diagramy mogą nie zrozumieć sensu przekazywanej informacji lub – co może mieć jeszcze poważniejsze konsekwencje – zrozumieją jąw błędny sposób i niepoprawnie wdrożą. Aby uniknąć tego typu problemów wskazane jest korzystanie wyłączanie z ustandaryzowanych języków modelowania i trzymanie się formalnych zasad ich zapisu.
Istnieje kilka różnych usystematyzowanych metod zapisu (tzw. notacji) procesów biznesowych. Najpopularniejsze z nich to BPMN, EPC oraz BPEL. Pierwszy z wymienionych, tj. BPMN (Business Process Model and Notation) jest najbardziej powszechny w branży informatycznej (i nie tylko), a przez to ogólnie zrozumiały. Obecną wersją tego standardu jest BPMN 2.0.
Z kolei EPC (Event-driven Process Chain) jest najczęściej używany do modelowania procesów biznesowych wyższego poziomu. Jest on częścią tzw. metody ARIS (Architecture of Integrated Information Systems) i jest standardem dużo starszym od BPMN. W dużym uproszczeniu można powiedzieć, że notacja ta jest skierowana głównie do typowego „biznesu”, podczas gdy BPMN ze względu na bardziej formalny charakter jest obecnie preferowany w przypadku systemów „IT”.
Ostatni z trzech wymienionych, tj. BPEL (Business Process Execution Language) jest językiem opartym na XML (Extensible Markup Language), który zgodnie z rozwinięciem swojego akronimu został stworzony do opisywania wyłącznie wykonywalnych procesów biznesowych. Procesy w tym języku eksportują i importują informacje wyłącznie za pomocą interfejsów usług sieciowych. Notacja ta została ustandaryzowana przez konsorcjum OASIS (Organization for the Advancement of Structured Information Standards).
Poza językami modelowania dedykowanymi typowym procesom biznesowym istnieje również szereg notacji o nieco innym zastosowaniu. Klasycznym i niemal równie popularnym co wcześniej wymieniony BPMN przykładem jest zunifikowany język modelowania UML (Unified Modeling Language). Jest on językiem półformalnym, który ma zastosowanie przy definiowaniu, wizualizacji i konstruowaniu różnego rodzaju systemów związanych z oprogramowaniem, ale wykorzystywany jest dużo szerzej – chociażby do reprezentowania struktur organizacyjnych czy modelowania procesów. W ostatnim z wymienionych przypadków częściej stosuje się jednak język BPMN jako historycznie nowszy i zaprojektowany na potrzeby wizualizacji typowych procesów.
W praktyce najczęściej spotykanymi standardami są oczywiście BPMN oraz UML, wspierane przez niemal wszystkie dostępne na rynku narzędzia do modelowania. Same narzędzia to z kolei bardzo szeroki temat, a wybór tego odpowiedniego powinien wynikać z indywidualnych preferencji danego analityka lub konwencji przyjętych w danym zespole projektowym. Należy też podkreślić, że nie zawsze konieczne jest posiadanie licencji na potężne i rozbudowane oprogramowanie do modelowania (np. Enterprise Architect). Nic nie stoi na przeszkodzie, aby poprawne i przede wszystkim wartościowe diagramy tworzyć za pomocą jednego z wielu dostępnych bezpłatnie narzędzi (np. draw.io).
Praca z modelami
Zastępowanie opisów w języku naturalnym diagramami cechuje się szeregiem innych zalet. I tak do najważniejszych korzyści wynikających rozwinięcia klasycznej (opisowej) formuły dokumentacji o odpowiednie modele należą:
- Uproszczona ocena zachowania rzeczywistego procesu (systemu) poprzez analizę jego modelu i jasno określone w nim scenariusze.
- Wykrycie brakujących elementów procesu oraz łatwamożliwość jego uzupełnienia lub rozbudowy.
- Ukrycie niepotrzebnych dla danej analizy szczegółów rzeczywistego i bardzo rozbudowanego procesu (systemu).
- Dopasowanie poziomu abstrakcji do potrzeb docelowego odbiorcy dokumentacji – szczególnie poprzez wyróżnienie kluczowych elementów, które pozwolą lepiej i łatwiej zrozumieć analizowane zagadnienie.
Wytwarzanie oprogramowania zazwyczaj jest czasochłonnym procesem, w który zaangażowanych jest wiele różnych osób. Docelowy diagram powinien być dostosowany do możliwości i potrzeb każdej z tych grup interesariuszy, przez co zawsze należy zwrócić szczególną uwagę na określenie złożoności tego typu dokumentacji oraz dobór poziomu jej abstrakcji. Na przykład nie jest wskazane przedstawianie grupie typowych użytkowników (np. edytorów systemów CMS) szczegółowego modelu implementacyjnego (na niskim poziomie abstrakcji). Z jednej strony nie będzie to dla nich zrozumiałe, a z drugiej zwizualizowanie tej grupie takiego poziomu szczegółów wdrożeniowych jest po prostu zbędne – niepotrzebnie angażujące czas i zasoby.
Idąc dalej, jedną z najbardziej istotnych zalet modeli jest fakt, że świetnie nadają się do stopniowego udoskonalania szczegółów, co ma znaczenie w kontekście odkrywania i opracowywania szczątkowych lub niejasno sformułowanych wymagań. Przedstawienie takiego typu zagadnienia na diagramie oraz wspólne omawianie modelu (zarówno w obrębie wewnętrznego zespołu jak i na spotkaniach z Klientem) pozwala na stopniowe modyfikowanie szczegółów i eliminowanie słabych punktów, które byłyby niezwykle trudne do wychwycenia podczas pracy na nawet najlepszym i najbardziej szczegółowym opisie w języku naturalnym. Podejście iteracyjne do weryfikacji i korygowania umieszczonych na diagramach informacji z punktu widzenia procesu wdrożeniowego jest znacznie szybsze i przez to również tańsze niż wprowadzanie zmian bezpośrednio na kodzie.
Podsumowanie
Model w założeniu służy uproszczeniu zidentyfikowanego problemu (procesu, systemu) poprzez ukrycie niepotrzebnych w danej sytuacji szczegółów. Przy jego budowie zawsze należy brać pod uwagę, jaki oraz czyj problem ma on rozwiązać. Te dwa elementy są kluczowe i od nich zależy wiele późniejszych decyzji projektowych, które dotyczącą m.in. wyboru określonego języka (notacji) czy dopasowania właściwego poziomu abstrakcji.
Tworzenie modeli w ramach analizy biznesowej nie jest co prawda procesem obowiązkowym, jednak ma szereg zalet. Może znacznie poprawić jakość i czytelność (przystępność) dokumentacji –zarówno tej opracowywanej na samym początku analizy przy walidacji bardzo „surowych” założeń uzyskanych od Klienta, jak i później przy ogólnej weryfikacji poprawności już usystematyzowanych i wstępnie zamodelowanych danych.
Czas poświęcony na przygotowanie starannych i zgodnych ze standardami diagramów należy zatem traktować jako inwestycję, która może się opłacić w wielu różnych płaszczyznach. Zarówno w kontekście walidacji kluczowych potrzeb Klienta, jak również dalszego uszczegółowienia tych wymagań w kolejnych krokach procesu wdrożeniowego aż do finalnego „dowiezienia” (delivered) projektu i przejścia w fazę utrzymania oraz rozwoju.
Infinity Group – Web Stories:
Źródła
- Zrozumieć BPMN: Modelowanie procesów biznesowych (Szymon Drejewicz; wyd. Helion)
- Modelowanie systemów informatycznych w języku UML 2.1 (Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski; wyd. PWN)
- Why Modeling Is an Essential Business Analysis Technique (https://www.modernanalyst.com/)
- Object Management Group (https://www.omg.org/)
- Overview Event-driven Process Chain notation (https://ariscommunity.com/event-driven-process-chain)
- Organization for the Advancement of Structured Information Standards (https://www.oasis-open.org/)
