Category Archives modelowanie procesów biznesowych

Na przestrzeni ostatnich lat świadomość modelowania procesów biznesowych w środowiskach informatycznych i nieinformatycznych rośnie. Nie ma już dyskusji czy warto modelować. Zasadniczo wiadomo, że warto.  Rozważania dotyczą tego co i jak modelować by praktycznie wykorzystać wykonaną pracę. Mam wrażenie, że brakuje wiedzy na temat jak ma sensownie wyglądać modelowanie procesów biznesowych. Jeśli istnieje potrzeba by zgłębić arkana praktycznego modelowania procesów…

Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście modelowania procesów biznesowych i systemowych (patrz tekst:  Diagramy procesów systemowych). Oba diagramy bardzo podobne do siebie choć BPMN 2.0 to już mega możliwości. Myślę, że kluczem do decyzji jest zastosowanie (czyt. Twoje potrzeby)

Lubię używać diagramów aktywności gdy:

Powszechnym jest iż czym większa organizacja tym więcej systemów informatycznych. U moich klientów są ich dziesiątki. Tak tak. Przez lata zbiera się ich trochę bo każdy rok to zmiany w procesach biznesowych i bardzo często dodanie nowego systemu. Znam firmy, w których stajnia Augiasza to najlepsze określenie na zaistniałą sytuację.  Co więcej firma albo modeluje procesy biznesowe w oderwaniu od IT albo nie modeluje ich wcale. Czasem modele biznesowe powstają w innym narzędziu niż pracuje IT.

Jak wobec tego poradzić sobie w takiej sytuacji?

Moją propozycją są diagramy procesów systemowych czyli  diagramy aktywności prezentujący proces biznesowy w kontekście używanych systemów lub komponentów oraz ludzi – użytkowników systemów.

Otrzymałem mailem ciekawe pytanie:

Czy wg Pana wiedzy istnieje w EA obiekt, który najbardziej nadawałby się do rejestracji problemów zidentyfikowanych podczas analizy (AS-IS) biznesowej lub systemowej? Mam na myśli taki obiekt, w którym rejestrowane byłby, parametry zidentyfikowanego podczas warsztatów problemu, np. nazwa, opis, powiązanie z procesem, przyczyna występowania, itp.,  a po zarejestrowaniu dałoby się łatwo wyeksportować wszystkie zarejestrowane problemy w formie tabeli do  RTF’a, wykorzystując przygotowany wcześniej template?

W czasie ostatnich wyborów, jeden z uczestników spotkania wyborczego zapytał: “Jak żyć Panie Premierze?” Przekładając na grunt modelowania często słyszę: “Jak modelować?”. I o ile daleko mi do Premiera i jego problemów dot. rządzenia krajem, tak blisko mi do problemów z modelowaniem. Otóż UML zna już sporo osób. Nieformalnym standardem w zakresie narzędzi jest Enterprise Architect, który jest używany Problem…

Swoją wiedzą i kompetencjami dzielę się nie tylko na szkoleniach ale także na studiach podyplomowych. Od kilku lat jestem związany ze Politechniką Warszawską, gdzie prowadzę kilkanaście godzin zajęć z analizy biznesowej i zarządzania wymaganiami. Po ostatnim wykładzie/warsztatach obiecałem swoim studentom, że polecę kilka pozycji związanych z tematem. Oto one:   Warsztaty wymagań Autor: Ellen Gottesdiener Tytuł oryginału: Requirements by Collaboration:…

Jedną z bardziej żmudnych czynności realizowanych w fazie wymagań jest analiza aktów normatywnych. W mojej ocenie dużym błędem jest wskazanie w wymaganiach na system iż ma on być zgodny np. z ustawą X. Moim zdaniem, niestety trzeba rozbić każdy (mający wpływ na system) paragraf i podpunkt na oddzielne wymaganie. Poniżej krótki opis mojego “sposobu” na dokumenty prawne, regulaminy i inne spisane zasady.

Planując pracę  swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one:

Plan szczegółowy buduję jedynie dla najbliższych zadań. Moim zadaniem użyteczne są plany na kilka najbliższych dni, tygodni, ale nie na kilka najbliższych miesięcy.

Nie przepadam za wykresami Gantta. Coraz częściej dochodzę do wniosku, że wykresy Gantta mają małą wartość dla projektów agile. Pomagają mi przemyśleć główne zależności ale nic więcej. Najlepszą techniką jest dla mnie się lista zadań dotyczących iteracji.

Zawsze staram się planować z zespołem. To ważne by ludzie wykonujący pracę byli aktywnie zaangażowani w planowanie. Są oni wtedy bardziej zmotywowani, aby wykonać swoją pracę dobrze. Ponadto jako współtwórcy planu prac łatwiej go akceptują.

Przez ostatnie sześć tygodni pozwoliłem sobie na pokazanie wybranych aspektów związanych z modelami wykonywanymi w ramach architektury korporacyjnej. Opisując mój przykład posłużyłem się ProVision firmy Metastorm. Wybór był nie przypadkowy. To narzędzie jest wymieniane jako jedno z najlepszych ( opisałem to: The Forrester Wave™: Enterprise Architecture Management Suites czyli ciąg dalszy o narzędziach do modelowania architektury korporacyjnej oraz Architektura korporacyjna a narzędzia). Ponadto wspiera TOGAF.

Close