Mamy więc pomysł o wdzięcz­nej nazwie Architektura Korporacyjna. Po nam to? Po co nam taka doku­men­ta­cja? Przykłady korzy­ści z jej posiadania:

mamy ​„na tacy” model sys­te­my zależ­no­ści (ana­li­zy wpły­wu) pozwa­la­ją­cy natych­miast oce­nić ryzy­ka zwią­za­ne z wza­jem­nym wpły­wem na sie­bie pro­ce­sów, ludzi, zaso­bów (np. jakie skut­ki będzie mia­ło wyłą­cze­nie kon­kret­ne­go ser­we­ra czy spóź­nie­nie do pra­cy kon­kret­ne­go pracownika),
mamy ​„na tacy” wyma­ga­nia na opro­gra­mo­wa­nie, bez nie­po­trzeb­ne­go ​„zwin­ne­go” ich poszu­ki­wa­nia meto­dą prób i błę­dów, nie­za­leż­nie od tego czy kupu­je­my nowe czy wymie­nia­my (nie­ste­ty, tak zwa­ne zwin­ne meto­dy to nie raz bar­dzo duże kosz­ty ​„zarzu­co­nych bocz­nych ście­żek” odkry­wa­nych burzą mózgów),
od razu zauwa­ży­my, że idea posia­da­nia mono­li­tycz­ne­go sys­te­mu ERP II nie bar­dzo ma sens (to usztyw­nia orga­ni­za­cje oraz two­rzy potęż­ny [[„sin­gle point of failu­re”]], zło­śli­wi doda­ją ​„sin­gle point of big cost” :)),
i naj­waż­niej­sze: jak tyl­ko prze­pro­wa­dzi­my ana­li­zę i wyko­na­my model AK szyb­ko wychwy­ci­my tak zwa­ne osie­ro­co­ne wyma­ga­nia na opro­gra­mo­wa­nie, osie­ro­co­ne sta­no­wi­ska pra­cy, osie­ro­co­ne pro­ce­du­ry, … (osie­ro­co­ne: nie­wy­ko­rzy­sty­wa­ne), to nie raz źró­dło samo w sobie – eli­mi­na­cja ​„sie­rot” – ogrom­nych oszczędności,
i inne …
Jak tym zarzą­dzać? Na pew­no nie ręcz­nie, bez opro­gra­mo­wa­nia CASE w zasa­dzie nie­re­al­ne. Czy to kosz­tow­ne? Hm… kła­nia się ana­li­za ROI, więc każ­da orga­ni­za­cja ma swój próg ren­tow­no­ści. Jednak od sie­bie powiem tak: oszczęd­no­ści poja­wia­ją się natych­miast w posta­ci iden­ty­fi­ka­cji ​„sie­rot”. Kolejny etap oszczęd­no­ści to reor­ga­ni­za­cja kosz­tów i ryzyk zarzą­dza­nia orga­ni­za­cją, kosz­tów posia­da­nia opro­gra­mo­wa­nia, kosz­tów jego roz­wo­ju, kosz­tów zaku­pu i two­rze­nia. Dobra wia­do­mość: począ­tek każ­dy już ma w posta­ci pro­wa­dzo­nej doku­men­ta­cji w dzia­le HR.