Zarządzanie zmianami biznesowymi

Na blo­gu prof. Andrzeja Sobczaka uka­zał się kolej­ny cie­ka­wy arty­kuł, w któ­rym auto­ra zauwa­ża, że:

Presja na uzy­ski­wa­nie jak naj­lep­szych wyni­ków w jak naj­krót­szym cza­sie powo­du­je bar­dzo duży nacisk na tzw. Time 2 Market (T2M) ? czy­li jak naj­szyb­sze wpro­wa­dza­nie pro­duk­tu na rynek (biz­nes coraz czę­ściej godzi się, że będzie to pro­dukt nie do koń­ca prze­te­sto­wa­ny, dopra­co­wa­ny,? ? ale będą dzię­ki temu pierw­si na ryn­ku i wyprze­dzą w ten spo­sób kon­ku­ren­cję ? zgod­nie z zasa­dą ?kto nie ryzy­ku­je, ten nie pije szampana?).

Dążenie do skró­ce­nia T2M powo­du­je, że zmia­ny reali­zo­wa­ne w orga­ni­za­cjach (czy to biz­ne­so­we, czy też tech­no­lo­gicz­ne) mają cha­rak­ter nie­sko­or­dy­no­wa­ny, punk­to­wy, meto­dą ?na sznur­ki?. Skutkuje to tym, że reali­za­cja tych zmian pro­wa­dzi do upra­wie­nia reali­za­cji frag­men­tu pro­ce­su biz­ne­so­we­go, pozwa­la na wpro­wa­dze­nie nowe­go pro­duk­tu na rynek, dostar­cza nowej funk­cjo­nal­no­ści dla departamentu/linii biz­ne­so­wej. Ale orga­ni­za­cja roz­pa­try­wa­na jako całość tra­ci na tym. Po pierw­sze rosną kosz­ty utrzy­ma­nia tak wdro­żo­nych roz­wią­zań (czy to orga­ni­za­cyj­nych, czy też IT). Po dru­gie coraz wię­cej cza­su poświę­ca­ne jest na koordynację/uzgadnianie/wyjaśniania ele­men­tów, któ­re od same­go począt­ku powin­ny ?skła­dać się? w jed­ną całość. Wreszcie orga­ni­za­cja postrze­ga­na holi­stycz­nie zmniej­sza swo­ją ela­stycz­ność (rośnie jej entro­pia) (Źródło: Manifest nowe­go ładu zarzą­dza­nia zmia­na­mi biz­ne­so­wy­mi | Architektura Korporacyjna)

Myślę, że naci­ski na skra­ca­nie T2M to tyl­ko czyn­nik narzu­ca­ją­cy wyma­ga­nia. SJP mówi, że stra­te­gia to ?prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie?. Czym jest więc archi­tek­tu­ra kor­po­ra­cyj­na (AK) dla stra­te­gii? A może czym powin­na być stra­te­gia dla AK? AK zawie­ra w sobie archi­tek­tu­rę apli­ka­cji, któ­re są jej ? AK- czę­ścią. Jeżeli uzna­je­my (jeże­li) pryn­cy­pia takie jak ?apli­ka­cja powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?, to dla­cze­go by nie uznać, że ?archi­tek­tu­ra kor­po­ra­cyj­na (tak­że) powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?? Wtedy stra­te­gia orga­ni­za­cji sta­no­wi­ła by rodzaj poli­ty­ki two­rze­nia i roz­sze­rza­nia AK. Oczekujemy zwin­no­ści od apli­ka­cji, ocze­kuj­my tez od AK?.

Czy to się da? Myślę, że tak. W koń­cu dowol­nie zło­żo­ny sys­tem IT moż­na spro­wa­dzić do rela­tyw­nie małej licz­by kom­po­nen­tów (to tyl­ko kwe­stia pozio­mu her­me­ty­za­cji szcze­gó­łów). Z dru­giej stro­ny podział sys­te­mu na odręb­ne apli­ka­cje jest sztucz­ny, wyni­ka wyłącz­nie z zakre­su pro­jek­tu ich dostaw­ców. To zna­czy, że poszcze­gól­ne kom­po­nen­ty moż­na podzie­lić na te wol­no-zmien­ne klu­czo­we, tak zwa­ne dome­no­we, kom­po­nen­ty obsłu­gu­ją­ce sce­na­riu­sze biz­ne­so­we oraz te obsłu­gu­ją­ce dia­log użyt­kow­ni­ka z sys­te­mem i ofe­ru­ją­ce użyt­kow­ni­kom usłu­gi apli­ka­cyj­ne (np. por­ta­le intra­ne­to­we). Szybkozmienny biz­nes nie raz wymu­si nowe usłu­gi, to czy będzie to zmia­na w ist­nie­ją­cym czy nowy kom­po­nent to poli­ty­ka budo­wy i zarzą­dza­nia zmia­ną AK, powin­na ona pomóc pod­jąć decy­zje czy będzie on zamiast wpro­wa­dza­nia kolej­nej (po co??) mody­fi­ka­cji, efe­me­ry­dą reali­zu­ją­cą okre­ślo­ną logi­kę biz­ne­so­wą w okre­ślo­nym, mają­cym począ­tek i koniec, okre­sie czasu.

Strategia orga­ni­za­cji to dłu­go ter­mi­no­we cele i poli­ty­ka ich reali­za­cji, kon­kret­ne rocz­ne czy kwar­tal­ne dzia­ła­nia to tak­ty­ki a nie stra­te­gia… Co więc robić? Przede wszyst­kim opi­sać stra­te­gię i poli­ty­kę jej reali­za­cji (stra­te­gia to plan ale poli­ty­ka to regu­ły dzia­ła­nia a nie opis dzia­łań). Polityka ta powin­na wyzna­czać tak­że spo­sób budo­wy AK, któ­ra musi pozwo­lić na reali­zo­wa­nie stra­te­gii. Mają poli­ty­kę, zbu­do­wać AK w zgo­dzie mię­dzy inny­mi z zasa­dą, że ?archi­tek­tu­ra kor­po­ra­cyj­na powin­na być zamknię­ta na zmia­ny i otwar­ta na rozszerzenia?.

Kim jest product owner?

Wczoraj pod­czas spo­tka­nia, mia­łem cie­ka­wą roz­mo­wę z przed­sta­wi­cie­la­mi jed­ne­go z pro­du­cen­tów sys­te­mów ERP. Okazało się, że mają bar­dzo podob­ne do moich doświad­cze­nia i wnio­ski: pod­czas wdro­że­nia sys­te­mu ERP potrzeb­ny im jest ktoś, jeden, kto zna i rozu­mie jak dzia­ła dana fir­ma, a nie set­ki stron doku­men­ta­cji czy ste­no­gra­my z dzie­siąt­ków godzin warsz­ta­tów z przy­szły­mi użyt­kow­ni­ka­mi. Do tego fir­ma ta – nabyw­ca sys­te­mu ERP – powin­na mieć, nie szcze­gó­ło­wo opi­sa­ne dzie­siąt­ki deta­licz­nie opi­sa­nych pro­ce­sów i ich warian­tów, pro­ce­dur czy set­ki i tysią­ce nie raz wyma­gań, a stra­te­gię i tak­ty­kę, z któ­rej wyni­ka (da się wyczy­tać) rola opro­gra­mo­wa­nia ERP w fir­mie: tak­ty­kę czy­li opis reali­za­cji stra­te­gii fir­my z pomo­cą pla­no­wa­ne­go do wdro­że­nia sys­te­mu ERP. Ta tak­ty­ka, to opis tego kie­dy i po co opro­gra­mo­wa­nie ma wspie­rać pra­cow­nikw orga­ni­za­cji. To, jak się to będzie odby­wa­ło w szcze­gó­łach, zosta­nie opra­co­wa­ne przez dostaw­cę (wyko­naw­cę) kon­kret­ne­go pro­duk­tu, to dostaw­ca goto­we­go opro­gra­mo­wa­nia opra­co­wu­je kon­cep­cję wdro­że­nia, na pod­sta­wie doku­men­tu opi­su­ją­ce­go tak­ty­kę uży­cia tego opro­gra­mo­wa­nia i wyma­ga­nia biz­ne­so­we (opro­gra­mo­wa­nie dedy­ko­wa­ne wyma­ga dodat­ko­wo zapro­jek­to­wa­nia i udo­ku­men­to­wa­nia logi­ki biz­ne­so­wej jaką ma ono realizować).

I co teraz? Teraz potrzeb­ne jest źró­dło spój­nej wie­dzy o orga­ni­za­cji, jej stra­te­gii i tak­ty­ce w któ­rą ma się wpa­so­wać opro­gra­mo­wa­nie ERP. Któż jest tym źró­dłem? [[Product owner]].

Pytane teraz brzmi: kim jest i człon­kiem czy­je­go zespo­łu jest (powi­nien być) pro­duct owner”? Tu zacy­tu­ję osta­ni aka­pit mojej cie­płej jesz­cze recen­zji książki:

…na ile wizja pro­duk­tu upraw­nia jej posia­da­cza do aktyw­ne­go kie­ro­wa­nia pro­jek­tem wraz z kie­row­ni­kiem pro­jek­tu (Scrum Master), ale to pozo­sta­wiam czy­tel­ni­kom i prak­ty­kom. Jedno moim zda­niem jest pew­ne: nie ma sen­su by zespół deve­lo­pe­ra kon­tak­to­wał się, z tabu­nem przy­szłych ?use­rów?, ma sens by dosta­wał spój­ną wie­dzę o tym co tak na praw­dę ma powstać.

Źródło: Agile Product Management with Scrum | Jarosław Żeliński IT-Consulting

Autor powyż­szej książ­ki nie daje wprost odpo­wie­dzi na to pyta­nie, jed­nak mil­czą­co zakła­da też, że to zespół dostaw­cy wal­czy” ze zja­wi­skiem i pro­duct owner jest człon­kiem tego zespo­łu, nie zmie­nia to fak­tu, że wyma­ga­na od nie­go wie­dza i zro­zu­mie­nie tego, do cze­go user będzie uży­wał opro­gra­mo­wa­nia, powin­na być taka jak opi­sa­łem wyżej.

Co usły­sza­łem po raz kolej­ny (podob­ne roz­mo­wy z dostaw­ca­mi opro­gra­mo­wa­nia nie raz już pro­wa­dzi­łem) od przed­sta­wi­cie­li dostaw­cy sys­te­mu ERP? Potrzebują bar­dzo zwię­złej i spój­nej doku­men­ta­cji (ale raczej 50-ciu stron niż setek, że nie wspo­mnę o kil­ku tysią­cach (tak – widy­wa­łem takie) i po stro­nie klien­ta (jed­nej) oso­by, któ­ra ten doku­ment zna, rozu­mie, ma dostęp do klu­czo­wych osób w orga­ni­za­cji. Najchętniej do auto­ra tego doku­men­tu… Dostawcy opro­gra­mo­wa­nia jak dosta­ją listę setek pozy­cji wyma­gań podzie­lo­nych w mało zro­zu­mia­ły spo­sób na funk­cjo­nal­ne i poza funk­cjo­nal­ne (i inne) raczej sobie z tych spe­cy­fi­ka­cji dwo­ru­ją niż cie­szą się z ich otrzy­ma­nia (pomi­jam, ze nie czy­ta­ją w cało­ści). Po co są więc robio­ne? Bo zama­wia­ją­cy postrze­ga swo­ją pra­cę przez pry­zmat jej zło­żo­no­ści, warian­to­wo­ści, nie patrzy z per­spek­ty­wy narzę­dzia a tym wła­śnie jest opro­gra­mo­wa­nie. To tak jak by cie­śla lub sto­larz opi­sał wyma­ga­nia na mło­tek cie­siel­ski w posta­ci setek stron user sto­ry” o tym jak, do cze­go i kie­dy używa(łby) młot­ka.. dla ana­li­ty­ka pro­jek­tan­ta taki opis (a kon­kret­nie jego ską­pa część) ma sens, dla kon­struk­to­ra – żad­ne­go, ten raczej ocze­ku­je rysun­ku tech­nicz­ne­go wykonawczego.

The role of Product Owner (Scott Ambler, Agile Modeling)
The role of Product Owner (Scott Ambler, Agile Modeling)

Powyższy dia­gram to poglą­do­wy model roli pro­duct owne­ra (PO) autor­stwa jed­ne­go z moich ulu­bio­nych zwin­nych ana­li­ty­ków”: Scott’a Amblera (Scott Ambler). Niewątpliwie moż­na dywa­go­wać czy PO to pra­cow­nik” dosa­tw­cy czy kupu­ją­ce­go ale tu chy­ba część wąt­pli­wo­ści roz­wie­ją sło­wa jed­ne­go z moich klien­tów, postrze­gam go jako jed­ne­go z lepiej zarzą­dza­ją­cych ryzy­kiem biz­ne­so­wym, zna­nych mi, pre­ze­sów firm: Panie Jarku nie wiem czy jest Pan lep­szym czy gor­szym spe­cja­li­stą od ludzi dostaw­cy, zatrud­ni­łem Pana bo prze­ło­żo­nym tam­tych jest Prezes tam­tej firmy”.

Where Do Product Owners Come From? The goods news is that the­re are seve­ral via­ble options for whe­re Product Owners may come from: Business ana­lyst. Although a tra­di­tio­nal busi­ness ana­lyst could fill the role of pro­duct owner, the­re is a risk that they will fall into the­ir old habits of com­mu­ni­ca­ting via docu­men­ta­tion. Keep in mind that what agi­le teams real­ly need are people with agi­le ana­ly­sis skills who are empo­we­red to make deci­sions. So, a bet­ter option is an empo­we­red agi­le busi­ness ana­lyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).

Tak więc nasu­wa się wnio­sek, że rolę PO powi­nien peł­nić ten czło­wiek, któ­ry wła­śnie skoń­czył ana­li­zę biz­ne­so­wą i napi­sał raport z niej. Raport, któ­ry zawie­ra spe­cy­fi­ka­cją wyma­gań (naj­le­piej w for­mie jak opi­sa­na powy­żej). W zasa­dzie nad­zór autor­ski nad reali­za­cją tak­ty­ki wdro­że­nia sys­te­mu ERP (opro­gra­mo­wa­nia w ogó­le) to nic inne­go jak bycie pro­duct owne­rem” w pro­jek­cie na eta­pie jego reali­za­cji a SCRUM fak­tycz­nie, na dzi­siej­sze cza­sy, wyda­je się być naj­lep­szą meto­dą zarzą­dza­nia taki­mi pro­jek­ta­mi a utrzy­my­wa­nie aktu­al­no­ści doku­men­tu ana­li­zy biz­ne­so­wej i wyma­gań w toku pro­jek­tu pro­wa­dzi do tego, że po zakoń­cze­niu pro­jek­tu mamy nie­chcą­cy” kom­plet­ną i aktu­al­ną doku­men­ta­cje sta­nu uzy­ska­ne­go w toku wdrożenia.

(książ­ki Scotta Amblera cze­ka­ją na recenzję ;))

Enterprise Architecture As Strategy

Pełny tytuł książ­ki to: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.

Bardzo cie­ka­wa książ­ka, auto­rzy dzie­lą się wyni­ka­mi badan jakie pro­wa­dzą od 1995 roku a doty­czą­cy­mi spo­so­bów opi­sy­wa­nia i mode­lo­wa­nia orga­ni­za­cji. Zaryzykuje tezę, że jed­nak opi­sy­wa­nia gdyż w książ­ce sto­so­wa­ne są nie­for­mal­ne meto­dy opi­su (autor­skie nie­sfor­ma­li­zo­wa­ne sche­ma­ty blo­ko­we) jed­nak nie sta­no­wi to gor­szej jako­ści książ­ki, gdyż auto­rzy dość wyczer­pu­ją­co opi­sa­mi swo­je prze­my­śle­nia. We wstę­pie przy­zna­ją, że klu­czo­wym odkry­ciem” było dla nich to, że nie da się ana­li­zo­wać zło­żo­nych sys­te­mów, jaki­mi są duże orga­ni­za­cje, bez wznie­sie­nie” się ponad szczegóły.

Enterprise Architecture As Strategy Creating a Foundation for Business ExecutionCytat

Opisują krok po kro­ku jak stwo­rzyć i wdro­żyć stra­te­gię zarzą­dza­nia bazu­ją­cą na archi­tek­tu­rze kor­po­ra­cyj­nej, któ­rą defi­niu­ją jako:

logi­ka zor­ga­ni­zo­wa­nia pro­ce­sów biz­ne­so­wych i zaso­bów IT, odzwier­cie­dla­ją­ca wyma­ga­nia na inte­gra­cję i stan­da­ry­za­cję jakie sta­wia model ope­ra­cyj­ny organizacji

Autorzy pod­kre­śla­ją, że nie jest to pro­jekt IT, zwra­ca­ją uwa­gę, że klu­czo­wy błąd jaki sami na począt­ku popeł­nia­li, to brnię­cie w szcze­gó­ły. Tworzenie mon­stru­al­nej ilo­ści szcze­gó­ło­wej doku­men­ta­cji (do cze­go mają skłon­ność IT i fir­my dorad­cze) nicze­mu nie słu­ży. Na przy­kła­dzie kil­ku dużych kor­po­ra­cji, poka­zu­ją krok po kro­ku ja zbu­do­wać model i jak uży­wać go jako narzę­dzia zarzą­dza­nia podej­mo­wa­nia decy­zji. Dedykowany roz­dział poświę­ci­li outsourcingowi.

Książka adre­so­wa­na jest do wyż­szych kadr kie­row­ni­czych i takim też jest napi­sa­na językiem.

Enterprise Architecture As Strategy: Creating a Foundation for Business Execution Hardcover
August 1, 2006, Harvard Business Press
by Jeanne W. Ross (Author), Peter Weill (Author), David Robertson (Author)
Amazon

Strategia krótkoterminowa

Ty razem krót­ko. Natchnął mnie arty­kuł kole­gi, tu frag­ment tego artykułu:

Przede wszyst­kim nie ist­nie­je coś takie­go jak ?stra­te­gia krót­ko­ter­mi­no­wa?. Otóż jest to kla­sycz­ny oksy­mo­ron ? ?prze­no­śne zesta­wie­nie pojęć o prze­ciw­staw­nym, wyklu­cza­ją­cym się wza­jem­nie zna­cze­niu, np. spie­szyć się powo­li, sucha woda; anty­lo­gia, epi­tet sprzeczny?[1]. […] Nie daj­my sobie robić wody z mózgu. Nie ist­nie­ją te wszyst­kie ?stra­te­gie? albo nie są stra­te­gia­mi. To jest opis spo­so­bu dzia­ła­nia, plan dzia­łań, któ­ry nie jest stra­te­gią. Przyrównując do woj­ny, nie są to stra­te­gie, tyl­ko tak­ty­ki pozwa­la­ją­ce na wygra­nie poszcze­gól­nych bitew. Nie powin­no się tego sto­so­wać nawet w odnie­sie­niu do poje­dyn­czej kam­pa­nii. To kam­pa­nia komu­ni­ka­cyj­na powin­na być pod­po­rząd­ko­wa­na stra­te­gii mar­ke­tin­go­wej. (źr. Strategia krót­ko­ter­mi­no­wa | Filozofia marketingu).

W tym miej­scu, tra­dy­cyj­nie, przy­ta­czam słow­ni­ko­we defi­ni­cje pojęć:

stra­te­gia ?prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie? ?dział sztu­ki wojen­nej obej­mu­ją­cy przy­go­to­wa­nie i pro­wa­dze­nie woj­ny oraz poszcze­gól­nych jej kam­pa­nii i bitew? (Słownik języ­ka pol­skie­go).

tak­ty­ka ?spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu? ?dzie­dzi­na sztu­ki wojen­nej obej­mu­ją­ca teo­rię i prak­ty­kę pro­wa­dze­nia wal­ki przez jed­nost­ki róż­nych rodza­jów wojsk? (Słownik języ­ka pol­skie­go).

Nie usu­wa­łem defi­ni­cji z dzie­dzi­ny woj­sko­wo­ści, bo te ter­mi­ny mają woj­sko­wy rodo­wód. Jak widać, jest pew­na róż­ni­ca mię­dzy stra­te­gią a tak­ty­ką. Tak więc woj­ny to raczej lata i ogól­ne zało­że­nia ich wygry­wa­nia – stra­te­gia ich pro­wa­dze­nia. Poszczególne bitwy są kon­se­kwen­cją zasto­so­wa­nej tak­ty­ki, to raczej tygo­dnie lub co naj­wy­żej mie­sią­ce. Patrząc więc teraz na te defi­ni­cje przez pry­zmat np. wie­dzy o II Wojnie Światowej, jaką mamy np. ze szko­ły pod­sta­wo­wej, widać, że zwrot stra­te­gia krót­ko­ter­mi­no­wa” brzmi podob­nie nie­mą­drze jak chwi­lo­wa woj­na światowa”.

Stosowanie okre­ślo­nych ter­mi­nów zgod­nie z ich wła­ści­wy­mi zna­cze­nia­mi ma głę­bo­ki sens. Rzecz w tym, by budo­wa­ny opis” (np. biz­nes plan, pro­spekt emi­syj­ny, kon­tekst pro­jek­tu IT), był nie tyl­ko powszech­nie zro­zu­mia­ły” ale o to by w ogó­le miał jakiś sens. Bo to, że ład­nie i mądrze brzmi” w kor­po­ra­cyj­nej doku­men­ta­cji to na dłuż­szą metę za mało.

Pojęcia te, stra­te­gia i tak­ty­ka, mają swo­je odzwier­cie­dle­nie tak­że w sfor­ma­li­zo­wa­nej for­mie w two­rze­niu mode­lu moty­wa­cji biz­ne­so­wej (BMM). Tu uży­to oba te ter­mi­ny i poka­za­no typo­wy kon­tekst ich użycia:

Startegia i taktyka

Jak widać (powyż­szy dia­gram wyko­na­ny zgod­nie z regu­ła­mi nota­cji BMM (http://​www​.omg​.org/​s​p​e​c​/​B​MM/) for­mal­ne, stan­dar­do­we defi­ni­cje i ich uży­cie w tym mode­lu, tak­że poka­zu­ją, że tak­ty­ka to dzia­ła­nia reali­zo­wa­ne w rela­tyw­nie krót­kim okre­sie, celem jest wspie­ra­nie przy­ję­tej stra­te­gii orga­ni­za­cji. Ta ostat­nia, to dłu­go­ter­mi­no­wo usta­la­ne regu­ły biz­ne­so­we, któ­re wyzna­cza­ją tak­ty­kę dzia­ła­nia. Strategia dzia­ła­nia jest kon­se­kwen­cją misji orga­ni­za­cji, wspie­ra reali­za­cję celów. Taktyka to osią­ga­nie kon­kret­nych i mie­rzal­nych dzia­łań na rzecz celów biznesowych.

Kolejnym eta­pem ana­li­zy biz­ne­so­wej i pla­no­wa­nia jest ana­li­za SWOT, któ­rą tak­że doku­men­tu­je­my (moż­na) nota­cją BMM, co opi­sa­łem już wcze­śniej w arty­ku­le A po co nam ten SWOT.

Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Jest dość licz­na gru­pa ludzi uwa­ża­ją­ca, że w Internecie nie obo­wią­zu­ją ani pra­wa fizy­ki, ani pra­wa eko­no­mii ani nawet zdro­wy roz­są­dek. W kwe­stii inży­nie­rii opro­gra­mo­wa­nia ludzie Ci stra­szą świat pro­jek­tów mitycz­nym wodo­spa­dem” jak kie­dyś dzie­ci stra­szo­ne były Babą Jagą.

[dzień po napi­sa­niu: po dys­ku­sji – patrz treść pod tym wpi­sem – a auto­rem cyto­wa­ne­go tu arty­ku­łu, doszli­śmy do wnio­sku, że nie róż­ni­my się zbyt­nio w poglą­dach, jed­nak zbyt­nie uprosz­cze­nie tre­ści mia­ło pra­wo wpro­wa­dzić mnie w błąd, jed­nak mój arty­kuł pozo­sta­nie w pier­wot­nej tre­ści bo pole­mi­zu­je głów­nie z pew­nym mitem a nie tym autorem]. 

Poniżej kolej­ny tego typu star­szak” o zna­mien­nym tytu­le Dlaczego tra­dy­cyj­ne meto­dy zarzą­dza­nia nie dzia­ła­ją w pro­jek­tach inter­ne­to­wych?” Szczerze mówiąc jak to czy­tam, natych­miast przy­po­mi­na mi się sta­re i wykpi­wa­ne w cza­sach sta­li­now­skich, obo­wiąz­ko­we wypra­co­wa­nie w szko­le na temat Dlaczego kocha­my Lenina” (bo, że go nie kocha­my wte­dy nie wcho­dzi­ło w grę).

Tu mamy dość cie­ka­wy przy­kład zastra­sze­nia, autor cyto­wa­ne­go arty­ku­łu uwa­ża, że pro­jek­ty inter­ne­to­we rzą­dzą się inny­mi prawami:

Mamy pomysł, ustal­my zakres oraz har­mo­no­gram na naj­bliż­sze 7 mie­się­cy, reali­zu­je­my pro­jekt i na koń­cu wpro­wadź­my pro­dukt na rynek. Oczywiście za nie­ma­łe pie­nią­dze. Czy war­to tak szcze­gó­ło­wa pla­no­wać swo­je nowe przed­się­wzię­cia? Czy war­to tak dłu­go dopiesz­czać swój pomysł?

waterfall_wiki

Jaką sku­tecz­ność w prze­wi­dy­wa­niu przy­szło­ści mają spe­cja­li­ści? Takie pyta­nie zadał sobie przed 10 laty Philip Tetlock, zna­ny ame­ry­kań­ski psy­cho­log. Przez dobrych kil­ka lat zbie­rał wśród mię­dzy­na­ro­do­wej śmie­tan­ki ana­li­ty­ków opi­nie na temat przy­szłych wyda­rzeń eko­no­micz­nych i poli­tycz­nych. Udało mu się uzy­skać ponad 82 tys. eks­perc­kich prze­po­wied­ni. (Dlaczego tra­dy­cyj­ne meto­dy zarzą­dza­nia nie dzia­ła­ją w pro­jek­tach internetowych?).

Drobne iro­nie w sty­lu za nie­ma­łe pie­nią­dze” to pró­by mani­pu­la­cji, któ­re pomi­jam. Po pierw­sze autor powo­łu­je się wyni­ki bada­nia, któ­re potwier­dza, że meto­dy heu­ry­stycz­ne się nie spraw­dza­ją jako meto­da pro­gno­zo­wa­nia, fakt zna­ny od daw­na w krę­gach nauki (pisa­łem o tym w Mucha…) i fak­tem jest, że takie (na bazie wie­dzy z okre­sów minio­nych) pro­gno­zo­wa­nie nie ma sen­su. Tu z auto­rem peł­na zgo­da. Ale jak się to ma do pro­jek­tów pro­gra­mi­stycz­nych? Nijak się nie ma, bo takich pro­gnoz nikt roz­sąd­ny nie robi w projekcie.

W inży­nie­rii opro­gra­mo­wa­nia nie pro­gno­zu­je się , bo to dome­na biz­ne­so­wa, w inży­nie­rii opro­gra­mo­wa­nia dąży się do zro­zu­mie­nia isto­ty pro­ble­mu imple­men­ta­cji. Czy ana­li­za i pro­jek­to­wa­nie to dłu­gie, szcze­gó­ło­we i zbęd­ne pla­no­wa­nie? Nie. Analiza ma za cel zro­zu­mie­nie i pod­ję­cie decy­zji o spo­so­bie imple­men­ta­cji. Jeżeli moż­na tu mówić o pla­no­wa­niu to raczej w kate­go­riach jak pla­nu­je­my zaim­ple­men­to­wać” to roz­wią­za­nie (któ­rym jest speł­nie­nie wyma­gań biznesu).

Owszem, moż­na pro­wa­dzić imple­men­ta­cje meto­dą pro­to­ty­pów, błą­dząc, z nadzie­ją, że szyb­ko (przy­pad­kiem) stwo­rzy­my dobre roz­wią­za­nie. Ale to w szcze­gól­no­ści trud­no zapla­no­wać (a nawet start-upy maja budże­ty). Czy to jest tań­sze? Nie sądzę. Nazywam to syn­dro­mem LOTTO: szyb­ka decy­zja bez pla­no­wa­nie daje pew­ne szan­se na odkry­cie popraw­ne­go roz­wią­za­nia, jed­nak to to samo co uzna­nie, że moż­na gra­jąc w LOTTO zaro­bić na bie­żą­ce życie aż do śmier­ci. Owszem, jest to moż­li­we, ale uda­je się nie­licz­nym (i wie­my dlaczego).

Start-upy nie­wąt­pli­wie mają swo­je pra­wa, i tu autor ma racje, twier­dząc, że nie ma cza­su”, jed­nak nie praw­dą jest, że:

Problem jest tyl­ko taki, że wszyst­ko, co na począt­ku usta­li­li­śmy to zwy­kłe prze­wi­dy­wa­nia naszych ?inter­ne­to­wych eko­no­mi­stów?. Całe nasze uza­sad­nie­nie biz­ne­so­we (model biz­ne­so­wy) jest prze­wi­dy­wa­niem, cały nasz zło­ty trój­ką pro­jek­tu (czas, zakres, budżet) jest prze­wi­dy­wa­niem. A jak dobrze wie­my, dzię­ki bada­niom Tetlocka, ludzie prze­wi­dy­wać dobrze nie potra­fią. Szczególnie w nowych warunkach.

Łączenie trój­ką­ta pro­jek­to­we­go” z pro­gno­za­mi biz­ne­so­wy­mi jest albo nie­po­ro­zu­mie­niem, albo nie­wie­dzą, albo cyni­zmem: model biz­ne­so­wy nie jest pro­gno­zą, model biz­ne­so­wy to opis spo­so­bu gene­ro­wa­nia war­to­ści doda­nej. Prognozą może być co naj­wy­żej plan przy­cho­dów z tej działalności.

Bo po pierw­sze w two­rze­niu mode­lu biz­ne­so­we­go, nie ma mowy o prze­wi­dy­wa­niu przy­szło­ści a o ana­li­zie gru­py doce­lo­wej. Wskazany zaś trój­kąt pro­jek­to­wy (zakres, ter­min, budżet) to plan wytwo­rze­nia kon­kret­ne­go opro­gra­mo­wa­nia (wspie­ra­ją­ce­go ten model biz­ne­so­wy). Owszem, tu – model biz­ne­so­wy – moż­na się pomy­lić, ale to nie pomył­ka pro­gno­zo­wa­nia tyl­ko np. zła decy­zja mar­ke­tin­go­wa. Teza, że np. moje kape­lu­sze będą mia­ły duży zbyt w gro­nie sno­bów”, to nie pro­gno­zo­wa­nie a plan mar­ke­tin­go­wy. Prognozowaniem było by stwier­dze­nie, że sprze­daż kape­lu­szy dla sno­bów osią­gnie 10 tys. szt. w cią­gu naj­bliż­sze­go roku” i tu fak­tycz­nie moż­na się nie­źle pomy­lić. Nie zmie­nia to fak­tu, że kape­lusz to kape­lusz i nale­ży go zapro­jek­to­wać i wytwo­rzyć, opro­gra­mo­wa­nie wspo­ma­ga­ją­ce sprze­daż kape­lu­szy przez inter­net (jego funk­cjo­nal­ność) nie zale­ży od ilo­ści sprze­da­ży (poza wydaj­no­ścią cało­ści) tyl­ko od tego co i jak chce­my sprzedawać.

Jednak nie zmie­nia to fak­tu, że pro­gram wspie­ra­ją­cy sprze­daż tych kape­lu­szy wyma­ga pew­nej ana­li­zy by zapro­jek­to­wać model dzie­dzi­ny tego opro­gra­mo­wa­nia, tu błąd kosz­tu­je cza­sem tyle, że wyma­ga­ny refak­to­ring (bez któ­re­go nie zre­ali­zu­je­my np. kolej­nej nowej potrzeb­nej funk­cjo­nal­no­ści) ad-hoc pisa­ne­go opro­gra­mo­wa­nia zabi­je budżet całe­go pro­jek­tu. To wyglą­da mniej wię­cej tak (źr. Znaczenie ma nie wiel­kość pro­jek­tu…):

Cykl życia aplikacji

Powyżej wykres poka­zu­ją­cy kosz­ty chwi­lo­we (linia cią­gła) i nara­sta­ją­ce (linia prze­ry­wa­na) pro­jek­tu two­rze­nia i utrzy­ma­nia opro­gra­mo­wa­nia. Linia zie­lo­na to pro­ces z dobrze opra­co­wa­nym pro­jek­tem na począt­ku, czer­wo­na to pro­jekt na żywioł”. 

Racje ma autor pisząc, że w przy­pad­ku start-upów może być dużym ryzy­kiem inwe­sto­wa­nie w pro­jek­to­wa­nie cze­goś co może oka­zać się nie­wy­pa­łem, jed­nak trze­ba pamię­tać, że jeże­li pro­jekt wypa­li, pra­wie na pew­no będzie wyma­gał wte­dy refak­to­rin­gu, by krzy­wa utrzy­ma­nia była jed­nak bliż­sza tej zie­lo­nej (niskie kosz­ty sta­łe to więk­sza marża).

Wodospad, któ­rym się star­szy dzie­ci” to przede wszyst­kim nie linio­wy” pro­jekt na lata (czy jak u auto­ra cyta­tów: 7 mie­się­cy start-up). Wodospad dzi­siaj to jedy­nie uzna­nie, że trzy fazy: ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja, są nie­roz­łącz­ne z czy­ste­go roz­sąd­ku. Prawda jest, że każ­da pro­gno­za wią­że się z ryzy­kiem, jeże­li uzna­my że jest ono duże (a z regu­ły jest), to nie pla­nu­je­my jak kiedyś:

Ryzyko projektu 1

(typo­wy struk­tu­ral­ny pro­ces), tyl­ko dzie­li­my pro­jekt na eta­py (kolej­ne funk­cjo­nal­no­ści) o dłu­go­ści na tyle krót­kiej, by błę­dy pro­gno­zy były akcep­to­wal­ne i nie nisz­czy­ły pro­jek­tu. Wtedy pro­jekt cha­rak­te­ry­zu­je się takim cyklem:

Ryzyko projektu 2

(źr. Mega pro­jek­ty…)

U auto­ra cyta­tów znaj­dzie­my bar­dzo podob­ny wykres, z jed­ną róż­ni­cą: tam jest to szu­ka­nie roz­wią­za­nia meto­dą pro­to­ty­pów, czy­li każ­da dotych­cza­so­wa pra­ca idzie do kosza. W tym przy­pad­ku, jest to prze­my­śla­ny pro­ces, powsta­ły już kod nie jest wyrzu­ca­ny, ale to wyma­ga dobre­go pro­jek­tu (szkie­le­tu archi­tek­tu­ry), obiek­to­wych metod i zasto­so­wa­nia wzor­ców analitycznych.

Autor arty­ku­łu pisze:

Mamy okre­ślo­ny cel biz­ne­so­wy. Nie wie­my, nie zna­my i nie mamy łatwe­go dostę­pu do naj­waż­niej­sze­go udzia­łow­ca ? użyt­kow­ni­ka, nie wie­my, co zro­bić, żeby speł­nić cel biz­ne­so­wy (zakres), tym samym nie wie­my, ile to będzie kosz­to­wać (budżet) i na kie­dy się uda go osią­gnąć (czas).

Wiemy nato­miast, że na pew­no będą zmia­ny i trze­ba jak naj­szyb­ciej z pro­duk­tem pro­jek­tu wejść na rynek.

Współczuję każ­de­mu, kto w tak eks­tre­mal­nych warun­kach, przy tak wiel­kim stop­niu nie­pew­no­ści musi tra­dy­cyj­ny­mi meto­da­mi reali­zo­wać projekt.

Od razu przy­po­mnę, że da się nowo­cze­sny­mi meto­da­mi two­rzyć opro­gra­mo­wa­nie odpo­wia­da­ją­ce powyż­szym wyma­ga­niom: to ma już nawet nawet ład­ną nazwę: SOLID gdzie klu­czo­wą cechą jest to, że tak pro­jek­to­wa­ne i wyko­ny­wa­ne opro­gra­mo­wa­nie jest zamknię­te na zmia­ny i otwar­te na roz­sze­rze­nia” (nie mylić zmian kodu ze zmia­ną stra­te­gii sprze­da­ży), ozna­cza to, że kod nie wyma­ga zmian (refak­to­ring, odrzu­ca­nie pro­to­ty­pów) a pozwa­la na roz­sze­rze­nia (nowe wyma­ga­nia). Metody obiek­to­we to nic inne­go jak odpo­wiedź na powyż­sze potrze­by. Jeżeli autor miał na myśli tra­dy­cyj­ne meto­dy w rodza­ju baza danych i funk­cje” to jestem po jego stro­nie, też współczuję.

Paradoksalnie to co opi­sa­łem jest tań­sze, bo nie­mal­że nic nie idzie do kosza. Każdy etap jest krót­ki więc pra­wie pew­ny”, nie­mal­że żad­na pra­ca nie idzie na mar­ne, sys­tem nie wyma­ga per­ma­nent­nej refak­to­ry­za­cji. Co tu jest waż­ne: zacho­wu­je­my cykl: ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja. Są to wte­dy krót­kie ite­ra­cje, ale zawsze kodo­wa­nie poprze­dza­my ana­li­zą dzie­dzi­ny. Druga waż­na rzecz: nie da się tak pro­wa­dzić pro­jek­tu meto­da­mi struk­tu­ral­ny­mi (naj­pierw baza danych, potem funk­cje) bo model bazy danych z zasa­dy obej­mu­je całą dzie­dzi­nę pro­ble­mu, a tej, jak słusz­nie zauwa­ża autor, nie zna­my (dłu­go­ter­mi­no­wa prognoza). 

Druga wer­sja (opi­sa­na powy­żej) jest rela­tyw­nie tania, moż­na prze­rwać w dowol­nym momen­cie i nie prze­in­we­sto­wać. Jednak rezy­gna­cja z ana­li­zy, któ­rej celem jest zro­zu­mie­nie pro­ble­mu i zde­cy­do­wa­nie o spo­so­bie imple­men­ta­cji to szu­ka­nie kło­po­tów takich jak ten:

most, agile, projektowanie, planowanie

Jak wyglą­da takie «wzor­co­we” pro­jek­to­wa­nie opi­sa­łem w arty­ku­le Plansza do gry w szachy…

Na koniec co nie­co o ryzyku:

ryzyko, popper, decyzje
(Karl Popper)

Tak więc nie ma metod jedy­nie słusz­nych (zwin­ne i nie­zwin­ne, itp.) , są tyl­ko ade­kwat­ne do sytu­acji projektowej.

Nie ma sen­su stra­sze­nie ludzie pro­ble­ma­mi inży­nie­rii opro­gra­mo­wa­nia z przed 30 lat (meto­dy struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia, kosz­tow­ny water­fall)!. Mamy dziś rok 2013, dobrze roz­wi­nię­te meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia, mode­lo­wa­nia, imple­men­ta­cji. Aplikacje biz­ne­so­we moż­na wręcz linio­wo two­rzyć i roz­wi­jać, wystar­czy chcieć przejść na inne meto­dy pra­cy niż te, któ­rych (nie­ste­ty) nadal uczą na stu­diach: funk­cje + struk­tu­ry danych = opro­gra­mo­wa­nie” bo to prehistoria.

Tak zwa­ne pro­jek­ty inter­ne­to­we to tak­że opro­gra­mo­wa­nie, tu tak­że obo­wią­zu­ją pra­wa fizy­ki i eko­no­mii oraz roz­są­dek”. Jeżeli coś je odróż­nia o innych to uży­ta tech­no­lo­gia inter­ne­to­wa” a i to coraz mniej, bo obec­ne opro­gra­mo­wa­nie biz­ne­so­we to coraz częściej„system dostęp­ny przez internet”…

Na pew­no wszel­kie start-up’y to pro­jek­ty inne”, ale to wyni­ka z ich natu­ry biz­ne­so­wej (ryzy­ko powo­dze­nia) a nie tech­no­lo­gicz­nej. Mylenie tych pojęć pro­wa­dzi do wnio­sku, że np. nowy samo­chód pro­to­ty­po­wy kon­stru­uje się ina­czej niż standardowy”.…nie, ina­czej pla­nu­je się finan­so­wa­nie ale deska kre­ślar­ska pozo­sta­je ta sama…

A na tytu­ło­we pyta­nie odpo­wiedź brzmi: nie ist­nie­je taki problem.

wielka ryba kto kogo zjadł wędkarz łowi złowiony

Strategia, model biznesowy, architektura korporacyjna ? jak to powiązać?

Na blo­gu moje­go kole­gi poja­wił się bar­dzo inspi­ru­ją­cy wpis, zakoń­czo­ny prowokacją :):

Oczywiście ? jest to moja pro­po­zy­cja podej­ścia do tema­tu. Będę wdzięcz­ny za Państwa opi­nie. (Strategia, model biz­ne­so­wy, archi­tek­tu­ra kor­po­ra­cyj­na ? jak to powią­zać? | Architektura Korporacyjna).

Charakter mam taki, że na nie­któ­re pro­wo­ka­cje odpo­wia­dam :). Odpowiadam na swo­im blo­gu, a nie bez­po­śred­nio kole­dze na stro­nie jego blo­ga, gdyż zbyt duży tekst mi się zro­bił” :).

W pro­jek­tach patrzę na poję­cia omó­wio­ne w arty­ku­le chy­ba nie­co (ale nie wie­le) ina­czej. Najpierw, zamiast cyta­tów z lite­ra­tu­ry, defi­ni­cje słownikowe:

wizja: czy­jeś wyobra­że­nie jakichś zda­rzeń mają­cych zajść w przy­szło­ści, zwy­kle przed­sta­wia­ne w książ­ce lub w filmie,

misja: posłan­nic­two, waż­ne odpo­wie­dzial­ne zada­nie do spełnienia

stra­te­gia: prze­my­śla­ny plan dzia­łań w jakiejś dziedzinie,

tak­ty­ka: spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu,

Z per­spek­ty­wy defi­ni­cji przy­ta­cza­nych w wyżej cyto­wa­nym arty­ku­le, nie widzę tu koli­zji. Nadając kon­tekst biz­ne­so­wy tym poję­ciom, wizja to wyobra­że­nie pew­nej hipo­te­tycz­nej posta­ci świa­ta (np. ryn­ku). Misja to nasze zada­nie”, to cze­go się podej­mu­je­my by tę Wizję urze­czy­wist­nić. Strategia biz­ne­so­wa to nic inne­go jak plan dzia­łań, przy­ję­ty jako spo­sób reali­za­cji wizji. Taktyka to spo­sób reali­za­cji tego pla­nu czy­li imple­men­ta­cja strategii.

Gdybym miał w ten spo­sób opi­sać swo­ją dzia­łal­ność to napi­sał bym:

Moja wizją są pro­jek­ty, reali­zo­wa­ne w spo­sób spro­wa­dza­ją­cy ich ryzy­ko do zera. Misją moją jest zdo­by­wa­nie i krze­wie­nie wie­dzy pozwa­la­ją­cej reali­zo­wać pro­jek­ty ide­al­ne. Strategia jaka przy­ją­łem, to samo­dziel­ne stu­dia, wyko­ny­wa­nie zawo­du ana­li­ty­ka i dzie­le­nie się zdo­by­tą wie­dzą. Taktyka dzie­le­nia się wie­dzą to pro­wa­dze­nie szko­leń, wygła­sza­nie refe­ra­tów na kon­fe­ren­cjach i pro­wa­dze­nie bloga.

Ponad sześc lat temu pisa­łem o mode­lu biznesowym:

Poprawnie wyko­na­ny model biz­ne­so­wy opi­su­je i defi­niu­je zarazem:

- źró­dła zaopatrzenia

- kana­ły zbytu

- wpływ konkurencji

- głów­ne źró­dło mar­ży (zysku)

- źró­dła zagrożeń

(uza­sad­nie­nie powyż­sze­go w Model biz­ne­so­wy…).

Wygląda więc na to, że model biz­ne­so­wy to w zasa­dzie tak­ty­ka reali­za­cji (jakiejś usta­lo­nej ) stra­te­gii (ryn­ko­wej).

Połączenie pojęć: misja, wizja, stra­te­gia, tak­ty­ka oraz archi­tek­tu­ra kor­po­ra­cyj­na, jak je wyko­nać? W arty­ku­le Nowa spe­cy­fi­ka­cja Business Motivation Model 1.2 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Przedstawia on mię­dzy inny­mi powyż­sze poję­cia i ich wza­jem­ne powią­za­nia. Jak widać, są to poję­cia zgod­ne z przy­ta­cza­ny­mi defi­ni­cja­mi (pole­cam lek­tu­rę spe­cy­fi­ka­cji mode­lu poję­cio­we­go i nota­cji BMM). Wizja to stan koń­co­wy, misja jest ele­men­tem zbio­ru środ­ków słu­żą­cych do osią­ga­nia wizji”. Mamy tu: misję oraz powią­za­ną z nią stra­te­gię i tak­ty­kę (jako imple­men­ta­cję strategii).

Gdzie tu Architektura Korporacyjna? Andrzej Sobczak (autor cyto­wa­ne­go arty­ku­łu) przy­ta­cza taką definicję:

archi­tek­tu­ra kor­po­ra­cyj­na (w jed­nym z jej ujęć) to for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie. Przy czym kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne. (Strategia, model biz­ne­so­wy, archi­tek­tu­ra kor­po­ra­cyj­na ? jak to powią­zać? | Architektura Korporacyjna).

I teraz war­to zwró­cić uwa­gę na to, że for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi” to struk­tu­ra orga­ni­za­cyj­na. Dalej mamy opis pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie” czy­li wizje, misję, stra­te­gię oraz tak­ty­kę fir­my, decy­zje jej Zarządu. Patrząc na stwier­dze­nie, że kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne” nale­ży uznać, że struk­tu­rę orga­ni­za­cyj­ną nale­ży uzu­peł­nić wie­dzą o narzę­dziach jakie Ci ludzie dosta­ją by poma­ga­ły im reali­zo­wać ich zada­nia, czy­li mię­dzy inny­mi sys­te­my infor­ma­tycz­ne (tak, one są jedy­nie narzędziami).

Pozostał nam fakt, że to powi­nien być for­mal­ny opis”. Zaglądamy do Encyklopedii PWN i czytamy:

język for­mal­ny: (inform.) język zło­żo­ny ze wszyst­kich słów (wyra­żeń) uzy­ski­wa­nych za pomo­cą ści­śle okre­ślo­nych reguł;

Czyli potrzeb­na jest nota­cja (sys­tem poję­cio­wy: prze­strzeń nazw). Jak widać mamy do dys­po­zy­cji BMM, któ­ry pasu­je” do oma­wia­ne­go pro­ble­mu. Uzupełniona sys­te­ma­mi poję­cio­wy­mi dzie­dzi­no­wy­mi” czy­li BPMN (pro­ce­sy biz­ne­so­we powią­za­ne z zaso­ba­mi) oraz UML (struk­tu­ry i sys­te­my) mam kom­plet­ny i spój­ny poję­cio­wo (dba o to orga­ni­za­cja OMG) zestaw narzę­dzi sta­no­wią­cy w moich oczach odpo­wiedź na tytu­ło­we pytanie.

I teraz moja kon­klu­zja: bazu­jąc na brzy­twie Ockhama” pod­ją­łem pró­bę spraw­dze­nia czy przy­pad­kiem odpo­wiedź na tytu­ło­we pyta­nie sfor­mu­ło­wa­ne przez Andrzeja, już nie ist­nie­je… Odnoszę wra­że­nie, że wła­śnie pra­ce OMG, ich wynik, są chy­ba odpo­wie­dzią na to pyta­nie. Faktem jest, że nie wprost, ale chy­ba ana­li­zu­jąc te sys­te­my poję­cio­we, archi­tek­tu­rę kor­po­ra­cyj­na oraz BMM, moż­na uznać, że tytu­ło­we powią­za­nie ist­nie­je. Opisałem to z nie­co innej stro­ny w arty­ku­le Architektura Korporacyjna z OMG.