Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Stosowanie analizy systemowej, modelowania oraz formalnych notacji do tworzenia modeli, powoduje, że wyniki analiz są daleko bardziej wiarygodne. Z reguły celem pracy analityka biznesowego czy projektanta jest opracowanie opisu rekomendowanego rozwiązania. Może nim być docelowy model organizacji czy też opis oprogramowania jakie należy dostarczyć (bo nie zawsze wytworzyć!). W procesie formalnej analizy systemowej (nie jest to analiza systemu informatycznego, to analiza dowolnego systemu), powstają modele, które testujemy. Taki model to najpierw hipoteza, a po weryfikacji, jest to opis rozwiązania (projekt tego co ma powstać). Idealną sytuacją była by taka, a której mamy narzędzia do modelowania każdej analizowanej dziedziny. W klasycznej inżynierii jest to rysunek techniczny i zasady obliczania wytrzymałości, sformalizowany system tworzenia schematów elektrycznych i elektronicznych i wiele innych (zależnie od dziedziny), notacje UML w inżynierii oprogramowania. W sferze zarządzania mieliśmy do niedawna biała plamę, teraz mamy już BMM czy ArchiMate. Moim zdaniem utrzymywanie, że można coś skutecznie analizować metodami nieformalnymi świadczy raczej o niewiedzy i braku kompetencji.

Continue ReadingNowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Diagram klas – czyli “re-inżynieria” analizy biznesowej. C.d. model dziedziny

Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.

Continue ReadingDiagram klas – czyli “re-inżynieria” analizy biznesowej. C.d. model dziedziny

Diagram klas czyli reinżynieria analizy biznesowej c.d. Przypadki użycia i granice systemu

Tworzenie modelu procesów ma dwa zadania: weryfikacja spójności i kompletności opisu Zamawiającego oraz stworzenie podstawy do określenia zakresu projektu i wyspecyfikowania wymagań funkcjonalnych czyli tak zwanych przypadków użycia.

Continue ReadingDiagram klas czyli reinżynieria analizy biznesowej c.d. Przypadki użycia i granice systemu

Diagram klas czyli reinżynieria analizy biznesowej

Dlaczego podnoszę pracochłonność analizy wymagań i projektuję model koncepcyjny do testów? Ano po to by błędy i niespójności odkryć teraz, bo na etapie implementacji ich usuwanie będzie nawet 100 razy droższe. Czy takie błędy są w projektach o uproszczonych analizach biznesowych (lub wręcz pominiętych?) Ci co mają takie projekty za sobą wiedzą doskonale, że są i to prawie zawsze...

Continue ReadingDiagram klas czyli reinżynieria analizy biznesowej

Modelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje

Tak więc stosowanie formalnych notacji i zasad obniża ryzyko projektu. Nie wyeliminuje go, bo model i jego jakość zależy bardzo od jego twórcy (modelowanie to jednak sztuka a nie rzemiosło), jednak łamanie zasad lub stosowanie nieformalnych diagramów stanowi kluczowe ryzyko projektów na etapie analizy.

Continue ReadingModelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje