Mój referat był wprowadzeniem do konferencji – dziękuję za zaufanie organizatorom. Nie streszczę tu konferencji bo nie taki mam cel, a i organizator by się nie ucieszył.  Zanim streszczę swój referat kilka refleksji.

Na początek, powód stosowania metod formalnych czyli przed czym chronimy projekt:

“Modelowanie biznesu jest odpowiednikiem metody naukowej w zarządzaniu – zaczynamy od hipotezy, którą można przetestować w działaniu udoskonalić jeżeli to konieczne. Niestety w praktyce model biznesu i strategia należą do najczęściej nadużywanych terminów w biznesie. Często oznaczają one niemal wszystko, ale potem okazuje się że nie znaczą niemal nic. Cierpią na fundamentalny brak języka formalnego.” ¹

Tak więc język formalny, użyta notacja, czyni projekt wartościowym. Bez tego raczej nie znaczy po protu nic.

Prezentowane rozwiązania troszkę przypominają mi o tym, że można odkryć koło po raz drugi, nie wiedzieć o tym i nazwać swój wynalazek inaczej.  Nie jest to krytyka tych pomysłów i niektórych referatów ale żal, że nadal tworzone są nowe nazwy na istniejące już “rzeczy”. Takim, moim zdaniem, przykładem jest “motor reguł z wyborem scenariusza”, który tak na prawdę jest zastosowaniem metody EDM (event driven modeling, ang. modelowanie zorientowane na zdarzenia). Innymi słowy zastosowanie zasady przyporządkowania procesu do zdarzenia a nie np. do dokumentu.  O co chodzi? A o to, że zamiast dorabiać ideologię do tego, że np. faktura kosztowa (tu lista scenariuszy obsługi faktur kosztowych w ogóle jest ogromna, prelegent wspomniał o ich liczbie równej 4500 a ogromny diagram tego procesu powalił na kolana całą salę) potraktowana “silnikiem reguł decyzyjnych” zostanie obsłużona jednym z możliwych scenariuszy (jakoś wybranych przez silnik reguł). Jednak wystarczy uznać, że nie faktura kosztowa, jako dokument, inicjuje proces a jedno z możliwych zdarzeń: poniesiono koszt zakupu do dalszej odsprzedaży, poniesiono koszt wydatku przewidzianego w budżecie, poniesiono innych koszt ad-hoc.

Czujecie Państwo różnicę? Mamy tu kilka różnych, stosunkowo prostych procesów inicjowanych przez każde z tych zdarzeń zamiast megaprocesu obsługi dowolnej faktury kosztowej. Ale cóż, kto nie był niech żałuje bo, nie licząc kilku tego typu ekscesów, konferencja była bardzo wartościowa.

Mój referat

(slajdy na końcu treści)

Życie pokazuje, że “badanie prawdy” (bo czym innym jest analiza) wymaga “porządku” czyli stosowania “prawa jednorodności” i “prawa specyfikacji”. Jednorodność i specyfikacja, jak być może już ktoś się domyśla, to spójny system pojęciowy zachowujący zasadę tak zwanej “brzytwy Ockhama“, modelowany często z pomocą diagramu klas. Zasada ta powinna być także spełniona przez semantykę (słownik) używanej notacji.

Notacja to narzędzie – język – komunikacji, ale jako pismo, oddziela piszącego (który wie co chce przekazać)  od czytającego – tego który chce poznać treść przekazywaną. Zrozumienie tego “niuansu” ma ogromne znaczenie, bo celem modeli jest przekazanie wiedzy analityka osobie, która czyta jego produkt – dokument projektowy. Dobra notacja i jej formalizm zmusza także do obiektywizmu przekazu, jeśli tylko jest stosowana zgodnie z jej regułami.

Kolejnym elementem “kształtującym” sukces projektu analitycznego jest metodyka czyli “zestaw metod” użytych do pracy. Osobiście uważam, że nieprawdą jest, że należy mieć “branżowe doświadczenie” w projekcie analitycznym. Jeśli tylko analityk radzi sobie z zadawaniem “właściwych” pytań i modelowaniem pozyskiwanej tak wiedzy, specyfika branży niewielkie ma znaczenie. Jak zadawać właściwe pytania? Modelować pozyskaną wiedzą i weryfikować model podczas rozmowy. Jeżeli uznać, że formalizm notacji (dla danego kontekstu projektu) spełnia zasady opisane na początku, to uznać także należy, że albo coś się da zamodelować, albo czegoś jeszcze nie wiemy (nie rozumiemy) i należy o to zapytać albo jest to “coś nieistotnego” w tym modelu i należy to po prostu pominąć (to także metoda na panowanie nad złożonością projektu!).

W efekcie uzyskamy model organizacji (przedsiębiorstwa), który w pewnych wypadkach (kontekst i cel projektu) może nam tę organizację po prostu zastąpić. Dodatkowo “zapisujemy” dane stanowiące podstawę wiedzy o tej organizacji w pewnym kontekście.

Dochodzimy do momentu, gdy model zaczyna “pracować”. Samo jego stworzenie to tylko etap pracy analitycznej (model sam z siebie, nie jest celem analizy). W analizie systemowej model służy do testowania hipotez i budowania rekomendacji. Hipotezą (model to hipoteza) jest stwierdzenie: “tak funkcjonuje [zamodelowana] organizacja”. Rekomendacją może być np. wskazanie miejsc optymalizacji, zdefiniowanie zakresu wdrożenia oprogramowania i wiele innych.

Tak więc użyta notacja i ograniczająca ją pragmatyka, decydują nie tylko o tym jaki model powstanie, ale też na ile pomoże on w projekcie. 

Jednym z tych wymagań jest spójny i pełny model pojęciowy. Tak zwana przestrzeń nazw (w notacji jest to lista symboli i definicje ich znaczeń) powinna być “wypełniona” definicjami całkowicie zaś obszary definiowanych pojęć nie mogą na siebie nachodzić.

Jak to się ma do procesów? Ano znana jeszcze z lat 60-tych definicja procesu opisuje go czterema pojęciami: wejście, wyjście, zasoby, ograniczenia (lub sterowanie) (ang. ICOM – input, controll, output, mechanizm). Sam proces to pewna abstrakcja (nie można go dotknąć w przeciwieństwie  do wskazanych czterech pojęć).

Proces jako taki (jego mapa) to czynność lub łańcuch czynności. Poza czynnościami (abstrakcyjnymi na diagramie bytami mówiącymi o np. ludzkiej pracy) mamy namacalne: produkty na wejściu i wyjściu procesu, zasoby (ludzie i ich kompetencje, maszyny i ich możliwości itp.) oraz (spisane najczęściej) sterujące ograniczenia w postaci procedur (opisu tego jak można to zrobić lub czego nie wolno robić w czasie realizacji procesu).

Te cztery materialne “byty” to nie “proces” a materiał na osobne (uzupełniajcie model procesów) dokumenty. Np. procedury ISO, opisu kompetencji pracowników (zasoby ludzkie) itp. Powszechnie popełnianym błędem jest np. modelowanie, na diagramach procesów, procedur.

Specyficznym elementem modeli procesowych są reguły biznesowe. Są to specjalne rodzaje ograniczeń i reguł decyzyjnych.

Są to jak widać specjalne ograniczenia, jednak wynikają one nie z ograniczeń takich jak procedura czy wymagane kompetencje wykonawcy, ale z pewnych narzuconych zasad np. liczbowych (umowy o wartości większej niż 1 mln. negocjuje tylko Zarząd) lub jakościowych (samochody ciężarowe obsługujemy poza kolejnością). Mogą być one (ich postać) wynikiem realizowanej strategii.

W przypadku reguł jakościowych należy wystrzegać się próby specyfikowania wszystkich wariantów na korzyść podejścia: znane warianty oczekiwane oraz pozostałe.

Podobnym przypadkiem są reguły związane z upływem czasu.

Tak więc stosowanie formalnych notacji i zasad obniża ryzyko projektu. Nie wyeliminuje go, bo model i jego jakość zależy bardzo od jego twórcy (modelowanie to jednak sztuka a nie rzemiosło), jednak łamanie zasad lub stosowanie nieformalnych diagramów stanowi kluczowe ryzyko projektów na etapie analizy.

Notacją spełniającą powyższe wymagania jest np. BPMN wraz z pragmatyką wynikająca z definicji procesu biznesowego (proces tworzy produkt, tak zwana orientacja produktowa modelu).