Tablice decyzyjne

Wiele firm ma problemy zarządcze nie dlatego, że są źle zarządzane, ale dlatego, że stopień złożoności tych firm jest zbyt duży by podejmować je na wyczucie. W obecnych czasach decyzje muszą być podejmowane w relatywnie krótkim czasie bo rynek nie czeka, jednak jakość tych decyzji nie powinna być zła. Dlaczego bywa zła? Bo decyzje są nie raz podejmowane z niepełnym zrozumieniem sytuacji. Podejmowana decyzja, by była możliwie najlepsza, wymaga pełnego zrozumienia, tego czego dotyczy (co chyba nie jest dziwne). Jeżeli dotyczy firmy, nie powinno się podejmować decyzji bez pełnego zrozumienia potencjalnego wpływu tej decyzji na firmę. W przeciwnym wypadku skutki są dość losowe, czyli nie zarządzamy a staramy się zarządzać. [...] Analiza biznesowa organizacji poprzedzająca np. wdrożenie nowego oprogramowania, powinna polegać na wykonaniu audytu i uporządkowaniu reguł decyzyjnych oraz opracowaniu modeli procesów biznesowych by je zweryfikować. Drugi krok to ocena, jakiej wiedzy oczekujemy od ludzi (ich umiejętności i wiedza). Dokumentujemy ją z obawy przed "błędem ludzkim". Tu zwracam uwagę na to, że wymaganiem na oprogramowanie może być tablica decyzyjna, jeżeli planujemy automatyzację jakiejś czynności. Proces biznesowy nie jest wymaganiem, to co najwyżej kontekst wykonywanych czynności.

Czytaj dalejTablice decyzyjne

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

Analiza przyczyn wypadków – gdzie fotoradary

Problem widzę gdzie indziej. Mamy może dobre prawo o ruchu drogowym ale fatalne jego stosowanie. Zaufanie do znaków drogowych maleje, bo stawiane są nie raz w sposób niezrozumiały nie tylko dla przeciętnego kierowcy. Po drugie zaś, nauczyliśmy się, że egzekwowanie prawa jest w Polsce na bardzo niskim poziomie i wielu ludzi niestety oswoiło się z bezkarnością. Tak więc widzę ogromną potrzebę dyskusji o tym jakie i gdzie zakazy na drogach się stawia, a nie o tym czy podnoszenie skuteczności egzekwowania prawa z pomocą fotoradarów jest złe bo jest bardzo dobre, czytaj skuteczne. Czy podnoszenie trudności uzyskania prawa jazdy, "mierzenie zdolności", nie jest także bezsensowne? Oczekiwał bym więc więcej kompetencji od 'ustawodawcy". A od mediów i polityków atakujących fotoradary oczekiwał bym więcej przemyśleń i odpowiedzialności w krytykowaniu podnoszenia skuteczności egzekwowania prawa. Problemem jest jakość prawa a nie egzekwowanie prawa złego, bo to prowadzi do usankcjonowania tego, że ono jest złe. Widzę inne zagrożenie brnięcia w tłumaczenia, że skoro prawo jest złe to nie powinno być (z pomocą fotoradarów) restrykcyjnie egzekwowane: skoro nikt nie przestrzega prawa mimo tego, że ono istnieje, to znaczy. że można uznaniowo ukarać każdego kogo sobie "wybierzemy", komu na rękę taka sytuacja? Moim zdaniem, jako społeczeństwo, powinniśmy się bronić nie przed fotoradarami, a przez psuciem prawa.

Czytaj dalejAnaliza przyczyn wypadków – gdzie fotoradary

Model-Driven Software Engineering in Practice

Większość książek z dziedziny analizy systemowej i inżynierii oprogramowania to książki "techniczne" opisujące notacje, przykłady ich stosowania czy wręcz konkretne metody pracy stosowane przez ich autorów. Tym razem książka nieco inna. Cytat z okładki: Ta książka to dyskusja o tym jak podejście zorientowane na modele doskonali codzienną prace profesjonalistów inżynierii oprogramowania. Podejście to znane jest jako Inżynieria Oprogramowania Zorientowana na Modelowanie (Model-Driven Software Engineering, MDSE). Celem autorów książki jest pokazanie aktualnego stanu wiedzy na ten temat i ich doświadczenia. Bardzo często dyskusje na forach, książki opisujące konkretne "sposoby postępowania" to…

Czytaj dalejModel-Driven Software Engineering in Practice

Polski rynek MSP z małym żalem…

W wielu polskich firmach zarządy są - wbrew temu co sami o sobie myślą - bardzo słabe. Wyposażenie handlowca to wynik żądań handlowca a nie realnych potrzeb jego sponsora. Drogi samochód i wydatki na paliwo porównywalne z comiesięczną ratą leasingową na ten samochód, z reguły wygrywają z oprogramowaniem wspomagającym zarządzanie, z bardzo prostego powodu: samochód widać gołym okiem a wydatki na paliwo "świadczą o tym, że handlowiec ciężko pracuje", oprogramowanie (15EUR za licencje miesięcznie to tylko 60zł kosztów na osobę!) z "gatunku" CRM nie przynosi żadnych korzyści handlowcom nastawianym na "dojenie pracodawcy" i żadnych korzyści właścicielom firm, których jedyna wiedza o sprzedaży zamyka się na tezie "trzeba być u klientów i sprzedawać".

Czytaj dalejPolski rynek MSP z małym żalem…

Architektura korporacyjna z OMG​.org

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.

Czytaj dalejArchitektura korporacyjna z OMG​.org

O językach…

Od czasu do czasu słyszę od niektórych ludzi, że język UML jest nieprzydatny, bo nie pomaga mu w projektach... ale to tak, jak by osoba oblewająca pisemną maturę z wiedzy o historii powiedziała, że język polski jest do pisania nieprzydatny... Ale uwaga! Nie mniej błędne jest stwierdzenie, że jeżeli coś jest napisane bez błędów językowych, z zasady jest dobre... (mój komentarz po pewnej dyskusji na forum o UML, o wielu innych notacjach można powiedzieć to samo...)

Czytaj dalejO językach…

Koniec treści

Nie ma więcej stron do załadowania