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 pro­ce­sy biz­ne­so­we i powią­za­ne zaso­by IT (model orga­ni­za­cji jako jej cyfro­wy bliźniak). 
  • Korzyść: 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 sys­te­mu IT. Skutkiem jest duże obni­że­nie kosz­tów ope­ra­cyj­nych, peł­ne zro­zu­mie­nie mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, prze­wi­dy­wal­ność wpły­wu na orga­ni­za­cję decy­zji o zmia­nach orga­ni­za­cyj­nych i wdro­że­niach opro­gra­mo­wa­nia. Świadome zarzą­dza­nie cią­gło­ścią dzia­ła­nia. Ad-hoc dostęp­na aktu­al­na doku­men­ta­cja pro­ce­sów biz­ne­so­wych i procedur. 

Wprowadzenie

Modelowanie pro­ce­sów to nie jest obraz­ko­wy zapis zeznań pra­cow­ni­ków.
Analiza biz­ne­so­wa to dopro­wa­dze­nie wie­dzy o orga­ni­za­cji do posta­ci spój­nej, kom­plet­nej i nie­sprzecz­nej jej doku­men­ta­cji.
Projektowanie roz­wią­zań to ulep­sza­nie a nie uła­twia­nie (bo to nie jest to samo!)

Problemy orga­ni­za­cyj­ne naj­czę­ściej doty­ka­ją zwo­len­ni­ków podej­ścia: u nas nie ma pro­ble­mów orga­ni­za­cyj­nych“. Tego rodza­ju poli­ty­ka opie­ra się na zało­że­niu, że to cze­go nie widać, nie ist­nie­je. Jest nie­ste­ty ina­czej. Ryzyka ist­nie­ją zawsze, tyl­ko nie zawsze się ujaw­nia­ją. To kry­zys dopie­ro jest tym momen­tem, któ­ry bez­li­to­śnie obna­ża wszyst­kie sła­be punk­ty organizacji.

Wsparcie w obsza­rze ana­li­zy biz­ne­so­wej i sys­te­mo­wej orga­ni­za­cji, anga­żo­wa­ne do poża­ru” (zle­ca­my ana­li­zę biz­ne­so­wą bo będzie wdro­że­nie, bo coś zmie­nia­my itp..), nie ma nic wspól­ne­go z zarzą­dza­niem ryzy­kiem. Dlatego zamiast zle­cać kolej­ne, od zera reali­zo­wa­ne, ana­li­zy ad-hoc bo jest pro­blem i będzie wdro­że­nie”, zapy­taj jak unik­nąć pro­ble­mów. Jest to trud­niej­sze, bo wyma­ga umie­jęt­no­ści zarzą­dza­nia ryzy­kiem. Jak uniknąć? 

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? Reasumując:

  • opisz cele spółki,
  • spo­rządź listę ryzyk zagra­ża­ją­cych tym celom,
  • usze­re­guj ryzy­ka sto­sow­nie do wiel­ko­ści wpły­wu wywie­ra­ne­go na organizację,
  • podej­mij decy­zje co do postę­po­wa­nia z poszcze­gól­ny­mi ryzy­ka­mi (akcep­ta­cja, wyko­rzy­sta­nie do reali­za­cji celów, zmniej­sze­nie praw­do­po­do­bień­stwa, likwi­da­cja źró­dła, podział ryzyka)
  • wpro­wadź plan postę­po­wa­nia z ryzykiem.

Ryzyka orga­ni­za­cyj­no-zarząd­cze ana­li­zu­je­my mapu­jąc je na model orga­ni­za­cji: model pro­ce­sów biz­ne­so­wych i powią­za­nych z nimi zaso­bów IT (UWAGA! W przy­pad­ku sys­te­mów infor­ma­cyj­nych, jed­nym z klu­czo­wych ryzyk jest ryzy­ko praw­ne w obsza­rze ochro­ny know-how i praw autorskich). 

Ale naj­pierw trze­ba ten model mieć i aktu­ali­zo­wać. Nieudane wdro­że­nia sys­te­mów infor­ma­tycz­nych to kla­sycz­ny przy­pa­dek ryzy­ka, któ­re z groź­by prze­szło do faktów…

Cyfrowy bliźniak organizacji

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:

Komputer (w nauce kom­pu­ter defi­nio­wa­ny jest jako pro­ce­sor, pamięć i pro­gram łącz­nie) jako cyfro­wy bliź­niak rzeczywistości.

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. 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 abs­trak­cja opi­su­ją­ca mecha­nizm dzia­ła­nia organizacji.

Cyfrowy bliź­niak (model pro­ce­sów biz­ne­so­wych połą­czo­ny z mode­lem infra­struk­tu­ry IT) i jego rola w pro­ce­sie zarządzania.

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 .

Sposób pro­wa­dze­nia audy­tów i mode­lo­wa­nia pro­ce­sów biz­ne­so­wych (opr. wła­sne autora)

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. 

Biznesowy model 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 to rola orga­ni­za­cji na ryn­ku. Innymi sło­wy, na tym eta­pie nie kwe­stio­nu­je­my tego co i komu fir­ma ofe­ru­je i dostar­cza. Opis stra­te­gii ma każ­da orga­ni­za­cja, pozo­sta­je jedy­nie jej sfor­ma­li­zo­wa­nie: tu uży­wa­my sys­te­mu poję­cio­we­go (nota­cji) Business Motivation Model (BMM, misja, wizja fir­my, stra­te­gia itd.). 

Model pro­ce­sów biz­ne­so­wych to wewnętrz­ne łań­cu­chy nazwa­nych zadań oraz ich pro­duk­ty (prak­tycz­nie są to zawsze doku­men­ty). Tu uży­wa­my sys­te­mu poję­cio­we­go i nota­cji Business Process Modeling & Notation (BPMN) odno­si­my się do sza­blo­nów doku­men­tów i pro­ce­dur. Powstaje tak­że sfor­ma­li­zo­wa­ny model struk­tu­ry orga­ni­za­cyj­nej (oso­bo­wy lub działowy). 

Procedury, sza­blo­ny doku­men­tów, zarzą­dze­nia, instruk­cje sta­no­wi­sko­we, zakre­sy obo­wiąz­ków itp. to naj­pierw źró­dło­we mate­ria­ły do opra­co­wa­nia powyż­szych mode­li pro­ce­sów, a potem przed­miot ewen­tu­al­nych reko­men­da­cji do ich zmian. Na tym pozio­mie doku­men­ty two­rzą kadry kie­row­ni­cze orga­ni­za­cji, ana­li­tyk je otrzy­mu­je jako mate­riał źródłowy!

W więk­szo­ści orga­ni­za­cji trze­ci, naj­niż­szy poziom jest udo­ku­men­to­wa­ny. Istnienie tych doku­men­tów jest kon­se­kwen­cją wymo­gów 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). 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. 

To cze­go wie­le orga­ni­za­cji nie ma, to wła­śnie mode­le pro­ce­sów biz­ne­so­wych: 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. Treści pro­ce­dur i zakre­sów obo­wiąz­ków (naj­niż­sza war­stwa powyż­szej powyż­szej pira­mi­dy) to imple­men­ta­cje tych celów i zadań (patrz tak­że arty­kuł Modele as-is i to-be, czy war­to je robić?).

UWAGA! Górny i środ­ko­wy poziom, czy­li abs­trak­cyj­ne mode­le dzia­ła­nia (mecha­ni­zmy). Powinny być przed­mio­tem ana­liz poprze­dza­ją­cych jaki­kol­wiek wybór roz­wią­zań i sys­te­mów IT. Wymaganiem np. na sys­tem ERP, są wyni­ki tej ana­li­zy: okre­ślo­ne cele orga­ni­za­cji i wybra­ne do uspraw­nie­nia pro­ce­sy biz­ne­so­we. Dopiero mając te wyma­ga­nia ma sens roz­po­czę­cie szu­ka­nia roz­wią­za­nia i jego dostaw­cy. I dopie­ro dostaw­ca, w swo­jej kon­cep­cji wdro­że­nia, zapro­po­nu­je i wdro­ży deta­le, czy­li będzie dzia­łał w war­stwie imple­men­ta­cji. Przedmiotem mojej usłu­gi jest opra­co­wa­nie ww. mode­li, co opi­sa­no w dal­szej części.

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). 

Strategia rynkowa

Rynkowy model biz­ne­so­wy to rola orga­ni­za­cji na ryn­ku. W wer­sji poglą­do­wej moż­na przed­sta­wić go tak:

Analityczny model łań­cu­cha war­to­ści ryn­ko­we (opr. wła­sne autora)

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

Łańcuch wartości M.E.Porter
Wewnątrzny łań­cuch war­to­ści M.E.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.

Model pro­ce­su biz­ne­so­we­go wyko­na­ny jako dia­gram BPMN: każ­dy ele­men­tar­ny pro­ces jest repre­zen­to­wa­ny przez parę aktyw­ność i jej pro­dukt. Każda aktyw­ność ma udo­ku­men­to­wa­ną pro­ce­du­rę jej reali­za­cji, np. w posta­ci doku­men­ta­cji pro­ce­dur ISO, lub w innej for­mie (listy kon­tro­l­ne, instruk­cje sta­no­wi­sko­we, itp.). (opr. wła­sne autora)

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: 

Przykłady spo­so­bów doku­men­to­wa­nia pro­ce­dur (opr. wła­sne autora)

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ą struk­tu­rę. Kluczowe poję­cia archi­tek­tu­ry kor­po­ra­cyj­nej moż­na zobra­zo­wać jak poniżej:

(na pod­sta­wie )

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.

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ść. 

architektura korporacyjna rentowność
Koszty opra­co­wa­nia i utrzy­ma­nia mode­lu archi­tek­tu­ry kor­po­ra­cyj­nej orga­ni­za­cji: obec­nie tem­po zmian powo­du­je, że zwrot kosz­tów nastę­puj w toku dru­gie­go pro­jek­tu wdra­ża­nia jakich­kol­wiek zmian. (opr. wła­sne autora)

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

Andrzej Sobczak. (2011, gru­dzie). Czym jest archi­tek­tu­ra kor­po­ra­cyj­na? https://​www​.archi​tek​tu​ra​kor​po​ra​cyj​na​.pl/​n​o​d​e/4
Arsanjani, A., & Corporation, I. (2005). Service-orien­ted mode­ling and archi­tec­tu­re How to iden­ti­fy, spe­ci­fy, and reali­ze servi­ces for your SOA. 16.
Bouzidi, A., Haddar, N., & Haddar, K. (2019). Traceability and Synchronization Between BPMN and UML Use Case Models. Ingénierie Des Systèmes d Information, 24(2), 215 – 228. https://​doi​.org/​1​0​.​1​8​2​8​0​/​i​s​i​.​2​4​0​214
Cabanillas, C., Resinas, M., & Ruiz-Cortés, A. (2012). Automated Resource Assignment in BPMN Models Using RACI Matrices. In R. Meersman, H. Panetto, T. Dillon, S. Rinderle-Ma, P. Dadam, X. Zhou, S. Pearson, A. Ferscha, S. Bergamaschi, & I. F. Cruz (Eds.), On the Move to Meaningful Internet Systems: OTM 2012 (Vol. 7565, pp. 56 – 73). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 33606-5_5
Cohn, D., & Hull, R. (2009). Business arti­facts: A data-cen­tric appro­ach to mode­ling busi­ness ope­ra­tions and pro­ces­ses. IEEE Data Eng. Bull., 32(3), 3 – 9.
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Dorrer, M. G. (2020). The digi­tal twin of the busi­ness pro­cess model. Journal of Physics: Conference Series, 1679(3), 032096. https://​doi​.org/​1​0​.​1​0​8​8​/​1​742 – 6596/1679/3/032096
Dyba, T., Kitchenham, B. A., & Jorgensen, M. (2005). Evidence-based softwa­re engi­ne­ering for prac­ti­tio­ners. IEEE Software, 22(1), 58 – 65. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​5.6
Karagiannis, D., Mayr, H. C., & Mylopoulos, J. (Eds.). (2016). Domain-Specific Conceptual Modeling: Concepts, Methods and Tools (1st ed. 2016). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 39417‑6
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Kühne, T. (2006). Matters of (Meta-) Modeling. Software & Systems Modeling, 5(4), 369 – 385. https://doi.org/10.1007/s10270-006‑0017‑9
Machamer, P., Darden, L., & Craver, C. F. (2000). Thinking abo­ut mecha­ni­sms. Philosophy of Science, 67(1), 1 – 25.
McDavid, D. W. (1999). A stan­dard for busi­ness archi­tec­tu­re descrip­tion. IBM Systems Journal, 38(1), 12 – 31. https://​doi​.org/​1​0​.​1​1​4​7​/​s​j​.​3​8​1​.​0​012
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Nigam, A., & Caswell, N. S. (2003). Business arti­facts: An appro­ach to ope­ra­tio­nal spe­ci­fi­ca­tion. IBM Systems Journal, 42(3), 428 – 445. https://​doi​.org/​1​0​.​1​1​4​7​/​s​j​.​4​2​3​.​0​428
OMG​.org. (2015, April). Business Motivation Model (BMM). https://​www​.omg​.org/​s​p​e​c​/​B​MM/
OMG​.org. (2012, May). Service Oriented Architecture Modeling Language (SoaML). https://​www​.omg​.org/​s​p​e​c​/​S​o​a​M​L​/​A​b​o​u​t​-​S​o​a​ML/
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
Reynolds, C. (2010). Introduction to busi­ness archi­tec­tu­re. Course Technology PTR.
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a gene­ral the­ory of plan­ning. Policy Sciences, 4(2), 155 – 169. https://​doi​.org/​1​0​.​1​0​0​7​/​B​F​0​1​4​0​5​730
Ross, jean­ne W., Weill, P., & Robertson, D. C. (2010). Architektura kor­po­ra­cyj­na jako stra­te­gia. Studio EMKA.
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512
Sobczak, A. (2009). Wstęp do Architektury Korporacyjnej (B. Szafrański, Ed.). Wojskowa Akademia Techniczna.
Yongchareon, S., liu, C., Yu, J., & Zhao, X. (2015). A view fra­me­work for mode­ling and chan­ge vali­da­tion of arti­fact-cen­tric inter-orga­ni­za­tio­nal busi­ness pro­ces­ses. Information Systems, 47, 51 – 81. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​s​.​2​0​1​4​.​0​7​.​004
Żeliński, J. (2017). Analiza biz­ne­so­wa: prak­tycz­ne mode­lo­wa­nie orga­ni­za­cji (Grupa Wydawnicza Helion, Ed.). Wydawnictwo Helion.
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Zapytanie