O problemach na projektach i roli analizy już pisaliśmy. Nie jest tajemnicą, dlaczego nie wolno oszczędzać na analizie i z jakimi problemami najczęściej trzeba się zmierzyć podczas wyzwania, jakim jest wdrożenie systemu informatycznego w firmie. Tym razem będzie kilka słów o tym, jak nas widzi analityk i jak powinniśmy modelować współpracę z nim, żeby zwiększyć prawdopodobieństwo sukcesu.
Analiza biznesowa a koncepcja wdrożenia. Czym to się różni?
Zacznijmy od tego, czym jest proces biznesowy. Wikipedia podaje nam:
„Seria powiązanych ze sobą działań lub zadań, które rozwiązują określony problem lub prowadzą do osiągnięcia określonego efektu.”
Zgodnie z tą definicją, procesy biznesowe zachodzą nawet w jednoosobowym zakładzie szewskim, jednak praktyka pokazuje, że firmy tych rozmiarów nie sięgają po rozwiązania klasy CRM/ERP. Tym samym analityk, idąc na spotkanie, spodziewa się, że procesów będzie sporo, a poziom ich złożoności – mocno zróżnicowany.
Cytując klasyka, „oczywistą oczywistością” jest, że nie da się zrobić koncepcji wdrożenia w oderwaniu od procesów biznesowych organizacji, a trzeba sporządzić analizę procesów. Analiza procesów, a co ważniejsze ich świadomość w organizacji, musi zaistnieć jeszcze zanim zaprosimy do współpracy partnera, który wdroży nam np. CRM. Czasami w trakcie takiej analizy okazuje się, że dodatkowo potrzebujemy w firmie jeszcze systemu klasy ERP lub że wystarczy nam zaprzyjaźnić się z Power BI. Ile wdrożeń, tyle historii, a każda jest inną przygodą.
Analiza biznesowa skupia się na tym, jakie cele rynkowe chce osiągnąć organizacja, jaka jest motywacja biznesowa dla poszczególnych działań oraz dla całej firmy, kto, kiedy i po co wykonuje jakąś pracę, jaki jest przepływ informacji oraz jakimi zasobami organizacja dysponuje. Efektem analizy powinien być kompletny i spójny opis działania firmy. Na tej podstawie mogą pojawić się konkretne rekomendacje dotyczące zmian, w tym wdrożenia narzędzi wspomagających, to właśnie tu jako firma powinniśmy zobaczyć, czego dokładnie potrzebujemy. W idealnym świecie to analityk biznesowy powinien pośredniczyć w rozmowach z przedstawicielami dostawcy konkretnej technologii. Staje się swego rodzaju pośrednikiem, w zwinnych metodykach prowadzenia projektu nazywany jest Product Owner. Jednak praktyka pokazuje, że bywa z tym różnie. Tak to obrazuje Scott Ambler:
Kiedy już mamy wynik analizy biznesowej, rekomendacje mówiące o potrzebie wdrożenia systemu, który pomoże nam skuteczniej zarządzać relacjami z naszymi klientami, wybieramy technologię, a następnie dostawcę. Zapewne dostawca powie nam, że musi zrobić analizę, która potrwa kilka dni, za którą musimy zapłacić. I tu często zdarza mi się usłyszeć od Klienta:
„Ale jaką analizę? My już mamy wszystko przeanalizowane, był analityk, rozpisał nam procesy, mamy diagramy, wszystko pięknie rozrysowane w BPMN, nie widzimy sensu i potrzeby płacić za to ponownie.”
W tym miejscu krzyżują się drogi analityka biznesowego z tym, który przygotuje koncepcję wdrożenia konkretnego systemu, np. Dynamics 365. Tworząc koncepcje wdrożenia, interesuje nas to, jak w danym procesie lub jego fragmencie ma zachować się system, gdzie powinien wspierać użytkownika, a gdzie przebieg procesu automatyzować. Zapewne u klienta zrodzi się pytanie, czy to nie może być jeden człowiek i jedna analiza? W mojej ocenie – tak, może być, ale nie zawsze.
Podczas jednego z seminariów na temat prowadzenia analizy biznesowej prelegent wprost powiedział, iż wg niego „analityk biznesowy, który zna technologię, to szkodnik”. Osobiście jako analityk uważam, że to zależy. Od czego?
Wyobraźmy sobie, że chcemy w naszym właśnie budowanym salonie mieć schody prowadzące na antresolę, nasza wiedza na temat schodów jest mierna, a wymagania sprowadzają się do :
- Ma nimi bez problemu wejść 4 rosłych facetów niosących sejf.
- Nie powinny zajmować całego salonu.
- Mają mieć dyskretne poręcze.
Kiedy zapytamy stolarza o te schody, to na 100% będą drewniane, a kiedy kowala, pewnie będą stalowe. I tu jest rola dla analityka biznesowego, który na bazie swojej wiedzy, kompetencji i doświadczenia mógłby pomóc nam podjąć decyzję, z czego i jakie optymalnie będą te schody. Jednak gdy jesteśmy na pewni, że muszą być drewniane, już śmiało możemy szukać stolarza.
Chodzi o to, żeby analityk skupił się na procesach w firmie i zbudował obiektywną analizę potrzeb klienta, na podstawie której wybierzemy optymalne rozwiązanie. Nie odwrotnie – czyli nie chcemy, żeby analityk budował opinię, mając w głowie sugestię docelowego systemu. Chyba, że wybraliśmy już swoje wymarzone rozwiązanie i do analityka zwracamy się tylko z prośbą o prześledzenie procesów i wskazanie miejsc do ulepszenia przez system.
W praktyce w większości małych i średnich wdrożeń to jest jeden człowiek, który zanim zaprojektuje funkcjonalność systemu, omawia na spotkaniu procesy biznesowe. Nie jest rzadkością, że w trakcie takiego spotkania dopiero buduje się świadomość istnienia tych procesów i jednocześnie je optymalizuje. Chyba każdy analityk przynajmniej raz usłyszał „to w sumie po co my to tak robimy?”.
Co wspólnego ma dobry kelner z analitykiem?
Na koniec kilka słów o tym, czego żaden analityk nie powinien robić. W mojej ocenie najważniejszym elementem pracy jest jej wynik, dlatego też analiza nie powinna skończyć się na zapisaniu wymagań w postaci listy życzeń, takie podejście nazywamy pracą „na kelnera”, czyli zebraniem zamówienia. Tak jak w dobrej restauracji oczekujemy, że kelner poleci nam wybór dań, a potem zasugeruje kilka win, z którymi te dania będą się świetnie komponowały, tak po profesjonalnej analizie powinniśmy dostać kilka sugestii, pomysłów czy też tak zwanych dobrych rad opartych na doświadczeniu analityka w innych projektach. Powinien nam na każdym etapie przedstawiać optymalną perspektywę, bo proces biznesowy sam w sobie przypomina kryształ, jest zamkniętą i zdefiniowaną bryłą, jednak w zależności od perspektywy z jakiej na niego patrzymy, łypie do nas różnymi kolorami.