O wykorzystaniu i „roli” procesów biznesowych w kontekście inżynierii wymagań rozmawiamy z Panią Moniką Perendyk, analitykiem, wykładowcą akademickim, współzałożycielem i Prezesem Stowarzyszenia Inżynierii Wymagań (www.siw.org.pl), założycielem i Redaktorem Naczelnym magazynu: REQ Magazyn (www.reqmagazyn.pl).
[…]
bpmstandard.pl:
Pani Moniko, w praktyce, jaką rolę w inżynierii wymagań pełnią procesy biznesowe?
Monika Perendyk:
Istnieje ścisła zależność między tymi dwoma dziedzinami. Tak jak wspominałam wcześniej, jednym z wyzwań, jakie czekają na analityka podczas zbierania i analizy wymagań jest omówienie i nierzadko udokumentowanie procesu biznesowego, który ma być obsłużony przez system.
W wielu swoich wystąpieniach podkreślam, że błędem jest koncentrowanie się dostawcy na szukaniu rozwiązania informatycznego bez identyfikacji procesu biznesowego, który chcemy obsłużyć. Pracę w projekcie informatycznym powinniśmy rozpoczynać od poszukiwania odpowiedzi na pytanie: Którą część omawianego procesu biznesowego ma wspierać tworzony system?
Aby odpowiedzieć na to pytanie w pierwszej kolejności musimy zanalizować sytuację i problem klienta, z którym obecnie się zmaga. Wykonujemy analizę „as is” poprzez zadawanie szeregu pytań interesariuszom, m.in:
• kto jest odpowiedzialny za realizację tego zadania?
• kiedy wykonywana jest dana czynność, jakie warunki początkowe musza być spełnione?
• co powinno być wykonane oraz jakie dane, produkty uzyskamy w wyniku działania?
Takie podejście umożliwia zidentyfikowanie reguł biznesowych, które stanowią podstawę do zdefiniowania wymagań.
Następnie wspólnie z klientem wykonujemy analizę stanu docelowego, czyli analiza „to be”. Na tym etapie szukamy odpowiedzi na pytania: co chcę osiągnąć dzięki rozwiązaniu, jakie chcę osiągnąć zyski dzięki rozwiązaniu, jak chcę aby docelowo mój proces wyglądał.
Nie wystarczy jedynie rozrysować proces biznesowy i zaimplementować go w systemie. Celem uruchomienia projektu informatycznego jest optymalizacja pracy interesariuszy. Odtworzenie 1:1 stanu obecnego w systemie informatycznym nie jest żadną optymalizacją, a jedynie zmianą narzędzia.
Przed przystąpieniem do pracy nad rozwiązaniem informatycznym w powinniśmy pokazać jak będzie wyglądał proces biznesowy po wdrożeniu rozwiązania. Wskazać, w którym miejscu będzie znajdował się system, jakie będą dane wejściowe, a jakie wyjściowe oraz którzy interesariusze będą korzystać z tego rozwiązania.
Czasem wdrożenie rozwiązania jest impulsem do zmodyfikowania procesu biznesowego, dostosowania do integracji z systemem, który jest zaimplementowany.
Jeszcze kilka lat temu procesy biznesowe nie były takie oczywiste w inżynierii wymagań, bowiem uważano, że ich analizą zajmują się tylko analitycy biznesowi. Obecnie elementy procesu biznesowego wykorzystywane są w technice spopularyzowanej przez J.Pattona w 2009 roku, czyli w „user story mapping”. Technika ta polega na tworzeniu zestawu historyjek z punktu widzenia biznesu. Przekształcamy aktywności użytkownika w przepływ działań, którego można w kolejnym kroku zamienić na zbiór mniejszych zadań powiązanych z konkretnym celem biznesowym. Przepływ tych działań tworzy proces biznesowy.
Jak widać obecnie inżynieria wymagań nie może istnieć bez wykorzystywania analizy procesów biznesowych.
[…]
Cały wywiad: https://bpmstandard.pl/wywiady/139-procesy-biznesowe-a-inzynieria-wymagan
