Wyniki wyszukiwania dla „modele procesów biznesowych” – Strona 16

CASE czyli komputerowe wspomagania analizy i projektowania systemów

I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.

Czytaj dalej

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

Ile jest tych wymagań na system ERP

Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli).

Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów (średnie przekroczenie budżetu to ponad 60%).

Czytaj dalej

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

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

Zarządzanie wymaganiami

Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!

Czytaj dalej

Poziomy modelowania c.d. czyli How work gets done

W kontekście poziomów modelowania polecam książkę How Works Get Done , którą właśnie kończę czytać. Bardzo dobre kompendium wiedzy o modelowaniu procesów w kontekście tytułowego "jak ta praca jest wykonywana".…

Czytaj dalej

System Analysis And Design with UML 2.0

Książkę polecam przede wszystkim analitykom do nauki ale także “wyżartym” programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.

Czytaj dalej