Wstęp

KLuczową ich wadą jest

To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!)  i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane,  swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!

Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!).

Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP “luźnej prozy”. Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji:

Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje).

Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze “nieudane” projekty…

O notacjach

Króciutko, żeby się nie powtarzać.  Notacja to pewien język wyrazu, przestrzeń nazw zawierająca skończoną liczbę pojęć o ściśle zdefiniowanych znaczeniach. Notacji mamy na rynku wiele. Czy to jakiś problem? W pewnym sensie tak, bo po pierwsze języki te nieco nakładają się na siebie (nakładają się na siebie przestrzenie nazw) ale nie dają się na siebie w sposób jednoznaczny tłumaczyć. Języki te nie zastępują się wzajemnie. Są “w użyciu” notacje (systemy tworzenia diagramów) niesformalizowane, trudno je w ogóle nazywać notacją. To po protu biblioteki symboli do tworzenia schematów blokowych a te nie koniecznie są “modelami”. Przykładem może być bardzo popularny MS Visio z wieloma bibliotekami symboli. Niestety tak powstające diagramy są zapewne ilustracją dla tekstu ale nie są żadnym modelem.

Opisze tu wybrane notacje, te których używam i uznaje za pewien standard de’facto. Nie będzie to żadne “szkolenie z notacji”, bo nie jest to ani miejsce ani dobry sposób na szkolenia (na te serdecznie zapraszam zainteresowanych na sale wykładową :)).  Powiemy sobie o ArchiMate (z tej notacji później zrezygnowałem z uwagi na jej niejednoznaczność i wprowadzone licencjonowanie), BMM, BPMN, UML.

Organizacji się nie “opisuje”, organizacje się modeluje

Każda organizacja to bardzo złożony organizm. Stopień złożoności jest duży, szczególnie gdy wziąć pod uwagę fakt, że niejedna zatrudnia setki pracowników, tworzy tysiące dokumentów, obsługuje tysiące spraw i używa dziesiątek narzędzi (w tym oprogramowanie) wspomagających tę pracę . Czy to w ogóle da się jakoś opisać? Owszem. Jak?

Ich modele to określone idealizacje, pozwalające zrozumieć sposób ich działania. Problem jednak  w tym, że organizacja to wiele różnych aspektów jej działania. Dla każdego z nich powstał inny język opisu, powodem jest (tak sądzę), po pierwsze różny odbiorca na każdym poziomie szczegółowości, a po drugie różne paradygmaty (procesowy, obiektowy czy system analiz wpływu). Kto inny czyta opis strategii biznesowej a kto inny opis techniczny systemu ERP, jednak oba te aspekty są jakoś powiązane (powinny być ;)) i to także powinno dać się opisać. Z tego powodu pierwszym podziałem modeli są: modele logiczne (abstrakcja) i wykonawcze (specyfikacja). Na to nakłada się sfera biznesowa (zarządzanie) oraz techniczna (zasoby w tym narzędzia).

Nie znajdziecie tu państwo definicji tych notacji, odsyłam na strony organizacji standaryzujących (Object Management Group oraz The Open Group). Pokaże do czego doszedłem na bazie dziesiątek projektów małych i dużych, dla realnych przedsiębiorstw i fikcyjnych badawczych. Posłużę się klasycznym chyba już modelem analizy zstępującej, w postaci piramidy obrazujące trzy poziomy abstrakcji opisu organizacji (im niżej tym więcej szczegółów zawiera dokumentacja):

Na najwyższym poziomie abstrakcji mamy strategię, tu pojawia się tak zwany model motywacji i analiza wpływu.  Obecnie używam na tym poziomie notacji (języka modelowania) Business Motivation Model. Zawiera takie pojęcia jak cel biznesowy, środki osiągania celu ale także bardzo ważne na tym etapie takie elementy jak czynniki wpływu, analiz a SWOT, ryzyka  czy strategie i taktyki.

Na tym poziomie od tego roku można stosować notację ArchiMate, jednak w moim przekonaniu jest ona w tym obszarze zbyt silnie ukierunkowana na metodykę i struktury opisu TOGAF, jest w moich oczach w tej sferze uboższa, brakuje jej wielu pojęć “obsługiwanych” przez BMM.

Jeżeli nie widzę nic złego w stosowaniu kilku notacji w jednym projekcie (jest to w zasadzie konieczność), to z zasady używam wyłącznie jednej notacji na jednym poziomie abstrakcji (warstwie jak wyżej). Używanie na jednym poziomie np. dwóch różnych notacji prowadzi co najmniej do braku spójności modeli gdyż pojęcia różnych notacji różnią się swoim zasięgiem (poszczególne pojęcia mają nieco inne znaczenia).

Na poziomie procesów biznesowych, stosuję zamiennie BPMN albo ArchiMate.  Z każdym kolejnym projektem skłaniam się jednak do używania na tym poziomie ArchiMate. Powodem jest to, że BPMN oferuje wyłącznie czyste pojęcia z definicji procesu (czynność, dane, zdarzenie, rola, pula, bramki). Na tym poziomie jednak nie raz należy wyrazić rozdzielnie takie pojęcia jak rola i aktor (np. klient i kontrahent mogą pełnić rolę zamawiającego w procesie) albo odrębne pojęcia takie jak funkcje biznesowe (aktor wraz z zasobami jakich używa pełni funkcję administracji wewnętrznej) albo usługi powiązane z procesami (proces sprzedaży powiązany z usługą obsługi klienta). Przykłady można mnożyć.

Realizacja procesów to “suche” łańcuchy czynności i twarda logika ich scenariuszy. Tu doskonale sprawdza się BPMN i pierwotny cel powstania tej notacji: modelowanie skryptów BPEL ([[Business Process Execution Language]], a obecnie  głównie [[XPDL]]). W tej warstwie BPMN nie ma konkurencji, jest w 100% zgodny z XPDL  (język opisu procesów zalecany przez [[Workflow Management Coalition, WfMC]]). Podejmowane są próby stosowania UML (Diagram czynności) ale nie wróżę tej metodzie sukcesu i nie polecam jej (powody na końcu tekstu).

Tu dodatkowa mała uwaga. Nawet na poziomie wykonawczym procesu rzadko pojawia się potrzeba, modelowania “explicite” każdej czynności, z dokładnością niemalże algorytmiczną. W większości wypadków zupełnie wystarczy “model celowości działań” i ich scenariusze, algorytm postępowania potrzebny jest tylko maszynie.  Na stronach BPM Research dostępne są wyniki badań pokazujące to zjawisko:  The average subset of BPMN used in these models consisted of just 9 different symbols. That means that the average BPMN model uses less than 20% of the available vocabulary. (Najczęściej używany w modelach zestaw pojęć BPMN to  9 symboli. Oznacza to, że w modelach BPMN używanych jest niecałe 20% zdefiniowanych w tej notacji pojęć). Polecam dostępny na tych stronach wykres.

Można się spotkać z pojęciem trzech poziomów modelowania procesów (Bruce Silver blog): warstwa opisowa, warstwa modeli analitycznych, warstwa modeli wykonawczych. w zasadzie nie odbiega to od powyższego modelu jednak autor proponuje tu w warstwie pierwszej (opis) tworzenie ogólnych modeli z zaniedbaniem reguł notacji. Tu jednak niestety narażamy się na niejednoznaczności. Ja widać nie ja jeden dostrzegam potrzebę  podziału na poziomy abstrakcji w modelowaniu i analizie. Propozycja Bruce’a Silvera jest jak najbardziej warta naśladowania, z tym jednak, że lepszym pomysłem jest, moim zdaniem, wybranie notacji dostosowanej do poziomu abstrakcji, dlatego na poziomi opisowym (ja jednak wole nazwę model biznesowy lub łańcuch wartości, to nadaje konkretny sens temu modelowi) stosuję oraz częściej ArchiMate by nie musieć łamać zasad systemu pojęciowego danej notacji (jak sam Bruce Silver przyznał, wymaga to wyłączenia kontroli poprawności modelu).

Warstwa architektury systemów IT. Tu w zasadzie równoprawnie można używać ArchiMate i UML (głównie diagram komponentów i diagram wdrożenia). Jednak kojarząc logikę biznesową (poziom procesów biznesowych) z architekturą aplikacji (system IT), należy zastosować jedną notację dla obu warstw by zachować spójność pojęciową modelu, a to daje nam właśnie ArchiMate (to są już projekty “dotykające” architektury korporacyjnej).

Najniżej mamy warstwę specyfikacji systemu IT, jego strukturę (albo jak to woli model realizacji systemu IT). Na tym poziomie w użyciu notacja UML, która do tego powstała. Jeżeli uznać fakt, że metody strukturalne odeszły do lamusa (notacje DFD) a modele relacyjnych baz danych są na zbyt niskim, inżynierskim poziomie (notacja ERD), to UML jako język obiektowy, nie ma w tym obszarze konkurenta. Poniżej typowy zakres (pakiety, w nich są lokowane “artefakty” produktu analizy) moich projektów:

Powyższy diagram obrazuje strukturę modeli (pod spodem odpowiadające mu drzewo katalogów, diagram powyższy do diagram pakietów UML).

Powyższy diagram to także podział z perspektywy adresata dokumentacji: dla tak zwanego biznesu adresowane są trzy warstwy licząc od góry. Dla wykonawców systemów ostatnia: wykonawcza.

Na zakończenie kilka słów o UML

Notacja ta powstała jako uniwersalna (Unified Modeling Language, Uniwersalny Język Modelowania)  jednak tu chyba autorzy tej notacji dotknęli problemu “coś co jest do wszystkiego jest do niczego”. Mimo tego, że z pomocą systemu tak zwanych profili w UML możliwe jest wyrażenie w tej notacji pojęć każdej z pozostałych wymienionych, nie jest to dobry pomysł. Mam nadzieję, że nie “zachoruje na to” The Open Group i ArchiMate (pojawiła się wspomniana ArchiMate 2.0).

Dlaczego UML nie powinien być używany do wszystkiego? Notacja ta jest “skażona” tak zwanym obiektowym paradygmatem, bardzo trudnym do przyswojenia dla osób nie obytych z metodami obiektowymi w inżynierii oprogramowania. Po drugie system graficzny w UML nie ułatwia odbioru, percepcji modeli gdyż większość pojęć jest obrazowana prostokątem z różnymi etykietami. Zjawisko to (zrozumiałość graficznych systemów komunikowani treści) opisuje nauka jaką jest [[Semiotyka]]. Nie jest to miejsce na jej opis, jednak wykazuje ona, że stosowanie np. UML do komunikowania czegokolwiek ludziom z tak zwanego “biznesu”, nie mającym nic wspólnego z obiektowym paradygmatem, nie jest dobrym pomysłem, a dokumenty opisujące  organizację w końcu mają im służyć.

Semiotyka “uczy nas”, że każde pojęcie (koncept) dla możliwie najlepszej zrozumiałości dla odbiorcy, powinien być reprezentowany innym znakiem (kształtem), najlepiej kojarzącym się z reprezentowanym znaczeniem (co znaczy ten znak).

Innym razem na kilku przykładach, pokażę modele w ArchiMate…