Macierz RACI czyli jak nie zużyć hektara papieru

Kolejne przeprowadzone szkolenia za mną, kolejna seria trudnych pytań też. Na szkoleniach z analizy biznesowej podaję, poza opisem dobrych praktyk, także anty-przykłady. Jednym z typowych anty-przykładów są diagramy zbyt szczegółowe, w szczególności próby “narysowania” konsultacji, serii zapętlonych zgłaszanych uwag do dokumentów i ich akceptacji, dziesiątek przekazywanych komuś innemu informacji. Diagram procesu BPMN nafaszerowany dziesiątkami rombów z wieloma wyjściami w rodzaju kto i w jakich warunkach ma coś skontrolować, zaakceptować, odesłać do poprawy itp. To mega diagramy, niemożliwe do zrealizowania próby algorytmizacji pracy modelowanej firmy (żadna firma nie jest deterministyczna). Przypomnę, że na poziomie procesów biznesowych (wewnętrzny łańcuch wartości) “pętle wstecz” reprezentują cofnięcie się w czasie, a czy to faktycznie ma miejsce?

Czytaj dalej Macierz RACI czyli jak nie zużyć hektara papieru

Program budowy kompetencji

Wprowadzenie Od 1991 roku zajmuję się analizami wymagań i potrzeb organizacji jako analityk biznesowy i projektant architektury systemów IT. Od 1998 roku prowadzę także własne badania nad skutecznością metod formalnych…

Czytaj dalej Program budowy kompetencji

Procedura – co to za zwierzę

Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty.
Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego “przejścia” (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożona normę ISO9000, to modelując procesy biznesowe i “podpinając” do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcja.

Czytaj dalej Procedura – co to za zwierzę

Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Gdzie tkwi podstęp: Logika Biznesowa Dedykowana MUSI być udokumentowana osobno w sposób jednoznaczny, nie dający programiście pola do własnej interpretacji, a to wymaga opisania tego metodami formalnymi. Logika biznesowa dedykowana musi być odrębnym TWOIM kodem (w umowie prawa majątkowe do niego oraz umowa o ochronie Twojego know-how). Ale to dużo kosztuje! Dostawca oprogramowania i tak na Twój koszt to w jakiejś formie zrobi! Otóż praktyka pokazuje, że zaprojektowanie i wykonanie odrębnej Logiki biznesowej dedykowanej, kosztuje zawsze mniej (nie raz znacznie mniej!) niż koszt dostosowywania ogromnej istniejącej już logiki dostarczonej. Większość kupujących systemy ERP z powodu braku tej wiedzy i pod naciskiem dostawcy oprogramowania, przyjmuje niekorzystną dla siebie metodę wdrożenia i podpisując wcześniej niekorzystną dla siebie umowę (kastomizacja oprogramowania).

Czytaj dalej Nie dać się szantażować swojemu własnemu dostawcy oprogramowania

Struktura organizacyjna jako system

Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.

Czytaj dalej Struktura organizacyjna jako system

Słownik pojęć biznesowych czyli po co nam przestrzeń nazw

I tu dochodzimy do sedna: aby stworzyć profil notacji – co czasami bywa niezbędne dla jakości analizy – należy zbudować słownik pojęć z dziedziny analizowanego problemu. Bez takiego słownika analiza może być niewykonywalna, albo jej jakość będzie bardzo niska – czytaj użycie jej wyników będzie bardzo ryzykowne.

Czytaj dalej Słownik pojęć biznesowych czyli po co nam przestrzeń nazw

Korzyści z Architektury Korporacyjnej

Od czego należy zacząć? Od zbudowania własnej (lub własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności – Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją (podobnie jak lekarz domowy to raczej nikt z domowników).

Czytaj dalej Korzyści z Architektury Korporacyjnej