Wywiady

BPMstandard.pl używa cookies.

Brak zmiany ustawienia przeglądarki oznacza Twoją zgodę.

Zrozumiałem
28Maj2016

Monika Perendyk o procesach biznesowych i inżynierii wymagań

monika perendyk

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­ży­cielem i Pre­zesem Sto­wa­rzy­sze­nia Inży­nie­rii Wyma­gań, zało­ży­cielem i Redak­torem Naczelnym maga­zynu: REQ Maga­zyn.

bpmstandard.pl:

Z perspektywy Pani doświadczenia, który etap procesu produkcji oprogramowania jest najtrudniejszy, najbardziej newralgiczny?

Monika Perendyk:

Najtrudniejszym i jednocześnie najważniejszym etapem wytwarzania oprogramowania jest zbieranie i analiza wymagań Klienta. Na tym etapie analityk może popełnić szereg błędów, których koszt naprawy będzie rósł lawinowo z każdym etapem wytwarzania oprogramowania. Dlatego tak ważna jest staranność i korzystanie z dobrych praktyk podczas analizy i zbierania wymagań. Trudność tego etapu wynika głównie z szeregu wyzwań, jakie czekają analityka, m.in.:
- omówienie i czasem udokumentowanie procesu biznesowego, który ma być obsłużony przez system,
- poprawne identyfikowanie wszystkich interesariuszy uczestniczących w procesie biznesowym oraz ich wzajemnych relacji,
- identyfikacja oczekiwań, ograniczeń wobec rozwiązania oraz zaangażowanie klienta w projekt
- identyfikowanie wzajemnie wykluczających się wymagań różnych interesariuszy,
- zrozumienie celu biznesowego dla każdego wymagania
i najtrudniejsze
– identyfikowanie brakujących wymagań, czyli takich, które klient uznaje za oczywiste, więc ich nie wypowiada.
Jak pokazuje Chaos Report, aż 61% projektów zakończyło się niepowodzeniem, bądź stanowiły spore wyzwanie dla dostawcy i klienta. Źródłem niepowodzeń w tych projektach było głównie: niejednoznaczne zdefiniowanie wymagań, wymagania ukryte, brak zarządzania zmianą wymagań czy oddanie produktu niezgodnego z oczekiwaniem klienta.
Jak widać większość przyczyn związana jest właśnie z analizą wymagań w projekcie.
Na tym etapie popełniane są najcześciej dwa błędy:
• brak zdefiniowania słownika pojęć, którym będziemy się posługiwali przez cały projekt,
• przyjęcie z góry rozwiązania bez zastanowienia się czemu ma służyć rozwiązanie oraz jakie problemy ma rozwiązywać.

W konsekwencji otrzymujemy jeden efekt: rozczarowanie klienta przy odbiorze produktu. Często zdarza się, że brak wyjaśnienia pojęcia, nawet zdawałoby się powszechnie znanego powoduje katastrofę w projekcie. Przykładem może być słowo: "klient". Podczas warsztatów analitycznych, nasz "klient" mówiąc o "kliencie" wcale nie ma na myśli samego siebie, lecz konsumentów, którzy korzystają z jego usług. Dla programisty, czytającego dokument wytworzony przez analityka, może oznaczać odbiorcę produktu, czyli tego, z którym rozmawiał analityk. Katastrofa gotowa.
Podobnie jest z procesem biznesowym. Najczęściej można spotkać się ze zdziwieniem w oczach klientów, kiedy proszę o omówienie procesu biznesowego. Wbrew ogólnemu przekonaniu mało firm formalizuje proces biznesowy. On istnieje w firmie, bo w jakiś sposób ona funkcjonuje, lecz mało kto zna wszystkich interesariuszy uczestniczących w procesie, czy wszystkie jego etapy. Ich identyfikacja to prawdziwe pole do popisu dla analityka.

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.
bpmstandard.pl:

Załóżmy, że zamawiający system informatyczny nie zamierza wdrażać zarządzania procesowego w organizacji, jaką zatem wartość przynosi analiza i modelowanie procesów dla dostawcy i zamawiającego w procesie produkcji i wdrożenia systemu?

Monika Perendyk:

W takim przypadku analiza procesu biznesowego ułatwia komunikację między klientem a dostawcą w momencie, kiedy chcemy przedstawić klientowi propozycję rozwiązania. Klientowi łatwiej jest zrozumieć rozwiązanie, jeśli zobaczy go w znanym sobie procesie biznesowym. Takie rozwiązanie pozwala mu przygotować się do implementacji rozwiązania. Czasem na takich warsztatach analitycznych klient modyfikuje proces biznesowy, przekazuje uwagi do rozwiązania.
Z drugiej strony dostawcy łatwiej jest pokazać korzyść biznesową wynikającą z implementacji rozwiązania informatycznego poprzez optymalizację pracy użytkowników, czy nawet automatyzację niektórych z etapów procesu biznesowego.
Dodatkowo analityk podczas opracowywania rozwiązania odnosząc się do procesu biznesowego może sprawdzić, czy wszystkie jego elementy zostały obsłużone w jego rozwiązaniu.
bpmstandard.pl:

Co stanowi największe wyzwanie na etapie zbierania i analizy wymagań w szczególności na styku z zamawiającym?

Monika Perendyk:

Największym wyzwaniem w pracy z klientem jest zrozumienie potrzeby jaka się kryje za słowami, które przekazuje na warsztatach analitycznych.
Klienci opowiadając o swoich wymaganiach wobec produktu najczęściej starają się go wizualizować na samym początku analizy. Opisują go przy użyciu pojęć ogólnie znanych, aby móc lepiej przekazać to, w jaki sposób wyobrażają sobie dane rozwiązanie. Trudno to nazwać nawet przekazywaniem wymagań, raczej jest to przedstawienie oczekiwań wobec już z góry założonego przez klienta rozwiązania.
Niestety tylko niektórzy klienci w zamówieniu piszą o celu biznesowym, jaki chcą osiągnąć dzięki rozwiązaniu oraz piszą o problemie, które wymagają zastosowania rozwiązania informatycznego. Jest to dość trudne z punktu widzenia analizy wymagań.
Henry Ford powiedział: „Gdybym pytał ludzi, czego chcą, poprosiliby o lepszego konia.” Myślę, że świetnym tego przykładem jest historia powstania samolotu bojowego F-16. Jest to jedna z moich ulubionych historii jaskrawo ilustrująca sposób komunikacji na linii klient-dostawca.
Mało osób pewnie zdaje sobie sprawę, jakie były założenia do F-16 złożone wraz z zamówieniem. Podstawowym wymogiem, jaki został postawiony projektowanemu samolotowi było osiągnięcie prędkości 2-2,5 Ma. Co ciekawe takiej prędkości nigdy nie udało się osiągnąć. Sama konstrukcja F-16 była udana, ponieważ projektanci zamiast bazować na wymaganiu przekazanym przez klienta dążyli do poznania istoty problemu. Wymaganie osiągnięcia prędkości 2-2,5 Ma prowadziły tylko do rozwiązania jednego z problemów. Projektanci na samym początku projektu zadali klientowi pytanie, dlaczego wymóg prędkości jest dla niego tak istotny, w odpowiedzi usłyszeli, że samolot, który mają stworzyć musi być zdolny do uniknięcia walki.
To właśnie poznanie problemu okazało się kluczem do sukcesu. W projekcie zastosowano szereg innowacyjnych rozwiązań, które w konsekwencji były lepsze i tańsze, niż rozwiązanie pierwotnie zaproponowane przez Klienta. W myśliwcu zastosowano m.in kroplową osłonę kabiny pilota, która zapewnia lepszą widoczność, fotel pilota o zmiennym położeniu oparcia dla zmniejszenia przeciążenia czy wyświetlacz pokazujący wszystki informacje z pola walki bezpośrednio przed oczami pilota, dzięki czemu nie wpływa to negatywnie na przegląd przestrzeni.
Dlatego tak ważne jest, aby za każdym razem starać się zrozumieć źródło problemu zamiast implementować to, co zostało przekazane w zamówieniu klienta. Wspólna praca z klientem nad zakresem projektu na podstawie celów, jakie chce osiągnąć jest najtrudniejszą częścią etapu zbierania, a później analizy wymagań.
Pominięcie tego fragmentu w rozmowie z klientem jest przyczyną rozczarowania klienta po otrzymaniu rozwiązania, które okazuje się nie rozwiązuje jego problemu.
Drugim, moim zdaniem, największym wyzwaniem jest zaangażowanie klienta w projekt. Najłatwiej jest z nowym klientem, kiedy budujemy taką relację od początku. Trudniej jest z klientem, który nie wierzy w sukces projektu, bądź ma złe doświadczenia z danym dostawcą. Wówczas analityk staje się mediatorem, który powinien stworzać atmosferę wzajemnego poszanowania, zaufania oraz partnerstwa w projekcie.
Musi uświadomić klientowi, że zespół projektowy to nie tylko programiści, testerzy, ale również przedstawiciele klienta. Zespół projektowy (dostawca i klient) ma jeden wspólny cel, do którego powinien dążyć - wytworzenie oprogramowania spełniającego potrzeby klienta.
Kolejną trudnością na etapie analizy wymagań jest brak realnego zaangażowania ze strony klienta. Powstanie luki oczekiwań klienta na końcu projektu wynika głównie z braku jego zaangażowania poprzez niedostarczanie niezbędnych informacji analitykowi. Kiedy na końcu projektu zaczynamy się zastanawiać dlaczego tego klient nam nie powiedział, słyszymy: "przecież nikt nie pytał", "myślałem, że jest to oczywiste", "a czy to było ważne?".
Wydaje mi się, że najtrudniejszym elementem w analizie jest analizowanie tematu, którego kompletnie nie znamy. Uważam, że jesteśmy tak dobrymi analitykami, jak dobrze znamy daną dziedzinę. Czy jesteśmy w stanie dobrze zidentyfikować wymagania klienta wykorzystując dobre praktyki, jeśli nie wiemy o co zapytać? Uważam, że nie jesteśmy w stanie dobrze przeprowadzić analizy, ponieważ nie mając doświadczenia w danym temacie możemy pominąć wiele aspektów wymagań pozafunkcjonalnych.
bpmstandard.pl:

W jaki praktyczny sposób możliwe jest wykorzystanie modelu procesów biznesowych zbudowanego w trakcie analizy biznesowej i systemowej, na etapie testów systemu?

Monika Perendyk:

Musimy pamiętać o tym, że testerzy mogą sprawdzić jedynie zgodność dostarczonego oprogramowania z zapisami w dokumencie analitycznym. Nie są w stanie sprawdzić, czy oprogramowanie spełnia oczekiwania klienta. Tutaj z pomocą przychodzi nam analiza procesów biznesowych. Umieszczenie w dokumencie rozrysowanego i opisanego procesu biznesowego znacznie ułatwia przygotowanie pełnego przypadku testowego. Jest to tym bardziej cenne, jeśli klient nie dostarczył nam podczas analizy przykładów przypadków, jakie mają być obsłużone.
bpmstandard.pl:

Wykorzystania, jakich notacji do modelowania procesów oczekują najczęściej zamawiający?

Monika Perendyk:

Osobiście nie spotkałam się z takim oczekiwaniem ze strony klientów. Spotykając się z interesariuszami większą wagę zwracam na rozrysowanie procesu biznesowego w języku zrozumiałym dla nich samych. Oczywiście, jeśli po stronie klienta zadeklarowana jest znajomość notacji BPMN, wówczas można pokusić się o rozrysowanie procesu biznesowego z wykorzystaniem dedykowanych do tego symboli. Należy pamiętać, że dokument, który tworzymy jest tworzony dla konkretnego odbiorcy, dlatego rolą analityka jest umiejętne wykorzystywanie opisów, notacji, diagramów, które będzie w stanie zrozumieć odbiorca. Najgorszą rzeczą, którą można sobie zrobić w projekcie to doprowadzenie do sytuacji, kiedy klient pochylając się nad dokumentem mówi: "Jeśli to co tutaj jest napisane jest tym, o czym mówiłem, to potwierdzam". W zamówieniach publicznych sytuacja jest diametralnie inna. Tutaj najczęściej pojawia się notacja BPMN w wersji 2.0, rzadziej można spotkać się z notacją eEPC.

bpmstandard.pl:

Podziękowania za rozmowę.

Monika Perendyk

monika perendyk

Cer­ty­fi­ko­wany Pro­fe­sjo­na­li­sta Inży­nie­rii Wyma­gań, współ­za­ło­ży­ciel i Pre­zes Sto­wa­rzy­sze­nia Inży­nie­rii Wyma­gań (www.siw.org.pl), któ­rego celem jest ugrun­to­wa­nie powszech­nej świa­do­mo­ści zna­cze­nia inży­nie­rii wyma­gań oraz jej inter­dy­scy­pli­nar­nego cha­rak­teru. Zało­ży­ciel i Redak­tor Naczelna maga­zynu: REQ Maga­zyn (www.reqmagazyn.pl). Wykładowca na Poli­tech­nice War­szaw­skiej oraz trener szkoleniowy, który nadal pra­cuje w zawo­dzie, dzięki czemu pod­czas szko­leń pre­zen­tuje naj­lep­sze prak­tyki wyko­rzy­sty­wane pod­czas pracy z Klientem. Posiada wie­lo­let­nie doświad­cze­nie jako inży­nier wyma­gań (ana­li­tyk biznesowy-systemowy) ze spe­cja­li­za­cją w sek­to­rze finan­so­wym ze szcze­gól­nym wska­za­niem na branżę leasin­gową oraz CFM. Pro­pa­ga­tor dobrych prak­tyk w zakre­sie komu­ni­ka­cji z Klien­tem oraz pro­wa­dze­nia ana­lizy w zło­żo­nych pro­jek­tach. Swoim doświadczeniem i wiedzą dzieli się na stronie: www.analizawymagan.pl, prowadzi również grupę dyskusyjną FB: analiza biznesowa i systemowa. Pre­le­gent na kon­fe­ren­cjach poświę­co­nych jako­ści opro­gra­mo­wa­nia oraz analizie. Mak­syma życiowa: “Nie ma rze­czy nie­moż­li­wych, wszystko jest kwe­stią czasu” Linkedin: https://pl.linkedin.com/in/monikaperendyk/pl


Więcej wywiadów

Marek Szelągowski o dynamicznym zarządzaniu procesami biznesowymi

marek szelagowski

Tomasz Burczyński o specyfice projektów wdrożeniowych BPM

tomasz burczynski

Grzegorz Bliźniuk o dojrzałości procesowej organizacji medycznych w Polsce

gblizniuk