Specyfikacja wymagań funkcjonalnych zawiera:

1. Przypadki użycia w tym aktorzy czyli role w procesach oraz integracja czyli inne systemy jako użytkownicy (aktorzy) - zasady wymiany danych z innymi systemami

2. Ograniczenia w tym:

a. Ograniczenia wydajnościowe - objętości baz danych, prędkości dostępu, szybkość wykonywania operacji.

b. Ograniczenia techniczne - systemy operacyjne, systemy telekomunikacyjne, technologie programistyczne.

c. Ograniczenia praw i metod dostępu do systemu.

d. Ograniczenia na maksymalne ryzyko funkcjonowania czyli bezpieczeństwo danych ( kopie awaryjne, procedury awaryjne).

Droga do osiągnięcia tej specyfikacji to:

1. Udokumentowanie mierzalnych celów biznesowych - lista i opis.

2. Analiza i model procesów biznesowych

a. Czynności -> przypadku użycia

b. Role -> aktorzy w systemie

Definicje procedur i procesów budzą wiele emocji więc postanowiłem je zebrać i spisać w formie w jakiej sam ich używam.Powstały one na bazie klasycznych definicji jednak terminologia nawiązuje do modeli procesów i analizy obiektowej oraz przede wszytkim teorii łańcucha wartości M.E.Portera. Jako, że osobiście jestem zwolennikiem uproszczeń niż komplikacji przy definiowaniu procedury posłużyłem się pojęciem ograniczenia z ogólnej teorii systemów. W metodykach modelowania, które stosuję funckjonują więc proste i rozłączne definicje oraz ich ograniczenia zamiast wielu pojęć, których definicje na siebie zachodzą, wymagających uwagi przy ich stosowaniu.

Procesy biznesowe, procedury, produkty

1. Produkt: byt (przedmiot, treść lub zdarzenie) przedstawiający sobą dla kogokolwiek wartość w oderwaniu od jego wytwórcy (np. książka ma wartość dla czytelnika mimo braku kontaktu z jej autorem i drukarnią, zburzony dom ma wartość jako oczyszczone pole nowej budowy i nie ma znaczenia kto i jak go wysadził w powietrze).

2. Proces: abstrakcja obrazująca (modelująca) działanie lub zespół działań, którego celem jest wytworzenie jasno określonego produktu; do wytworzenia produktu proces wymaga zasobów (człowiek, maszyny) a jeżeli jest procesem przetwórczym a nie twórczym, wymaga dodatkowo innych produktów (surowców); proces ma więc wejście i wyjście oraz wymaga zasobów, tworzenie produktu może być w jakiś sposób ograniczone.

3. Podproces: proces tworzący produkt swojego procesu nadrzędnego, jeżeli jeden produkt może składać się z elementów składowych będących także prostszymi produktami proces taki także może składać się prostszych procesów składowych tworzących produkty składowe, innymi słowy proces może zawierać podprocesy (procesy składowe, podrzędne).

4. Proces elementarny: proces tworzący produkt będący niepodzielnym bytem (nie wyróżniono podprocesów). Jeżeli dany produkt jest niepodzielnym bytem lub składa się z bytów, których samodzielne istnienie jest niemożliwe lub nielogiczne w danej sytuacji to proces, który tworzy taki produkt nazywamy procesem elementarnym.

5. Procedura: jest to opis wytworzenia produktu w procesie (realizacja procesu, jego implementacja); zawiera specyfikację prac (czynności lub podprocesów) jakie muszą zostać wykonane wraz z kolejnością ich wykonywania by produkt powstał, procedura stanowi ograniczenie mówiące, że inaczej tego produktu nie można wytworzyć; jeżeli takiego ograniczenia nie ma procedur nie tworzy się.

Przykład: samochód składa się z tysięcy podzespołów, proces wyprodukowania samochodu ma tysiące procesów elementarnych, które mogą być grupowane np. w proces powstania (produkcji) zespołu napędowego. Proces tworzenia elementu karoserii, np. pokrywy silnika, jest procesem elementarnym gdyż element taki ma wartość pod warunkiem że jego wytworzenie zostało całkowicie ukończone. Wytłaczanie, oczyszczanie i lakierowane niepodzielnego elementu karoserii jest opisywane procedurą mówiącą co i w jakiej kolejności należy wykonać. Jednak montaż samochodu z podzespołów, czyli to jakie i w jakiej kolejności podzespoły należy zmontować w montowni, jest także procedurą, tu procedurą montażu. Procedura jest scenariuszem, który opisuje jakie produkty składowe i w jakiej kolejności muszą zostać wytworzone. Jeżeli końcowe mycie samochodu można przeprowadzić na wiele różnych sposobów tworzenie procedury nie jest potrzebne, proces mycia i jego przeprowadzenie pozostawiamy kompetencji osoby odpowiedzialnej za jego umycie. Jest tak dlatego, że szczegóły procesu mycia nie są aż tak istotne (nie są ograniczeniem), celem (produktem) jest czysty samochód.

Niekończące się żarty na temat inżynierii systemów, a szczególności inżynierii wymagan owocują takimi właśnie rysunkami nie pozbawionymi zresztą prawdy..

Powyższy "model" jest chyba ilustracją wyników badań: ponad 80% projektów IT to porażki w tym w 100% podawano źle określone i źle udokumentowane wymagnia. Warto więć chyba tworzyc poprawne formalnie i skuteczne modele...

Jak już na jednej z tych grup napisałem, rysunki zawsze można sprzedawać i są tacy co je kupują, modelowanie zaś to wstęp do analizy modelowanego zjawiska, a jest nim także proces biznesowy.

Czym sie różni rysunek wieży Eiffla od modelu tejże wieży? No tym, że rysunek poza tym, że nie raz ładnie wygląda na ścianie nie przyda się do analizy odporności wieży na podmuchy wiatru, nie przyda się do oceny jej sztywności, nie przyda sie nawet do dokładnego wyliczenia ile czasu jaki będzie spadał z niej samobójca (teraz jest siatka więc już nie spadają). Tutaj powiemy troszkę o modelach jakimi są także mapy procesów, nie będziemy modelowali statków.

Prawdziwy model

Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo powinien bez potrzeby kontaktu z rzeczywistym pierwowzorem zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania rzeczy oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze bo zawsze wieżą można kiedyś przemalować i nie wpłynie to istotnie na jej aerodynamikę. Na tej same zasadzie rysowanie na diagramie faktu, że dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem.

Nie będę tu rozwijał tego wątku gdyż temat dokładnie zdefiniowałem w treści kursu ale kilka przykładów. Oferta w pewnej firmie jest tworzona przez handlowca, zatwierdza ją jego przełożony jeżeli wartość przekracza 10.000zł, handlowiec pracujący krócej niż kwartał zanosi do zatwierdzenia wszystkie swoje oferty. Na diagramie który swego czasu audytowałem było sześć czynności (sześć prostokącików) nazwanych "Przekazanie dokumentu...". Konia z rzędem temu kto pokaże tu wartość dodaną (patrz słownikowa definicja procesu biznesowego). Skoro jedna osoba dokument przygotowała a druga go czyta to oczywistym jest, że musi zostać przekazany. Nie musimy (i nie powinniśmy) pisać tego w jaki sposób sie to stało bo może to ulec zmianie bez utraty istoty procesu (następstwa czynności) ot choćby po wprowadzeniu elektronicznego obiegu dokumentów.

Pierwsza rada dla Państwa: jeżeli osoba modelująca Wam procesy umieści na diagramach czynności oczywiste to znaczy, że jest to rysownik a nie modelarz. Bo jeżeli nawet np. czynność przekazania dokumentu jest istotna z powodów czasowych a planujemy symulacje czasu trwania procesu na podstawie tego modelu to należy ją połączyć z procesem (czynnością) opracowania dokumentu bo celem procesu opracowania dokumentu jest to by znalazł sie on w rękach osoby dla której został przygotowany. Pomijam, że osobiście nie widzę nic wartościowego w takich symulacjach ale to moje subiektywne zdanie.

Drugi przykład (także z życia). W pewnej instytucji (nie mogę zdradzić jakiej niestety jest to ważna instytucja) uaktualniałem modele procesów. Jakież było moje zaskoczenie gdy znalazłem na diagramie niemalże algorytm obsługi sprzętu służącego do przekazywania depesz. Proces wysłania lub odebrania depeszy tym sprzętem jest dokładnie opisany w instrukcji obsługi. Sam proces odebrania lub wysłania zawsze ma ten sam cel, sprzęt może zostać wymieniony na nowszy jednak proces nie ulegnie zmianie a tu proszę: model instrukcji obsługi! Po drugie sprzęt jest typowy dla tego typu instytucji i umiejętność jego obsługi jest zapisana w oczekiwanych kwalifikacjach pracowników zatrudnianych w tej organizacji (zakres obowiązków w dziale kadr). Tak więc jeżeli ktoś Państwu "modeluje" kompetencje pracownika to jest to rysownik a nie modelarz.

Tak więc model procesów biznesowych, którego celem jest opisanie tego jak powstaje wartość dodana w firmie i jak jest firma zorganizowana nie powinien zawierać algorytmów pracy, opisów czynności oczywistych czy też opisów oczekiwanych kompetencji. Wtedy modele procesów są na prawdę wartościowymi dokumentami, nie są to setki stron papieru, można je przeczytać bez potrzeby wlewania w siebie litrów RedBull'a, opisują sedno rzeczy, doskonale nadają się np. do sprecyzowania wymagań na system IT czy też wdrożenia Zrównoważonej Karty Wyników.

Nie zapominajmy jednak, że rysownicy rozliczają się z ilości papieru a modelarze z liczby modeli a dobry model procesów jest jak wiersz: sztuką jest jego stworzenie ale do przeczytania powinna wystarczyć znajomość alfabetu. Niestety w wielu firmach spotykam sie z rysunkami i nie dziwię się, że ich prezesi nie widzą w tym sensu.

Krótko o narzędziach

Na zakończenie kilka słów o narzędziach. Modele można robić ołówkiem na papierze i jest to także dobry sposób. Można sobie troszkę ułatwić rysowanie jakimś programem do tworzenia schematów blokowych (np. mój ulubiony MS Visio). Jednak nie raz mamy do czynienia z modelami dużych organizacji, modelami zawierającymi wiele elementów i skomplikowanych zależności. Próba wykonania ich prostym narzędziem nie jest niemożliwa ale jest bardzo pracochłonna i obarczona ryzykiem powstania wielu błędów niespójności. W takich przypadkach faktycznie potrzebny jest kilku poziomowy system kontroli jakości by tego typu błędy wychwytywać, jest to jednak wyjątkowo kosztowny i czasochłonny proces (nawet kilku konsultantów zaangażowanych w wytworzenie jednego diagramu).

Na szczęście na rynku dostępne są systemy dedykowane do tego typu pracy. Powszechnie nazywane są systemami typu BPM (Business Process Management) lub bardziej rozwinięte systemy klasy CASE (Computer Aided System Engineering). Czy warto w nie inwestować? Warto. Bo wyobraźcie sobie Państwo, że Waszą pracę magisterską nafaszerowaną rysunkami z wielopoziomowym systemem rozdziałów i podrozdziałów, indeksów pojęć i przypisów zleciliście do przepisania osobie mającej do dyspozycji tylko Notatnik z systemu Windows a osoba ta rozlicza się z Wami za czas pracy. Tak właśnie wygląda praca z diagramami nie tylko w Visio a znam takich co robią to za pomocą programu do przygotowywania prezentacji. Nie twierdzę, że modele te są złe, one po prostu są koszmarnie pracochłonne i kosztowne.

Tak więc na początku projektu należy sobie zawsze odpowiedzieć na pytanie: modelarz czy rysownik. Po drugie nie kupujcie modelowania tylko płaćcie ekspertom za wsparcie w rozwiązywaniu Waszych problemów i dokumentowaniu Waszych decyzji bo model to także doskonały sposób na udokumentowanie decyzji ot choćby właśnie organizacyjnych.

W przygotowaniu artykuł o modelowaniu systemów z pomocą notacji UML jako zapis moich przemyśleń po konferencji na ten temat. Tych, którzy chcą podjąć próbę samodzielnego modelowania procesów zapraszam zaś na mój autorski kurs dostępny zdalnie: Modelowanie procesów biznesowych w analizie systemowej.

Wdrażajac systemy ERP sprzedawca chce dostarczyc to czym dysponuje. Umiejętnosc modelowania to srodek do uzgodnienia co potrzebnego klientowi możemy dostarczyc. Na kursie, oprocz poznania zarysu sztuki modelowania procesow biznesowych, nauczylem sie jeszcze jednej waznej rzeczy.

Trzeba rzetelnie opisac procesy biznesowe klienta, aby na modelu procesow pokazac jak duzo oferowany system moze zrealizowac.

Cieszę sie z uczestnictwa w kursie i wiem, ze bede swoja sztuke modelowania rozwijal. Dziekuje.

Szanowni Koledzy,

jest jeszcze coś, co musi znaleźć się w modelu przed wdrożeniem, a nawet do zapytania ofertowego w procesie selekcji rozwiązań.

To jest wykrycie wszystkich reguł biznesowych napotkanych w przebiegu procesów. To jest bardzo istotne, gdyż pomaga stworzyć formularz oceny systemów. W końcu kupowany lub budowany dedykowany system musi wszystkie reguły istniejące w danej firmie realizować.

Przykład: w systemach B2B (Zakupy) musi być możliwość ustawienia, do której godziny muszą być wyemitowane zamówienia do dostawców. Z każdym dostawcą jest to inna godzina. Jest to reguła biznesowa ustalona na poziomie umowy między obcymi podmiotami.

Lub inna reguła: jaki jest dopuszczalny czas zwrotu zakupionego towaru. Często sklepy mają swoje reguły lub korzystają z ustawowych. Taka reguła musi być w systemie zaimplementowana.

Tak więc, ja zaznaczam na moich schematach, że w danym kroku procesu funkcjonuje taka czy inna reguła.

Inne rzeczy, to punkty styku i wymiana danych między systemami uczestniczącymi w procesach. To musi być na modelu zaznaczone, bo daje obraz skali koniecznej integracji między systemami.

Teraz to ma coraz większe zastosowanie, bo wchodzi na całego SOA, co eliminuje jednorodne monolityczne systemy.

(źr. Konsultant wewnętrzny, pracownik firmy handlowej, planującej wdrożenie, ukończył mój kurs modelowania procesów.)