Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w “oryginale” Use Case (UC).  Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na “polecenia”. Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia.

Przypadki użycia budzą jednak wiele kontrowersji, gdyż  konwencja ta jest sformalizowana (jest to część notacji UML), używanie jej “po swojemu” prowadzi najczęściej do bezużyteczności modeli przypadków użycia.

Jeden z czytelników sprowokował ciekawą dyskusję:

…jakiej notacji używa Pan, aby pokazać wpływ jednego procesu na drugi? Konkretnie chodzi mi o przypadek, że problem występuje w procesie rozliczania płatności, ale żeby go naprawić trzeba wprowadzić zmiany w procesie zakupów. Nie wiem czy samo rozrysowanie procesów w BPMN jest wystarczające czy można to jakoś lepiej zamodelować.

Niektóre analizy wymagają czegoś “ponad” procesami”. Mamy dwa wyjścia: tworzenie nadrzędnych map procesów i na nich “szukanie” związków albo zastosowanie innej notacji na “wyższym poziomie abstrakcji”. Notacja np. BPMN wystarczy, rzecz w tym by opisać proces na odpowiednio wysokim poziomie abstrakcji. Tego typu problemy wymagają uogólnienia  i spojrzenia z “wyższej” perspektywy. Pomagają przypadki użycia.

Jeśli chodzi o modele PU, to przyznam, że rzadko je stosuję. W przypadku 1 czynność – 1 PU, to jeśli mamy proces w BPMN, to wg mnie model PU, to po prostu wrzucenie do jednego worka wszystkich czynności. Czyli jest to inna graficznie (wg mnie słabsza, bo brak kolejności) prezentacja tego samego co w BPMN. Chyba że mamy czynności, które nie są wspierane systemem albo wiele procesów, które wykorzystują tą samą czynność (różni aktorzy dla tego samego PU).

Troszkę o tym (przypadki użycia w skrócie PU) tu: https://it-consulting.pl//?s=przypadki+u%C5%BCycia

Ogólnie PU to usługa systemu, czynność w procesie to element pewnego łańcucha takich czynności (proces ma swój cel, pewne czynności mogą się powtarzać w różnych procesach, np. archiwizacja dokumentu). System (oprogramowanie) rzadko wspomaga wszystkie czynności w procesach. Model procesu służy do zrozumienia (i przetestowania) tego co i po co się dzieje w organizacji, część czynności (zakres projektu) jest (ma być) wspierana oprogramowaniem (usługa systemu).

Po drugie model PU to tak na prawdę korzeń struktury opisu oprogramowania. Rolą modelu PU nie jest opis procesów a specyfikacja “usług systemu” z perspektywy “zewnętrznego użytkownika”, jest to opis funkcji narzędzia a nie proces.

Rzecz zasadza się w tym, jak zostaną zdefiniowane pojęcia “przypadek użycia” i “czynność” (w procesie). Ciekawe jest to, że obie te definicje są (PU w UML i czynność w BPMN) permanentnie zaniedbywane (łamane) w dokumentacjach projektowych. W moich oczach jest to niezrozumienie celowości modelowania, które ma być lekarstwem na niejednoznaczność prozy a nie jej inną firmą.

Dziękuję, za takie precyzyjne (łopatologiczne) wyjaśnienie. Mimo, że czytałam wcześniej Pana artykuły (oczywiście nie wszystkie) to dopiero teraz to do mnie wyraźnie dotarło. Nadal nie wiem jak sensownie za pomocą modelu PU przedstawić pełny zakres systemu np. ERP/CRM. Na takim diagramie powinno być chyba kilkadziesiąt elementów i taki diagram nie będzie wg mnie przejrzysty. Czy może dla jednego systemu należy zrobić kilka modeli PU, ale z podziałem na aktorów…

A czy ma Pan może jakiś przykład PU gdzie aktorami są 2 systemy tzn. nie ma udziału osoby fizycznej?

Duże systemy warto podzielić na tak zwane bloki funkcjonalne ograniczone dziedzinowo (tak zwane [[bounded context]]) i “pracować nad nimi” niezależnie (każdy ma swój interfejs). Duży system może mieć setki UC, dzieli się je na pakiety ale nie “per aktor” a raczej “per kontekst” (np. księgowanie dowodów księgowych w jednym podsystemie, niezależnie od tego ilu jest aktorów). Nie ma sensu upychanie na jednym diagramie wszystkich UC…

Co do zasady, model PU zawiera pojęcie System (abstrakcja modelowanego oprogramowania), w nim przypadki użycia (PU) oraz poza nim aktorów tego Systemu. Co jest ważne: model PU to model “Jednego systemu i jego otoczenia”, jeden model PU nie może zawierać wielu równorzędnych Systemów.

Co do zasady model PU to: System modelowany, przypadki jego użycia (jego usługi świadczone na zewnątrz) oraz aktorzy, aktorem jest każdy zewnętrzny byt żądający obsługi. Możliwe jest więc, że system nie ma żadnego “ludzkiego” aktora. Nie przesadzał bym z tym, że PU to “głównie rozmowy systemów” choć projektując “głównie” systemy middleware i elementy integracji można mieć “takie wrażenie” 🙂

O narzędziach

Agilian ogólnie wspiera każde “śladowanie”. Każda operacja utworzenia PU z czynności BPMN, po drodze ma etap wskazania jaki diagram UC oraz jaki Model jest docelowy (a może ich być wiele). Tu trzeba bardzo uważać, bo jeżeli mam proces (np. w BPMN) obsługi reklamacji, to pojawią się czynności z obszaru FK (sprawdzenia czy sprzedano taki towar), z obszaru logistyki (sprawdzenia kiedy wydano lub dostarczono) oraz CRM (czynności “biurowe” obsługi klienta, tu obsługa reklamacji). W zasadzie jeden proces “użył” co najmniej trzy narzędzia (systemy) z różnych obszarów dziedzinowych.

Co do adresatów diagramów, ja także skłaniam się ku tezie, że dla biznesu jest BPMN a PU to już diagram “systemowy”, jednak wiele metodyk (w tym RUP) traktuje diagram PU jako pierwszy powstający (?!) i jako adresowany do zamawiającego… cóż…

Generalnie diagram PU jest bardzo dobrym “korzeniem” do analizy i tworzenia pozostałych modeli, ale bez powstającego “natychmiast” modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów.

Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na “strawne” kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje.

Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek….

 

Na stronach www.modernanalyst.com pojawił się kolejny ciekawy artykuł, kluczowe tezy to:

The two major areas for change driving the new IS shift are the desire or need to:

(1) manage business process and business rules as separate but closely related and connected resources and

(2) decompose software or programming code into reusable modules, called services, managed by a service oriented architecture (SOA) infrastructure. The SOA infrastructure manages and mediates services used in a business process.

(A New Information Systems Paradigm: What does a Business Analyst Needs to Know?).

To kolejne źródło, które publikuje “przepowiednię” mówiącą, że kluczowy wpływ na  rozwój i projektowanie systemów informatycznych będą miały dwie kluczowe kompetencje i analityków i projektantów: zarządzanie procesami biznesowymi i regułami biznesowymi jako odrębnymi, powiązanymi obszarami, opisującymi organizacje oraz umiejętność dekompozycji oprogramowania na samodzielne odrębne moduły-usługi, których można  niezależnie używać np. w architekturze SOA.  Architektura SOA daje możliwość niezależnego przyporządkowania potrzebnych usług do konkretnych procesów biznesowych.

W 2007 roku pisałem, że przewiduję powolne odchodzenie od idei systemów zintegrowanych. Dotychczasowa ich zaleta czyli pełna integracja przestaje być zaletą a staje się garbem. System zintegrowany można już ?skleić? ze specjalizowanych aplikacji, komponentów. Technologia obiektowa bardzo ten proces ułatwiła. Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu wykroić koszt wsparcia pojedynczego procesu. (Czy to już nadchodzący koniec zintegrowanych ERP?).

W roku 2011, rok temu można było zauważyć, że  rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego ?super systemu? ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci ?gotowej? tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nawę je ?zapóźnione?, nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane API, Application Programming Interface) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing).  Przyszłość to komponenty? (Biznes wychodzi z objęć systemu ? monolitycznego ERP).

W ubiegłym roku na konferencji SOA Executive Forum miałem referat Jak rozumiane SOA odejdzie do lamusa? Co nastąpi po SOA?. Poruszyłem kilka spraw:

1. SOA jako Service Oriented Architectute, czym było jako technologia?
2. SOA jako Service Oriented Analysis a cóż to takiego?
3. SOA jako nowoczesna architektura systemów wspomagających zarządzanie
4. Nowe czasy: architektura oparta na komponentach rynkowych czyli SaaS, Clod Computing i inne

Duże zainteresowanie wzbudziło wtedy rozwinięcie skrótu: [[Service Oriented Analysis]]. Otóż analiza procesów biznesowych i następująca po niej analiza wymagań, a być może dalej obiektowe projektowanie, prowadzi właśnie do “orientacji na usługi”. Przypadek użycia w UML (i jako wymaganie w obiektowym paradygmacie)  to nic innego jak usługa systemu. Nic nie stoi na przeszkodzie, by je – te usługi – implementować “oddzielnie i niezależnie. Otrzymamy wtedy znane od lat COTS. Powyższy diagram jasno pokazuje, że “system” wspomagający zarządzanie to pakiet usług wspomagających konkretne procesy biznesowe i nie koniecznie będący jednym zintegrowanym pakietem oprogramowania ERP II.

Podejście takie jest wygodne gdyż pozwala projektować i wdrażać nawet bardzo złożone systemy metodą kolejnych kroków-komponentów, spokojnie można je nazwać etapami a całość, zwinnym  projektem. Jednak z drugiej strony ta zwinność, to nie może być “rzut na taśmę bez analizy i projektowania”.

Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić?

1. Opisać strategie rynkową firmy,
2. Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów),
3. Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych,
4. Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści,
5. Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi.

Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. – SOA) 

Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.

Swego czasu w artykule Business Rule Concepts ? czyli jak ?wyłuskać istotę rzeczy? opisałem rolę reguł biznesowych w modelowaniu organizacji. Dzisiaj pora na rolę struktury organizacyjnej. Także w ostatnim artykule poruszyłem problem tę kwestię:

Model organizacji to: opis motywacji jej działania, opis ludzi, jacy realizują wewnętrzne zadania, opis reguł jakie regulują ich zachowaniami. Całość (model) powinna być na tyle uporządkowana, by model był w 100% jednoznaczny, czyli kluczowe pojęcia w nim użyte powinny być zebrane w jeden wewnętrzny, spójny biznesowy słownik tej organizacji. To wszystko dopiero pozwoli stworzyć model procesów biznesowych, czyli wewnętrzne scenariusze zachowania (Modelowanie biznesowe).

Więc przyszła pora na ludzi…

Opis ludzi, jacy realizują wewnętrzne zadania

Jednym z regularnie zaniedbywanych, a nie raz całkowicie zaniechanych elementów analiz biznesowych, jest struktura organizacyjna. Prowadzi to do wielu problemów nie tylko z np. systemem uprawnień we wdrażanym oprogramowaniu. Zaniechanie to prowadzi bardzo często do  braku możliwości opracowania poprawnych modeli procesów. Dlaczego?

Przytoczę jeszcze raz model obrazujący związki pomiędzy tym co opisuje organizację:

Tak więc w skrócie: proces ma wejście i wyjście, jego wykonanie jest zależne  od procedur i reguł biznesowych (ograniczenia), za wykonanie (czynności) odpowiada Odpowiedzialny, pełniący w organizacji określoną rolę. I teraz bardzo ważne: Odpowiedzialny ma swój zakres obowiązków, ma wymagane na jego stanowisku umiejętności i jest umiejscowiony “gdzieś w strukturze organizacyjnej” (komuś podlega i czasem kimś kieruje).

Pamiętając moje poprzednie artykuły na ten temat, nie da się, nie ma sensu, modelowanie umiejętności i przepisów prawa czy też zarządzeń wewnętrznych (nie algorytmizuje się pracy ludzi). Jednak “trzeba to co muszą i potrafią robić gdzieś ująć” i miejscem tym jest struktura organizacyjna.

Zasoby to nie tylko systemy IT czy maszyny (to czego używają ludzie do realizacji swoich zadań), to także ludzie  i Ci są ważniejsi, bo to oni odpowiadają za efekty swojej pracy (u kogo z Państwa “na dywanik” wzywany jest komputer a nie pracownik?).

Idąc dalej: zarządzenia i prawo to jest…. no co? To jest coś co musi znać pracownik (wykonawca), musi postępować zgodnie z ustalonymi zasadami,  a one są wiedzą jaką musi posiadać ta osoba (nie przypadkiem wpisujemy w ogłoszeniu rekrutacyjnym “wymagana znajomość…”).

Skoro więc wynik pracy (produkt procesu) zależy od wiedzy i umiejętności jej wykonawcy, to znaczy, że model procesu biznesowego powinien nam powiedzieć:

1. co jest na wejściu procesu,
2. co jest jego produktem,
3. kto jest wykonawcą czynności/procesu,
4. co musi umieć/wiedzieć wykonawca by osiągnąć zamierzony efekt (produkt procesu).

Jakaś czynność w procesie, może np. wymagać znajomości pewnej ustawy (wymagana wiedza osoby “znajomość prawa podatkowego”), w firmie obowiązuje reguła biznesowa: “dokument musi być konsultowany z przełożonym”, a ze struktury organizacyjnej ów pracownik (i czytający model procesu) zawsze dowie się kim jest ten przełożony.

Jaki z tego pożytek? Reguły i struktura organizacyjna to elementy, które ulegają relatywnie częstym zmianom. Jeżeli “zamodelujemy” je w procesie “jako procesy”, to model taki będzie po pierwsze bardzo złożony (czytaj kosztowny, trudny do studiowania czyli najczęściej niewykorzystywany). Bardzo złożony model jest bardzo trudny i kosztowny w “konserwacji”, dlatego jak tylko taki powstanie, to pierwsze zmiany np. w prawie uczynią go nieaktualnym czyli nie przydatnym. Skoro zaś jego aktualizacja jest kosztowna, to jest najczęściej zarzucana i cała praca poszła na marne.

Dlatego na pytanie “ile kosztuje utrzymanie i aktualizacja takich diagramów” zawsze odpowiadam: im gorszy model tym kosztowniejszy w utrzymaniu.

Jak można modelować strukturę organizacyjną

Z literaturą na ten temat bardzo ciężko. Proszę zwrócić uwagę na fakt, że niemalże żadna książka czy prezentacja, w której używa się pojęcia “struktura organizacyjna”, nie przytacza żadnej jej definicji. Pod modelami procesów znajdziemy opis “notacja BPMN”, pod modelami struktury oprogramowania znajdziemy np. “notacja UML”, a co znajdujemy pod diagramami struktur organizacyjnych? Najczęściej nic! Co mamy w prezentacjach i książkach o zarządzaniu? Ano np. to:

Próba poszukania definicji tak zwanego organigramu w sieci kończy się na WIKI:

An organizational chart (often called organization chart, org chart, organigram(me), or organogram(me)) is a diagram that shows the structure of an organization and the relationships and relative ranks of its parts and positions/jobs. (Organizational chart – Wikipedia, the free encyclopedia).

W dużym uproszczeniu: organigram to diagram obrazujący strukturę organizacji, wewnętrzne stanowiska i ich zależności. Czyli nie za wiele. Szukamy więc czym jest owa “struktura organizacji” (structure of an organization). Zaglądamy do WIKI (bo znowu wyszła jako pierwsza w wyszukiwarce ;)):

An organizational structure consists of activities such as task allocation, coordination and supervision, which are directed towards the achievement of organizational aims.[1] It can also be considered as the viewing glass or perspective through which individuals see their organization and its environment. (Organizational structure – Wikipedia, the free encyclopedia).

Niewiele lepiej, znowu mało konkretów ale już coś jest:  “consists of activities such as task allocation” (opisuje gdzie są wykonywane jakie zadania). Drugie zdanie jest nie mniej ważne: jest to perspektywa z jakiej postrzegają organizację jej pracownicy.

Pochylmy się nad problemem. Typowy tak zwany “przyzwoity organigram” wygląda najczęściej tak:

Jest jakaś hierarchia (najczęściej i działów i ludzi). Wadą wielu takich diagramów jest to, że prawie nigdy nie mają jakichkolwiek zasad. Co mamy w większości firm?

Np. diagram ze strony Promis ), publicznie dostępny więc popatrzmy:

Zarząd nijak się ma do reszty, Sklepem w zasadzie chyba nikt nie kieruje, są jakieś nazwiska a przy nich raz Leader, raz Kierownik, raz Manadżer, specjalista itp. Wygląda to tak, jak by każdy pracownik, odizolowany od pozostałych napisał coś o sobie po swojemu i wrzucił do worka, zaś jeszcze inna osoba poukładała to także po swojemu na bazie wiedzy z jakiego pokoju pochodzi dana karteczka.

Inny diagram (także ze strony firmy, która go prezentuje). Tu dla odmiany wyczynem jest zrozumienie podległości zakładów produkcyjnych. Wygląda to na tak zwany “zgniły kompromis” kierowników tych działów. Próba dojścia kto kim kieruje staje się nie lada wyczynem:

(źr. http://public-relations.eprace.edu.pl/513,Struktura_organizacyjna.html)

Takie diagramy można przytaczać bez końca.

Jak (można) modelować strukturę organizacji

Zanim pokażę, przykładowe sposoby modelowania struktury organizacyjnej zdefiniujmy pojęcia jakie będą wykorzystane bo one są tu podstawą.

Struktura organizacji to hierarchiczna struktura obrazująca obszary poszczególnych komórek organizacyjnych, podległość osób oraz ich przynależność do komórek organizacyjnych. Cechą poprawnego modelu struktury organizacji jest jego drzewiasta[1] struktura oraz istnienie ścisłej definicji każdego typu użytego “bloczka” (czyli mamy jednoznaczny opis tego co każdy z nich oznacza). Przykładowe definicje (opracowanie własne):

1. Podmiot  – każda organizacja skupiająca ludzi i zasoby niezależnie od jej formy prawnej.
2. Rola/Stanowisko pracy to podstawowy, pojedynczy i niepodzielny element struktury organizacyjnej organizacji, posiada zakres wymaganych obowiązków, uprawnień i wymagane umiejętności, w celu realizowania zadań wyznaczonych mu przez organizację. Jest dość powszechną praktyką łączenie stanowisk pracy w komórki organizacyjne, które są kierowane przez jedną osobę zarządzającą nią. Każde stanowisko może wystąpić  tylko raz i tylko w jednej komórce organizacyjnej ale może być zajmowane przez wiele osób za wyjątkiem osoby kierującej komórką).
3. Osoba Do każdego stanowiska pracy przydzielony jest jeden lub wielu pracowników.
4. Podmiot grupuje komórki organizacyjne, role i pełniące je osoby. Komórka organizacyjna grupuje podległe komórki organizacyjne, role (stanowiska), te są piastowane przez konkretne osoby.

[[1] Drzewo ? oznacza w teorii grafów graf, który jest acykliczny i spójny. Mówiąc językiem obrazowym, z każdego wierzchołka drzewa można dotrzeć do każdego innego wierzchołka (spójność) i tylko jednym sposobem (acykliczność, czyli brak możliwości chodzenia w “kółko”)].

Te definicje mają (taki jest także ich cel) ważną cechę: pojęcia (ich definicje) wzajemnie sę wykluczają ([[zasada wyłączonego środka]]), gwarantuje nam to w jednoznaczną interpretację diagramu. Kolejną ważną rzeczą jest uznanie zasady, że “Każde stanowisko może wystąpić  tylko raz i tylko w jednej komórce organizacyjnej”. Może się to wydawać kontrowersyjne ale to konsekwencja wymaganej (w dobrze zarządzanej organizacji) jednoznacznej odpowiedzialność (przypominam, że nazwa identyfikuje stanowisko wiec Kierownik Produkcji i Kierownik Sprzedaży to dwóch różnych kierowników podobnie jak Asystent Działu Sprzedaży i Asystent Działu Produkcji).

Po co to wszystko? Po pierwsze, jeżeli jakiś obrazek ma być modelem to powinien symulować (móc zastąpić) w określonym kontekście to co modeluje. Modelowana jest struktura komórek organizacyjnych jako elementów grupujących, w pewnym sensie są one [[przestrzeniami nazw]] np. DziałFinasowy/Dyrektor, tak więc wolno nawet użyć pojęcia Dyrektor wielokrotnie w modelu bo i tak każdy “Dyrektor” jest umieszczony w innym dziale i zachowujemy unikalność nazw.

Model struktury organizacyjnej w notacji UML

Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe wyobrażenie o rolach pracowników.

Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie  (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły),  na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Dodam, że traktowanie diagramu przypadków użycia właśnie jako modelu uprawnień w systemie jest nie mniej fałszywe.

Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa)  tego działu nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe.

W efekcie projektując oprogramowanie stosując metodę dziedziczenia dla aktorów systemu powielamy te nieprawdę w systemie co rodzi nie raz ogromne kłopoty. Nie przypadkiem w praktyce stosuje się metody macierzowe zarządzania prawami dostępu (niewydolne i nieskuteczne) lub kontekstowe (dużo lepsze).

Jeżeli już używać UML do modelowania struktury organizacyjnej, to raczej pakietów i związków użycia, reprezentujących “relację” usługobiorca-usługodawca.

Jest to jedna z możliwych konwencji, jednak modelowanie struktury organizacyjnej w UML, jak widać, wymaga użycia profilu dla aktorów (stereotypy).   Osobiście uważam, że modelowanie struktury organizacyjnej w UML nie jest dobrym pomysłem i odradzam to zawsze. Są do tego “prostsze” narzędzia, nie przypadkiem te lepsze narzędzia CASE mają do tego dedykowany diagram. Niestety nie ma tu dedykowanej notacji, dlatego bardzo ważne jest by słownik pojęć w modelu zawierał takie pojęcia jak pracownik, komórka organizacyjne itp. Dobrym pomysłem jest zdefiniowanie własnej konwencji (diagram, symbole, definicje pojęć) np. jak ta na początku artykułu.

Tym razem o pewnej książce: [[Business modeling David M. Bridgeland, Ron Zahavi]]. Najpierw cytat:

A business model is a simple representation of the complex reality of a business. The primary purpose of a business model is to communicate something about the business to other people, to employees, customers, partners, or suppliers. A business model can be analyzed, for example to understand the impacts of a change. A model can be simulated, showing how things change over time, and supporting experimentation with different alternative future changes. And some models can be executed by software applications, allowing models created by business modelers to substitute for code created by software engineers. (Business modeling ? Bridgeland and Zahavi on Business Modeling).

Ta książka spadła mi z nieba. Własnie tak. W pracy nad doktoratem utrwala mi się obraz, jaki prezentuje od kilku lat na moich autorskich szkoleniach: model organizacji to nie tylko model procesu czy danych. Model organizacji, czyli to co ją tworzy i decyduje o tym jak reaguje na rynek, to kompleks składający się z ludzi, reguł jakim podlegają w pracy oraz tego czym “obracają” w swojej pracy czyli informacja: dokumenty i ich treść, zarówno ta formalna jak i nieformalna czyli wykorzystywana a nie utrwalana. Mamy więc strukturę organizacyjną, prawo i wewnętrzne zarządzenia i ludzi z ich umiejętnościami i obowiązkami.

A gdzie procesy? Hm… a ile firm ma je w postaci udokumentowanej?

Często jestem pytany o to, po co modelować procesy biznesowe. Na stronach wielu firm doradczych i wdrożeniowych można znaleźć w treści oferty, modelowanie procesów biznesowych. Niemalże żadna nie zawiera informacji: po co.

Nie raz tu pisałem, że woda płynie z góry na dół zgodnie z ukształtowaniem terenu a nie odwrotnie. Obserwując firmę z boku, widać, że pracuje i to nie raz bardzo sprawnie, więc po co te modele.

Model procesu biznesowego nie jest nam do niczego potrzebny do czasu, gdy nie chcemy w niego ingerować.

 Tu znowu pora na jeden z moich ulubionych cytatów:

Modelowanie przedsiębiorstwa stwarza dobrą możliwość analizy oraz kształtowania procesów działania. Dzięki temu można uniknąć problemów przy wprowadzaniu zmian. (Hubert H. Zimmermann).

To kwintesencja celu modelowania biznesowego: zanim zaczniemy ingerować w żywy organizm, jakim jest każda organizacja, warto opracować jego model i na nim “ćwiczyć” planowane zmiany. Dlaczego? Bo ryzyko, że “coś pójdzie nie tak” jest bardzo duże.

Tu dopiero pojawia się problem: czym jest model organizacji? Jaki musi być, by faktycznie model pokazał jak w przyszłości zareaguje organizacja na konkretne, planowane zmiany.

Nauka mówi dość jasno: aby przewidywać reakcje badanego przedmiotu należy zrozumieć jak funkcjonuje i opracować jego model. Po drodze należy udowodnić, prawdziwość modelu.

Model organizacji to: opis motywacji jej działania, opis ludzi, jacy realizują wewnętrzne zadania, opis reguł jakie regulują ich zachowaniami. Całość (model) powinna być na tyle uporządkowana, by model był w 100% jednoznaczny, czyli kluczowe pojęcia w nim użyte powinny być zebrane w jeden wewnętrzny, spójny biznesowy słownik tej organizacji. To wszystko dopiero pozwoli stworzyć model procesów biznesowych, czyli wewnętrzne scenariusze zachowania.

Samo utworzenie map (bo nie modeli) w postaci diagramów procesów z pomocą wywiadów, sesji warsztatowych i obserwacji, da produkt podobny do zdjęcia lotniczego rzeki: wiemy którędy płynie,  ale kompletnie nie rozumiemy dlaczego akurat tak. Mamy jedynie udokumentowany stan obecny.

Ingerencja w ten stan rzeczy, bez zrozumienia reguł rządzących tym jak i którędy płynie woda, kończy się nie raz katastrofami jakie znamy z doniesień o powodziach i zalaniach ostatnich  lat. Bez poznania zasad rządzących zachowaniem się organizacji można “nie uniknąć problemów przy wprowadzaniu zmian”.

Każda reorganizacja, a w szczególności jest nią wdrażanie nowego oprogramowania, jest taką zmianą. Ta książka jest o modelowaniu organizacji. Model taki ma cztery zasadnicze, powiązane z sobą obszary, z kórych żaden nie jest samowystarczalny:

Mamy na nim: słownik pojęć (Glossary), model struktury organizacyjnej, reguły biznesowe (specyfikacja) oraz model procesów biznesowych korzystający z trzech poprzednich. Całość stanowi dopiero kompletny model organizacji.

Niedawno mój serdeczny kolega napisał:

Samo zebranie wymagań to ważny etap. Schody zaczynają się jednak dalej. Trzeba zweryfikować pozyskane wymagania, uszczegółowić, nadać priorytety. Gdzie te schody? […] Nie mamy w Polsce standardu dokumentowania projektów. Czegoś na co można się powołać. (Inżynieria wymagań ? certyfikat | Michał Wolski).

jak to mówią “święte słowa”. Jednak mamy standard dokumentowania wymagań, który można wykorzystać. Jaki? Moje początkowe opory do stosowania “kolejnej notacji” były jednak chyba przesadzone. SysML to obiektowe (w sensie paradygmatu) rozszerzenie UML. Pomijając kwestie samej notacji, jeden z jej diagramów, diagram wymagań, pozwala na uporządkowanie “listy wymagań”. To jednak mała zaleta. Dużą zaletą jest spójność pojęciowa z metodami obiektowymi, ale może dosyć “trudnych terminów”.

Wymagania  to hierarchiczna lista “oczekiwań wobec potrzebnego rozwiązania”. Zobrazowanie listy wymagań na diagramie pomaga pokazać wzajemne związki pomiędzy wymaganiami oraz związki wymagań z następnymi elementami projektu takimi jak testy odbiorcze i elementy modelu opisujące realizacje tych wymagań:

Powyższy diagram pozwala po pierwsze “zobaczyć” wymagania, po drugie pokazuje związki tych wymagań z produktami kolejnych kroków projektu. Po co? Przede wszystkim sprawdzimy, że te związki są, że są spójne i kompletne (nie brakuje żadnego). Zapewne wielu z Was woli postać tabeli:

i słusznie, do czytania jak najbardziej ale ta tabela, gdyby powstała jako jedyna, nie pozwoli na weryfikację kompletności implementacji wymagań i testów.

Cechy wymagań to bardzo  ważne elementy zarządzania wymaganiami, zalecam stosowanie:

1. Priorytet:
   1. najwyższy (np. 3.) – niespełnienie tego wymagania czyni rozwiązanie całkowicie nieprzydatnym do celu w jakim powstaje
   2. średni (np. 2.) – niespełnienie tego wymagania powoduje ograniczenie przydatności rozwiązania
   3. niski (np. 1.) – niespełnienie tego wymagania pogorszy jakość korzystania z rozwiązania
2. Status:
   1. Zgłoszone
   2. Uznane
   3. Odrzucone (ale nie usunięte)
3. Źródło:
   1. analiza (dokumentów, procesów, inne samodzielne efekty pracy analityka)
   2. osoba (konkretne źródło informacji po stronie analizowanej organizacji)
4. Rodzaj (te na różnych etapach):
   1. biznesowe
   2. wobec rozwiązania
      1. funkcjonalne
      2. jakościowe
      3. dziedzinowe

(więcej o klasyfikacji wymagań)

Mamy IEEE 830-1998, który opisuje dokumentowanie wymagań. Często się mówi, że wymagania mają być FURPS i SMART ale jak to osiągnąć? Pomaga w tym nie rysunek a model, czyli nie tylko zobrazowanie ale także interpretowanie.

Osobna kwestią jest to jak pozyskujemy wymagania. Mogą to być wywiady, sesje JAD itp. Ja osobiście jestem zwolennikiem analiz dokumentów, a potem wyjaśniam je i ich role  z wykonawcami procesów, ale o tym już było (i nie raz pewnie będzie ;)).

Na koniec ważna rzecz: nie wolno utracić panowania nad szczegółami, których nie powinno być zbyt wiele…

Gdyby ktoś zapytał: a po co kolejny diagram, odpowiem: model to system obiektów, ich powiązań i cech. Ani tabela ani tym bardziej ilustrowany obrazkami tekst nam tego nie da, a bez tych powiązań nie sprawdzimy ani kompletności wymagań ani tego czy ich implementacja jest spójna.

Aha, ile tych diagramów ma być? Nie za wiele, ale muszą być dobre? jak książeczka do gry w szachy a do niej opis czego oczekujemy od naszych szachistów? (Ile tego ma być ? analiza i model procesów biznesowych).