Kaizen w projektach IT — dlaczego małe kroki dowożą więcej niż wielkie plany

Co to jest Kaizen

Kaizen (改善) to japońskie słowo złożone z dwóch znaków: kai — zmiana, i zen — dobry. Razem: ciągłe doskonalenie. Filozofia powstała w japońskim przemyśle po II wojnie światowej i stała się fundamentem systemu produkcyjnego Toyoty — jednego z najbardziej skutecznych systemów zarządzania jakością w historii przemysłu.

Sedno jest proste: zamiast czekać na idealny moment i przeprowadzać wielką reformę — wprowadzaj małe, regularne ulepszenia. Każde z nich jest weryfikowalne, każde buduje na poprzednim. Efekt skali pojawia się z czasem — i jest trwalszy niż efekt jednorazowej rewolucji.

W projektach danych stosujemy to podejście nie dlatego że przeczytaliśmy o nim w książce — ale dlatego że wielokrotnie widzieliśmy co się dzieje gdy ktoś próbuje odwrotnie.

Kaizen w migracji danych — tabele mają kolejność

Przy każdej migracji między systemami ERP dane mają naturalne zależności — i ta kolejność nie jest przypadkowa. Nie można migrować faktur zanim zmigrujemy klientów. Nie można migrować umów zanim zmigrujemy produkty i kontrahentów. Dane są jak drabina: każdy szczebel musi stać pewnie zanim wejdziesz na następny.

Kluczowa zasada którą stosujemy: błędy i braki na danym etapie naprawiamy zanim przejdziemy do następnego. Nie odkładamy ich "na potem" licząc że ułożą się same. W praktyce nie układają się — mnożą się.

Migracja "wszystkiego naraz" wygląda atrakcyjnie na harmonogramie — jeden duży krok zamiast czterech małych. W praktyce kończy się tygodniami debugowania niespójności które są splątane ze sobą na wszystkich poziomach jednocześnie.

Historia: projekt który szedł do przodu małymi korektami

W jednym z projektów wdrożenia ERP klientem kontaktowym po stronie zamawiającego był pracownik działu marketingu. Bez wcześniejszego doświadczenia w projektach IT, z dobrą wolą — ale z założeniem że my wiemy co trzeba zrobić i wystarczy nam przestrzeń do pracy.

W praktyce projekty danych wymagają wiedzy merytorycznej po stronie klienta: jak działają faktury i korekty, jakie są wyjątki w umowach, skąd bierze się dana wartość w konkretnym polu. Marketingowiec tej wiedzy nie miał — i projekt stanął w miejscu nie dlatego że coś było technicznie nie tak, ale dlatego że nie było komu odpowiedzieć na pytania.

To jest Kaizen w praktyce zespołowej: nie szukamy jednego idealnego rozwiązania od razu. Identyfikujemy konkretną przeszkodę, robimy małą korektę — i idziemy dalej. Korekta nie musi być doskonała, musi być wystarczająca żeby odblokować następny krok.

Kaizen kontra podejście "big bang"

Podejście "big bang" w projektach IT to wielka jednorazowa zmiana: migrujemy wszystko w jeden weekend, wdrażamy pełny system od razu, dashboard ma mieć od dnia zero wszystkie funkcjonalności. Brzmi efektywnie. W praktyce:

• → Błędy z jednego obszaru blokują wszystkie inne — bo wszystko jest połączone w jednym momencie
• → Użytkownicy dostają nowy system który jeszcze nie działa dobrze — i tracą zaufanie zanim zdążą go polubić
• → Nie ma punktu kontrolnego — nie wiadomo czy projekt idzie dobrze aż do samego końca
• → Cofnięcie się jest bardzo kosztowne — wielki krok trudno jest "odkręcić"

Małe kroki dają coś czego big bang nie daje: regularne potwierdzenie że idziemy w dobrym kierunku. Po każdym etapie wiemy co działa, co wymaga korekty i czy założenia z początku projektu nadal są aktualne.

Kaizen w codziennej pracy — nie tylko w projektach

Filozofia małych kroków nie kończy się na projekcie. Stosujemy ją też do własnych narzędzi i procesów: skrypt ETL który działa wystarczająco dobrze jest regularnie poprawiany po każdym kolejnym użyciu. Szablon dokumentacji który wydawał się kompletny — uzupełniamy gdy pojawia się pytanie na które nie odpowiada. Dashboard który klient zaakceptował — rozbudowujemy o kolejną zakładkę gdy dane w systemie stają się wystarczająco kompletne.

Nie czekamy na idealny moment żeby zacząć doskonalić. Idealny moment nie istnieje — istnieje następny krok.

Najczęstsze pytania