analiza systemowa

Read more about the article Tablice decyzyjne

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

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.

Continue ReadingAnaliza przyczyn wypadków – gdzie fotoradary
Read more about the article Od biznesu do przypadków użycia

Od biznesu do przypadków użycia

Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w "oryginale" Use Case (UC). Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na "polecenia". Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia. Generalnie diagram PU jest bardzo dobrym "korzeniem" do analizy i tworzenia pozostałych modeli, ale bez powstającego "natychmiast" modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów. Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na "strawne" kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje. Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek....

Continue ReadingOd biznesu do przypadków użycia

Business Model Canvas vs. Business Motivation Model

Jak widać, "klasyczny" model biznesowy pokazuje tylko "co jest przedmiotem działalności i kluczowym źródłem zysku". Model taki jest modelem procesu, ten proces jednak to tylko opis tego co, jaką wartość dodaną, dana organizacja dostarcza swoim klientom i gdzie się zaopatruje. Model to-Be opisuje stan pożądany, nie daje żadnej wiedzy o tym, jak do niego dojść. Model As-is i To-be ma lukę pomiędzy tymi As-Is i To-be. Tę lukę wypełnia moim zdaniem kompletny model BMM - każe "opracować" strategię, taktykę, analizę SWOT, ryzyka i inne mające wpływ na osiągnięcie celu, a nawet na to czy jest on w ogóle osiągalny. Po co to wszystko? Bo dobra analiza, powinna być sama dla siebie dowodem słuszności jej wyników (dlatego nie raz tu napisałem, że powinna być prowadzona "metodą naukową").

Continue ReadingBusiness Model Canvas vs. Business Motivation Model