Dzisiaj mała (być może) nie­spo­dzian­ka. Bardzo czę­sto mówi­my o tym, że ana­li­za biz­ne­so­wa każe nam” mode­lo­wać pro­ce­sy biz­ne­so­we by zro­zu­mieć co i jak robi dana orga­ni­za­cja. Bywa, że pró­ba mode­lo­wa­nia pro­ce­sów koń­czy się mon­stru­al­ną ilo­ścią dia­gra­mów pro­ce­sów bo klient” zawsze ma jesz­cze w zana­drzu kolej­ny, inny spo­sób zała­twie­nia spra­wy”. To pro­wa­dzi czę­sto do tak zwa­nej utra­ty pano­wa­nia nad zło­żo­no­ścią projektu”.

Przypomnę, że (wśród wie­lu) mamy dwa para­dyg­ma­ty wg. któ­rych moż­na two­rzyć mode­le orga­ni­za­cji. Najczęściej sto­so­wa­ny jest para­dyg­mat pro­ce­so­wy. Paradygmat pro­ce­so­wy zakła­da, że świat moż­na przed­sta­wić (mode­lo­wać) jako zacho­dzą­ce pro­ce­sy prze­kształ­ca­nia lub two­rze­nia rzeczywistości.

Modelowanie orga­ni­za­cji z pomo­cą pro­ce­sów zakła­da, że zna­my wszyst­kie (lub głów­ne) zda­rze­nia na jakie orga­ni­za­cja reagu­je, i potra­fi­my prze­wi­dzieć (lub narzu­cić) pro­ce­sy (łań­cuch wyda­rzeń) jakie one zaini­cju­ją. Niestety nie zawsze jest to moż­li­we. Bywa, że nasze zor­ga­ni­zo­wa­ne zaso­by reagu­ją dyna­micz­nie na ota­cza­ją­ca rze­czy­wi­stość, nie wie­my jako to się sta­nie, ale potra­fi­my narzu­cić (żądać) ocze­ki­wa­ny efekt.

Modelowanie pro­ce­sów ma sens tam, gdzie mamy do czy­nie­nia z zarzą­dza­niem zorien­to­wa­nym na pro­ce­sy. Jeżeli z jakie­goś powo­du orga­ni­za­cja dzia­ła w spo­sób zorien­to­wa­ny na samo­dziel­ność i kom­pe­ten­cje, brnię­cie w model pro­ce­sów poni­żej” mode­li end-to-end pro­wa­dzi do ogrom­nej, nie­koń­czą­cej się licz­by moż­li­wych sce­na­riu­szy. Zaryzykuje tezę, że to nie ma żad­ne­go sensu.

Wtedy war­to przejść na para­dyg­mat obiek­to­wy mode­lo­wa­nia sys­te­mu jakim jest orga­ni­za­cja. Paradygmat obiek­to­wy zakła­da, że ota­cza­ją­ca nas rze­czy­wi­stość to współ­pra­cu­ją­ce ze sobą obiek­ty, reali­zu­ją­ce wspól­ny (narzu­co­ny) cel.

Popatrzmy na dział han­dlo­wy, wie­le orga­ni­za­cji daje dużą swo­bo­dę pra­cow­ni­kom tych dzia­łów. Reagują w spo­sób zależ­ny od zasta­nej sytu­acji, ogra­ni­cze­nia jakie mają, to regu­ły pra­cy narzu­co­ne przez prze­ło­żo­nych, Ci zaś mogą korzy­stać z zade­kla­ro­wa­nych w umo­wach o pra­ce, umie­jęt­no­ściach swo­ich pod­wład­nych i współpracowników.

Wyobraźmy sobie Dział Handlowy. Nieduża fir­ma: Asystent DH, Sprzedawcy i Dyrektor Handlowy. Dział dys­po­nu­je wie­dzą o tym co sprze­da­je, jakie doku­men­ty i dla kogo wytwo­rzył oraz wie­dzą o tym jakich reguł ma przestrzegać.

Aby opra­co­wać model tego dzia­łu nale­ży użyć goto­we­go lub opra­co­wać na uży­tek tego mode­lu, dedy­ko­wa­ny model poję­cio­wy (name­spa­ce, prze­strzeń nazw). Organizacje, w któ­rych klu­czo­wym zaso­bem są ludzie oraz to co wie­dzą i potra­fią, moż­na mode­lo­wać wła­śnie jako sys­tem ele­men­tów repre­zen­tu­ją­cych wie­dzę i umie­jęt­no­ści. Skorzystajmy, po raz kolej­ny, ze słow­ni­ka języ­ka pol­skie­go PWN:

wie­dza: zasób infor­ma­cji z jakiejś dziedziny

umie­jęt­ność: prak­tycz­na zna­jo­mość cze­goś, bie­głość w czymś

Podstawą defi­ni­cji sys­te­mu jest jego gra­ni­ca. Z wie­lu powo­dów war­to wyod­ręb­nić w sys­te­mie ele­men­ty łączą­ce sys­tem z jego oto­cze­niem. Nie ma takie­go obo­wiąz­ku ale dobrą prak­ty­ką jest wyod­ręb­nie­nie ele­men­tów, któ­rych jedy­nym zada­niem jest kon­takt sys­te­mu z jego oto­cze­niem (sepa­ru­ją one wła­ści­wy sys­tem od jego oto­cze­nia). Analogicznie ma to miej­sce z nami: nasze zmy­sły słu­żą wyłącz­nie do prze­ka­zy­wa­nia bodź­ców do wnę­trza, jest to ich jedy­na rola. My oddzia­łu­je­my na oto­cze­nie tym co wytwo­rzy­my (co robimy).

Tak więc ana­li­zu­jąc dział jakiejś hipo­te­tycz­nej orga­ni­za­cji, np. pla­nu­jąc okre­śle­nie wyma­gań na sys­tem CRM, uzna­je­my ten dział za odręb­ny sys­tem do ana­li­zy, two­rzy­my jego model, upew­nia­my się, że zro­zu­mie­li­śmy jak dzia­ła. W toku ana­li­zy roz­kła­da­my dział na han­dlo­wy na trzy typy ele­men­tów: obiek­ty repre­zen­tu­ją­ce umie­jęt­no­ści, repre­zen­tu­ją­ce wie­dzę i ten sepa­ru­ją­ce sys­tem od jego otoczenia:

Dział Handllowy jako System

Jeżeli jesz­cze ktoś nie wyczuł pod­stę­pu to niniej­szym infor­mu­ję, że powyż­szy dia­gram to dia­gram klas nota­cji UML. Jego cechą jest to, że kla­sy z odpo­wied­ni­mi ste­reo­ty­pa­mi, zosta­ły przed­sta­wio­ne z pomo­cą ikon, repre­zen­tu­ją­cych te ste­reo­ty­py. Zgodnie z UML, linie prze­ry­wa­ne z gro­tem repre­zen­tu­ją związ­ki uży­cia (grot wska­zu­je na uży­ty obiekt), aso­cja­cje z peł­nym rom­bem to kom­po­zy­cje (zwią­zek całość część). Trzy opi­sa­ne poję­cia (gra­ni­ca, umie­jęt­ność, wie­dza) to pro­fil uży­ty do stwo­rze­nia tego mode­lu (dia­gra­mu). Czy taki dia­gram, jak powy­żej, jest zro­zu­mia­ły dla biznesu?

Po co to? Powyższy dia­gram to model as-is nasze­go Działu han­dlo­we­go. Teraz wystar­czy okre­ślić, jego nową postać, prze­te­sto­wać efek­ty: skut­ki ewen­tu­al­nych zmian. Jeżeli oka­że się, że reko­men­do­wa­nym roz­wią­za­niem jest nowe opro­gra­mo­wa­nie, może­my w mode­lu to-be okre­ślić, któ­re jego obiek­ty zosta­ną odwzo­ro­wa­ne w posta­ci opro­gra­mo­wa­nia (doj­dzie kolej­na kla­sa na dia­gra­mie), i któ­re umie­jęt­no­ści zosta­ną prze­su­nię­te z ludzi na oprogramowanie.

Tylko… czy­li cze­ka nas żmud­na i nie łatwa ana­li­za 🙂 sys­te­mo­wa tego działu.

A po co dia­gra­my? Nie lep­szy tekst, jak do tej pory? Mając takie mode­le, może­my pano­wać nad: spój­no­ścią, kom­plet­no­ścią, nie­sprzecz­no­ścią, pro­wa­dzić ana­li­zy wpły­wu, wypro­wa­dzić model dzie­dzi­ny sys­te­mu, i inne czy­li zamiast meto­dą prób i błę­dów pra­co­wać na opro­gra­mo­wa­niem lub reor­ga­ni­za­cją, mar­no­wać czas i środ­ki na kolej­ne pró­by, może­my od razu w spo­sób prze­my­śla­ny i bez­piecz­ny, zapro­jek­to­wać nowy lub zmie­nio­ny system.

Mam tak­że nadzie­ję, że tu widać wyraź­nie, że mode­lo­wa­nie dzie­dzi­ny sys­te­mu w posta­ci klas połą­czo­nych z pomo­cą pro­stych opi­sa­nych licz­no­ścia­mi aso­cja­cji itp., to nie model obiek­to­wy a nie­udol­na atra­pa bazy danych, któ­ra z para­dyg­ma­tem obiek­to­wym nie wie­le ma wspólnego.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.