Analiza usprawnień w procesie (odc. 8.)

Przeszliśmy mozolną drogę mapowania stanu ASIS. W kolejnych mailach opisałem, co po kolei należy zrobić i jak uniknąć pułapek używając metody Event Storming. Dzisiaj domykamy proces ASIS i zaczynamy wprowadzać usprawnienia w procesie biznesowym. Nie martw się, to jeszcze nie jest koniec cyklu, lecz domknięcie etapu.

Dążymy stanu, który poglądowo można wyrazić poniższym obrazkiem.

Mamy zatem: zampowaną domenę, wydzielone i nazwane podprocesy. Lecz cóż to są za nowe karteczki w kolorze...(nie jestem pewny) morskiej zieleni? To są propozycje usprawnień.

Poszukiwanie usprawnień w procesie biznesowym

W trakcie Event Stormingu, który opisałem, uczestnicy ze strony Twojego klienta, będą aż kipieć chęcią rozmowy nad tym, jak powinien działać ich biznes, po wprowadzeniu zmian. To zrozumiałe - są zmęczeni stanem obecnym, dlatego zatrudnili Ciebie lub firmę, w której pracujesz.

Z drugiej strony pisałem również, że aby przepisać ten moduł (na tym się wszak teraz skupiamy), potrzebujesz mieć punkt odniesienia w postaci stanu ASIS - jak jest teraz. Jednoczesne analizowanie perspektyw ASIS oraz TOBE, nie wychodzi na zdrowie.

Z trzeciej strony, uczestniczy się będą się niecierpliwić, bo chcą się podzielić swoim pomysłami. W tym momencie w sukurs przychodzi karteczka w kolorze morskiej zieleni - usprawnienia. Piszę o niej dopiero teraz, żeby zachować w tekście elementarny porządek, lecz Ty gdy tylko zauważysz, że uczestnicy warsztatu zaczynają zmierzać w stronę procesu TOBE, powiedz, że "za pomocą pomarańczowych faktów wyklejamy proces takim, jaki on jest teraz. Jednak na zielonkowych kartkach zamieszczajcie swoje pomysły i wskazówki na temat tego, jak inaczej i lepiej powinien on działać".

Taka informacja przeważnie wystarczy. Co jakiś czas sprawdzaj tylko, czy zielonkawych karteczek nie robi się czasem więcej niż pomarańczowych. Prosty zabieg z zapisywaniem usprawnień pomaga przeprowadzać Event Storming w sposób bardziej płynny.

Potwierdź ASIS z klientem

Ostatecznym klepnięciem, że mamy stan ASIS wraz z propozycjami usprawnień jest potwierdzenie przez klienta. Jeśli jednak przeprowadziłeś proces analizy w sposób, który opisałem w tym i poprzednich mailach, potwierdzenie już wydarzyło. Osoby ze strony klienta uczestniczyły w warsztatach, są na bieżąco, rozumieją o co chodzi i niecierpliwie czekają na dalsze efekty.

Karteczki usprawnień w procesie biznesowym to nie dokumentacja

A co z dokumentacją? No, przecież zazwyczaj przy tego typu przedsięwzięciach trzeba przygotować jakiś dokument do akceptu, projekt techniczny, studium wykonalności, itd.

Pamiętaj proszę, że karteczkowa wyklejanka z Event Stormingu to nie jest dokumentacja projektowa. Event Storming to metoda warsztatowa, która ułatwia współpracę z klientem i angażuje go do tej współpracy. Spotykam klientów, którzy wprost tego rodzaju współpracy oczekują. No, może nie powiedzą wprost, że chodzi im o Event Storming, ale powiedzą, że chcą współpracować: po partnersku, blisko, z zaangażowaniem, ewentualnie: zwinnie, adżajlowo :)

Ja spotkałem się z tym, że klienci cenią sobie ten rodzaj współpracy. Przede wszystkim wyraźnie mówią, że karteczkową wyklejankę rozumieją, natomiast dokumentację projektową niekoniecznie.

Może się jednak zdarzyć, że w przypadku:

• projektów publicznych,
• uwarunkowań przetargu,
• oczekiwania klienta,
• wymagań regulatora z konkretnych branż np. bankowość, lotnictwo, automotive

opisane usprawnienia w procesie biznesowym nie wystarczy i dokumentacja techniczna będzie potrzebna. Wtedy trzeba ją przygotować i jest to osobny artefakt. Użytecznym szablonem do przygotowania takiej dokumentacji jest Software Requirements Specification, który możesz pobrać tu.

Dobrze jest, dopóki jest dobrze

Nieformalne podejście, którą opisuję, nie opiera się na wykazie dostarczonych produktów projektu, lecz na stylu współpracy, zaangażowaniu, zaufaniu oraz końcowym efekcie, który będzie wartościowy dla klienta. Ten rodzaj relacji można krótko streścić jako: Jest dobrze, dopóki jest dobrze.

Oznacza to, że w przypadku trudności, opóźnień i różnego rodzaju nieprzewidzianych sytuacji, klienci mogą zachowywać się różnie - w zależności od swoich doświadczeń, kultury organizacyjnej i potencjalnego ryzyka wynikającego z zaistniałych trudności. Trudno to przewidzieć. Dlatego najprawdopodobniej Key Account Manager, Project Manager, członek zarządu, czy ktokolwiek kto jest odpowiedzialny za relację z tym klientem, będzie nalegać na zachowanie pewnych formalności. Formalnościami mogą być spotkania odbioru, oficjalne maile potwierdzające zakończenie etapu prac, itp. Zgódź się na to, pamiętając że jest to element zarządzania ryzykiem, a priorytetem zawsze pozostaje wartość dostarczona klientowi.

W kolejnych odcinkach skupię się na tym od czego zacząć prace, jak wybrać priorytety, jak zaplanować kolejne etapy dostarczania.

Pisane w Gdyni, tuż po spotkaniu na meetupie dla analityków :)