To, że są one tak na praw­dę tyl­ko upo­rząd­ko­wa­nym zapi­sem wywia­dów z klien­tem a nie fak­tycz­ną ana­li­zą orga­ni­za­cji i jej potrzeb (bo nie koniecz­nie jej pra­cow­ni­ków!) i celów biz­ne­so­wych. Jakie są tre­ści tek­sto­we­go lub tabe­la­rycz­ne­go zapi­su wywia­dów? NIEJEDNOZNACZNE! Jakie są nie­sfor­ma­li­zo­wa­ne, swo­bod­nie two­rzo­ne dia­gra­my pro­ce­sów? NIEJEDNOZNACZNE! Jakie są słow­ne opi­sy struk­tu­ry opro­gra­mo­wa­nia jakie ma powstać? NIEJEDNOZNACZNE!

Co zro­bić? Używać już na eta­pie ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia sfor­ma­li­zo­wa­nych narzę­dzi takich jak stan­dar­do­we nota­cje i meto­dy­ki, wte­dy opi­sy będą JEDNOZNACZNE. Czy to trud­ne? Tak, w koń­cu te 70% pora­żek to nie przy­pa­dek? ( czy­taj cały arty­kuł: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność z doku­men­tów analitycznych!).

Dlaczego tak jest? Bo opro­gra­mo­wa­nie jest two­rzo­ne z pomo­cą języ­ków pro­gra­mo­wa­nia a te SĄ sfor­ma­li­zo­wa­ne. Nie da się skom­pi­lo­wać do posta­ci sys­te­mu ERP ​„luź­nej pro­zy”. Napisałem to w Listopadzie 2011, dzi­siaj ciąg dal­szy. Na począ­tek dodam jesz­cze moją kon­klu­zję z pew­nej konferencji:

Tak więc język for­mal­ny, uży­ta nota­cja, czy­ni pro­jekt war­to­ścio­wym [jed­no­znacz­nym]. Bez tego raczej nie zna­czy on po pro­tu nic. (Modelowanie pro­ce­sów biz­ne­so­wych – dla­cze­go mają sens tyl­ko meto­dy for­mal­ne i uzna­ne notacje).

Jak to mówią: moc­ne sło­wa, ale nie zapo­mi­naj­my, że mało któ­ry pro­jekt biz­ne­so­wy IT koń­czy się w ter­mi­nie i zamy­ka w zało­żo­nym budże­cie. Zastanówcie jak były doku­men­to­wa­ne Wasze ​„nie­uda­ne” projekty…