Warsztaty przedwdrożeniowe – a komu to potrzebne?

Business Process Modelling – zacznijmy od celów

Dla jednych idealnym autem będzie mały, zwinny pojazd, który wciśnie się w każdy zakamarek parkingu i nie wymaga częstych wizyt na stacji benzynowej, dla drugich – potężny pick-up z ogromną przestrzenią ładunkową i terenowymi oponami, a dla jeszcze innych – sportowe cabrio o osiągach bolidu Formuły 1.

Podobnie jest z wdrożeniami Salesforce – może nie dosłownie, ale analogii jest sporo.

W tym, może nieco przydługim, wstępie chciałem powiedzieć, że cena wdrożenia, czas jego trwania i ilość niezbędnych do zainwestowania środków (nie tylko finansowych) zależą od ZAKRESU, innymi słowy – wymagań co do systemu. Oczywiście, wynikają one bezpośrednio z celów biznesowych, jakie klient stawia przed takim projektem.

Znasz cele? Opisz je w RFP

W idealnym świecie są one jasno określone, tak jak opis sytuacji w firmie klienta czy wstępny plan działania – zazwyczaj w formie RFI (ang. Request For Information) bądź RFP (ang. Request For Proposal) i związanych z nimi elementach procesu ofertowego.

Idealny świat, czyli idealne RFP, zdarza się sporadycznie i bardzo cieszy, niemal jak prawdziwek na grzybobraniu. Najczęściej cele biznesowe są określone mgliście lub w zarysie. Trzeba wtedy wykonać pracę u podstaw, jaką jest analiza biznesowa – czyli ustalić szczegółowe wymagania i zakres projektu, adekwatnie do wspomnianych celów biznesowych.

Na szczęście rozumiemy, że przygotowanie RFP nie jest prostą sprawą. Dlatego nie zniechęcają nas niedoskonałe czy mało precyzyjne zapytania. W takiej sytuacji – i w odpowiedzi na pytanie “Ile kosztuje samochód?” – proponujemy klientowi warsztaty.

Jeśli nie RFP, to może… warsztaty?

Nasze warsztaty nazywamy przedwdrożeniowymi, ale – co ważne – nie są one zobowiązaniem do współpracy z nami. To również okazja, aby – niezależnie od ustaleń merytorycznych – po prostu lepiej się poznać i także na tej podstawie podejmować dalsze decyzje.

Podczas warsztatów, wspólnie z przedstawicielami biznesu, skupiamy się na celach biznesowych (pojawiają się one już kolejny raz, ale nie dlatego, że autor tekstu pisze słabo i nie zadbał o unikanie powtórzeń, lecz dlatego, że są kluczowe dla sukcesu wdrożenia ?) Staramy się zrozumieć procesy, które już istnieją bądź – dzięki planowanym do wdrożenia narzędziom – będą realizowane i posłużą osiągnięciu naszych “ulubionych” celów.

“Nie samym biznesem firma żyje”. Parafrazując klasyka, chcę podkreślić, że nie mniej ważnymi uczestnikami takich warsztatów są pracownicy działów technicznych – architekci, programiści czy osoby odpowiadające w firmie klienta za szeroko rozumianą infrastrukturę IT. Ich pomoc jest niezbędna, aby łatwiej nam było wpasować puzzel z napisem “Salesforce” w sieć systemów już istniejących w firmie. (O tym, jak wybrać właściwy puzzel i jak budować rozwiązania IT na Platformie Salesforce pisaliśmy w artykule “Klocki zamiast linii, czyli o szybkim osiąganiu ROI w projektach IT”).

Zachęcamy również, aby w warsztatach wzięli udział użytkownicy końcowi, nierzadko znający niuanse procesów, z których nie tylko prezes, ale nawet sama asystentka prezesa, mogą nie zdawać sobie sprawy.

Po warsztatach – Business Process Model and Notation, podsumowanie i kolejne kroki

Co jest efektem takiego spotkania? Przede wszystkim dokumentacja powarsztatowa. Najczęściej zawiera ona takie elementy, jak:

• Proces biznesowy (kroki, aktorzy) w postaci graficznego BPMN (Business Process Model and Notation).
• Struktura organizacyjna.
• User stories, które opisują kryteria akceptacji funkcjonalności, aktorów oraz wymagania biznesowe.
• Architektura rozwiązania:
  • model danych;
  • wykorzystane funkcjonalności;
  • konieczne customizacje.
• Kontrakty integracyjne.
• Wstępna koncepcja/propozycja rozwiązania wraz z wyceną MVP (Minimum Viable Product) i jego harmonogramem.

W ten sposób klient otrzymuje pełen pakiet informacji – wie już nie tylko, co możemy wspólnie osiągnąć, ale również w jaki sposób. Co ważne – z jakimi inwestycjami będzie się to wiązało (jeśli chodzi o pieniądze i czas), a także co konkretnie dostanie w zamian.

My, jako partner, dzięki warsztatom pozyskujemy wiedzę o tym, jakie rozwiązanie dostarczyć i  bierzemy za to pełną odpowiedzialność. W centrum naszej uwagi są niezmiennie wartość biznesowa przyszłego systemu oraz cele biznesowe (nie opuszczą nas do końca tego tekstu) – pracujemy nad tym, aby mogły być zrealizowane jak najszybciej.

Business Process Model and Notation w praktyce

Co do tego, że ważne jest zaangażowanie klienta podczas przygotowywania zakresu wdrożenia, nie ma wątpliwości. Pozostaje pytanie: Jak długo ta pomoc będzie nam potrzebna? Czy uda się zamknąć temat w jeden, kilka bądź kilkanaście dni? Pamiętamy przecież, że “nie tylko nowym systemem firma żyje”, a pracownicy oddelegowani do wdrożenia mają swoje inne, stałe zadania.

Tu, podobnie jak w przypadku pytania o koszt, odpowiedź brzmi: To zależy. Zależy przede wszystkim od rozmiaru projektu. Jeśli szykuje się projekt większy, bardziej skomplikowany, realizowany w rozbudowanej infrastrukturze IT – wówczas etap analizy trwa nieco dłużej, podobnie jak samo wdrożenie. Nawet wtedy jednak staramy się podzielić ten duży tort na mniejsze, możliwe “do zjedzenia” kawałki. (Chęć wdrożenia nowego systemu na zasadzie “jednego rzutu” to jedna z wdrożeniowych pułapek – o tych typowych możecie przeczytać w tekście “6 pułapek, w które można wpaść, gdy wdraża się system IT”).

Po etapie wspólnej pracy przechodzimy do design thinking, czyli do próby dopasowania (tam, gdzie jest to możliwe) rozwiązań pudełkowych do potrzeb klienta. To prototypowanie nierzadko prowadzi w efekcie do pokazania demo rozwiązania docelowego – jako kolejnego elementu dostarczanego po warsztatach.

Jesteście ciekawi, na czym to polega? O tym, co dzieje się po warsztatach napiszę w kolejnym tekście.