Projekt z celem, nie jednorazowa naprawa — metodyka pracy z systemami organizacyjnymi
Najczęstszy powód, dla którego wdrożenia systemów wiedzy, automatyzacji czy nowych narzędzi nie przetrwają roku, nie jest techniczny. Jest organizacyjny: rozwiązanie zostało zaprojektowane tak, że wymaga jednej konkretnej osoby, żeby działało — a kiedy ta osoba odchodzi, system zaczyna gnić.
Projekt, nie naprawa
Lepszym modelem niż jednorazowa naprawa jest myślenie o każdym elemencie — systemie wiedzy, stronie internetowej, automatyzacji — jako o projekcie z jasnym celem, ale też z planem na to, co dzieje się po wdrożeniu. Wdrożenie kończące zaangażowanie i wiedzę zostawiające u wykonawcy to model wysokiego ryzyka; wdrożenie zaczynające kolejny etap, z dokumentowaną i przekazaną wiedzą, to model trwały.
Trzy zasady, które stosuję w każdym wdrożeniu
1. Dokumentuj pracę, nie tylko efekt. Dokumentacja decyzji — czemu wybrano tę strukturę, jakie alternatywy rozważano — pozwala przyszłym osobom zrozumieć kontekst, nie tylko skopiować instrukcję.
2. Projektuj proste struktury, nie efektowne. Prostota — jasne kategorie, przewidywalne nazewnictwo — decyduje o tym, czy zespół realnie będzie korzystał z systemu za pół roku.
3. Szkol zespół z zasad, nie tylko z obsługi. Zespół potrzebuje zrozumieć dlaczego proces działa w ten sposób, żeby samodzielnie podjąć decyzję, kiedy sytuacja nieprzewidziana w dokumentacji się wydarzy.
Nie kończ na wdrożeniu
W jednej z prowadzonych przeze mnie transformacji organizacyjnych nie zakończyłem współpracy na dniu wdrożenia — z tym samym klientem nadal na bieżąco wprowadzam usprawnienia, techniczne i organizacyjne. Priorytetem w każdym wdrożeniu jest to, żeby organizacja mogła dalej samodzielnie korzystać z wdrożonych rozwiązań bez stałej zależności od jednej osoby.
Jak to wygląda w praktyce wdrożeniowej
Pytania do zadania przy każdym wdrożeniu: co się stanie, jeśli osoba, która to wdrożyła, zniknie z organizacji jutro? Czy ktoś inny w zespole rozumie, dlaczego system działa w ten sposób? Czy istnieje dokumentacja decyzji, nie tylko instrukcja obsługi? Kto jest odpowiedzialny za aktualizację systemu, kiedy organizacja się zmieni?
Ta metodyka stoi za pełnym case study transformacji systemu wiedzy i infrastruktury, które opisuję w Realizacjach. Jeśli Twoja organizacja potrzebuje nie tylko wdrożenia, ale dalszego wsparcia, opisuję to w Stałej opiece oraz Audycie i projekcie systemu wiedzy.