I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.
Na konferencjach i forach toczą się stale dyskusje na ten temat. Większość firm doradczych, informatycznych i ich analitycy bronią tezy, że celem analizy jest zebranie informacji w postaci dokumentów i zestawień. Niestety takie dokumenty są kompletnie nieprzydatne, mają wartość nagrania (patrz wyżej zdjęcie lotnicze), nie da się na ich postawie wyciągać żadnych pozwalających na dowodzenie ich słuszności, wniosków nie licząc może oceny estetyki edytorskiej. Niewątpliwą "zaletą takiej analizy" jest to, że nie wymaga ona absolutnie żadnych kompetencji poza umiejętnością komunikacji. Takim analitykiem może być niemalże każdy (łatwa rekrutacja, niski koszt), ale czy taki jest cel analiz poprzedzających projekty, warte setki tysięcy złotych a nie raz miliony?Na zakończenie dodam, że najgorszym sposobem jaki znam i jaki niestety często spotykam, na modelowanie struktury organizacyjnej, jest użycie diagramu klas lub diagramu przypadków użycia i modelowanie z zastosowaniem dziedziczenia (klas lub aktorów).
Mamy więc pomysł o wdzięcznej nazwie Architektura Korporacyjna. Po nam to? Po co nam taka dokumentacja? Przykłady korzyści z jej posiadania:mamy "na tacy" model systemy zależności (analizy wpływu) pozwalający natychmiast ocenić ryzyka związane z wzajemnym wpływem na siebie procesów, ludzi, zasobów (np. jakie skutki będzie miało wyłączenie konkretnego serwera czy spóźnienie do pracy konkretnego pracownika), mamy "na tacy" wymagania na oprogramowanie, bez niepotrzebnego "zwinnego" ich poszukiwania metodą prób i błędów, niezależnie od tego czy kupujemy nowe czy wymieniamy (niestety, tak zwane zwinne metody to nie raz bardzo duże koszty "zarzuconych bocznych ścieżek" odkrywanych burzą mózgów), od razu zauważymy, że idea posiadania monolitycznego systemu ERP II nie bardzo ma sens (to usztywnia organizacje oraz tworzy potężny [["single point of failure"]], złośliwi dodają "single point of big cost" :)), i najważniejsze: jak tylko przeprowadzimy analizę i wykonamy model AK szybko wychwycimy tak zwane osierocone wymagania na oprogramowanie, osierocone stanowiska pracy, osierocone procedury, ... (osierocone: niewykorzystywane), to nie raz źródło samo w sobie - eliminacja "sierot" - ogromnych oszczędności, i inne ... Jak tym zarządzać? Na pewno nie ręcznie, bez oprogramowania CASE w zasadzie nierealne. Czy to kosztowne? Hm... kłania się analiza ROI, więc każda organizacja ma swój próg rentowności. Jednak od siebie powiem tak: oszczędności pojawiają się natychmiast w postaci identyfikacji "sierot". Kolejny etap oszczędności to reorganizacja kosztów i ryzyk zarządzania organizacją, kosztów posiadania oprogramowania, kosztów jego rozwoju, kosztów zakupu i tworzenia. Dobra wiadomość: początek każdy już ma w postaci prowadzonej dokumentacji w dziale HR.
Stosowanie opisanych tu formalizmów to uznanie, że dobre i sprawdzone standardy pozwalają zminimalizować ryzyko projektów analitycznych.Analiza to nie zbieranie danych o firmie i ich sortowanie, bo czy to nie brzmi jak ekologiczne zbieranie śmieci? Analiza to porządkowanie zebranej wiedzy o organizacji, korzystając z wypracowanych systemów pojęciowych, czyli przyporządkowywanie wszystkiego co wiemy do skończonej liczby pojęć, oraz uzupełnianie lub naprawianie wszystkiego czego zabranie w tak opracowanym modelu. Kluczem dobrej analizy jest uogólnianie czyli wychwytywanie rzeczy istotnych oraz odsiewanie informacji zbędnych, nie mających wpływu na cel projektu a zaciemniających go. Analiza to odkrywanie i rozumienie reguł, panowanie nad złożonością organizacji.Większość projektów takich jak np. wdrażanie nowych metod kontrolingu, zrównoważonej karty wyników, nowych systemów IT itp. cierpi głównie z powodu posiadania nadmiaru informacji z jednej strony i kompletnego jej niezrozumienia z drugiej. Sławne już w badaniach "złe i niekompletne wymagania" czy "zmiany zakresu projektu w trakcie jego trwania" to klasyczne skutki złej (a często pomijania!) analizy biznesowej. Koszty tych porażek wielokrotnie przewyższają koszt takich analiz.
Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu.UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań.Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.
