Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Mapa (model) procesów oraz struktura organizacyjna, by były jednoznaczne, muszą być także zestawem zdefiniowanych pojęć. Musimy wiedzieć co znaczy słowo: przełożony, podwładny, komórka organizacyjna czy jej kierownik. Jeszcze większym wyzwaniem zdefiniowanie systemu pojęć dla mapy procesów (proces, czynność, zdarzenie, dokument...). Budowanie systemów pojęciowych spełniających powyższe warunki jest bardzo trudne dlatego dla modeli procesów biznesowych najlepiej wykorzystać gotowy model pojęciowy: jest nim notacja. Najlepiej obecnie opracowanym takim modelem pojęciowym jest gotowa notacja [[BPMN]]. Tworzenie własnych jest kosztowne (czas i wiedza osoby opracowującej) i bardzo ryzykowne (może się nie udać). Dlatego używanie dzisiaj własnych lub innych (np. dostosowywane profilami diagramy UML) jest w moich oczach nieracjonalnym podejściem. Model pojęć specyficzny dla danej organizacji niestety musi powstać "od zera", podobnie jak powiązana z nim specyfiakcja reguł biznesowych. Jest to trudne bo tworzenie przestrzeni nazw wymaga utrzymania niezależności poszczególnych definicji i spójności i zupełności całego ich systemu. Niedochowanie tych wymagań prowadzi do niepełności a nawet sprzeczności reguł biznesowych, które w końcu są budowane (odkrywane i dokumentowane) z pomocą tych pojęć. Zanim wiec zaangażujesz kogoś do modelowania własnej firmy, upewnij się, komu zlecasz tę pracę... W bardzo dużym więc skrócie: procesy biznesowe to faktyczny, widoczny sposób pracy firm (ludzi w nich zatrudnionych), procesy to efekt funkcjonowania ludzi w środowisku ograniczeń, należy poznać tych ludzi, ograniczenia to: procedury, prawo, zarządzenia wewnętrzne oraz specyficzne dla firmy wewnętrzne normy zwane regułami biznesowymi, opracowanie biznesowego modelu firmy wymaga zrozumienia i opisania tego co powyżej opisałem, nie istnieje droga na skróty. ...

Continue ReadingReguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!

"Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty". Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani. Rola Kierownika Projektu to między innymi zarządzanie ryzykiem. Statystyki są nieubłagane, więc brak dobrego analityka i dobrej analizy wymagań spycha projekt w kierunku kłopotów. No to mamy kolejne badanie: Znaczenie i zapotrzebowanie na specjalistów wg. Forrestera: 70% badanych decydentów uważa, że Analityk Biznesowy to kluczowa postać w projekcie. Jednak nie dlatego, że jest ważniejszy od np. kierownika projektu, bo nie jest ważniejszy. Dlatego, że od jakości jego produktu (analiza i specyfikacja wymagań) zależy właśnie ryzyko całego projektu. Co jest wadą większości analiz biznesowych? To, że są one tak na prawdę uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji, jej potrzeb (bo raczej 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...

Continue ReadingAnalityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!

Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną). Innymi słowy: jeżeli jakieś ziarno węgla jest kostką to na pewno nie jest ani groszkiem, ani orzechem ani miałem. A co jeżeli jednak wynik analizy jest opisem w języku naturalnym lub zestawem diagramów łamiących zasady notacji? Wtedy tak naprawdę analitykami są programiści, bo oni i tak muszą to zamienić na kod w języku programowania, którego używają. Czy to dobry pomysł? Pozostawię odpowiedź czytelnikowi...

Continue ReadingLogika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

Udziałowcy projektu czyli który diagram UML …

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.

Continue ReadingUdziałowcy projektu czyli który diagram UML …