Odpowiedź.

W perspektywie historycznej analitycy systemowi korzystali z metod ręcznych — obserwacja, wywiady, analiza istniejącej dokumentacji. Wraz z rozwojem IT pojawiły się standardy (np. BPMN, IDEF0, EPC), które uporządkowały podejście do modelowania obecnych i przyszłych procesów.

Problem: wybór podejścia często komplikuje niepełność informacji, czas, złożoność dziedziny oraz różna dojrzałość procesów biznesowych. Błędy na tym etapie prowadzą do błędnego opisu wymagań, poważnych przeróbek i utraty zaufania do roli analityka.

Rozwiązanie: optymalne podejście — łączyć metody ilościowe i jakościowe:

Analizować dokumentację i rzeczywiste zachowanie poprzez obserwację.
Formalizować procesy za pomocą notacji BPMN lub IDEF0 w zależności od zadania.
Dla „as-is” — zbierać opinie od wykonawców, organizować warsztaty.
Dla „to-be” — prowadzić modelowanie z klientem, wcześniej ustalać oczekiwany wynik i kryteria sukcesu.
Przeprowadzić analizę luk (gap-analysis), zidentyfikować niedobory i ryzyka.

Kluczowe cechy:

Wykorzystywanie kilku technik równolegle.
Zapis wydarzeń i alternatywnych scenariuszy.
Ciągła weryfikacja danych poprzez demonstracje i krótkie iteracje.

Pytania z pułapką.

Czy zawsze można stosować BPMN do opisu wszystkich procesów, w tym technicznych i złożonych integracyjnych?

BPMN nadaje się tylko do procesów biznesowych lub procedur z wyraźną logiką. Technologiczne lub głęboko integracyjne scenariusze najlepiej opisywać diagramami sekwencji (UML), schematami architektonicznymi lub specjalistycznymi notacjami.

Czy wystarczy przeprowadzić wywiad z jednym przedstawicielem grupy biznesowej, aby uzyskać prawdziwy obraz bieżącego procesu?

Nie, jeden źródło nigdy nie odzwierciedla całej rzeczywistości. Należy zbierać wersje od różnych ról: wykonawców, użytkowników, działu IT, menedżerów. Minimalizuje to ryzyko błędów i odkrywa ukryte zakończenia procesu.

Czy należy szczegółowo opracować przyszły proces „to-be” dla każdej operacji biznesowej, zanim zaprojektuje się rozwiązanie IT?

Nie zawsze. Nadmierna szczegółowość prowadzi do biurokracji i utraty elastyczności. Wystarczy uzgodnić kluczowe scenariusze, punkty automatyzacji, niezbędne zmiany ról i integracji, a szczegóły opracowywać iteracyjnie w trakcie realizacji.

Typowe błędy i antywzorce

Opisanie procesu tylko na podstawie teorii, bez analizy rzeczywistych scenariuszy biznesowych
Ignorowanie niejawnych lub ukrytych ścieżek realizacji procesu
Nadmiar szczegółów lub, wręcz przeciwnie, nadmierna ogólność schematów

Przykład z życia

Negatywny przypadek: Analityk zbudował mapę procesu tylko na podstawie regulaminu, nie analizując rutynowych obejść i „obejściowych” schematów wykonawców.

Zalety:

Szybkie uzgodnienie dokumentacji

Wady:

Brak rzeczywistej użyteczności i zrozumienia rzeczywistych problemów
Rozwiązanie IT źle działa w praktyce, wymagana poprawka

Pozytywny przypadek: Analityk przeprowadził warsztaty, wywiady, sformalizował stan obecny i docelowy, pokazał różnice. Ujął przykłady rzeczywistych scenariuszy i ich problemów, uwzględnił opinie interesariuszy.