Tak więc jest meto­da, prak­ty­ka poka­zu­je, że spraw­dza się. Praktyka poka­zu­je tak­że, że nie­ste­ty nie jest to łatwe (mode­lo­wa­nie biz­ne­su meto­da­mi obiek­to­wy­mi, tu nie­ste­ty nie da się powie­dzieć, że ​„nie świę­ci garn­ki lepią”) dla­te­go powsta­ły pew­ne zale­ce­nia i wzor­ce pro­jek­to­we. Należy je zro­zu­mieć, nauczyć się sto­so­wać i sto­so­wać, co i tak nie zastą­pi ​„pro­jek­to­wa­nia” czy­li twór­cze­go pier­wiast­ka w tym pro­ce­sie. Dokładnie tak samo jak nie da się auto­ma­tycz­nie two­rzyć kodu pro­gra­mu, do tego potrzeb­ni są (dobrzy) programiści.

Z prze­ko­rą powiem też, że nie wiem jak zwin­ność metod pro­gra­mi­stycz­nych ([[Agile Manifesto]]) mia­ła by ten pro­ces uzdro­wić i uczy­nić lep­szym (nadal uwa­żam, że brak doku­men­ta­cji, w tym mode­li, raczej psu­je pro­jek­ty). Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (CIM) oraz spe­cy­fi­ka­cja tego co ma powstać (PIM), to dru­gie to kom­plet­ne wyma­ga­nia. Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: imple­men­ta­cji mode­lu PIM, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne) oraz dostar­cze­niu i wdrożeniu.
Powyższe, tak udo­ku­men­to­wa­ny pro­jekt, pozwa­la tak­że osią­gnąć dodat­ko­wą korzyść: ​„wie­dza orga­ni­za­cji” tkwi w mode­lu PIM i deve­lo­per nie może jej prze­jąć bez zgo­dy auto­ra, Analityka Biznesowego i spon­so­ra pro­jek­tu (pra­wo autorskie).