Pisząc recenzję książki Modelowanie biznesowe napisałem, że kompletny model organizacji to:

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.

W Listopadzie ubiegłego roku także pisałem o modelowaniu struktury organizacyjnej.

Osobiście uważam, że modelowanie struktury organizacyjnej w UML nie jest dobrym pomysłem. 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. (Modelowanie struktury organizacyjnej).

Są widoki by ten brak został uzupełniony. OMG pracuje nad formalnym metamodelem ([[Organisation Structure Metamodel]]) do modelowania struktur organizacyjnych. Specyfikacja jeszcze nie została opublikowana, jest na etapie RFP, ale mamy przecieki :).

Ogólnie szkielet tego metamodelu ma następującą postać:

Powyższy diagram  przedstawia profil czyli model pojęciowy, który może służyć do budowy diagramu struktury organizacyjnej. Powyższe pojęcia to system stereotypów, czyli “znaczników”. Przykładowy schemat struktury organizacyjnej z użyciem tych stereotypów mógłby mieć poniższą postać (diagram większe są dzielone na podrzędne struktury):

Kilka słów komentarza. Szkieletem każdej takiej struktury jest system komórek organizacyjnych. Ta część z reguły nie budzi wątpliwości i nie stwarza problemów, do czasu gdy zachowuje drzewiastą strukturę (każdy ma tylko jednego przełożonego). Problemem pojawia się, gdy zaczynamy mówić o kompetencjach, rolach i funkcjach osób zajmujących poszczególne stanowiska i próbie modelowanie funkcjonowania organizacji.

Typowym problemem, z jakim spotykam się pomagając tworzyć lub audytując modele procesów biznesowych czy np. analizy ciągłości działania, jest mapowanie ról w procesach na strukturę organizacyjną oraz zarządzanie kompetencjami.

Mamy tu do czynienia z problemem jakim jest to, że jedną rolę w procesie może pełnić wiele osób (stanowisk). Klasyką jest np. to, że fakturę może wystawić nie tylko Fakturzysta ale np. każdy pracownik działu księgowości i dyr. sprzedaży. Porażką “modelarza” będzie narysowanie diagramu, na którym będzie, dla każdego z powyższych stanowisk, dedykowany tor w procesie i jakaś “logika bramek” pokazująca kiedy kto wystawi tę fakturę. Z drugiej strony z reguły nieprawdą jest, że nikt poza fakturzystą nie może wystawić faktury. Wystarczy jednak stworzyć “bloczek” Rola lub Kompetencje (zależnie od sytuacji)->Wystawianie faktur i skojarzyć z właściwymi stanowiskami, a bloczek ten dopiero mapować na role w procesach. Uzyskamy dzięki temu “prawdziwszy” model, uzyskujemy możliwość jednoznacznego mapowania (śladowanie: <<trace>>) elementów struktury organizacyjnej na model procesów biznesowych, być może na model dziedziny. Możliwe stanie się testowanie poprawności modelu.

Praktycznie żaden diagram struktury organizacyjnej, jaki można spotkać w dokumentach większości firm i spółek, nie nadaje się do niczego poza ilustrowaniem dokumentów w jakich jest umieszczany. Nie ma w tym nic złego, do czasu gdy nie dochodzi do analizy funkcjonowania takiej organizacji.

Ktoś zapyta: po co te zabawy, komu to przeszkadza? Odpowiedź jest prosta: diagram, który nie pozwala na analizę zależności, analizę wpływu, testowanie jednoznaczności nie jest żadnym modelem, nie jest przydatny do analizy. Można nim co najwyżej ładnie zilustrować dokumenty ale na pewno nie nadaje się do analizy a przypomnę, że:

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.

Zaś:

Samo utworzenie map (bo nie modeli) w postaci diagramó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.

Tak więc, jeżeli analiza ma posłużyć wdrożeniu jakiegokolwiek oprogramowania czy zmian organizacyjnych, to pomogą nam w tym tylko modele a nie “obrazki”…

Na konferencjach i forach toczą się stale dyskusje na ten temat. Większość firm doradczych, informatycznych oraz ich analitycy bronią tezy, że celem analizy jest zebranie informacji w postaci dokumentów i zestawień. Niestety takie dokumenty są kompletnie  nieprzydatne, mają wartość nagrania (patrz wyżej zdjęcie lotnicze), nie da się na ich postawie wyciągać żadnych pozwalających na dowodzenie ich słuszności, wniosków nie licząc może oceny estetyki edytorskiej.

Wiele się pisze o tym, że modelowanie służy do dokumentowania projektów. Otóż nie. Do dokumentowania projektów służy rysowanie, modelowanie służy do prowadzenia analiz poprzez testy modeli, symulacje i analizę scenariuszy. (Sabotaż dokumentacyjny).

Niewątpliwą zaletą takiej pisanej obrazkowej “analizy” jest to, że nie wymaga ona absolutnie żadnych kompetencji poza umiejętnością komunikacji. Takim analitykiem może być niemalże każdy (łatwa rekrutacja, niski koszt), ale czy taki jest cel analiz poprzedzających projekty, warte setki tysięcy złotych a nie raz miliony?

Na zakończenie dodam, że najgorszym sposobem jaki znam i jaki niestety często spotykam, na modelowanie struktury organizacyjnej, jest użycie diagramu klas lub diagramu przypadków użycia i modelowanie z zastosowaniem dziedziczenia (klas lub aktorów).

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 i stosując metodę dziedziczenia dla aktorów systemu powielamy te nieprawdę w systemie co rodzi nie raz ogromne kłopoty. (Modelowanie struktury organizacyjnej).

Na zakończenie polecam ciekawy artykuł na temat modelowania ról w oprogramowaniu.