Dzisiaj mała (być może) niespodzianka. Bardzo często mówimy o tym, że analiza biznesowa “każe nam” modelować procesy biznesowe by zrozumieć co i jak robi dana organizacja. Bywa, że próba modelowania procesów kończy się monstrualną ilością diagramów procesów bo “klient” zawsze ma jeszcze w zanadrzu “kolejny, inny sposób załatwienia sprawy”. To prowadzi często do tak zwanej “utraty panowania nad złożonością projektu”.

Przypomnę, że (wśród wielu)  mamy dwa paradygmaty wg. których można tworzyć modele organizacji. Najczęściej stosowany jest paradygmat procesowy. Paradygmat procesowy zakłada, że świat można przedstawić (modelować) jako zachodzące procesy przekształcania lub tworzenia rzeczywistości.

Modelowanie organizacji z pomocą procesów zakłada, że znamy wszystkie (lub główne) zdarzenia na jakie organizacja reaguje, i potrafimy przewidzieć (lub narzucić) procesy (łańcuch wydarzeń) jakie one zainicjują. Niestety nie zawsze jest to możliwe. Bywa, że nasze zorganizowane zasoby reagują dynamicznie na otaczająca rzeczywistość, nie wiemy jako to się stanie, ale potrafimy narzucić (żądać) oczekiwany efekt.

Modelowanie procesów ma sens tam, gdzie mamy do czynienia z zarządzaniem zorientowanym na procesy.  Jeżeli z jakiegoś powodu organizacja działa w sposób zorientowany na samodzielność i kompetencje, brnięcie w model procesów “poniżej” modeli end-to-end prowadzi do ogromnej, niekończącej się liczby możliwych scenariuszy. Zaryzykuje tezę, że to nie ma żadnego sensu.

Wtedy warto przejść na paradygmat obiektowy modelowania systemu jakim jest organizacja. Paradygmat obiektowy zakłada, że otaczająca nas rzeczywistość to współpracujące ze sobą obiekty, realizujące wspólny (narzucony) cel.

Popatrzmy na dział handlowy, wiele organizacji daje dużą swobodę pracownikom tych działów. Reagują w sposób zależny od zastanej sytuacji, ograniczenia jakie mają, to reguły pracy narzucone przez przełożonych,  Ci zaś mogą korzystać z zadeklarowanych w umowach o prace,  umiejętnościach swoich podwładnych i współpracowników.

Wyobraźmy sobie Dział Handlowy. Nieduża firma: Asystent DH, Sprzedawcy i Dyrektor Handlowy. Dział dysponuje wiedzą o tym co sprzedaje, jakie dokumenty i dla kogo wytworzył oraz wiedzą o tym jakich reguł ma przestrzegać.

Aby opracować model tego działu należy użyć gotowego lub opracować na użytek tego modelu, dedykowany model pojęciowy (namespace, przestrzeń nazw).  Organizacje, w których kluczowym zasobem są ludzie oraz to co wiedzą i potrafią, można modelować właśnie jako system elementów reprezentujących wiedzę i umiejętności. Skorzystajmy, po raz kolejny, ze słownika języka polskiego PWN:

wiedza: zasób informacji z jakiejś dziedziny

umiejętność: praktyczna znajomość czegoś, biegłość w czymś

Podstawą definicji systemu jest jego granica. Z wielu powodów warto wyodrębnić w systemie elementy łączące system z jego otoczeniem. Nie ma takiego obowiązku ale dobrą praktyką jest wyodrębnienie elementów, których jedynym zadaniem jest kontakt systemu z jego otoczeniem (separują one właściwy system od jego otoczenia). Analogicznie ma to miejsce z nami: nasze zmysły służą wyłącznie do przekazywania bodźców do wnętrza, jest to ich jedyna rola. My oddziałujemy na otoczenie tym co wytworzymy (co robimy).

Tak więc analizując dział jakiejś hipotetycznej organizacji, np. planując określenie wymagań na system CRM, uznajemy ten dział za odrębny system do analizy, tworzymy jego model, upewniamy się, że zrozumieliśmy jak działa. W toku analizy rozkładamy dział na handlowy na trzy typy elementów: obiekty reprezentujące umiejętności, reprezentujące wiedzę i ten separujące system od jego otoczenia:

Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy z odpowiednimi stereotypami, zostały przedstawione z pomocą ikon, reprezentujących te stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt), asocjacje z pełnym rombem to kompozycje (związek całość część). Trzy opisane pojęcia (granica, umiejętność, wiedza) to profil użyty do stworzenia tego modelu (diagramu). Czy taki diagram, jak powyżej, jest zrozumiały dla biznesu?

Po co to? Powyższy diagram to model as-is naszego Działu handlowego. Teraz wystarczy określić, jego nową postać, przetestować efekty: skutki ewentualnych zmian. Jeżeli okaże się, że rekomendowanym rozwiązaniem jest nowe oprogramowanie, możemy w modelu to-be określić, które jego obiekty zostaną odwzorowane w postaci oprogramowania (dojdzie kolejna klasa na diagramie), i które umiejętności zostaną przesunięte z ludzi na oprogramowanie.

Tylko… czyli czeka nas żmudna i nie łatwa analiza 🙂 systemowa tego działu.

A po co diagramy? Nie lepszy tekst, jak do tej pory? Mając takie modele, możemy panować nad: spójnością, kompletnością, niesprzecznością, prowadzić analizy wpływu, wyprowadzić model dziedziny systemu, i inne czyli zamiast metodą prób i błędów pracować na oprogramowaniem lub reorganizacją, marnować czas i środki na kolejne próby, możemy od razu w sposób przemyślany i bezpieczny, zaprojektować nowy lub zmieniony system.

Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych opisanych licznościami asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.