Modelowanie przed­się­bior­stwa stwa­rza dobrą moż­li­wość ana­li­zy oraz kształ­to­wa­nia pro­ce­sów dzia­ła­nia. Dzięki temu moż­na unik­nąć pro­ble­mów przy wpro­wa­dza­niu zmian. (Hubert H. Zimmermann).

• Produkt: Spójna, kom­plet­na i nie­sprzecz­na doku­men­ta­cja opi­su­ją­ca stra­te­gię orga­ni­za­cji, pro­ce­sy biz­ne­so­we i pro­ce­du­ry oraz powią­za­ne z nimi zaso­by IT (model orga­ni­za­cji jako jej cyfro­wy bliźniak). 
• Korzyść: Możliwość zapre­zen­to­wa­nia part­ne­rom biz­ne­so­wym zwię­złe­go opi­su dzia­ła­nia. Możliwość prze­ka­za­nia nowym pra­cow­ni­kom spój­nej i czy­tel­nej infor­ma­cji o ich roli, obo­wiąz­kach i moż­li­wo­ściach. Możliwość wyko­na­nia natych­mia­sto­we­go stu­dium wyko­nal­no­ści dowol­nej decy­zji orga­ni­za­cyj­nej, tak­że doty­czą­cej wdro­że­nia nowe­go sys­te­mu IT lub zmian w już ist­nie­ją­cym. Skutkiem jest obni­że­nie kosz­tów ope­ra­cyj­nych i obni­że­nie ryzyk z tytu­łu wpro­wa­dza­nia zmian. Świadome zarzą­dza­nie cią­gło­ścią dzia­ła­nia. Aktualna doku­men­ta­cja pro­ce­sów biz­ne­so­wych i pro­ce­dur dostęp­na ad-hoc i on-line. 

Jeżeli budże­to­wa­nie i rapor­to­wa­nie zwa­ne con­trol­lin­giem, poma­ga w bie­żą­cym zarzą­dza­niu finan­sa­mi, to aktu­al­ny model pro­ce­sów i sys­te­mów IT tak samo poma­ga w zarzą­dza­niu pozo­sta­łym obsza­rem firmy.

Cyfrowy bliźniak organizacji

Czy masz aktu­al­ny model pro­ce­sów biz­ne­so­wych? Uporządkowane pro­ce­du­ry? Czy wiesz gdzie, jaki i do cze­go sys­tem infor­ma­tycz­ny jest uży­wa­ny? Czy wiesz jaki mają wza­jem­nie na sie­bie wpływ? Czy wiesz jakie ryzy­ka i gdzie, są dla Ciebie naj­groź­niej­sze? Czy masz plan postę­po­wa­nia na wypa­dek gdy ryzy­ko z zagro­że­nia sta­nie się fak­tem? Czytaj wię­cej o Cyfrowy bliź­niak pro­ce­sów i sys­te­mu IT.

Cyfrowy bliź­niak (ang. digi­tal twin), to poję­cie jako nazwa i kon­cep­cja, zosta­ło uży­te i powsta­ło w 2002 roku (przy­pi­sy­wa­na Michaelowi Grievesowi, wów­czas z Uniwersytetu Michigan, w 2002 r.). W lite­ra­tu­rze pod tą nazwą poja­wia się od ok. 2016 roku. Cyfrowe bliź­nia­ki są wyni­kiem cią­głe­go dosko­na­le­nia w two­rze­niu pro­jek­tów pro­duk­tów i dzia­łań inży­nie­ryj­nych: prze­szły dro­gę od ręcz­ne­go kre­śle­nia rysun­ków pro­duk­tów i spe­cy­fi­ka­cji inży­nier­skich, przez kom­pu­te­ro­wo wspo­ma­ga­ne pro­jek­to­wa­nie, do inży­nie­rii sys­te­mów opar­tej na modelach.

Jednak tak na praw­dę poję­cie odwzo­ro­wa­nia rze­czy­wi­sto­ści w posta­ci jej mode­lu oraz zalet i ogra­ni­czeń tego podej­ścia, opi­sa­no znacz­nie wcze­śniej, bo już w 1985 roku:

Powyższy sche­mat blo­ko­wy obra­zu­je ideę pole­ga­ją­ca na odwzo­ro­wa­niu rze­czy­wi­sto­ści w posta­ci kom­pu­te­ra . Nie cho­dzi tu jed­nak o peł­ną symu­la­cję jako np. obraz 3D, celem jest opra­co­wa­nie odwzo­ro­wa­nia (model) okre­ślo­nej rze­czy­wi­sto­ści, pozwa­la­ją­ce­go np. na podej­mo­wa­nie bie­żą­cych decy­zji doty­czą­ce orga­ni­za­cji i firm, bo model, i jego imple­men­ta­cja w posta­ci kom­pu­te­ra, jest dosko­na­łym narzę­dziem prze­wi­dy­wa­nia: model zacho­wu­je się tak jak rze­czy­wi­stość (albo nie jest jej mode­lem), jest więc narzę­dziem pre­dyk­cji. Ogólnie mozna to przed­sta­wić tak:

Kluczem mode­lo­wa­nia jest jed­nak zro­zu­mie­nie a nie obserwacja:

Modelowanie pole­ga na abs­tra­ho­wa­niu od okre­ślo­nych szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm, gdyż opis obser­wo­wal­nych zmian sta­nów ?maszy­ny? nie jest mode­lem jej działania.

Model czym więc jest? Odwzorowaniem w okre­ślo­nym kon­tek­ście, w nauce defi­nio­wa­ny jest jako:

abs­trak­cyj­na kon­struk­cja wyra­żo­na wzo­ra­mi mate­ma­tycz­ny­mi, sche­ma­tem blo­ko­wym lub algo­ryt­mem, opi­su­ją­ca mecha­nizm zacho­wa­nia się okre­ślo­nej rze­czy­wi­sto­ści (sys­te­mu) i wyja­śnia­ją­ca te zachowania

Dlatego model orga­ni­za­cji, opra­co­wa­ny na potrze­by podej­mo­wa­nia decy­zji, to nie zapis obser­wa­cji i wywia­dów, to wynik ana­li­zy dokumentów.

Poprawny i aktu­al­ny model pro­ce­sów biz­ne­so­wych orga­ni­za­cji to jej cyfro­wy bliź­niak, a powią­za­ny z nim model sys­te­mu IT, to cyfro­wy bliź­niak klu­czo­wych zaso­bów infor­ma­cyj­nych wspie­ra­ją­cych jej działanie.

Bardzo cie­ka­we i twór­cze (ale to nie pierw­szy taki pomysł) zasto­so­wa­nie tej defi­ni­cji to two­rze­nie tak zwa­ne­go ​„cyfro­we­go bliźniaka”.

„Cyfrowy bliź­niak (ang. digi­tal twin) to okre­śle­nie wir­tu­al­nej repli­ki ist­nie­ją­cych już obiek­tów, pro­duk­tów, pro­ce­sów czy sys­te­mów. Model jest wła­ści­wie połą­cze­niem fizycz­ne­go obiek­tu oraz jego cyfro­we­go odwzorowania”

źr.: https://​gisplay​.pl/​g​i​s​/​1​0​1​6​5​-​p​o​w​s​t​a​n​i​e​-​c​y​f​r​o​w​y​-​b​l​i​z​n​i​a​k​-​p​o​r​t​u​-​g​d​y​n​i​a​.​h​tml

Rozwiązania tego typu to np. sys­te­my zarzą­dza­nia infra­struk­tu­rą, sta­no­wią­ce model infra­struk­tu­ry, sto­so­wa­ne np. jako sys­tem utrzy­ma­nia ruchu (bra­łem udział w takim pro­jek­cie dla KGHM).

Ale powyż­sze doty­czy zakła­dów prze­my­sło­wych. Ja ​„Cyfrowego bliź­nia­ka” budu­ję czę­sto dla moich klien­tów: jest to model pro­ce­sów biz­ne­so­wych i prze­pły­wu infor­ma­cji spię­ty z mode­lem sys­te­mów IT. Do cze­go tu słu­ży? Do podej­mo­wa­nia decy­zji o jakich­kol­wiek zmia­nach orga­ni­za­cyj­nych, do pro­wa­dze­nia ana­liz wpły­wu np. skut­ków prze­cią­że­nia pra­cą jakie­goś wydzia­łu, zarzą­dza­nia ryzy­kiem utra­ty wydol­no­ści np. przed pod­pi­sa­niem umo­wy sil­nie obcią­żą­ją­cej zaso­by fir­my. Taki model jest jak ​„stra­żak”: sta­le aktu­al­ny i goto­wy do uży­cia, uży­wa­ny rzad­ko ale jak już poja­wi się taka potrze­ba, odpo­wia­da na pyta­nia Zarządu w sekundę.

Z takim mode­lem decy­zje o jakich­kol­wiek zmia­nach w pro­ce­sach, zmia­nach w sys­te­mie IT czy wręcz o jego wymia­nie na inny (ana­li­za wyma­gań), to już nie są kolej­ne żmud­ne ana­li­zy, to kwe­stia kil­ku­na­stu minut na wyge­ne­ro­wa­nie kon­tek­sto­we­go rapor­tu i prze­pro­wa­dze­nia Analizy Wpływu na resz­tą pla­no­wa­nej zmiany.

Metody

Analiza mate­ria­łów źró­dło­wych i współ­pra­ca z inte­re­sa­riu­sza­mi biz­ne­so­wy­mi w całym przed­się­bior­stwie, w celu zma­po­wa­nia i prze­pro­jek­to­wa­nia pro­ce­sów biz­ne­so­wych wokół potrzeb klientów/użytkowników koń­co­wych. Oparcie się na dowo­dach (arte­fak­ty: doku­men­ty ope­ra­cyj­ne, pra­wo, regu­la­cje wewnętrz­ne) w celu obiek­ty­wi­za­cji pro­ce­su modelowania.

Najpierw dowiedz­my się ​„jak jest i dla­cze­go jest tak jak jest” a potem napisz­my ​„jak powin­no być i co nale­ży uczy­nić, aby było tak jak być powinno” 

„Każda fir­ma, nie­za­leż­nie od tego, jakie fizycz­ne towa­ry lub usłu­gi wytwa­rza, opie­ra się na doku­men­ta­cji han­dlo­wej. Musi ona zapi­sy­wać szcze­gó­ły to, co wytwa­rza w posta­ci kon­kret­nych infor­ma­cji. Artefakty biz­ne­so­we są mecha­ni­zmem zapi­su tych infor­ma­cji w jed­nost­kach, któ­re są kon­kret­ne, iden­ty­fi­ko­wal­ne, samo­opi­su­ją­ce się i nie­po­dziel­ne.”

https://​ieeexplo​re​.ieee​.org/​a​b​s​t​r​a​c​t​/​d​o​c​u​m​e​n​t​/​5​3​8​6​806

„W cią­gu ostat­nich kil­ku lat, coraz więk­sze wyma­ga­nia sta­wia­ne są efek­tyw­nym podej­ściom do pro­jek­to­wa­nia, mode­lo­wa­nia i wdra­ża­nia mię­dzy­or­ga­ni­za­cyj­nych pro­ce­sów biz­ne­so­wych. W pro­ce­sie współ­pra­cy ponad gra­ni­ca­mi orga­ni­za­cyj­ny­mi, orga­ni­za­cje nadal pozo­sta­ją auto­no­micz­ne, co ozna­cza, że każ­da z nich może dowol­nie mody­fi­ko­wać swo­je wewnętrz­ne ope­ra­cje, aby osią­gnąć swo­je pry­wat­ne cele, jed­no­cze­śnie speł­nia­jąc wza­jem­ne cele swo­ich part­ne­rów. Ostatnio udo­wod­nio­no, że mode­lo­wa­nie pro­ce­sów skon­cen­tro­wa­ne na arte­fak­tach zapew­nia więk­szą ela­stycz­ność w mode­lo­wa­niu i reali­za­cji pro­ce­sów niż tra­dy­cyj­ne meto­dy mode­lo­wa­nia skon­cen­tro­wa­ne na odkry­wa­nych działaniach.” 

https://​www​.scien​ce​di​rect​.com/​s​c​i​e​n​c​e​/​a​r​t​i​c​l​e​/​a​b​s​/​p​i​i​/​S​0​3​0​6​4​3​7​9​1​4​0​0​1​264

Dlatego od wie­lu lat z powo­dze­niem sto­su­ję meto­dy pro­wa­dze­nia audy­tu i ana­li­zy opar­te na dowo­dach (arti­fact-cen­tric para­digm, evi­den­ce-based ana­ly­sis), są to meto­dy opie­ra­ją­ce się przede wszyst­kim na fak­tach (arti­fact-cen­tric para­digm), wywia­dy są jedy­nie uzu­peł­nie­niem .

Jest to etap pro­jek­tów o naj­więk­szym ryzy­ku dotrzy­ma­nia ter­mi­nu reali­za­cji, gdyż na tym eta­pie poziom nie­wie­dzy o bada­nej orga­ni­za­cji jest naj­więk­szy (audyt słu­ży wła­śnie pozy­ska­niu tej wie­dzy). Dlatego jako kry­te­rium ukoń­cze­nia prac przyj­mu­je się: albo wyko­rzy­sta­nie cza­su prze­zna­czo­ne­go na opra­co­wa­nie mode­li meto­dą ​„od ogó­łu do szcze­gó­łu” (ter­min jako kry­te­rium odbio­ru), albo wypra­co­wa­nie zapla­no­wa­ne­go zakre­su audy­tu (zakres jako kry­te­rium odbio­ru). Decyzje podej­mu­je Zamawiający roz­po­czy­na­jąc projekt. 

Modelowanie

Zdolność czło­wie­ka do pano­wa­nia nad zło­żo­no­ścią cze­goś ma swo­je gra­ni­ce. Modelowanie umoż­li­wia zawę­że­nie licz­by deta­li pro­ble­mu, któ­ry roz­wią­zu­je­my. Dzięki mode­lo­wa­niu zwięk­sza­my moż­li­wo­ści ludz­kie­go inte­lek­tu. Właściwy wybór mode­lu uła­twia pra­ce na wyż­szym pozio­mie abstrakcji.

Typowe błę­dy popeł­nia­ne na wcze­snych eta­pach projektów:

1. pró­by umiesz­cza­nia na mode­lach wszystkiego
2. pró­by roz­wią­zy­wa­nia pro­ble­mów na nie­wła­ści­wym poziomie
3. brak sto­so­wa­nia narzę­dzi lub uży­wa­nie narzę­dzi nie­wła­ści­wych lub nie­ade­kwat­nych do problemu

Przygotowując się do utwo­rze­nia Architektury Biznesowej (cyfro­we­go bliź­nia­ka pro­ce­sów) zbie­ra­ne są wyłącz­nie dane, któ­rych posia­da­nie jest uza­sad­nio­ne w pro­jek­cie. Im wię­cej danych tym trud­niej zapew­nić i utrzy­mać ich jakość. 

Przez mode­lo­wa­nie, two­rze­nie cyfro­we­go bliź­nia­ka pro­ce­sów biz­ne­so­wych (the digi­tal twin of the busi­ness pro­cess model, ) osią­ga­my trzy klu­czo­we cele:

1. Łatwiej może­my wyobra­zić sobie orga­ni­za­cję taką, jaka jest, lub taką, jaką chce­my żeby była.
2. Modelowanie umoż­li­wia wyspe­cy­fi­ko­wa­nie struk­tu­ry i zacho­wa­nia orga­ni­za­cji w reak­cji na zda­rze­nia wewnątrz i na zewnętrz organizacji.
3. Modele sta­no­wią tak­że doku­men­ta­cję pod­ję­tych przez nas decy­zji, pozwa­la tak­że na bez­piecz­ne podej­mo­wa­nie nowych.

Audyt orga­ni­za­cji pro­wa­dzo­ny jest na pod­sta­wie ist­nie­ją­cych doku­men­tów aktu­al­nej war­stwy imple­men­ta­cji. Optymalizacja i stan­da­ry­za­cja pro­ce­sów odby­wa­ją się na pozio­mie mode­lu pro­ce­sów biz­ne­so­wych. Strategię two­rzy Zarząd orga­ni­za­cji a imple­men­ta­cję zmian reali­zu­je wyko­naw­ca opra­co­wa­ne­go roz­wią­za­nia jako nową war­stwę implementacji. 

Poziomy opisu organizacji

Poniżej zobra­zo­wa­no zakres usłu­gi czy­li obszar mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Poprawnie opra­co­wa­ne mode­le pro­ce­sów biz­ne­so­wych to model dzia­ła­nia orga­ni­za­cji zwa­ny tak­że wewnętrz­nym łań­cu­chem wartości:

Prostym mier­ni­kiem wła­ści­we­go pozio­mu szcze­gó­ło­wo­ści mode­li pro­ce­sów biz­ne­so­wych jest czas potrzeb­ny na zapo­zna­nie się z prze­bie­giem jed­ne­go pro­ce­su: albo jest to 5 minut, albo doku­ment jest zbyt szcze­gó­ło­wy by poma­gał w bie­żą­cych ope­ra­cyj­nych decy­zjach w toku zarządzania. 

Strategia Opis stra­te­gii róż­nych for­mach ma każ­da organizacja. 

Procedury Szablony doku­men­tów, zarzą­dze­nia, instruk­cje sta­no­wi­sko­we, zakre­sy obo­wiąz­ków. To tak­że w róż­nych for­mach organ­zi­cje mają.

Model pro­ce­sów biz­ne­so­wych To abs­trak­cja (sche­ma­ty blo­ko­we jako mode­le) opi­su­ją­ca mecha­nizm dzia­ła­nia orga­ni­za­cji: doku­ment o obję­to­ści kil­ku­dzie­się­ciu opi­su­ją­cy całą orga­ni­za­cje, łatwy do uży­cia przy podej­mo­wa­niu decy­zji o wpro­wa­dza­niu zmian .

W więk­szo­ści orga­ni­za­cji pierw­szy i trze­ci poziom jest udo­ku­men­to­wa­ny. Istnienie tych doku­men­tów jest kon­se­kwen­cją wymo­gów i ryn­ku i pra­wa, np. zakre­sy obo­wiąz­ków w umo­wach o pra­cę i kon­trak­tach czy postę­po­wa­nie z dowo­da­mi księ­go­wy­mi i ich postać), a czę­sto tak­że efek­tem wdro­żo­nych sys­te­mów zarzą­dza­nia jako­ścią (np. ISO9000). 

To cze­go wie­le orga­ni­za­cji nie ma, to wła­śnie mode­le: sche­ma­ty poka­zu­ją­ce pre­cy­zyj­nie co i kie­dy powsta­je w odpo­wie­dzi na bodź­ce z zewnątrz. W toku mode­lo­wa­nia i ana­li­zy pro­ce­sów biz­ne­so­wych mogą powstać reko­men­da­cje do zmian i stan­da­ry­za­cji tych dokumentów. 

Jednak ilość i dro­bia­zgo­wość danych na pozio­mie wewnętrz­nych deta­li pro­ce­sów biz­ne­so­wych (pro­ce­du­ry) jest zbyt duża do podej­mo­wa­nia stra­te­gicz­nych decy­zji, dla­te­go mode­le jako czy­sta logi­ka biz­ne­so­wa, są dosko­na­łą meto­dą jej opi­su. Poprzez odse­pa­ro­wa­nie logi­ki biz­ne­so­wej od deta­li pro­ce­sów biz­ne­so­wych zysku­je­my pro­sto­tę mode­li. Czym innym jest np. to kie­dy udzie­la­my komuś upu­stu (pro­ces), a czym innym to ile ten upust wynie­sie w danej sytu­acji (regu­ła jego nali­cze­nia) To dru­gie nie ma zna­cze­nia na pozio­mie stra­te­gii działania. 

Przedmiotem mojej usłu­gi jest opra­co­wa­nie, utrzy­my­wa­nie aktu­al­no­ści i udo­stęp­nia­nie na żąda­nie ww. mode­li z wyma­ga­nej w danym pro­ble­mie perspektywy.

Biznesowy model orga­ni­za­cji to repre­zen­ta­cja wyżej opi­sa­nych deta­li na takim pozio­mie, by moż­li­we było szyb­kie zapo­zna­nie się z tym «co» i «po co» jest robio­ne. Opis tego «jak» jest ogrom­nym zbio­rem doku­men­tów i nie da się z nimi pra­co­wać ope­ra­cyj­nie dzień w dzień, ale te deta­le są zawsze dostęp­ne na żąda­nie. Nazwa «biz­ne­so­wy» ozna­cza, że poziom szcze­gó­łów (ich licz­ba) pozwa­la pra­co­wać z nimi ​„na żywo”. 

Architektura Biznesowa

Pojęcie Architektury Biznesowej poja­wia­ło sie już w latach 90-tych . Były to pierw­sze pró­by stan­da­ry­za­cji metod pod­cho­dzą­cych cało­ścio­wo to zarzą­dza­nia orga­ni­za­cją i jej zaso­ba­mi infor­ma­cyj­ny­mi. Coraz powszech­niej poja­wia­ło sie poję­cie mode­lo­wa­nia (wię­cej o mode­lo­wa­niu czy­taj w: Analiza…).

Różne mode­le sta­no­wią sobą róż­ne per­spek­ty­wy spoj­rze­nia na orga­ni­za­cję. Pełna wie­dza o orga­ni­za­cji to kon­kret­ne mode­le łącz­nie, wraz z wie­dzą o wza­jem­nym ich wpły­wie na sie­bie , . Są to przede wszyst­kim struk­tu­ra orga­ni­za­cyj­na, pro­ce­sy biz­ne­so­we, model infor­ma­cyj­ny (struk­tu­ry doku­men­tów, słow­ni­ki pojęć), regu­ły biznesowe. 

Innymi sło­wy:

do podej­mo­wa­nia decy­zji orga­ni­za­cyj­nych, w tym tak­że o wdro­że­niach nowych tech­nik zarzą­dza­nia czy sys­te­mów infor­ma­tycz­nych, potrzeb­na jest wie­dza o tym gdzie i jakie nale­ży wpro­wa­dzić zmia­ny w orga­ni­za­cji oraz jakie kon­se­kwen­cje dla cało­ści spo­wo­du­je ich wpro­wa­dze­nie. (Analiza sys­te­mo­wa orga­ni­za­cji).

Potrzebna jest tak­że udo­ku­men­to­wa­na for­ma opi­su mecha­ni­zmu dzia­ła­nia całej orga­ni­za­cji, gdyż doku­ment taki sta­no­wi potem dosko­na­ły mate­riał dla dostaw­ców roz­wią­zań (opro­gra­mo­wa­nia i nowych tech­nik zarzą­dza­nia, patrz Enterprise Architecture as a Strategy) , tak­że .

Pod poję­ciem ana­li­zy biz­ne­so­wej orga­ni­za­cji, kry­je się w pierw­szym rzę­dzie ana­li­za doku­men­ta­cji jaką ona sama wytwa­rza (doku­men­ty ope­ra­cyj­ne, wzo­ry umów itp.). Powstaje tak­że Model Informacyjny.

Produkt tej ana­li­zy, to model biz­ne­so­wy czy­li pro­ce­sy i regu­ły biz­ne­so­we. Powinien on być ?spój­ny, kom­plet­ny i nie­sprzecz­ny?. Dokumentacja taka bar­dzo czę­sto powsta­je meto­dą ite­ra­cyj­no-przy­ro­sto­wą, czy­li ana­li­za pro­ble­mu i jego roz­wią­zy­wa­nie pro­ble­mu jest pro­wa­dzo­na jed­no­cze­śnie z podzia­łem na obsza­ry ana­li­zy (pew­ne obsza­ry są JESZCZE ana­li­zo­wa­ne a inne są JUŻ wdrażane). 

Formalizacja opisu strategii

Popatrzmy tu na samą doku­men­ta­cję stra­te­gicz­ną orga­ni­za­cji i jej treść. (wię­cej: Audyt spój­no­ści wizji i misji orga­ni­za­cji z jej dzia­ła­nia­mi | | Jarosław Żeliński IT-Consulting) . Na tym pozio­mie model ten pozwa­la zro­zu­mieć pozy­cje bada­nej orga­ni­za­cji na ryn­ku. Rynkowy model biz­ne­so­wy jako pierw­sza część ana­li­zy biz­ne­so­wej, sta­no­wi pod­sta­wę dal­szych, bar­dziej prac ana­li­tycz­nych (patrz wyżej: aksjo­mat). Jednak już na tym eta­pie jest on for­ma­li­zo­wa­ny z uży­ciem poniż­sze­go sys­te­mu nota­cyj­ne­go (nota­cja BMM):

Mapa i modele procesów biznesowych

Model pro­ce­sów biz­ne­so­wych ma za zada­nie wyspe­cy­fi­ko­wa­nie reali­zo­wa­nych wewnątrz zadań i ich efek­tów. Innymi sło­wy poka­zu­je pro­duk­ty pra­cy (opi­sa­ne z pomo­cą doku­men­tów) i kolej­ność ich powsta­wa­nia, łącz­nie z ewen­tu­al­ny­mi warian­ta­mi. Dlatego pro­ces biz­ne­so­wy defi­nio­wa­ny jest jako aktyw­ność (czyn­ność) two­rzą­ca pro­dukt biz­ne­so­wy, może ona wyma­gać okre­ślo­nych innych pro­duk­tów na swo­im wej­ściu. Atomowe pro­ce­sy (pary czynność/zadanie – produkt/dokument) sta­no­wią sobą tak­że ato­mo­we (ele­men­tar­ne) pro­ce­sy biznesowe. 

Model referencyjny

Podstawą (i począt­kiem) ana­li­zy jest tak zwa­na mapa pro­ce­sów end-to-end, czy­li pro­ce­sy ini­cjo­wa­ne infor­ma­cją z zewnątrz i wysy­ła­ją­ce wytwo­rzo­ne infor­ma­cje tak­że na zewnątrz. Tu, jako bazo­wy szkie­let, od wie­lu lat z powo­dze­niem sto­su­ję struk­tu­rę uzna­wa­ną za refe­ren­cyj­ną, któ­rą opi­sał M.Porter . 

Aktywności wspie­ra­ją­ce to stan­dar­do­we pro­ce­sy, nie raz regu­lo­wa­ne pra­wem. Nie mają one wpły­wu na kon­ku­ren­cyj­ność fir­my, jedy­nie na kosz­ty. Ten obszar z regu­ły nie jest mode­lo­wa­ny. Kluczowe dla firm są są głów­ne aktyw­no­ści, nazy­wa­ne czę­sto pro­ce­sa­mi ope­ra­cyj­ny­mi. To one są klu­czo­wym obsza­rem audy­tu i usprawnień. 

Mapa procesów operacyjnych

Do zobra­zo­wa­nia zakre­su audy­tu pro­ce­sów na tym eta­pie, bar­dzo czę­sto wyko­rzy­sty­wa­ny jest pro­sty zestaw sym­bo­li repre­zen­tu­ją­cych ode­bra­ne infor­ma­cje, powią­za­ne ze sobą pro­ce­sy, i infor­ma­cje wysła­ne. Przykładowa mapa zakre­su pro­jek­tu (tak zwa­ne pro­ce­sy end-to-end): 

Modele procesów

Każdy powyż­szy pro­ces biz­ne­so­wy jest mode­lo­wa­ny już w spo­sób bar­dziej sfor­ma­li­zo­wa­ny (np. z uży­ciem nota­cji BPMN). Poniżej sche­ma­tycz­nie poka­za­ny model pro­ce­su biz­ne­so­we­go wyko­na­ny z uży­ciem nota­cji BPMN.

Szczegóły reali­za­cji aktyw­no­ści (czyn­no­ści) w pro­ce­sach opi­su­je się z uży­ciem pro­ce­dur (instruk­cji sta­no­wi­sko­wych itp.), czy­li sfor­ma­li­zo­wa­nych opi­sów tego, jakie kolej­ne kro­ki nale­ży wyko­nać (np. z uży­ciem norm ISO, są to struk­tu­ral­ne tek­sty a nie dia­gra­my!). Uzupełnieniem mode­li pro­ce­sów biz­ne­so­wych są: słow­ni­ki pojęć, regu­ły biz­ne­so­we, macie­rze odpo­wie­dzial­no­ści (macierz RACI) oraz sza­blo­ny doku­men­tów sta­no­wią­cych pro­duk­ty pro­ce­sów (obiek­ty danych).

Procedury

Każda aktyw­ność na mode­lu pro­ce­sów (BPMN) repre­zen­tu­je albo okre­ślo­ną kom­pe­ten­cję lub umie­jęt­ność, albo pro­ce­du­rę. Procedury sta­no­wią sobą odręb­ne doku­men­ty. Zalecana i prak­ty­ko­wa­ną for­mą ich doku­men­to­wa­nia są struk­tu­ral­ne opi­sy lub tabele: 

Stosowanie gra­ficz­nej for­my doku­men­to­wa­nia takich deta­li, przy­po­mi­na­ją­ce sobą gra­fy algo­ryt­mów, jest kosz­tow­ne i nie­prak­tycz­ne (ludzie na co dzień i tak z nich nie korzy­sta­ją a pra­wo­daw­ca ocze­ku­je jed­nak tek­sto­wej for­my tre­ści umów) .

UWAGA! Procedury są zawsze przed­mio­tem audy­tu, jed­nak na tym eta­pie celem jest spraw­dze­nie ich ich spój­no­ści a nie ich doku­men­to­wa­nie (one albo są w bada­nej orga­ni­za­cji albo ich nie ma i nale­ży je stwo­rzyć). Tworzenie (kory­go­wa­nie) pro­ce­dur to odręb­ny etap: imple­men­ta­cja zale­ceń i opra­co­wa­nych roz­wią­zań, ana­lo­gicz­nie jak wdra­ża­nie zapro­jek­to­wa­nych sys­te­mów informatycznych. 

Kto i kie­dy powi­nien zając się naj­niż­szą war­stwą: deta­la­mi? To kon­kret­ne, mają­ce począ­tek i koniec, pro­jek­ty opty­ma­li­za­cji pole­ga­ją­ce na wdra­ża­niu np. sys­te­mu zarza­dza­nia jako­ścią ISO9000, Lean Management, Six Sigma, wdro­że­niu sys­te­mu ERP i wie­le innych. Robią to kadry mene­dżer­skie wspie­ra­ne przez wyspe­cja­li­zo­wa­ne firmy. 

Podsumowanie

Audyt opar­ty jest w 100% na fak­tach (ope­ra­cyj­ne doku­men­ty biz­ne­so­we) co daje nie­mal­że 100% dokład­ność audy­tu i wia­ry­god­ność. Stosowany jest tak zwa­ny «arti­fact-cen­tric busi­ness pro­cess models» . Więcej o mode­lo­wa­niu pro­ce­sów i pro­ce­dur w arty­ku­le: Procesy biz­ne­so­we a pro­ce­du­ry.

Architektura Korporacyjna – cyfrowy bliźniak organizacji

W XXI w. moż­na bez­piecz­nie zało­żyć, że: każ­da orga­ni­za­cja prze­twa­rza infor­ma­cje, i że każ­da orga­ni­za­cja robi to z pomo­cą tech­no­lo­gii infor­ma­tycz­nych (to dru­gi aksjo­mat, nie kwe­stio­nu­je­my tego fak­tu). Dlatego od pew­ne­go cza­su mode­le biz­ne­so­we (mode­le dzia­ła­nia orga­ni­za­cji) są uzu­peł­nia­ne o ele­men­ty tych tech­no­lo­gii. Modele takie są okre­śla­ne jako Architektura Korporacyjna i zawie­ra­ją dodat­ko­wo spe­cy­fi­ka­cję klu­czo­wych zaso­bów IT sko­ja­rzo­nych z pro­ce­sa­mi biz­ne­so­wy­mi. Architektura Korporacyjna to model orga­ni­za­cji obej­mu­ją­cy więc nie tyl­ko ludzi i pro­ce­sy biz­ne­so­we ale tak­że wspie­ra­ją­ce je sys­te­my infor­ma­tycz­ne. Nazywane są tu kom­po­nen­ta­mi orga­ni­za­cji, a każ­dy z nich reali­zu­je okre­ślo­ną funk­cję i ma okre­ślo­ną strukturę. 

Procesy biz­ne­so­we (Business Processes) są wspie­ra­ne usłu­ga­mi (Business Services), świad­czo­ny­mi użyt­kow­ni­kom przez okre­ślo­ne apli­ka­cje (Components). Całość jest utrzy­my­wa­na w śro­do­wi­sku IT (Operational Resources). Zobrazowano to na poniż­szym dia­gra­mie :

Każda dzi­siej­sza orga­ni­za­cja (o ile nie jest start-up’em) posia­da już okre­ślo­ną infra­struk­tu­rę IT. Dlatego mode­le pro­ce­sów biz­ne­so­wych nale­ży uzu­peł­nić wie­dzą o tym, jakie apli­ka­cje je wspie­ra­ją i to jest isto­ta Architektury Korporacyjnej: posia­da­nie peł­ne­go obra­zu orga­ni­za­cji i jej klu­czo­wych zasobów.

Do sku­tecz­ne­go, bie­żą­ce­go zarzą­dza­nia orga­ni­za­cją potrzeb­ny jest jej czy­tel­ny pro­sty opis (model). Większość orga­ni­za­cji posia­da opis stra­te­gii oraz deta­licz­ne opi­sy pro­ce­dur, zakre­sów obo­wiąz­ków, instruk­cje sta­no­wi­sko itp. Pierwszy jest zbyt ogól­ny dru­gi zbyt szcze­gó­ło­wy do podej­mo­wa­nia bie­żą­cych decy­zji. Opisany powy­żej model orga­ni­za­cji to kom­pro­mis mię­dzy tymi dwo­ma: abs­trak­cja ukry­wa­ją­ca deta­le ale poka­zu­ją­ca ​„jak dzia­ła­my”. Jeżeli takie­go mode­lu orga­ni­za­cja nie posia­da, to prak­tycz­nie każ­da decy­zja orga­ni­za­cyj­na: wdro­że­nie zmian orga­ni­za­cyj­nych lub opro­gra­mo­wa­nia, sta­no­wi samo­dziel­ny, nie­za­leż­ny, bar­dzo ryzy­kow­ny i kosz­tow­ny projekt.

Produkty i ich produkcja

Wdrożenie idei Digital Twins sta­ło się już powszech­nym zada­niem dla wie­lu firm prze­my­sło­wych w celu zapew­nie­nia ocze­ki­wa­nej cyfry­za­cji pro­duk­tów i utrzy­ma­nia kon­ku­ren­cyj­no­ści. W związ­ku z tym powsta­je pyta­nie, jakie korzy­ści daje dodat­ko­wy wysi­łek spo­wo­do­wa­ny pro­jek­to­wa­niem mode­li Digital Twins. Coraz czę­ściej wyko­rzy­sty­wa­ne są mode­le (dia­gra­my) z uży­ciem nota­cji SysML, a cza­sa­mi nawet bez­po­śred­nie wypro­wa­dze­nie z nich kodu użyt­ko­we­go do dal­szej imple­men­ta­cji. Pozwala to na obni­że­nie kosz­to­we­go pro­gu sto­so­wa­nia metod MBSE i zwięk­sze­nie korzy­ści pły­ną­cych z tego podej­ścia .

Typowe dla firm pro­duk­cyj­nych jest wdra­ża­niem sys­te­mów MES/APS oraz PLM (kolej­no: zarzą­dza­nie pro­duk­cja, pla­no­wa­nie pro­duk­cji oraz zarza­dza­nie cyklem życia pro­duk­tu). Rzecz w tym, że bez mode­li pro­duk­tów bar­dzo trud­ne jest je wdro­żyć bez ​„odkry­wa­nia wyma­gań” meto­dą prób i błę­dów. Opracowanie cyfro­we­go bliź­nia­ka (frag­ment na dia­gra­mie poni­żej) pozwa­la opra­co­wać kom­plet­ny i spój­ny opis pro­duk­tu na potrze­by CAM (struk­tu­ry pro­duk­tów oraz tak zwa­ne mBOM, BOM i technologie). 

Korzyści

Poniższy dia­gram obra­zu­je jed­ną z klu­czo­wych korzy­ści z posia­da­nia i utrzy­my­wa­nia mode­lu Architektury Korporacyjnej: jest nią sta­łe, niskie, ryczał­to­we obcią­że­nie (utrzy­ma­nie i roz­wój mode­li) zamiast sko­ko­we­go kosz­tu wyko­na­nia ana­li­zy wyma­gań czy przed­wdro­że­nio­wej, z zamia­rem prze­pro­wa­dze­nia nowe­go pro­jek­tu reor­ga­ni­za­cji czy zmian w sys­te­mie IT. Mając model orga­ni­za­cji moż­li­we jest sta­łe jej moni­to­ro­wa­nie i opty­ma­li­za­cja. Kluczowe jest moni­to­ro­wa­nie pro­ce­sów biz­ne­so­wych (pozio­me zależ­no­ści w orga­ni­za­cji) i moni­to­ro­wa­nie struk­tu­ry orga­ni­za­cyj­nej (zależ­no­ści pio­no­we). W efek­cie orga­ni­za­cja jest w sta­nie płyn­nie i ewo­lu­cyj­nie pod­no­sić efektywność. 

Stałe utrzy­ma­nie takie­go mode­lu jest wyma­ga­ne gdyż każ­da orga­ni­za­cja i wspie­ra­ją­ce ją opro­gra­mo­wa­nie roz­wi­ja­ją się sta­le jako jed­na całość: ewo­lu­cyj­ne i w peł­nej sym­bio­zie.^?2? Wprowadzenie jakiej­kol­wiek zmia­ny: out­so­ur­cing, fuzje, reor­ga­ni­za­cja i pod­no­sze­nie efek­tyw­no­ści, kolej­ne wdro­że­nie nowe­go opro­gra­mo­wa­nia i zmian orga­ni­za­cyj­nych, wyma­ga tu jedy­nie zapla­no­wa­nia sta­nu doce­lo­we­go oraz prze­ka­za­nie takiej doku­men­ta­cji dostaw­cy roz­wią­za­nia. Nie są potrzeb­ne już żad­ne kolej­ne kosz­tow­ne ana­li­zy przedwdrożeniowe.

Korzyścią z posia­da­nia mode­lu Architektury Korporacyjnej, jest tak­że posia­da­nie w posta­ci udo­ku­men­to­wa­nej całe­go know-how fir­my, bez cze­go nie ma moż­li­wo­ści praw­nej ochro­ny tego, co nazy­wa­my ​„tajem­ni­cą przed­się­bior­stwa” w obsza­rze metod działania.

Powyższe podej­ście coraz czę­ściej sta­je się stan­dar­dem w dobrze zarzą­dza­nych fir­mach, kon­ty­nu­ują­cych aktu­ali­za­cję doku­men­ta­cji powsta­łej na eta­pie ana­li­zy biz­ne­so­wej, jako sta­łe­go nad­zo­ru autor­skie­go. Powoli przy­by­wa tak­że firm, widzą­cych powyż­sze korzy­ści w bie­żą­cym zarzą­dza­niu. Dostrzegają tak­że to, że posia­da­nie aktu­al­nej udo­ku­men­to­wa­nej Architektury Biznesowej, jest efek­tyw­niej­sze niż zle­ca­ne ​„z dosko­ku” kolej­nych nowych, kosz­tow­nych ana­liz biz­ne­so­wych i przed-wdrożeniowych. 

Przykład reali­za­cji usłu­gi: Analiza i mode­lo­wa­nie pro­ce­sów biz­ne­so­wych, szko­le­nie kadry kie­row­ni­czej z zakre­su two­rze­nia map pro­ce­sów oraz sta­łe wspar­cie w reor­ga­ni­za­cji pro­ce­sów dla rodzi­ny spół­ek FCA Sp.z o.o. i ASCOMP Sp. z o.o., Umowa na wspar­cie ana­li­zy pro­ce­sów zarząd­czych i ich opty­ma­li­za­cję z Vision Express Sp. z .o.o., Analiza, mode­lo­wa­nie i opty­ma­li­za­cja funk­cjo­no­wa­nia fir­my EXTREM Sp. j., opra­co­wa­nie mode­lu wdro­że­nia sys­te­mu CRM, wspar­cie w nego­cja­cjach z dostaw­ca­mi, nad­zór nad reali­za­cją pro­jek­tu. (refe­ren­cje), Analiza biz­ne­so­wa, pro­jekt Architektury Korporacyjnej i spe­cy­fi­ka­cja wyma­gań na sys­tem IT dla INTAR Sp. z o.o., Analiza funk­cjo­no­wa­nia i pro­jekt stan­da­ry­za­cji pro­ce­dur utrzy­ma­nia ruchu KGHM SA Polska Miedź.

Źródła

Zapytanie