Jeżeli cze­goś nie potra­fisz nary­so­wać, to zna­czy, że nadal tego nie rozu­miesz, jeże­li coś jest trud­ne do nary­so­wa­nia, to tym bar­dziej będzie to trud­ne do realizacji.

(JarosŁaw Żeliński)

Wprowadzenie

Podstawowe poję­cie w obsza­rze pro­fe­sjo­nal­nych ana­liz i pro­jek­to­wa­nia to sto­so­wa­ne w nauce poję­cie mecha­nizm” . Po co i kie­dy uży­wa­my tego poję­cia? Mechanizmów poszu­ku­je się w celu wyja­śnie­nia, jak powsta­je jakieś zja­wi­sko lub jak dzia­ła jakiś istot­ny pro­ces.” . Innymi sło­wy ana­li­zu­jąc lub pro­jek­tu­jąc sys­te­my, odpo­wied­nio odkry­wa­my lub pro­jek­tu­je­my mecha­ni­zmy ich dzia­ła­nia. Ważna uwa­ga: sys­tem to nie tyl­ko sys­tem infor­ma­tycz­ny”, sys­te­mem jest każ­de urzą­dze­nie, każ­da orga­ni­za­cja, każ­de pań­stwo. To co nazy­wa­my sys­te­mem infor­ma­tycz­nym”, bar­dzo rzad­ko jest samo­dziel­nym systemem. 

Kluczowym eta­pem ana­li­zo­wa­nia lub pro­jek­to­wa­nia sys­te­mu jest zro­zu­mie­nie i usta­le­nie, czym ten sys­tem jest, gdzie są jego gra­ni­ce, oraz na co i jak reagu­je. System infor­ma­tycz­ny z zasa­dy jest jedy­nie pod­sys­te­mem orga­ni­za­cji, któ­ra go uży­wa. Dlatego moż­na ana­li­zo­wać orga­ni­za­cję pomi­ja­jąc sys­tem infor­ma­tycz­ny (Computation Independent Model), ale nie moż­na zapro­jek­to­wać sys­te­mu infor­ma­tycz­ne­go nie mając popraw­ne­go mode­lu orga­ni­za­cji w jakiej będzie używany. 

Rynek

Bardzo popu­lar­ną meto­dą pro­wa­dze­nia ana­liz są spo­tka­nia, wywia­dy i warsz­ta­ty. Czy to sku­tecz­ne? Wywiady i warsz­ta­ty z pra­cow­ni­ka­mi bada­nej orga­ni­za­cji dadzą infor­ma­cje o tym, jak oni sobie wyobra­ża­ją to co robią, z naci­skiem na sytu­acje wyjąt­ko­we (incy­den­ty), bo te dłu­żej zapa­da­ją w pamięć. 

Wykazano, że wyni­kiem takiej ana­li­zy są jedy­nie nie­kom­plet­ne i nie­spój­ne zapi­sa­ne wyobra­że­nia, nie raz bar­dzo dale­kie od rze­czy­wi­sto­ści . Taki model z zasa­dy jest zły, a na jego pod­sta­wie nie da się zapro­jek­to­wać i sku­tecz­nie wdro­żyć, ade­kwat­ne­go do potrzeb orga­ni­za­cji, sys­te­mu ERP. 

Więc jak ina­czej? Oprzeć się na fak­tach, dowo­dach rze­czo­wych” jaki­mi są tu doku­men­ty ope­ra­cyj­ne. To ana­li­za tre­ści doku­men­tów, a nie roz­mo­wy, da obraz tego jak orga­ni­za­cja dzia­ła na praw­dę. Praktyka poka­zu­je, że nie jest też praw­dą, że orga­ni­za­cje tych doku­men­tów nie mają lub mają ich mało… (bo co więc mają w swo­ich wiel­kich sza­fach, szu­fla­dach i na dys­kach komputerów?)

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ż sam zapis obser­wo­wal­nych zmian sta­nów ?maszy­ny? nie jest mode­lem jej działania.

Dlatego w toku ana­li­zy sto­su­ję zna­ne i sto­so­wa­ne meto­dy opar­te na fak­tach oraz mode­le opra­co­wa­ne nauko­wy­mi meto­da­mi .

Metodyka pracy

Samo to, że nauczy­my się kogoś naśla­do­wać nie wystar­czy, aby sku­tecz­nie dzia­łać trze­ba zro­zu­mieć mecha­nizm tego dzia­ła­nia. Zrozumieć zaś ozna­cza umieć narysować? .”

Często moż­na spo­tkać ofer­ty sto­so­wa­nia autor­skiej meto­dy­ki wraz z tezą, że jest lep­sza i sku­tecz­niej­sza o zna­nych stan­dar­dów. Trudno obro­nić taką tezę. Stosowanie autor­skich metod ana­liz i mode­lo­wa­nia to odci­na­nie się od porów­nań, stan­dar­dów i cał­ko­wi­te uza­leż­nia­nie się od ich auto­ra. Uważam, że to nie­uczci­we, dla­te­go meto­dy i narzę­dzia pra­cy jakie sto­su­ję, to nie jest moja meto­dy­ka”, to zestaw stan­dar­do­wych, zna­nych, dostęp­nych i sku­tecz­nych narzę­dzi. Moim wkła­dem jest tu ich dobór i upo­rząd­ko­wa­nie. Pełny opis jest dostęp­ny w recen­zo­wa­nej publi­ka­cji nauko­wej: Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns .

Celowo opra­co­wa­łem powyż­szą stan­da­ry­za­cję jako publi­ka­cją nauko­wą, by pod­dać ją ostrej kry­ty­ce innych (IGI Global ma potrój­ny sys­tem recen­zo­wa­nia publi­ka­cji). Publikacja ta sta­ła się nawet ele­men­tem ofi­cjal­ne­go słow­ni­ka pojęć meto­dycz­nych: https://​www​.igi​-glo​bal​.com/​d​i​c​t​i​o​n​a​r​y​/​c​o​m​p​u​t​a​t​i​o​n​-​i​n​d​e​p​e​n​d​e​n​t​-​m​o​d​e​l​/​4​4​607.

Kolejnym, po meto­dach, istot­nym ele­men­tem ana­liz i pro­jek­to­wa­nia sys­te­mów jest archi­tek­tu­ra infor­ma­cji. Architektura infor­ma­cji jest mózgiem i cen­tral­nym ukła­dem ner­wo­wym każ­dej dużej orga­ni­za­cji. Choć jest to praw­do­po­dob­nie naj­waż­niej­sza część eko­sys­te­mu orga­ni­za­cji, archi­tek­tu­ra infor­ma­cji jest jed­ną z naj­trud­niej­szych do zro­zu­mie­nia dla ogó­łu popu­la­cji, ze wzglę­du na potrze­bę dogłęb­ne­go zro­zu­mie­nia biz­ne­su, a tak­że sze­ro­kiej gamy obsza­rów spe­cja­li­za­cji IT obej­mu­ją­cych archi­tek­tu­rę danych, dane refe­ren­cyj­ne, dane pod­sta­wo­we, zarzą­dza­nie dany­mi, zarzą­dza­nie dany­mi, odkry­wa­nie danych, dane w ruchu oraz sze­reg powią­za­nych dys­cy­plin .

Dlatego uzu­peł­nie­niem jest kolej­na moja recen­zo­wa­na publi­ka­cja: Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases .

Celem moim jest zapew­nie­nie moim klien­tom mak­sy­mal­ne­go bez­pie­czeń­stwa, jako­ści i nie­za­leż­no­ści. Dzięki stan­da­ry­za­cji, moi klien­ci dosta­ją doku­men­ty zro­zu­mia­łe dla innych, nie są uza­leż­nie­ni ode mnie. Jeżeli wyra­żą taką wolę, mogą sami kon­ty­nu­ować dal­sze pra­ce nad aktu­ali­za­cją prze­ka­za­nej im dokumentacji. 

Orientacja na fakty

Kluczowym pro­ble­mem ana­liz jest zapew­nie­nie ich obiek­ty­wi­zmu. Dlatego pod­sta­wo­wym mate­ria­łem są doku­men­ty ope­ra­cyj­ne takie jak pisma klien­tów, ofer­ty, fak­tu­ry, zamó­wie­nia, umo­wy, zarzą­dze­nia. Ich uzu­peł­nie­niem są obo­wią­zu­ją­ce akty praw­ne doty­czą­ce obsza­ru reali­zo­wa­nej ana­li­zy. Razem sta­no­wią one tak zwa­ne arte­fak­ty (arti­fact-cen­tric para­digm, ). Zawierają one efek­ty pra­cy ludzi, infor­ma­cje jakich potrze­bu­ją i jakie two­rzą, tak­że wszel­kie istot­ne regu­la­cje. To są fak­ty z życia orga­ni­za­cji. Badanie doku­men­tów, to naj­sku­tecz­niej­sza obec­nie meto­da ana­li­zy . Praca w opar­ciu o takie doku­men­ty pozwa­la tak­że na prze­pro­wa­dze­nie pro­jek­tu ana­li­tycz­ne­go w 100% zdal­nie.

Przekaż mi doku­men­ty ope­ra­cyj­ne, a ja oddam ci doku­ment opi­su­ją­cy to, jak na praw­dę dzia­ła Twoja organizacja

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 tego, 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 niepodzielne.” 

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 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 tak­że w inży­nie­rii opro­gra­mo­wa­nia, meto­dy opie­ra­ją­ce się przede wszyst­kim na fak­tach, wywia­dy są jedy­nie ewen­tu­al­nym uzu­peł­nie­niem .

Idealizacja

Modelowanie pole­ga na abs­tra­ho­wa­niu od 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. (Craver & Tabery, 2019)

Nadal bar­dzo czę­sto spo­ty­kam się z ocze­ki­wa­niem two­rze­nia mode­li as-is i to-be. Ma to pomóc pod­jąć decy­zję o pla­no­wa­nych zmia­nach. Tworzenie dwóch mode­li to dodat­ko­wa pra­ca i czas. Detaliczna ana­li­za sta­nu obec­ne­go, tyl­ko po to by zde­cy­do­wać cze­go zanie­chać to dodat­ko­wa pra­ca, zaś decy­do­wa­nie dzi­siaj” o tym cze­go nie chce­my jutro”, jest przy­sło­wio­wym wró­że­niem z fusów”. To typo­we, od lat kry­ty­ko­wa­ne, podej­ście zwa­ne water-fall”.

Modele – narzędzie a nie cel

Podstawowym celem mode­lo­wa­nia jest danie sobie oka­zji do myśle­nia przed pod­ję­ciem dzia­ła­nia” (Scott Ambler)

Analiza i pro­jek­to­wa­nie opar­te na ide­ali­za­cji nie wyma­ga mode­li as-is 

Czasy obec­ne to zmia­ny na ryn­ku zacho­dzą­ce w ska­li mie­sią­ca a nie deka­dy. Oznacza to, że ana­li­za, bez wzglę­du na wiel­kość pro­jek­tu, powin­na trwać co naj­wy­żej kwar­tał a dal­szy ciąg pro­jek­tu to cykl życia sys­te­mu zamiast wyma­gań. Rozwiązaniem pro­ble­mu ogra­ni­czo­ne­go cza­su jest sku­pie­nie się na audy­cie orga­ni­za­cji, któ­re­go celem jest opra­co­wa­nie jej ide­ali­za­cji czy­li wizji przy­szłe­go jej ide­al­ne­go funk­cjo­no­wa­nia. W efek­cie mamy ści­śle wyzna­czo­ny kie­ru­nek roz­wo­ju i wdra­ża­nia nowych tech­no­lo­gii, np. infor­ma­tycz­nych, i nie tra­ci­my cza­su na doku­men­to­wa­nie tego co zosta­nie odrzu­co­ne. Dokumentujemy na bie­żą­co tyl­ko co co przy­bli­ża nas do celu .

Notacje

Do korek­ty możesz użyć gum­ki na eta­pie mode­lo­wa­nia, lub mło­ta kowal­skie­go na eta­pie budo­wa­nia”. Frank Lloyd Wright (para­fra­za)

Dość powszech­ne w fir­mach, uży­wa­nie licen­cjo­no­wa­nych lub opa­ten­to­wa­nych metod pra­cy i narzę­dzi powo­du­je, że bene­fi­cjent takiej usłu­gi sta­je się nie­wol­ni­kiem usłu­go­daw­cy. Jeżeli meto­dy pra­cy są dodat­ko­wo utrzy­my­wa­ne w tajem­ni­cy jako tajem­ni­ca usłu­go­daw­cy, nie jest moż­li­we spraw­dze­nie czy usłu­ga zosta­ła wyko­na­na należycie.

Dlatego wyko­rzy­stu­ję wyłącz­nie otwar­te stan­dar­dy i nota­cje oraz meto­dy nie wyma­ga­ją­ce opłat licen­cyj­nych. Dzięki cze­mu doku­men­ty, któ­re prze­ka­zu­ję jako pro­duk­ty swo­jej pra­cy, są w 100% moż­li­we do dal­sze­go, samo­dziel­ne­go użyt­ku. Są to w szcze­gól­no­ści (skró­ty wyja­śnio­ne w słow­ni­ku): MDA. MOF, UML, BPMN, SBVR. BMM, SysML. 

W arty­ku­le Metoda nauko­wa w ana­li­zie biz­ne­so­wej w 2011 roku opi­sa­łem czym jest meto­da nauko­wa. Poniżej usys­te­ma­ty­zo­wa­ny opis spo­so­bu pro­wa­dze­nia audy­tów i ana­liz uzu­peł­nio­ny lite­ra­tu­rą źródłową. 

Fundamentem metod jakie sto­su­ję są mode­le: pro­ste, sko­men­to­wa­ne ale sfor­ma­li­zo­wa­ne sche­ma­ty blo­ko­we, zro­zu­mia­łe dla adre­sa­ta. W efek­cie ana­li­za i komu­ni­ka­cja pole­ga na: pozy­ski­wa­niu mate­ria­łów o orga­ni­za­cji ana­li­zo­wa­nej, two­rze­niu mode­li opi­su­ją­cych tę orga­ni­za­cję, oraz recen­zo­wa­niu ich przez oso­by z ana­li­zo­wa­nej orga­ni­za­cji. Jest to sku­tecz­na meto­da ana­li­zy i mode­lo­wa­nia dzia­ła­nia orga­ni­za­cji .

[Jeżeli inte­re­su­je Cię mniej tech­nicz­ny a bar­dziej biz­ne­so­wy opis, przejdź teraz na stro­nę: Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji.]

Analiza systemowa

Podstawowe pyta­nia w ana­li­zie sys­te­mo­wej to: jak jest i dla­cze­go jest tak jak jest” oraz jak powin­no być i co nale­ży uczy­nić, aby było tak jak być powin­no” , mode­lo­wa­nie zaś to narzę­dzie a nie cel .

Czym jest?

Analiza sys­te­mo­wa- jest to jaw­ne i for­mal­ne bada­nie wspo­ma­ga­ją­ce dzia­ła­nie osób odpo­wie­dzial­nych za podej­mo­wa­ne decy­zje lub linię postę­po­wa­nia, w ści­śle okre­ślo­nej sytu­acji cha­rak­te­ry­zu­ją­cej się nie­pew­no­ścią. Jej celem jest okre­śle­nie pożą­da­nych dzia­łań lub linii postę­po­wa­nia poprzez stwo­rze­nie i roz­wa­że­nie dostęp­nych warian­tów, jak tak­że porów­na­nie ich prze­wi­dy­wa­nych następstw. 

(na podst.: )

Tak więc jets to pew­ne okre­ślo­ne podej­ście do podej­mo­wa­nia decy­zji. Takimi decy­zja­mi są np. zmia­ny w orga­ni­za­cji, a wdro­że­nie nowych lub zmie­nio­nych pro­ce­sów biz­ne­so­wych czy też nowe­go opro­gra­mo­wa­nia jest taką zmia­ną. Jednak:

Celem ana­liz sys­te­mo­wych nie jest two­rze­nie ogrom­nej i kosz­tow­nej doku­men­ta­cji, jest nim two­rze­nie mode­li i opra­co­wa­nie reko­men­da­cji w posta­ci moż­li­wie zwię­złe­go opracowania.

Analiza sys­te­mo­wa orga­ni­za­cji nie powin­na się opie­rać na subiek­tyw­nych rela­cjach jej pra­cow­ni­ków, powin­na być opar­ta w 100% na fak­tach . Dlatego sto­su­ję meto­dy bazu­ją­ce cał­ko­wi­cie na dostar­cza­nych doku­men­tach i auto­ry­zo­wa­nych opi­sach, wywia­dy są jedy­nie ewen­tu­al­nym uzu­peł­nie­niem tak pozy­ska­nej wie­dzy. Cała ana­li­za opar­ta jest na kolek­cjo­no­wa­niu fak­tów (pra­wo, regu­la­mi­ny wewnętrz­ne, doku­men­ty ope­ra­cyj­ne i ich sza­blo­ny, wyni­ki audy­tów tech­nicz­nych i eks­per­tyz, prze­ka­zy­wa­ne przez zama­wia­ją­ce­go w for­mie pisem­nej). . Tak prze­pro­wa­dzo­na ana­li­za i jej efek­ty, są w mak­sy­mal­nie moż­li­wym stop­niu obiek­tyw­ne i wol­ne od subiek­tyw­nych ocen pra­cow­ni­ków orga­ni­za­cji analizowanej. 

Standardowa pro­ce­du­ra prze­pro­wa­dze­nia ana­li­zy sys­te­mo­wej wyglą­da jak poniżej: 

Proces analizy systemowej
Proces ana­li­zy sys­te­mo­wej: ana­li­za sytu­acji, sfor­mu­ło­wa­nie pro­ble­mu, bada­nie, opra­co­wa­nie mode­li, inter­pre­ta­cja i testy mode­li, powtó­rze­nie pro­ce­du­ry lub publi­ka­cja wyni­ków. ,

Jedną z moż­li­wych reko­men­da­cji może być opis roz­wią­za­nia w posta­ci opro­gra­mo­wa­nia, wyra­żo­ne jako jego pro­jekt (patrz: wyma­ga­nia na opro­gra­mo­wa­nie).

Modele pojęciowe

Pierwszym i klu­czo­wym eta­pem pra­cy jest ana­li­za poję­cio­wa dzie­dzi­ny pro­ble­mu. Tworzenie mode­li poję­cio­wych jest pod­sta­wo­wym eta­pem bada­nia spój­no­ści tre­ści i wyni­ków każ­dej ana­li­zy i opi­su roz­wią­za­nia. Model poję­cio­wy (prze­strzeń poję­cio­wa, ang. name­spa­ce) to słow­nik klu­czo­wych pojęć bada­nej dzie­dzi­ny oraz wra­żo­na gra­ficz­nie ich struk­tu­ra, obra­zu­ją­ca związ­ki mię­dzy tymi poję­cia­mi: tak­so­no­mia i związ­ki syn­tak­tycz­ne, pozwa­la­ją­ca zagwa­ran­to­wać spój­ność i nie­sprzecz­ność nazew­nic­twa zasto­so­wa­ne­go w toku ana­li­zy i doku­men­to­wa­nia jej wyni­ków. . Proces ana­li­zy poję­cio­wej opi­su­je . poniż­szy dia­gram :

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011
M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011

Kluczowe etapy analizy i usprawnienia organizacji

Określenie problemu

Pierwszym eta­pem jest sfor­mu­ło­wa­nie pro­ble­mu badaw­cze­go czy­li okre­śle­nie przy­czy­ny i celu pro­wa­dze­nia ana­li­zy. W sfor­ma­li­zo­wa­nej for­mie, tak­że gra­ficz­nej efek­ty tego eta­pu są doku­men­to­wa­ne jako Model Motywacji Biznesowej . Kluczowymi ele­men­ta­mi tego mode­lu są wizja i misja fir­my oraz stra­te­gia i cele biz­ne­so­we wyra­żo­ne okre­ślo­ną war­to­ścią i jej miarą.

Opracowanie modelu informacyjnego organizacji

Jakiekolwiek reko­men­da­cje, jeże­li mają być świa­do­me i popar­te dowo­dem ich popraw­no­ści, muszą być poprze­dzo­ne zro­zu­mie­niem i udo­ku­men­to­wa­niem mecha­ni­zmu dzia­ła­nia organizacji. 

Do opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji sto­su­je­my sfor­ma­li­zo­wa­ne mode­le wyra­żo­ne jako Architektura Biznesowa (mode­le pro­ce­sów biz­ne­so­wych, regu­ły biz­ne­so­we, mode­le infra­struk­tu­ry IT i mapo­wa­nie pro­ce­sów na opro­gra­mo­wa­nie, struk­tu­ry doku­men­tów w pro­ce­sach). .

Model pro­ce­sów biz­ne­so­wych poka­zu­je, jakie zada­nia są wyko­ny­wa­ne w ramach pro­ce­sów i w jakiej kolej­no­ści, oraz pro­duk­ty tych zadań. Zawiera infor­ma­cje na temat ich wyko­naw­ców, doku­men­tów wyko­rzy­sty­wa­nych i two­rzo­nych w ramach pro­ce­su, ich tre­ści, zaso­bów nie­zbęd­nych do reali­za­cji pro­ce­su (w tym sys­te­mów IT), może zawie­rać opi­sy wskaź­ni­ków KPI (Key Performance Indicators) . (opis tego eta­pu w doku­men­cie Analiza i opra­co­wa­nie archi­tek­tu­ry biz­ne­so­wej).

Wszystkie ele­men­ty mode­lu orga­ni­za­cji powsta­ją i są kon­tro­lo­wa­ne, jed­no­cze­śnie, gdyż zbie­ra­ne mate­ria­ły źró­dło­we rzad­ko kie­dy są upo­rząd­ko­wa­ne. Kolejne, ite­ra­cyj­nie uzgad­nia­ne, wer­sje pro­wa­dzą do powsta­nia osta­tecz­ne­go Raportu z Analizy zawie­ra­ją­ce­go opis orga­ni­za­cji od ogó­łu do szcze­gó­łu j.w. oraz wyma­ga­nia na reko­men­do­wa­ne rozwiązanie.

Opracowanie modelu informatycznego i projektowanie rozwiązania

Na bazie powsta­łej Architektury Biznesowej, opra­co­wy­wa­ne są reko­men­da­cje do zmian wyra­żo­ne jako pro­jekt roz­wią­za­nia (archi­tek­tu­ra sys­te­mu i reali­zo­wa­na logi­ka biz­ne­so­wa), sta­no­wią wyma­ga­nia dla dostaw­cy roz­wią­za­nia (patrz opis: Wymagania na opro­gra­mo­wa­nie). .

Tworzenie kodu dla sys­te­mów inten­syw­nie wyko­rzy­stu­ją­cych opro­gra­mo­wa­nie obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji mode­lo­wa­nia dostęp­nych jako wyso­ko­po­zio­mo­we kon­struk­cje pro­gra­mi­stycz­ne poma­ga zde­fi­nio­wać kod i upew­nić się, że kie­dy sys­tem dzia­ła z opro­gra­mo­wa­niem wyko­ny­wa­nym przez maszy­ny, kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Wyjaśniamy w tym arty­ku­le, że mimo to pozo­sta­je luka, któ­rej nie moż­na wypeł­nić zwy­kły­mi meto­da­mi pro­gra­mo­wa­nia, ale któ­rą moż­na wypeł­nić, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy mode­lo­wa­nia (meto­dę pro­jek­to­wa­nia i ana­li­zy oraz język).

Realizacja

Po zawar­ciu umo­wy z dostaw­cą roz­wią­za­nia, wspie­ram orga­ni­za­cję pro­wa­dząc nad­zór autor­ski, któ­ry pole­ga na bie­żą­cym aktu­ali­zo­wa­niu doku­men­ta­cji opi­su­ją­cej model orga­ni­za­cji i roz­wią­za­nia. W dniu zakoń­cze­nia wdro­że­nia sta­no­wi on aktu­al­ną doku­men­ta­cję uzy­ska­ne­go efektu. 

Dodatek:

Dlaczego metody naukowe?

Celem nauki jest obser­wa­cja fak­tów i zro­zu­mie­nie mecha­ni­zmu ich powsta­wa­nia, celem inży­nie­rii jest two­rze­nie kon­struk­cji wyko­rzy­stu­ją­cych odkry­te mecha­ni­zmy

Opisany powy­żej pro­ces to kla­sycz­na ana­li­za sys­te­mo­wa . Jest to zasto­so­wa­nie zasad nauki do pro­jek­tów biznesowych.

Analiza sys­te­mo­wa to pro­ces nauko­wy, opar­ty na ana­li­zie fak­tów, sto­so­wa­ny w pro­jek­tach o pod­wyż­szo­nym ryzy­ku (a pro­jek­ty infor­ma­tycz­ne do takich nale­żą, ponad 70% tych pro­jek­tów to nie­ste­ty pro­jek­ty nie­uda­ne). Podejście sys­te­mo­we wymu­sza sys­te­ma­tycz­ną i logicz­ną ana­li­zę reali­zo­wa­nych przez przed­się­bior­stwo dzia­łań, sto­su­jąc opar­te na mode­lach podej­ście, pozwa­la zro­zu­mieć stan obec­ny i jego przy­czy­ny. Dzięki temu wyni­ki ana­liz sys­te­mo­wych są obiek­tyw­ne.

Nauka to nie tyl­ko, ency­klo­pe­dycz­ne gro­ma­dze­nie wie­dzy, to meto­dycz­ne bada­nia dzie­dzi­ny, będą­cej przed­mio­tem zainteresowania. 

Nauka nie pole­ga bowiem na gro­ma­dze­niu infor­ma­cji, choć­by cie­ka­wych i poży­tecz­nych, ale na roz­wią­zy­wa­niu zagad­nień .

Bardzo wie­le ksią­żek zali­cza­nych do opra­co­wań nauko­wych, powo­łu­je się w pierw­szych roz­dzia­łach na zna­cze­nia pojęć, gdzie zwra­ca się uwa­gę na to, że nauka to bada­nia dążą­ce do odkry­wa­nia praw, zaś inży­nie­ria to two­rze­nie (roz­wią­zań) na bazie wie­dzy o tych pra­wach

W toku pra­cy badaw­czej okre­śla­ne są warian­ty (sce­na­riu­sze) roz­wią­za­nia pro­ble­mu. Aby wska­zać (zare­ko­men­do­wać) wybra­ny wariant, opra­co­wy­wa­ny jest model orga­ni­za­cji (model jest testo­wa­ny na zgod­ność z fak­ta­mi). Na bazie mode­lu pro­wa­dzo­ne są ana­li­zy warian­tów, na bazie wyni­ków tych ana­liz powsta­ją reko­men­da­cje. Mogą nimi być: zale­ce­nia reor­ga­ni­za­cji, zale­ce­nia wdro­że­nia nowych tech­no­lo­gii, wyma­ga­nia na reko­men­do­wa­ne roz­wią­za­nie infor­ma­tycz­ne, itp. Wynik ana­li­zy ma postać opra­co­wa­nia nauko­we­go: stresz­cze­nie, wpro­wa­dze­nie (opis pro­ble­mu), uży­te meto­dy, opis rezul­ta­tów, opis pro­ce­su ich powsta­wa­nia, bibliografia. 

(wię­cej o meto­dzie nauko­wej z arty­ku­le: Metoda nauko­wa w ana­li­zie biz­ne­so­wej)

Modele, modelowanie i perspektywy

Proces ana­li­zy i mode­lo­wa­nia jest znacz­nie mniej kosz­tow­ny, w porów­na­niu z meto­da­mi opar­ty­mi na prak­ty­ce”, czy­li pro­to­ty­po­wa­niu decy­zji we wła­snej organizacji. 

(źr. )

Projektowanie to pro­ces pro­wa­dzą­cy od sfor­mu­ło­wa­nia pro­ble­mu do powsta­nia wdro­że­nia rozwiązania:

Orientacja na mode­le (Model Driven Engineering, ) pozwa­la zarzą­dzać zło­żo­no­ścią pro­jek­tów, pano­wać nad ich zakre­sem, a kolej­ne fazy, będąc wyni­kiem śla­do­wa­nia czy­li wywo­dze­nia jed­nym mode­li z dru­gich (trans­for­ma­cje) pozwa­la­ją sta­le testo­wać popraw­ność kon­cep­cji całe­go roz­wią­za­nia i pro­jek­tu .

Standardowo sto­su­ję nota­cje BMM, BPMN, SBVR i UML . Kluczowy etap to opra­co­wa­nie prze­strze­ni poję­cio­wej (name­spa­ce) czy­li dzie­dzi­no­we­go słow­ni­ka pojęć. Na jego pod­sta­wie two­rzo­ny jest pro­fil poję­cio­wy dla wszyst­kich sche­ma­tów blo­ko­wych. Następnie two­rzo­ne sa mode­le opi­su­ją­ce dzia­ła­nie ana­li­zo­wa­ne­go i pro­jek­to­wa­ne­go sys­te­mu – wyra­żo­ne jako sche­ma­ty blo­ko­we i sce­na­riu­sze testu­ją­ce opra­co­wa­ne modele. 

Istotnym ele­men­tem mode­lo­wa­nych orga­ni­za­cji są doku­men­ty: ich struk­tu­ry i zawar­tość oraz regu­ły kon­tro­li popraw­no­ści (sys­tem infor­ma­cyj­ny orga­ni­za­cji). Obecnie są one z zasa­dy są mode­lo­wa­ne jako struk­tu­ry XML.

Większość orga­ni­za­cji to zło­żo­ne sys­te­my ludzi i infor­ma­cji mają­ce sta­łe inte­rak­cje z oto­cze­niem. Są to więc tak­że bar­dzo zło­żo­ne mode­le (wie­le ele­men­tów i wie­le połą­czeń mię­dzy nimi). Budowanie wiel­kich i szcze­gó­ło­wych sche­ma­tów blo­ko­wych jest nie­efek­tyw­ne komu­ni­ka­cyj­nie: ich zro­zu­mie­nie jest trud­ne a dla więk­szo­ści ludzi po pro­tu nie­moż­li­we. Dlatego doku­men­ta­cje sys­te­mu opra­co­wu­je się jako zestaw wie­lu rela­tyw­nie pro­stych dia­gra­mów, sta­no­wią­cych tak zwa­ne per­spek­ty­wy, czy­li pro­ste opi­sy ukie­run­ko­wa­ne na jeden okre­ślo­ny kontekst: 

Poniżej pro­sty dia­gram, któ­ry obra­zu­je opi­sa­ne podej­ście jako całość:

Analiza sys­te­mo­wa orga­ni­za­cji to pro­ces pro­wa­dzą­cy do zro­zu­mie­nia tego jak dzia­ła ana­li­zo­wa­na orga­ni­za­cja. Powstały w toku tej ana­li­zy model opi­su­ją­cy tę orga­ni­za­cję, to teo­ria wyja­śnia­ją­ca zacho­wa­nie się orga­ni­za­cji i to jak ona na praw­dę funk­cjo­nu­je. Mając taki model moż­na prze­wi­dy­wać skut­ki pla­no­wa­nych zmian.

Można to pod­su­mo­wać tak: 

Na zakończenie…

(źr. Martin Fowler, Analysis Patterns, 1997)
.

Zachęcam tak­że to lektury: 

Jaroslaw Zelinski. (3023, October 21). Metody [Professional Blog]. LinkedIn Blog. https://www.linkedin.com/pulse/metody-jaroslaw-zelinski-fru7e%3FtrackingId=11%252BHhe6oRsaJTiMo3ki33A%253D%253D/?trackingId=11%2BHhe6oRsaJTiMo3ki33A%3D%3D

Źródła

Ackoff, R. L. (1999). Ackoff’s best: his clas­sic wri­tings on mana­ge­ment. Wiley.
Ackoff, R. L. (1967). Management misin­for­ma­tion sys­tems. Management Science, 14(4), B‑147.
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Arlow, J., & Neustadt, I. (2004). Enterprise pat­terns and MDA: buil­ding bet­ter softwa­re with arche­ty­pe pat­terns and UML. Addison-Wesley.
Bertalanffy, L. (2003). General sys­tem the­ory: foun­da­tions, deve­lop­ment, appli­ca­tions (Rev. ed., 14. paper­back print). Braziller.
Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89 – 110). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 03418-4_6
Borshchev, A., & Filippov, A. (2004). From sys­tem dyna­mics and discre­te event to prac­ti­cal agent based mode­ling: reasons, tech­ni­qu­es, tools. Proceedings of the 22nd International Conference of the System Dynamics Society, 22.
Bridgeland, D. M., & Zahavi, R. (2009). Business mode­ling: a prac­ti­cal guide to reali­zing busi­ness value. Morgan Kaufmann/Elsevier.
Bronk, A. (2006). Metoda nauko­wa. Nauka, 47 – 64.
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/
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
Findeisen, W. (Ed.). (1985). Analiza sys­te­mo­wa – pod­sta­wy i meto­do­lo­gia. Państw. wydawn. nauk.
Forward, A., & Lethbridge, T. C. (2008). A taxo­no­my of softwa­re types to faci­li­ta­te search and evi­den­ce-based softwa­re engi­ne­ering. Proceedings of the 2008 Conference of the Center for Advanced Studies on Collaborative Research Meeting of Minds – CASCON 08, 179. https://​doi​.org/​1​0​.​1​1​4​5​/​1​4​6​3​7​8​8​.​1​4​6​3​807
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.
Hamdani, A., & Abdelli, A. (2019). Towards model­ling and ana­ly­zing timed work­flow sys­tems with com­plex syn­chro­ni­za­tions. Journal of King Saud University – Computer and Information Sciences, S131915781930182X. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​j​k​s​u​c​i​.​2​0​1​9​.​0​8​.​007
Kamiński, S. (1919 – 1986). (1981). Pojęcie nauki i kla­sy­fi­ka­cja nauk / Stanisław Kamiński. Oddział Zbiorów Cyfrowych. https://​dli​bra​.kul​.pl/​d​l​i​b​r​a​/​p​u​b​l​i​c​a​t​i​o​n​/​3​3​7​9​2​/​e​d​i​t​i​o​n​/​3​1​624
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.
Koźmiński, A. K. (1979). Decyzje: ana­li­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Kreuter, T., Scavarda, L. F., Thomé, A. M. T., Hellingrath, B., & Seeling, M. X. (2021). Empirical and the­ore­ti­cal per­spec­ti­ves in sales and ope­ra­tions plan­ning. Review of Managerial Science. https://​doi​.org/​1​0​.​1​0​0​7​/​s​1​1​8​4​6​-​021 – 00455‑y
Luisi, J. V. (2014). Part IV – Information Architecture. In J. V. Luisi (Ed.), Pragmatic Enterprise Architecture (pp. 189 – 261). Morgan Kaufmann. https://doi.org/10.1016/B978‑0 – 12-800205 – 6.00004 – 4
Machamer, P., Darden, L., & Craver, C. F. (2000). Thinking abo­ut mecha­ni­sms. Philosophy of Science, 67(1), 1 – 25.
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
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Object Management Group. (2014, January). Business Process Model and Notation (BPMN). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Object Management Group. (2014, June 18). Model Driven Architecture (MDA). OMG​.Org. https://​www​.omg​.org/​m​da/
Object Management Group. (2015). Business Motivation Model (BMM). https://​www​.omg​.org/​s​p​e​c​/​B​MM/
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Reynolds, C. (2010). Introduction to busi­ness archi­tec­tu­re. Course Technology PTR.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Sienkiewicz, P. (1994). Analiza sys­te­mo­wa: pod­sta­wy i zasto­so­wa­nia. Wydaw. Bellona.
Sobczak, A. (2009). Wstęp do Architektury Korporacyjnej (B. Szafrański, Ed.). Wojskowa Akademia Techniczna.
Thalheim, B. (2019). Models for Communication, Understanding, Search, and Analysis. Data Analytics and Management in Data Intensive Domains: ХХI In-Ternational Conference DAМDID/RCDL’2019 (October 15 – 18, 2019, Kazan, Russia): Conference Proceedings. Edited Bу Alexander Elizarov, Boris Novikov, Sergey Stupnikov. – Kazan: Kazan Federal University, 2019. – 496 р., 19.
Thalheim, B. (2011). The scien­ce of con­cep­tu­al model­ling. International Conference on Database and Expert Systems Applications, 12 – 26.
van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23 – 24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680‑5
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
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

Aktualizacja: [last-modi­fied]