Odpowiedź

Historycznie analitycy systemowi często zaczynali pracę od dogłębnej analizy procesów biznesowych firmy. Pozwoliło to zrozumieć, gdzie i jak system informacyjny może zautomatyzować lub zoptymalizować działalność organizacji. Jednak często granice między analizą procesów biznesowych a projektowaniem technicznym się zacierają.

Kluczowe cechy:

• Opis procesów biznesowych skupia się na identyfikacji i formalizacji działalności organizacji jako systemu, bez uwzględnienia szczegółów realizacji za pomocą technologii IT.
• Projektowanie systemu informacyjnego zaczyna się po sformułowaniu wymagań, i obejmuje opracowanie architektury, interfejsów, integracji, formatów danych.
• Ważne jest oddzielanie tych etapów: najpierw analityk określa "co robić", a potem — "jak robić".

Historia problemu

Wcześniej granica między tymi etapami była wyraźniejsza: analityk biznesowy odpowiadał za modelowanie procesów, analityk systemowy — za przekładanie wymagań na specyfikacje techniczne. W nowoczesnej praktyce zadania często się mieszają.

Problem

Wielu analityków zaczyna projektować system przed pełną analizą procesów, co prowadzi do błędnego określenia wymagań i nadmiernej szczegółowości technicznej.

Rozwiązanie

Wyraźnie oddzielać analizę obszaru przedmiotowego od projektowania, używać BPMN i EPC do opisu procesów, a do projektowania — UML, diagramy przepływu danych (DFD) itp.

Pytania z podstępem.

Co jest ważniejsze — analizować procesy biznesowe czy projektować system?

Nie można wyodrębnić czegoś jednego: analiza procesów jest potrzebna do opracowania poprawnych wymagań, projektowanie — do ich realizacji. To są etapy następujące po sobie.

Czy można używać tych samych diagramów do opisu procesów i projektowania systemu?

Nie, BPMN/EPC są stosowane w procesach, UML/DFD — do analizy strukturalnej lub obiektowej i projektowania.

W jakim przypadku można zrezygnować z modelowania procesów biznesowych?

Tylko jeśli projekt jest niewielki i procesy są już w pełni sformalizowane w dokumentach lub standardach. W większości przypadków modelowanie jest konieczne.

Typowe błędy i anty-wzorce

• Przedwczesne szczegółowe przejście do schematu danych, nie rozumiejąc zadań biznesowych.
• Mieszanie opisu procesów i rozwiązań technicznych.
• Ignorowanie interesów użytkowników końcowych.

Przykład z życia

Negatywny przypadek:
Analityk od razu zaczął rysować schemat bazy danych i usługi, nie badając, jak pracują pracownicy i czego potrzebują. Zalety: szybka realizacja, wszyscy zadowoleni z pierwszej wersji.
Wady: system nie rozwiązuje rzeczywistych problemów, użytkownicy niezadowoleni, potrzebne były poprawki.

Pozytywny przypadek:
Analityk najpierw przeprowadził serię wywiadów z pracownikami, zbudował BPMN, a następnie przeszedł do projektowania API i bazy danych. Zalety: wymagania jasne, system pokrywa rzeczywiste procesy.
Wady: dłuższy początek projektu, wyższe koszty analizy.