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ć:
- co jest na wejściu procesu,
- co jest jego produktem,
- kto jest wykonawcą czynności/procesu,
- 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):
- Podmiot – każda organizacja skupiająca ludzi i zasoby niezależnie od jej formy prawnej.
- 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ą).
- Osoba Do każdego stanowiska pracy przydzielony jest jeden lub wielu pracowników.
- 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.
