Dlaczego nie warto śpieszyć się z wyborem rozwiązania? – o prawidłowej Analizie Biznesowej

Systemy informatyczne są zwykle drogie. Ich wdrożenie to nierzadko koszt kilkuset tysięcy lub nawet wielu milionów złotych. Planując tak istotną inwestycję, warto starannie ją przemyśleć i przygotować, tak aby przyniosła maksymalny zwrot oraz dostarczyła organizacji możliwie największej wartości.

Wartość ta może być zdefiniowana bardzo wymiernie, np.: jako wzrost przychodów, spadek kosztów lub jako coś trudniej mierzalnego np.: zmniejszenie określonego ryzyka, poprawa ergonomii środowiska pracy lub czy zwiększenie efektywności wybranych procesów.

Powyższe stwierdzenie wydaje się oczywistością, a jednak często w swojej praktyce widuję projekty z niewłaściwie określonym celem biznesowym, wyrażonym jako wdrożenie określonego systemu. Projekty takie od samego początku są realizowane z założeniem, że miarą ich sukcesu jest fakt wdrożenia z góry wybranego systemu, niezależnie jakie finalnie przyniesie to skutki dla organizacji.

W konsekwencji skupiają się jedynie na pozyskaniu szczegółowych wymagań, które najczęściej są następnie realizowane jedynie w takim zakresie, na jaki pozwala konfiguracja systemu.

W artykule przedstawię na konkretnych przykładach, co zrobić, by zadziałać bardziej efektywnie.

Najpierw wymagania, potem rozwiązanie

Ze wskazaniem finalnego rozwiązania nie warto się śpieszyć. Nie chodzi tutaj oczywiście o zbędną zwłokę i przeciąganie podejmowana decyzji, ale o poprzedzenie wyboru rozwiązania rzetelnym i poprawnym zdefiniowaniem potrzeby, wymagań oraz rozpoznaniem dostępnych opcji. Na tym właśnie polega prawidłowo przeprowadzana analiza biznesowa, definiowana w BABOK (A Guide to the Business Analysis Body of Knowledge®), jako:

Praktyka umożliwiania zmian w kontekście przedsiębiorstwa poprzez definiowanie potrzeb i rekomendowanie rozwiązań, które dostarczają wartość interesariuszom.

Warto przytoczyć również znajdującą się w BABOK definicję potrzeby:

Problem lub szansa, którymi należy się zająć.

oraz definicję wymagania:

Użyteczna reprezentacja potrzeby.

Należy zatem najpierw zdefiniować potrzebę i wyrażające je wymagania, a dopiero w kolejnym kroku przejść do analizy dostępnych opcji oraz rekomendowania rozwiązań. Wynika z tego, że cel danej inicjatywy nie powinien być wyrażony jako wdrożenie systemu XYZ, ale jako problem, który należy rozwiązać lub szansa, którą należy wykorzystać.

Dlaczego tak?

Gdy nie koncentrujemy się najpierw na potrzebie i wymaganiach, ale od razu przechodzimy do konkretnych rozwiązań, często tracimy z oczu rozwiązania potencjalnie lepsze, zaspokajające rzeczywistą potrzebę w większym stopniu i dostarczające większej wartości.

Banalnym przykładem będącym ilustracją tego zjawiska jest sytuacja, z którą spotkałem się, pracując jako analityk IT w jednym z banków inwestycyjnych. Zespół, którego byłem częścią, odpowiadał za utrzymanie i rozwój kilku systemów informatycznych. Pewnego dnia użytkownicy jednego z systemów skontaktowali się z nami i przekazali nam „wymagania” mówiące o konieczności dodania do systemu formularza zawierającego konkretne pola. Opisali również, w szczegółowy sposób, miejsce w systemie, do którego mają trafiać wprowadzone ręcznie dane.

Słowo wymagania w poprzednim zdaniu celowo ująłem z cudzysłów, gdyż nie były to wymagania, a konkretna propozycja rozwiązania. Idąc utartym i znanym schematem rozumowania (brak danych -> wprowadzanie ich przez formularz), użytkownicy systemu stracili z pola widzenia potencjalnie inne, lepsze rozwiązania. Oczywiście po krótkiej rozmowie okazało się, że ich rzeczywistą potrzebą nie jest posiadania formularza w systemie, ale możliwość obsługi nowych produktów inwestycyjnych. Aby móc to robić, potrzebują konkretnych danych. Wiedząc to, po krótkiej analizie mogliśmy zaproponować inne, lepsze rozwiązanie polegające na automatycznym imporcie potrzebnych danych.

Powyższy przykład jest banalny, ale dobrze ilustruje on problem, który może wynikać ze zbyt wczesnego definiowania rozwiązań, bez poprzedzającej to rzetelnej analizy. Problemem tym jest wybór i wdrożenie rozwiązania, które być może w jakimś stopniu zaspokaja rzeczywistą potrzebę biznesową, ale nie jest optymalne.

Przytoczony przykład dotyczy niewielkiej funkcjonalności w istniejącym już systemie informatycznym, a nie całościowego wdrażania nowego systemu. Jednak podczas realizowania dużych i skomplikowanych projektów wpadamy często w identyczna pułapkę. Dodatkowo, im większa jest inwestycja, tym istotniejsze staje się to to, aby zrealizować w jej ramach najlepsze z możliwych, a nie zaledwie „jakieś” rozwiązanie.

AS-IS i TO-BE

Jak już wcześniej wspomniałem, punktem wyjścia do rozpoczęcia określonej inicjatywy powinno być zdefiniowanie potrzeby. To właśnie ona informuje o tym co, chcemy uzyskać jako organizacja i to ona powinna stanowić podstawę do zdefiniowania wymagań biznesowych.

Następnym krokiem powinna być analiza stanu obecnego (AS-IS), czyli stanu, w którym obecnie znajduje się organizacja i w którym istnieje zdefiniowana potrzeba biznesowa. Następnie przejść należy do zdefiniowania stanu docelowego (TO-BE), czyli stanu organizacji, w którym potrzeba biznesowa zostanie zaspokojona.

Zwykle istnieje sporo możliwych przejść pomiędzy stanem obecnym (AS-IS) oraz docelowym (TO-BE). Mogą one łączyć wiele elementów i wymagać zmian procesów biznesowych, inwestycji w kompetencje pracowników, czy też wdrożenia odpowiednich systemów IT. Każde z możliwych przejść jest potencjalną opcją rozwiązania. Należy je ocenić, porównać i wybrać najlepsze z nich.

Business Case – do czego służy?

Dokumentem, który zdecydowanie wspiera opisane powyżej podejście, jest Business Case. Jego opracowywanie stanowi jedną z technik opisanych w BABOK.

Dokument ten przedstawia:

• potrzebę biznesową,
• oczekiwany rezultat, który pozwoli na jej zaspokojenie,
• porównanie zidentyfikowanych opcji rozwiązania.

Opcje rozwiązana są ocenione za pomocą wybranych kryteriów. Zwykle są to:

• koszty,
• wartość biznesowa,
• powiązane ryzyka.

Business Case kończy się zazwyczaj rekomendacją jednego z rozwiązań, popartą jasnymi i rzeczowymi argumentami. Przedstawienie i porównanie opcji w tej formie oraz rekomendowanie jednej z nich pozwala interesariuszom, w tym szczególnie sponsorowi projektu, na podjęcie trafnej, poprzedzonej analizą decyzji o wyborze konkretnego rozwiązania.

Przeprowadzając analizę w opisany sposób, definiując różne możliwości dotyczące rozwiązania i rzetelnie porównując je pomiędzy sobą, stanowczo zwiększamy prawdopodobieństwo wyboru optymalnego rozwiązania, długofalowo dostarczającego organizacji maksymalną wartość. W konsekwencji dbamy o to, aby nasz projekt okazał się sukcesem, a nie kosztowną i nikomu niepotrzebną lub niechcianą inwestycją, nieprzynoszącą oczekiwanego zwrotu.

Czy to działa?

Argumentem potwierdzającym tezę o poprawności opisanego podejścia może być przykład projektu realizowanego dla jednego z klientów. Projekt miał dotyczyć analizy przedwdrożeniowej systemu ERP. Wydawał się trudny ze względu na wcześniejsze, negatywne doświadczenia klienta, który twierdził, że wcześniej „ […] miał problem, wdrażał system, wydawał pieniądze i nadal miał problem”.

Po namowach klient zgodził się, aby tym razem projekt nie dotyczył stricte analizy wymagań dotyczących wdrożenia konkretnego systemu IT, lecz aby potraktować go jako okazję do analizy i optymalizacji jego organizacji. W efekcie zdefiniowana została potrzeba i wynikające z niej wysokopoziomowe wymagania biznesowe. Następnie przeprowadzona została analiza AS-IS oraz TO-BE wybranych procesów. Obejmowała ona opracowanie modeli w notacji BPMN.

Finalnym rezultatem była lista proponowanych zmian i optymalizacji dotyczących analizowanych procesów oraz zbiór wymagań dotyczących systemów informatycznych mogących je wesprzeć. Cała analiza przeprowadzona została według zasady „solution agnostic”, czyli bez zakładania z góry wdrożenia konkretnego systemu, a skupiając się na wymaganiach organizacji i oczekiwanych rezultatach.

Na podstawie udokumentowanych wymagań powstał dokument RFP (ang. Request for proposal), który wysłano do dostawców oprogramowania w celu uzyskania ofert. Oczywiście klient otrzymał pełne wsparcie w zakresie analizy ofert i wyboru wykonawcy, a następnie wdrożenia systemu.

Ostatnim etapem projektu było sprawdzenie, czy zaproponowane zmiany, w tym zmiany w procesach oraz wdrożenie wybranych systemów IT, przyniosły oczekiwany skutek. W tym celu opracowano mierniki wynikające wprost ze zdefiniowanych na początku projektu wymagań biznesowych.

Na podstawie zebranych danych okazało się, że rzeczywiście wymagania biznesowe zostały spełnione, a co za tym idzie, zdefiniowana potrzeba organizacji została zaspokojona. Dzięki porównaniu różnych opcji rozwiązania, bez początkowego założenia co do wyboru konkretnego systemu, została ona zaspokojona w sposób optymalny.

***

Jeśli interesuje Cię temat Analizy Biznesowej, sprawdź koniecznie inne artykuły naszych specjalistów.