Pracuję inaczej. Pierwsze wdrożenie zamyka się w czterech tygodniach, w jednym dziale, i kończy działającym narzędziem w codziennej pracy zespołu. Poniżej rozkładam, co dzieje się tydzień po tygodniu i dlaczego akurat taka skala.

Dlaczego cztery tygodnie, a nie pół roku

Cztery tygodnie to nie skrót ani promocja. To skala dobrana do tego, jak działa średnia firma produkcyjna.

Dłuższy projekt ma jedną wadę, o której mało kto mówi na starcie: im dłużej trwa, tym bardziej oddala się moment, w którym ktokolwiek widzi efekt. Pół roku to dość czasu, żeby zmienił się priorytet zarządu, odszedł człowiek, który był po stronie projektu, albo żeby zespół zdążył uznać, że „znowu coś wdrażają i nic z tego nie będzie". Widziałem projekty, które umarły nie dlatego, że rozwiązanie było złe, tylko dlatego, że nikt nie dożył efektu.

Krótki cykl odwraca tę logikę. Po czterech tygodniach jest coś, czego się używa. Nie prezentacja, nie raport, nie prototyp do dalszych rozmów. Narzędzie, które ktoś w dziale otwiera w poniedziałek rano i które oszczędza mu czas. To zmienia całą dynamikę — następna decyzja zapada na podstawie czegoś, co działa, a nie obietnicy.

Drugi powód jest praktyczny. Cztery tygodnie to czas, w którym da się w pełni zaangażować zespół jednego działu bez wyłączania go z bieżącej pracy. Dłuższe zaangażowanie zaczyna konkurować z robotą, którą ci ludzie i tak muszą wykonać. Krótszego nie starcza na rozpoznanie i zbudowanie czegoś sensownego. Cztery tygodnie trafiają w okno, w którym jedno i drugie się mieści.

Tydzień pierwszy — rozpoznanie

Pierwszy tydzień nie jest o technologii. Jest o tym, jak dział naprawdę pracuje.

Siadam z zespołem i przechodzę przez to, co robią każdego dnia. Gdzie schodzi czas. Co się powtarza. Co wszyscy robią, choć nikt nie lubi. Gdzie informacja grzęźnie, przepada albo przechodzi przez czyjąś głowę, bo nie ma jej nigdzie indziej. To są miejsca, w których AI ma sens. Nie te, które brzmią efektownie. Te, które bolą codziennie.

Wchodzę z katalogiem typowych problemów dla danego działu, bo część rzeczy powtarza się w firmach produkcyjnych niezależnie od branży. Ale katalog to punkt wyjścia, nie gotowa odpowiedź. W pierwszym tygodniu sprawdzam, które z tych problemów są w tym dziale realne dzisiaj, a które trzeba dopisać, bo są specyficzne dla tego biznesu.

Pod koniec pierwszego tygodnia jest moment decyzyjny. Wybieramy, co dokładnie budujemy. Jeśli na tym etapie obraz się nie zgadza, lepiej to wiedzieć po tygodniu niż po miesiącu — i tak ten checkpoint jest skonstruowany.

Pierwszy tydzień pilotażu pokrywa się z tym, co daje Audyt Gotowości AI — rozpoznanie, gdzie wdrożenie ma sens. Jeśli chcesz tę mapę mieć przed decyzją o pełnym pilotażu, audyt jest krokiem zero. → Audyt Gotowości AI

Tygodnie środkowe — budowa z zespołem, nie obok zespołu

Tu powstaje narzędzie. Ważniejsze od tego, co się buduje, jest jak.

Aplikacja powstaje razem z ludźmi, którzy mają z niej korzystać. Nie znika na dwa tygodnie do budowy, żeby wrócić gotowa. Zespół widzi kolejne wersje, mówi, co nie pasuje, i poprawiamy to na bieżąco. Brzmi oczywiście, a robi całą różnicę — narzędzie zbudowane w oderwaniu od ludzi, którzy mają go używać, prawie zawsze rozmija się z tym, jak praca wygląda naprawdę.

Jest w tym drugie, mniej widoczne założenie. Przez te tygodnie zespół uczy się, jak to działa. Nie chodzi o to, żeby zrobić z nich programistów. Chodzi o to, żeby rozumieli, co mają w ręku — gdzie są granice narzędzia, czemu czasem odpowiada inaczej, kiedy mu ufać, a kiedy sprawdzić. Po wdrożeniu, w którym ludzie tylko dostali gotowy system, zostaje zależność. Po takim, w którym współbudowali, zostaje kompetencja. To jest różnica, na której mi zależy.

Tydzień ostatni — wejście do codziennej pracy

Ostatni tydzień to przejście od „działa na pokazie" do „działa w robocie".

Narzędzie wchodzi do realnego użycia. Wychodzą rzeczy, których nie widać na demo — sytuacja brzegowa, której nikt nie przewidział, krok procesu, który w praktyce wygląda inaczej niż na warsztacie. To się domyka teraz, na świeżo, kiedy jeszcze jestem w dziale.

Zostaje działające narzędzie, zespół który umie z niego korzystać, i obraz tego, co dalej. Bo pierwszy pilotaż rzadko jest końcem. Częściej pokazuje kolejne miejsca, w których to samo podejście się przyda — w tym samym dziale albo obok. Co z tym zrobić, to już osobna decyzja, podejmowana na podstawie czegoś, co masz w ręku, a nie czego się spodziewasz.

Czego ten pilotaż nie jest

Trzy rzeczy, żeby było uczciwie.

Nie jest transformacją całej firmy. Pracuje w jednym dziale, z jednym czy dwoma procesami. To jest celowe. Wielkie wdrożenia „wszystko naraz" to dokładnie ten rodzaj projektu, który ginie w pół roku — pisałem o tym osobno przy okazji mikroaplikacji.

Nie jest gotowym produktem z półki, który się włącza. Powstaje pod konkretny dział i konkretny proces, więc wymaga zaangażowania zespołu przez te cztery tygodnie. Bez tego zaangażowania nie ma z czego budować.

I nie jest magią. AI nie rozwiąże procesu, który jest popsuty u podstaw — najwyżej szybciej pokaże, że jest popsuty. Jeśli problem działu leży w tym, jak praca jest poukładana, to najpierw układamy pracę, a dopiero potem nakładamy na nią narzędzie. Czasem najlepszym efektem pierwszego tygodnia jest właśnie ta diagnoza.

Co dalej

Jeśli zastanawiasz się nad pierwszym wdrożeniem, kolejność jest prosta. Wybierz dział, w którym jest powtarzalny proces albo powtarzalny problem — tam zwrot przychodzi najszybciej. Sprawdź, czy ten proces jest na tyle poukładany, że da się go wesprzeć narzędziem. I zacznij od rozpoznania, zanim cokolwiek się buduje.

Pełną mechanikę pakietu, sześć wariantów obszarowych dopasowanych do działów i odpowiedzi na konkretne pytania trzymam na osobnej stronie.

→ Zobacz Wdrożenie Pilotażowe i sześć wariantów → Umów konsultację 30 minut