Budowa Flow Management System – od czego zacząć? (cz.1)

Chcecie zatem zbudować Flow Management System bazujący na Lean, Kanban (opisany na https://www.jsproject.pl/flow-mgt-system/966-flow-management-system-z-kanbanize) tak by w całej firmie pracować efektywnie pod względem ekonomicznym, nad najlepszymi - z punktu widzenia celów firmy – inicjatywami i projektami, dostarczać produkty – i związaną z nimi hipotetyczną wartość w sposób przewidywalny.

I stawiacie sobie pytanie; co na początek jest niezbędne do podjęcia takich prac oraz od czego zacząć?

 

Jak zacząć budowę Flow Management System

Poniżej znajdziecie garść praktycznych wskazówek, wynikających z naszych doświadczeń z ostatnich 2-3 lat.

Pierwszą wskazówkę znajdziemy u Lewisa Caroll’a w „Alicji w krainie czarów” – „Begin at the beginning”. A na ten początek składają się - moim zdaniem – następujące elementy:

  1. Znajomość – choćby podstawowa zasad i praktyk Flow Management, gdyż to one są podstawą budowanego systemu zarządzania
  2. Odpowiedź na pytanie: po co chcemy zbudować FMS, czyli świadomość i znajomość konkretnych bolączek/problemów aktualnego sposobu funkcjonowania firmy i blisko z nią związana wizja efektywnego funkcjonowania firmy
  3. Zwinny mind-set, zarówno kadry zarządzającej, jak i pracowników, obejmujący: nastawienie na ciągłe doskonalenie się i uczenie, nastawienie na pracę zespołową, orientację na rezultaty biznesowe i klienta (wewnętrznego, jak i zewnętrznego), transparentność.

Jeśli któregoś elementu brakuje, to zdecydowanie warto właśnie na początku go zacząć tworzyć, czy to przez udział w warsztatach Flow Management, czy też poprzez przeprowadzenie sesji identyfikacji występujących w firmie problemów biznesowych i organizacyjno-zarządczych.

Mając taki fundament można zacząć budowę Flow Management System. I od razu uwaga: warto zacząć myśleć i działać systemowo, czyli biorąc pod uwagę albo cały system – czyli naszą firmę, albo też dużą jego część, np. kluczowe działy i/lub obszary biznesowe. I najlepiej by taki system obejmował albo całość:  od poziomu zarządczego, po poziom realizacyjny, albo też pionowy wycinek firmy: także od poziomu zarządczego, po poziom realizacyjny.

A pierwszym krokiem jest identyfikacja lub nieduża modyfikacja istniejących procesów realizacyjnych i procesu zarządczego oraz ich wizualizacja na tablicy Kanban. W przypadku firmy realizującej projekty będą to – patrząc od dołu:

  • Procesy realizacyjne – wytwórcze, np. proces wytwarzania oprogramowania lub proces/procesy tworzenia produktu non-IT, np. nowego mebla, lub nowego muralu
  • Proces projektowy: od podpisania umowy (lub nawet wcześniej, czyli łącznie z procesem ofertowania i sprzedaży) poprzez proces realizacyjny – taki sam, jak powyższy proces lub nieco zagregowany, do wytworzenia produktu lub jego dostarczenia do klienta (zależy to od kontekstu firmy i przyjętych założeń)
  • Proces portfelowy obejmujący projekty realizowane przez firmę.

Mając przedyskutowane te procesy teraz można przystąpić do ich modelowania i konfigurowania w platformie Kanbanize. Dlaczego platforma Kanbanize? Pisałem o tym w innych tekstach "Dlaczego wybieram platformę Kanbanize cz.1 i cz.2".

I teraz z pewnością zapytacie: a dlaczego już na tym etapie pojawia się platforma? Czy nie wystarczą tablice fizyczne?

Korzyści z podejścia systemowego

Tablice fizyczne były dobre dawno temu, gdy firmy nie tworzyły całego systemu, lecz tylko pojedyncze zespoły, niewspółpracujące ze sobą zaczynały pracować zwinnie. To właśnie przypadek pojedynczego zespołu Scrumowego. Teraz jednak nie chodzi o to by ta enklawa, jaką jest pojedynczy zespół mógł pochwalić się zwinnością. Teraz firma potrzebuje systemowego, całościowego rozwiązania. Dlatego też takie, a nie inne proponowane podejście.

Dodatkowo korzyść takiego systemowego podejścia to: włączenie kadry zarządzającej: PM-ów, menedżerów Produktu i – co szczególnie ważne – kadry zarządzającej najwyższego szczebla, np. zarządu, lub członków tzw. Rady Portfela – ciała decydującego w większych firmach o portfelu projektów. Flow musi być zarówno na poziomie realizacyjnym – tam, gdzie wykonywane są prace, lecz także na poziomach wyższych – tam gdzie podejmowane są decyzje, rozwiązywane problemy poza zakresem odpowiedzialności zespołu.

Częsty problem  jaki napotykam to: Flow w zespole i … tylko na poziomie zespołu. Flow w zespole to konieczny element Flow na poziomie firmie. Konieczny, lecz niewystarczający. Problem z Flow na poziomie zespołu nazywa się: lokalna optymalizacja: zespół dostarcza efektywnie swoje produkty.  Tyle, że firma nie dostarcza na czas, tego co chcą klienci. Potrzebna jest bowiem optymalizacja globalna – na poziomie całego systemu. A ona będzie możliwa, gdy od samego początku będziemy budowali całościowe rozwiązanie, czyli system.

Czyli w pierwszym kroku: „wkładamy” zidentyfikowane, lub nieco ulepszone procesy w Kanbanize i … oglądamy, analizujemy i testujemy. My, czyli tzw. Master Team Klienta – zespół osób budujących, zwykle z większym lub mniejszym wsparciem zewnętrznego konsultanta, specjalisty w zakresie Flow Management i platformy Kanbanize.

Testujemy i ewentualnie rozbudowujemy konfigurację rozwiązania w Kanbanize o takie elementy, jak:

  • Zależności pomiędzy produktami i/lub procesami
  • Powiadomienia (najczęściej mailowe) o wykonaniu konkretnego produktu lub zajścia konkretnego zdarzenia
  • Automatyzacja wybranych działań (jak np. tworzenie „dzieci Projektu”, czyli jego głównych produktów) poprzez zastosowanie tzw. reguł biznesowych dostępnych w Kanbanize

Po tym testowaniu i rozbudowaniu konfiguracji i potwierdzeniu przez Master Team, że rozwiązanie w Kanbanize jest „good enough”, czyli wystarczająco dobre, przychodzi czas na jego wykorzystanie przez użytkowników z firmy: członków zespołów realizacyjnych, menedżerów – na przykład kierowników projektów i menedżerów odpowiedzialnych za portfel realizowanych projektów  i … lub produktów, a także menedżerów sprzedaży. Testowanie i zbieranie doświadczeń, zbieranie propozycji usprawnień. Będą one istotnym wkładem do kolejnego etapu budowy systemu FM w firmie.

Zaraz, zaraz spytacie. A co z limitami prac w toku? Co z raportami i panelami menedżerskimi? Co z ustaleniem na poziomie procesów SLE, czyli Service Level Expectations?

„Nie od razu Kraków zbudowano”. I tak samo jest z Flow Management System. Oprócz fundamentów potrzebna jest solidna baza, czyli procesy: realizacyjne, projektowe lub produktowe i portfelowe. Testowanie przez Master Team oraz okres pracy z rozwiązaniem użytkowników z różnych poziomów zarządzania daje taką właśnie solidną bazę do dalszego, ewolucyjnego, realizowanego drogą współpracy rozwoju rozwiązania. Tak, jak sugerują to zarówno Lean, jak i Kanban.

O kolejnym etapie budowy Flow Management System przeczytacie w odrębnym tekście.