Read more about the article Teoria a praktyka – czyli kompetencyjna tragedia
nie istnieją proste rozwiązania złożonych problemów

Teoria a praktyka – czyli kompetencyjna tragedia

Co jakiś czas czytamy o porażkach projektów w sferze publicznej, zapewniam, że są one nie takim rzadkim zjawiskiem w sferze prywatnej. Dlaczego nie czytamy o tym? Bo, na szczęście dla firm prywatnych, nie dotyczy ich ustawa o dostępie do informacji publicznej itp., projekt nabywa status "tajemnica korporacji"' i nikt nie wie poza tymi, co brali udział w projekcie. Miewam konsultacje, korepetycje, coaching itp. Pytany jestem często: "czy zdarza się Panu w projektach, że np. kierownik projektu mówi, że nie ważna jest jakość tych projektów tylko termin i protokół odbioru, klient i tak nie potrafi tego skontrolować". Powiem tak, zdarza mi się i wtedy odmawiam albo rezygnuje z udziału w projekcie, jednak ja nie mam umowy o prace i jestem nią szantażowany (jej utratą). Prawdę mówiąc nie wiem co mam tym ludziom mówić, poza powyższym oczywiście, ale i tak zawsze mówię: bądź uczciwy (co jest bardzo trudne).

Czytaj dalejTeoria a praktyka – czyli kompetencyjna tragedia

Tablice decyzyjne – fakty a nie procesy

Tak więc, reguły biznesowe to ogólno-organizacyjne ograniczenia. Tablice decyzyjne to rodzaj "wiedzy" wpisanej w punkty podejmowania decyzji. Na modelach (diagramach) procesów biznesowych modelujemy jedynie skutki, czyli reakcje na podjęte - zgodnie z tablicą - decyzje. Gdyby modelować powyższe na diagramie np. BPMN, mielibyśmy bramkę z czterema wyjściami, każde wyjście reprezentował by wiersz Działań. Jak widać spodziewać się należy tu bramek XOR (alternatywa wyłączna) lub OR (alternatywa "zwykła"). Na diagramach BPMN za bramką byłyby czynności nazwane tak jak działania w wierszach. Aby nie komplikować nazewnictwa tych diagramów, tablica decyzyjna użyta z diagramem BPMN miała by wiersze Działań nazwane np. odpowiednio Wariant-1, Wariant-2 itd. a czynności były by umieszczone już na diagramie. Tego typu tablice doskonale nadają się do modelowania systemów rabatowych, lojalnościowych, wartości kredytów kupieckich, wag scoringu kredytów i wielu innych, w których kombinacje skończonej liczby czynników tworzą deterministyczną, skończoną liczbę dopuszczalnych zachowań. Na diagramie procesu powołujemy się wyłącznie na nazwę tablicy (np. kojarząc ją z konkretną czynnością) zamiast modelować skomplikowane przebiegi. Dlaczego? Bo warto pamiętać, że decyzja - nawet bardzo skomplikowana - nie jest procesem a zaistniałym faktem, odpowiedzią na zastane warunki Jak widać, reakcja kierowcy na sygnalizator, to nie proces a fakt. Jest to konkretna reakcja na konkretną kombinację kolorów świateł na sygnalizatorze. W przypadku analizy wymagań, stosowanie tablic decyzyjnych, jako narzędzia specyfikowania pewnych zachowań systemu, jest bardzo wygodne bo po pierwsze: jest jednoznaczne, po drugie tablice decyzyjne to już standardowe narzędzie w inżynierii oprogramowania i nie trzeba wymyślać ich implementacji (np. w postaci maszyny stanowej: reguły to zdarzenia a działania do przejścia).

Czytaj dalejTablice decyzyjne – fakty a nie procesy

Koniec treści

Nie ma więcej stron do załadowania