Projekt z celem, nie jednorazowa naprawa — metodyka pracy z systemami organizacyjnymi

Bazy wiedzy, automatyzacje i nowe narzędzia najczęściej nie padają z przyczyn technicznych. Padają, bo ktoś zbudował je tak, że działają wyłącznie przy jednej konkretnej osobie. Kiedy ta osoba odchodzi, całość zaczyna gnić.

Projekt, nie naprawa

Zamiast łatać, warto każdą taką rzecz, czy to bazę wiedzy, stronę, czy automat, potraktować jak projekt: z celem, ale i z pomysłem na to, co stanie się po uruchomieniu. Jeżeli po wdrożeniu cała wiedza o rozwiązaniu zostaje u wykonawcy, firma uzależnia się od jednej osoby albo jednej agencji. Trwale wygląda to inaczej: wdrożenie zaczyna kolejny etap, a dokumentacja i sposób obsługi przechodzą do firmy.

Trzy zasady, które stosuję w każdym wdrożeniu

1. Opisuj decyzje, nie tylko efekt. Kiedy zapiszesz, dlaczego wybrałeś taką strukturę i co jeszcze rozważałeś, następna osoba zrozumie kontekst, zamiast ślepo powtarzać instrukcję.

2. Rób prosto, nie efektownie. Jasne kategorie i przewidywalne nazwy decydują o tym, czy ktokolwiek zajrzy tam za pół roku.

3. Tłumacz zasady, nie tylko obsługę. Zespół musi rozumieć, dlaczego proces wygląda tak, a nie inaczej. Inaczej utknie przy pierwszej sytuacji, której nie ma w instrukcji.

Nie kończ na wdrożeniu

W PROMC nie skończyło się na dniu uruchomienia. Pracuję tam nadal i co jakiś czas coś poprawiam, technicznie albo organizacyjnie. To akurat wygoda etatu, a nie model, który sprzedaję: przy zleceniach zależy mi na czymś odwrotnym, żeby firma poradziła sobie beze mnie.

Jak to wygląda w praktyce wdrożeniowej

Pytania do zadania przy każdym wdrożeniu:


Tak właśnie pracowałem przy systemie wiedzy w PROMC. Nie prowadzę stałej opieki ani abonamentów, więc każde zlecenie kończę tak, żeby dało się je utrzymać bez mojego udziału. Co dokładnie robię, opisuję w ofercie.

Zobacz też