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.

Czytaj dalejNowa 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.

Czytaj dalejDiagram 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.

Czytaj dalejDiagram 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...

Czytaj dalejDiagram 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.

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

BPM GigaCon – 16 listopad 2010

Procesy biznesowe to nie kolejny termin do opanowania, lecz codzienność każdego przedsiębiorstwa. Z naszym udziałem, bądź nie ? procesy zachodzą. Tylko od podejścia kierownictwa zależy, czy będziemy nad nimi panować i sprawnie zarządzać, przyczyniając się do poprawy funkcjonowania firmy. Czy nam się to podoba, czy nie, procesy biznesowe to element naszej organizacji. Świadome i odpowiedzialne podejście pozwoli zarządzać nimi mądrze.

Czytaj dalejBPM GigaCon – 16 listopad 2010

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Czytaj dalejProjektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

Czym jest obieg dokumentów i BPM? Dlaczego pozornie prosty system obiegu dokumentów

Praktyka pokazuje, że wiele map procesów zawierających dziesiątki diagramów tak na prawdę pokazuje warianty tego samego procesu. Bardzo często także to co jest modelowane jako jeden skomplikowany proces to tak na prawdę kilka procesów współdzielących dane (jest to bardzo często spotykany przypadek w audytach jakie prowadzę). Na zakończenie przykład, który pokaże opisane zjawiska i korzyści z formalizacji. [...]

Czytaj dalejCzym jest obieg dokumentów i BPM? Dlaczego pozornie prosty system obiegu dokumentów

Na forach czyli znowu modelowanie

Wąskim gardłem jest przejście z procesów na model dziedziny i przypadki użycia, które to tak na prawdę powinny być sprowadzone jeden do jednego do modułów (klas) wykonawczych np. widoku i kontrolera wzorca MVC (który bardzo lubię :)) a model dziedziny wchodzi jeden do jednego w Model w MVC.

Czytaj dalejNa forach czyli znowu modelowanie

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?

Czytaj dalejDokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Wdrożenie BPM czyli modelowanie organizacji i procesów biznesowych

Nie szukać systemu który ?pasuje do nas? bo raczej żaden od razu nie pasuje. Ostrożnie podchodzić do ?dobrych praktyk? i ?modeli referencyjnych?. Zgodnie z zasadą: Jeżeli w dwóch różnych firmach, nawet w tej samej branży, funkcjonuje taki sam model biznesowy i procesowy to w jednej z nich na pewno jest zły! System informatyczny powinien pozwolić obsłużyć nasze wymagania (procesy) ale nie procedury. Procedury tworzy się w tracie wdrażania.

Czytaj dalejWdrożenie BPM czyli modelowanie organizacji i procesów biznesowych

Modelowanie a rysowanie

Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo model powinien bez potrzeby kontaktu z pierwowzorem zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania informacje oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze i o tym ile schodów należy pokonać by na nią wejść. Na tej samej zasadzie rysowanie na diagramie faktu, że np. dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem.

Czytaj dalejModelowanie a rysowanie

Koniec treści

Nie ma więcej stron do załadowania