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.

Continue ReadingTablice 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).

Continue ReadingTablice decyzyjne – fakty a nie procesy

Nowy paradygmat systemowy

Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić? Opisać strategie rynkową firmy, Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów), Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych, Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści, Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi. Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA) Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.

Continue ReadingNowy paradygmat systemowy

Modelowanie biznesowe

Model organizacji to: opis motywacji jej działania, opis ludzi, jacy realizują wewnętrzne zadania, opis reguł jakie regulują ich zachowaniami. Całość (model) powinna być na tyle uporządkowana, by model był w 100% jednoznaczny, czyli kluczowe pojęcia w nim użyte powinny być zebrane w jeden wewnętrzny, spójny biznesowy słownik tej organizacji. To wszystko dopiero pozwoli stworzyć model procesów biznesowych, czyli wewnętrzne scenariusze zachowania. Samo utworzenie map (bo nie modeli) w postaci diagramów procesów z pomocą wywiadów, sesji warsztatowych i obserwacji, da produkt podobny do zdjęcia lotniczego rzeki: wiemy którędy płynie, ale kompletnie nie rozumiemy dlaczego akurat tak. Mamy jedynie udokumentowany stan obecny. Ingerencja w ten stan rzeczy, bez zrozumienia reguł rządzących tym jak i którędy płynie woda, kończy się nie raz katastrofami jakie znamy z doniesień o powodziach i zalaniach ostatnich lat. Bez poznania zasad rządzących zachowaniem się organizacji można "nie uniknąć problemów przy wprowadzaniu zmian". Każda reorganizacja, a w szczególności jest nią wdrażanie nowego oprogramowania, jest taką zmianą. Ta książka jest o modelowaniu organizacji.

Continue ReadingModelowanie biznesowe

Ile tego ma być … analiza i model procesów biznesowych

Tak więc analiza organizacji i opracowanie jej modelu to trudna, praca, nie raz długa, ale nie powinny to opasłe księgi. Dobry model organizacji to właśnie broszurka, która odpowiada na pytanie "dlaczego". Jeżeli wynikiem analizy są opasłe księgi to znaczy, że mamy jedynie dziesiątki nagrań kolejnych partii szachów a nie reguły tej gry... a wtedy nadal nie wiemy "dlaczego". Co ciekawe, każda organizacja ma, lub powinna mieć, taką instrukcję: jest to lista stanowisk (struktura organizacyjna) i reguły gry w postaci wewnętrznych zarządzań i procedur. Ale powinna ona być spójna i kompletna. Przypomnę, że każda organizacja jakoś funkcjonuje, a mało która ma mapy procesów biznesowych. Po co więc te modele procesów? Wróćmy do wspomnianej na początku "piramidy". Jej szczyt to cele, model biznesowy: chcemy grać w szachy i wygrywać. Jej najniższa warstwa to figury i reguły gry. Czym jest środkowa warstwa, czym są te modele procesów biznesowych? Dobry szachista ma pewne z góry przewidziane scenariusze, są to "gotowe" rozwiązania na pewne powtarzająca się sytuacje na szachownicy. One oczywiście nie są w stanie zastąpić szachisty, ale bardzo ułatwiają mu grę, raz przećwiczone i uznane za "dobre" i skuteczne scenariusze, stosuje zawsze gdy napotka "standardową sytuację". Organizacje także je mają, to właśnie procesy biznesowe, ale nie jest to recepta na pracę firmy, takiej nie jesteśmy w stanie stworzyć. Procesy biznesowe, te udokumentowane by służyły firmie, to wszystkie te przewidywalne, powtarzające się scenariusze, które stanowią tak na prawdę nasze organizacyjne know-how. Cała reszta to kompetencje naszych pracowników a tych nie modelujemy, z nich korzystamy.

Continue ReadingIle tego ma być … analiza i model procesów biznesowych