Osobą odpowiedzialną za system IT zawsze będzie zamawiający.  Dlatego zamawiający powinien jednoznacznie opisać swoje oczekiwania i zrozumieć potem odpowiedź czyli propozycję ich wykonawcy. Menedżer nie musi uczyć się diagramów UML ale powinien rozumieć modele procesów tak by mieć możliwość ich oceny i zatwierdzania. Dlatego modele procesów powinny być tworzone metodami zrozumiałymi dla menedżerów, moim zdaniem nie jest to notacja UML. Notacja ta jednak jest niewątpliwie doskonałym narzędziem do udokumentowania i przekazania swoich oczekiwań przyszłemu wykonawcy systemu: integratorowi IT. Tak więc wykonaj model procesów biznesowych, określ które procesy chcesz informatyzować. Potem przygotuj na bazie tej analizy listę przypadków użycia przyszłego systemu, uzupełnij ją o model pojęciowy twojego biznesu i firmy i przekaż to do realizacji wykonawcy systemu. Na koniec pozostaje wdrożenie a to już osobny projekt :), socjologiczny.

Mały wstęp dla informatyków

Menadżera interesują procesy biznesowe a nie przypadki użycia. System IT kupujemy po to by te procesy wesprzeć a nie po to by mieć system.

Coraz częściej menedżerowie są jednak obciążani decyzjami  o oczekiwanej funkcjonalności systemów, za które potem płacą.   Paradoksem wielu nieudanych projektów jest to, że dostawcy rozwiązań IT po pierwsze dokumentują sami sobie wymagania, po drugie robią to metodami niejednokrotnie nieznanymi menadżerom (np.. właśnie diagramy UML), ci podpisują dokumenty nie przyznając się, że ich nie zrozumieli (takie strasznie mądre te kwity),  dostawca realizuje projekt a na końcu menadżer mówi: TO NIE TO CHCIAŁEM!

UML czyli jak napisać dokumentację niezrozumiałą dla jej adresata

Systemy często są opisywane od razu za pomocą przypadków użycia,  te zaś opisują zasoby ale już nie relacje między nimi.  Problem,  który przewijał się w większości referatów na konferencji to moim zdaniem mieszanie procesów, zasobów i produktów okraszone wplataniem w to tak zwanych przypadków użycia.  Do tego dochodzi wierność metodom analizy zorientowanym właśnie na przypadki użycia, które to metody są moim zdaniem niekompletne i powodują wiele nieporozumień.  Przypadki użycia to podzbiór pełnej listy działań w firmie. Dlatego bazowanie tylko na nich skutkuje często zupełną utratą kontekstu projektu wdrożeniowego.

Próbą naprawy tego faktu są modele tak zwanych biznesowych i systemowych przypadków użycia, które jednak moim zdaniem zaciemniają tylko obraz. Twierdzenie zaś, że biznes powinien się nauczyć analizy obiektowej skoro zamawia systemy jest moim zdaniem tyle samo warte co twierdzenie, że kierowcy powinni się uczyć termodynamiki silników spalinowych.

Wiec jednak procesy i ich analiza

W analizie procesowej opisujemy organizacje poprzez produkty (głownie dokumenty ale nie tylko) jakie ona wytwarza i procesy wymagane by produkty te powstawały. System IT jako zasób dla procesów jest z natury rzeczy opisywany rolami ludzkimi (aktorzy) i zasobami systemowymi, którymi są programy i sprzęt informatyczny . Procesy to sieć działań. Pojęcie sieci działań i kłopotów związanych z opisywaniem ich za pomocą przypadków użycia wiążą się moim zdaniem z tym, że opis procesowy bazuje na łańcuchach wartości będących łańcuchem następstw przetwarzanych produktów o czym zapominają analitycy programiści a przypadki użycia to lista tych momentów, gdy człowiek korzysta z systemu by proces zrealizować.

Jak więc opisać wymagania na system IT

Kluczowym elementem procesu przejścia od opisu organizacji do opisu systemu IT jest transformacja procesów biznesowych, czyli wewnętrznego łańcucha wartości, na zasoby je wspierające i przypadki ich użycia czyli funkcjonalności systemu.  Kluczowym elementem jest decyzja czy wszystkie procesy i przypadki użycia systemu będą implementowane w systemie czy nie, co nazywa się po prostu analizą rentowności projektu.

Patrząc na procesy biznesowe musimy mieć umiar w szczegółowości ich definiowania, tak by nie doprowadzić do próby algorytmizacji firmy. Pamiętajmy, że musimy zawsze bazować na kompetencjach ludzi i ich wiedzy o tym co i jak mają robić. Jeżeli nie weźmiemy tego pod uwagę to stworzymy system przepływu pracy łączący przypadki użycia w ciągi o skończonej liczbie kombinacji. Pozornie jest to skuteczniejsze jednak kluczową wartością firm jest to, że człowiek radzi sobie z nietypowymi sytuacjami co z kolei powoduje, że nie można mu wiązać rąk scenariuszem. Szczegółowe scenariusze mogą mieć zastosowanie tam, gdzie 100% pracy jest opisana np. w KPA (Kodeks Postępowania Administracyjnego dla Urzędów) ale i tak bałbym się je zbyt szczegółowo opisywać. W firmach rynkowych kluczowym elementem są kompetencje i doświadczenie ludzi i tu typowe systemy przepływu pracy (ang. workflow) stwarzają nie raz wiele kłopotów odzierając  ludzi z prawa użycia ich własnej inwencji.

System dla ludzi

Dlatego wiele gotowych udanych systemów w efekcie ma postać  zbioru usług wspierających zasoby (ludzi) w realizacji ich bieżących prac. Proces to pojęcie w 100% abstrakcyjne nie mające bytów rzeczywistych, jest to abstrakcja łącząca ze sobą pojęcia: produktów, zasobów, reguł, wartości i jakości (dlatego jest tak trudny do zrozumienia jako pojęcie). Próba ich opisu metodami obiektowymi, nie tylko moim zdaniem, jest skazana na niepowodzenie.  Opis procesów często bywa przez niektórych analityków dodatkowo komplikowany przepływem samych danych. Prawdopodobnie jest więc tak, że:

• Procesy są łańcuchami tworzącymi wartość dodaną,
• Procesy są fizycznie realizowane przez zasoby (ludzi, systemy),
• Komunikują się z sobą  zasoby (ludzie, aktorzy) a nie procesy,
• Przepływ danych nie musi być tożsamy z łańcuchem procesów (nawet rzadko taki jest).

Ostatni a uwaga jest jednym z powodów dla których w literaturze można spotkać się z opiniami, że przyczyną fiaska wielu projektów była analiza wymagań bazująca tylko na Diagramach Przepływu Danych (ang. DFD: Data Flow Diagram). Pominięcie modelu procesowego rodzi ryzyko utraty zrozumienia konstrukcji wewnętrznej organizacji.

Model procesów powinien być uproszczeniem, abstrakcją skupiającą się na celowości działań a nie na szczegółach ich realizacji. Te ostatnie mogę podlegać stałym zmianom w firmie. Należy wręcz unikać na etapie zbierania wymagać zbytniego uszczegóławiania opisu. Powinno się zamiast opisowego precyzowania wymagań dla procesu operować przykładami, wzorami produktów każdego procesu. Minimalizuje to możliwość nieporozumień oraz czyni taki opis bardziej jednoznacznym.

Prawdopodobnie więc na etapie opisu wymagań zupełnie wystarczające jest  napisanie, że system powinien wspierać wystawianie faktur i dodać wzór tego dokumentu niż wylistować cechy tego dokumentu takie jak: możliwość wpisania nazwy produktu, liczby sztuk, nazwy jednostki, wartości podatku, automatyczne wyliczanie wartości pośrednich, sum częściowych i summy całkowitej, wypisanie terminu płatności , …. Wzór dokumentu z jego opisem jest skuteczniejszym i tańszym sposobem specyfikowania wymagań.

(tekst ten to moje przemyślenia po wysłuchaniu referatów na konferencji  UML - zastosowania w biznesie http://www.cpi.com.pl/imprezy/2007/uml/index.php ).