Autor w kilku miejscach Silver sam przyznaje, że "nagina" semantykę notacji, nie licząc kilku "drobnych" nagięć (odsyłam do lektury), "poważnym" nagięciem jest praktycznie zmiana znaczenia pojęcia pool z "biznes" na "proces". Dziwi mnie to, gdyż proces to "diagram" w BPMN (definicja pojęcia proces biznesowy to pragmatyka a nie element tej notacji). Prowadzi to niezgodności z modelem współpracy. Jednak zainteresowanym proponuje jednak przeczytanie uzasadnienia w treści książki i samodzielna ocenę.
To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!
Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!).
Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP "luźnej prozy". Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji:
Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych - dlaczego mają sens tylko metody formalne i uznane notacje).
Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze "nieudane" projekty...
