Jak nadzorować wdrożenie e-commerce dla sklepu 5-15 mln PLN obrotu bez bycia ekspertem technicznym

Większość poradników o nadzorze wdrożenia mówi to samo: ustal cele, zrób plan komunikacji, raportuj regularnie. To bezużyteczna prawda. Wdrożenie e-commerce dla sklepu o obrocie 5-15 mln PLN rocznie nie powstaje jak tramwaj. Drugiego dnia po rozpoczęciu plan jest już nieaktualny: zespół wie więcej, klient wie więcej, agencja wie więcej, a rzeczywistość zdążyła się zmienić.

Skoro plan starzeje się szybciej niż się go pisze, realny nadzór wdrożenia e-commerce wymaga trzech rzeczy: umiejętności patrzenia w przód, zapobiegania zagrożeniom i elastycznego dostosowania do zmieniającej się sytuacji. Wykres Gantta tego nie da - tu nie chodzi o harmonogram, tylko o decyzje podejmowane w trakcie projektu.

Brakuje historii z placu boju - takich, w których widać krew, pot i łzy po obu stronach. Bo tylko one pokazują, jak te decyzje wyglądają w praktyce. Ten wpis to 13+ lat doświadczenia z ponad 30 wdrożeń: 6-fazowy framework nadzoru, 5 wzorców systemowych, decyzja której żałuję jako Head of Delivery, tabela 8 przypadków z konkretnymi kwotami strat i 2-krokowa metoda do uruchomienia samodzielnie w 30 minut.

Skala ryzyka - ile faktycznie kosztuje wdrożenie dla sklepu 5-15 mln PLN obrotu

Tak więc po kolei: jaki rachunek faktycznie płaci firma e-commerce o obrocie 5-15 mln PLN rocznie za wdrożenie nowej platformy.

Doprecyzowanie na wstępie: "5-15 mln PLN" w tym wpisie zawsze odnosi się do rocznego obrotu sklepu, NIE do budżetu wdrożenia. Sam budżet wdrożenia dla sklepu tej skali to zwykle około 500 000 PLN. Dodatkowo 20-40 tysięcy PLN miesięcznie na utrzymanie po go-live. Te liczby pochodzą z mojej praktyki, nie z benchmarków rynkowych - Twoje wartości mogą się różnić, ale rząd wielkości jest stabilny.

Wycena projektu kontra TCO 12 miesięczny

Typowe wdrożenie powyżej MVP zamyka się w okolicach 500 000 PLN. Tę liczbę wszyscy widzą w ofercie. Tego co przychodzi po niej, już prawie nikt nie widzi przed podpisaniem umowy.

Utrzymanie po go-live to 20 000 - 40 000 PLN miesięcznie. Pomnóż przez 12 miesięcy i masz dodatkowe 240 000 - 480 000 PLN. Razem TCO 12-miesięczne to 740 000 - 980 000 PLN dla typowego sklepu w tym przedziale obrotu. To bez zespołu klienta po jego stronie biurka.

Pięć kategorii kosztów które generują te 20-40 tysięcy miesięcznie po go-live:

• Agencja - development bieżący, hotfixy
• Hosting - infrastruktura, CDN, monitoring, backupy
• Licencje - Magento Commerce, Shopify Plus, dodatki SaaS, licencja ERP
• Zmiany - rozszerzenia funkcjonalne, nowe integracje
• Utrzymanie i nieprzewidziane - aktualizacje bibliotek, łatki bezpieczeństwa, incydenty

Drugie zaskoczenie pojawia się około trzeciego miesiąca po go-live: rzeczy zaczynają przestawać działać tam, gdzie wczoraj jeszcze działały. Konieczne aktualizacje bibliotek zmieniają integracje, dostawcy SaaS modyfikują API, sposoby komunikacji między aplikacjami się przesuwają. Bez budżetu utrzymania to nie jest "naprawimy w tym tygodniu" tylko "wyłączymy część sklepu na 3 dni i będziemy szukać agencji która to weźmie".

Zespół klienta - osobny rachunek, nie w TCO

Wdrożenie nie obsługuje się samo spoza budżetu. Po stronie klienta potrzebne są role, które nie pojawiają się na fakturze agencji.

Najczęściej spotykane modele to 2 osoby po pół etatu dedykowane projektowi (model A) albo 4 osoby po 1/4 etatu rozbite na kompetencje (model B): e-commerce manager jako orkiestrator, content (PIM, CMS, opisy produktów), produkty (merchandising, kategorie, atrybuty), marketing i sprzedaż. Proporcje zmieniają się w obie strony.

Bywają też skrajne wersje: jeden silny operator z decyzyjnością, czasem cztery osoby z różnych działów po kawałku. Ale jeśli tych kompetencji nie ma w organizacji, projekt utknie po stronie klienta.

Trzy obszary gdzie pieniądze giną najszybciej

Z mojego doświadczenia trzy kwestie powtarzają się niezależnie od skali, branży i technologii:

• Brak Product Ownera po stronie klienta - jednej osoby która włada tym e-commerce, ma mandat decyzyjny i czas na projekt
• Ping-pong pomiędzy dostawcami - każdy pilnuje swojego ogródka, nikt nie pilnuje całokształtu pomiędzy sklepem, ERP, marketingiem i serwerami
• Życzeniowe wdrażanie funkcjonalności - dlatego że są ładne, brzmią fajnie, ale bez liczenia jak przełożą się na przychody

Te trzy obszary wyjaśniają większość przekroczeń budżetu które widzę. Nadzór wdrożenia e-commerce w wersji minimum to przede wszystkim ich pilnowanie.

6-fazowy framework nadzoru wdrożenia

Każda faza wdrożenia ma własne pułapki budżetowe i własne dźwignie nadzoru. Te 6 faz pokrywa całość cyklu od pre-kontraktu do stabilizacji po starcie. Każda jest pokazana na konkretnej historii którą widziałem w 13+ latach pracy, z kwotą strat i wnioskiem strukturalnym.

Faza 1: Pre-kontrakt - co naprawdę kupujesz

W trzech różnych projektach wdrożeniowych, w trzech różnych branżach, widziałem dokładnie ten sam mechanizm. Oferta opisuje "ścisłą współpracę", "elastyczne podejście do zakresu" i "kompleksowe wdrożenie pod klucz". Treści marketingowe zamiast definicji zakresu. Brakuje sekcji wykluczeń.

W trzecim miesiącu pojawia się faktura na "dodatkowe warsztaty analityczne" - 40 000 do 80 000 PLN. Klient pyta "ale czy to nie było w zakresie?" i dostaje odpowiedź "to analiza nowych wymagań". Pomnóż przez trzy duże zmiany i masz 120-240 tysięcy których nikt nie zaplanował.

Lekcja strukturalna: sześć pytań do każdej oferty zanim ją podpiszesz:

• Sekcja wykluczeń.
• Liczbowe parametry zakresu (ile produktów, ile kategorii, ile widoków).
• Definicja "gotowe" per funkcjonalność.
• Matryca odpowiedzialności kto co robi.
• Konsekwencje opóźnień po obu stronach.
• Wyceniona osobno analiza przedwdrożeniowa zamiast "doprecyzujemy w trakcie".

Pełną metodykę z porównaniem 2 realnych ofert opisałem osobno: 6 pytań do oferty - pełna analiza.

Druga pułapka to klauzule własności infrastruktury. Repozytorium kodu na koncie agencji, serwer u agencji, środowiska testowe u agencji. Dla klienta to wygląda przyjaźnie ("agencja to ogarnie"). Wygląda przyjaźnie do momentu zmiany dostawcy, kiedy 80 000 PLN awaryjnego transferu staje się jedyną drogą na wydostanie własnego sklepu. Pełną listę dostępów do zapisania w umowie znajdziesz tutaj: Zmiana agencji - checklista dostępów.

Faza 2: Kick-off - fundamenty projektu

Klient zatrudnia agencję. Po każdej stronie jedna osoba koordynacyjna. Po stronie agencji PM, po stronie klienta osoba operacyjna (czasem e-commerce manager, czasem dyrektor IT, czasem dyrektor sprzedaży, zależy od organizacji). Projekt zamyka się za PM-em agencji jak za szybą. Product Owner klienta jest formalnie sponsorem, a w praktyce widzi statusy raz w miesiącu.

Komunikacja jest jednowarstwowa. Koordynator agencji rozmawia z koordynatorem klienta. Zespół programistów agencji nie ma bezpośredniego dostępu do osoby która zna biznes klienta. Pytania techniczne idą w górę przez PM-a klienta, w drugą stronę propozycje agencji idą przez PM agencji. Każda warstwa coś filtruje, czegoś nie rozumie, coś interpretuje po swojemu.

Po 4-5 miesiącach pracy budżet pierwotny jest spalony, a projekt nie jest blisko zakończenia. Zakres spuchł przez funkcjonalności które nigdy nie powinny powstać i przez funkcjonalności które są niedoprecyzowane. Klient i agencja zaczynają rozmowę "skąd weźmiemy pieniądze żeby to dowieźć". W jednym z projektów, które widziałem, ta rozmowa kończyła się 120 000 PLN dodatkowych poprawek (15% pierwotnego budżetu) - bo Product Owner po stronie klienta był nominalnie obecny ale "miał 10 innych tematów i kieruje sprzedażą".

Faza 2 fundamentu wdrożenia to nie spotkanie kick-off na 90 minut z prezentacją PowerPoint. To ustanowienie bezpośredniego kanału zespół agencji - Product Owner klienta. Bez tego cały projekt jedzie na grubo filtrowanej informacji.

Faza 3: Sprint 1-3 - rejestr zmian, którego nie ma

Ten sam projekt co Faza 2, kilka miesięcy później. Product Owner klienta dalej jest odseparowany. PM agencji robi mikro-decyzje na bazie ustaleń z PM-em klienta. Wydaje się że to są decyzje "których potrzebuje programista" - granularne wybory implementacyjne, wybór biblioteki, decyzja jak interpretować wymogi z briefu. Wydaje się też, że są niewielkie.

W praktyce mikro-decyzje były błędne. Dlatego że nie miał kontaktu z osobą która zna biznes. Co gorsza, zmiany nie były odnotowywane. Brak rejestru zmian, brak różnicowania: jak miało być, a jak jest, dlaczego i kiedy zostało zmienione. Wiedza została bezpowrotnie utracona.

Z punktu widzenia klienta wygląda to tak: "agencja ciągnie od nas kasę na niekończące się prace". Z punktu widzenia agencji wygląda to tak: "klient nie wiedział czego chce, nie było wiadomo co jest do zrobienia i jaki ma być efekt końcowy". Obie strony mają rację w swojej narracji. Obie się frustują, chcąc wykonywać swoją pracę dobrze.

To wzorzec systemowy: brak rejestru zmian z danymi (kto, kiedy, dlaczego, jakie założenie zostało zaktualizowane) plus brak drugiego kanału komunikacyjnego. Razem dają projekt, który jedzie na ślepo, a obie strony myślą, że to druga strona zawiniła.

Faza 4: Środek projektu - drugi kanał komunikacji

Ten sam projekt, jeszcze kilka miesięcy później. Decyzja po obu stronach: trzeba to naprawić, bo dłużej tak się nie da.

Trzy rzeczy się zmieniły. Po pierwsze, klient został wpuszczony do systemu zadań agencji. Nie jako obserwator - jako uczestnik, z możliwością komentowania zadań i odpowiadania na pytania. Po drugie, ustanowiono cotygodniowe spotkanie zespołu agencji z Product Ownerem po stronie klienta, czasem z udziałem CTO klienta, czasem z udziałem programistów agencji. Po trzecie, w komentarzach do zadań pojawił się ślad rozmów technicznych pomiędzy zespołami.

Efekt: było wiadomo co, jak i po co ma być zrobione. Wyniki rozmów technicznych przenoszone były do zadań. Mikro-decyzje przestały być przepustką do rozrostu zakresu, bo każda miała kontekst i akceptanta.

Najważniejsza obserwacja z tej historii: tego nie było wcale dużo. Jedno spotkanie tygodniowo. Jedna osoba decyzyjna od klienta dostępna na 60-90 minut. Niski koszt operacyjny, wysoki zwrot. Brakowało struktury, która ustanawia drugi kanał komunikacyjny obok PM-PM. Ten sam wzorzec opisuje zresztą jedna z zasad Manifestu Agile: biznes i deweloperzy muszą pracować razem codziennie przez cały projekt. W polskich wdrożeniach e-commerce nadal traktuje się to jako "opcjonalną dobrą praktykę".

W innym projekcie, który widziałem, brak tego drugiego kanału kosztował 250 000 PLN za przekroczenie budżetu (2 razy ponad plan). Dialog "Mogę pogadać z zespołem?" "Ja wszystko przekażę" jest klasyką - PM jako jedyny filtr informacji pomiędzy klientem a zespołem to gwarancja, że asymetria informacji zacznie kosztować przy każdej decyzji.

Faza 5: UAT - definicja "gotowe" musi obejmować odbiorcę danych

Wdrożenie e-commerce z integracją z ERP. Pomiędzy sklepem a ERP klienta była szyna danych agencji - middleware który zbiera zamówienia, dokumenty księgowe, statusy z e-commerce i wysyła do ERP. Wymagania były spisane: dane mają wchodzić do szyny w określonych formatach, z określoną częstotliwością, w pełnym komplecie.

UAT pokazał że wszystko działa. Sklep wypychał dane do szyny prawidłowo. Kryteria akceptacji spełnione, zadania zamknięte, faktura wystawiona. Definicja "gotowe" została spełniona po stronie producenta danych - sklepu.

Problem ujawnił się dopiero na produkcji. Aplikacja klienta po drugiej stronie szyny (ERP) nie mogła pobierać części danych bez modyfikacji. Format był poprawny technicznie, ale logika biznesowa po stronie ERP wymagała innej struktury klucza, innej kolejności pól, innego mapowania statusów. Dostosowanie kosztowało zarówno czas, jak i pieniądze, których nikt nie przewidział.

Mechanizm: klątwa wiedzy. Tylko agencja wiedziała jak te dane funkcjonują, w jakich są formatach, jaka logika za tym stoi. Klient zakładał że "wysyłamy dane to ERP je przeczyta". ERP nie miał wglądu w to co dokładnie pojawi się w szynie. Definicja "gotowe" obejmowała producenta, ale nie obejmowała konsumenta.

Strukturalna lekcja: w UAT projekcie integracyjnego "gotowe" musi obejmować odbiorcę danych, nie tylko ich nadawcę. Bez tego udany UAT równa się produkcyjnej porażce. Pokrewny problem to brak matrycy odpowiedzialności w dokumentacji "pod klucz" - dialog "Czekamy na mapowanie procesów u Was" / "Przecież to Wasza robota?" kosztował 80 000 PLN nadwyżki i 4 miesiące opóźnienia w jednym z projektów B2B z integracją ERP który widziałem.

Faza 6: Post go-live - stabilizacja i koszt rzeczywistości

Sklep odzieżowy, świeżo po go-live, jeszcze w fazie stabilizacji. Kampania z influencerami została zaplanowana na drugi tydzień po starcie. Hosting współdzielony, taki sam jaki sklep miał przed migracją. Brak testów obciążeniowych w zakresie wdrożenia, brak planowania infrastruktury pod ruch szczytowy. Nikt po stronie agencji nie pytał o ruch podczas kampanii, nikt po stronie klienta nie sygnalizował influencer marketingu na etapie wymagań.

Influencerka wrzuciła link do sklepu. 100 000 wejść w ciągu pierwszej godziny. Serwer współdzielony "klęknął" po 3 minutach. Sklep był niedostępny przez kilka krytycznych godzin szczytu, dokładnie wtedy kiedy płynął ruch z kampanii.

Rachunek:

• Kampania influencer, w całości spalona: 50 000 PLN
• Utracona sprzedaż (szacunek za czas niedostępności): 80 000 PLN
• Łączna strata: 130 000 PLN

To nie była wina agencji, bo nie wiedziała o kampanii. To nie była wina klienta, bo nie wiedział, że hosting współdzielony nie obsłuży 100 tysięcy wejść w godzinę. To wzorzec systemowy: brak komunikacji 2-warstwowej z Fazy 2 replikuje się w Fazie 6. Nikt nie zapytał, nikt nie odpowiedział, infrastruktura nie była przedmiotem planowania marketingowego, marketing nie był przedmiotem planowania infrastrukturalnego.

Strukturalna lekcja: testy obciążeniowe i skalowalna infrastruktura muszą być w wymaganiach, jeśli planowane są kampanie z dużym ruchem. DevOps lub Admin zaangażowany w fazę planowania infrastruktury, nie tylko w fazę uruchamiania serwera. Kalendarz marketingowy klienta na 6 miesięcy po golive powinien być częścią dokumentacji projektu.

Pokrewna sytuacja to pompowanie kampanii za 25 000 PLN na niestabilny sklep w dniu go-live. 68% porzuconych koszyków przy 3 200 sesjach, bo płatności pokazywały błąd zanim klient zdążył potwierdzić transakcję. Dialog "Potrzebujemy 2 tygodnie na stabilizację" / "Mamy sezon, nie możemy czekać" jest stałym elementem mojej pracy. Kalendarz biznesu nie ma litości dla decyzji infrastrukturalnych, ale infrastruktura nie ma litości dla kalendarza biznesu.

5 wzorców systemowych

Każdy projekt wdrożeniowy ma swoje unikalne wyzwania. Ale widzę 5 wzorców systemowych które powtarzają się niezależnie od skali budżetu, branży i technologii. Nazywam je systemowymi, bo nie pochodzą od konkretnej agencji ani konkretnego klienta - są efektem struktury rynku.

Wzorzec 1: Komunikacja kuleje

Manifestacje tego wzorca są stałe niezależnie od projektu: założenia nie były spisywane, notatki nie były robione, ustalenia zapadały w dziwnych miejscach (czat zamiast ticket, decyzje na korytarzu zamiast w meeting recap). W jednym z projektów, które widziałem skutkowało to wprowadzeniem PM-a za 20 000 PLN/mc, który po 6 miesiącach złożył wypowiedzenie - 120 000 PLN spalone, bo fundamentów projektu nie da się zbudować po fakcie tylko przez wprowadzenie topowego zawodnika do chaosu.

Wzorzec 2: "Wy się znacie, jesteście ekspertami, macie to ogarnąć"

Klient deleguje 100% decyzji do agencji bez angażowania się merytorycznie. Wygląda elegancko ("zaufajmy specjalistom") i jest najszybszą drogą do projektu, który dowozi nie to, czego biznes potrzebuje. Klasyczna manifestacja w dialogu rozpoznawczym: "Kto jest właścicielem tego projektu?" / "Andrzej, ale ma jeszcze 10 innych tematów i kieruje sprzedażą w firmie". Agencja buduje "coś", ale nie wie dokładnie "co". 120 000 PLN poprawek, 6 miesięcy opóźnienia, problem w braku Product Ownera z realną decyzyjnością.

Wzorzec 3: Ego - skala konsekwencji rośnie z decyzyjnością

Skala szkód rośnie wraz z istotnością osoby z wybujałym ego. Na poziomie Programisty lub osoby zarządzającej bazą produktową - lokalny problem, łatwo go zlokalizować i naprawić. Na poziomie TechLeada, PMa, Product Ownera, e-Commerce Managera zaczynają się poważne reperkusje wynikające z wpływu który ta osoba ma na wszystkich. Decyzje całych zespołów muszą być podejmowane na bazie informacji od osoby grającej ego, co jest miną fundamentu pod każdy następny sprint.

Wzorzec 4: Klątwa wiedzy plus asymetria doświadczenia

Platforma e-commerce wdrożona dobrze żyje co najmniej 3 lata, częściej zmierza w kierunku 6. Wychodzi, że zespoły klientów przeprowadzą 3-5 takich projektów w ciągu 15 lat. Agencja w tym samym czasie ma dziesiątki wdrożeń. Widzi wzorce. Widzi powtarzające się błędy. Ale przy każdym konkretnym projekcie ma swoją klątwę wiedzy: widzi i doświadcza, ale będąc tu i teraz, trudno jej się oddzielić i wskazać to z perspektywy.

Klient z kolei nie ma pojemności żeby to zobaczyć z własnej pozycji. Walczy ze sprzedażą, walczy o marketing, walczy o przychody. Walka toczy się w innych miejscach, projekt wdrożeniowy nie jest dla niego głównym frontem.

W jednym z projektów opisanych wcześniej, brak tego spojrzenia kosztował 250 000 PLN ponad plan (z budżetu wyjściowego 250 000 PLN do końcowych 500 000 PLN). PM agencji był jedynym łącznikiem między klientem a zespołem. Klient widział środowisko testowe, raporty godzin, statusy raz w tygodniu. Pomiędzy "co klient powiedział" a "co zespół usłyszał" rosła przepaść.

Wzorzec 5: Brak przestrzeni do szczerej rozmowy

Podejście oparte na konfrontacji buduje się w obie strony jednocześnie. Agencja patrzy na klienta i myśli: "OK, wy nam nie będziecie chcieli zapłacić, więc musimy tutaj tak kombinować żeby zrobić jakąś robotę, ale jednocześnie żebyście nie podważali faktur". Klient patrzy na agencję i myśli: "Dobra, ale to wy pewnie chcecie żebyśmy jak najwięcej wam zapłacili, więc robicie wszystko żeby tylko jak najwięcej godzin przepracować".

Obie strony mają częściowo rację. Ich interesy są strukturalnie inne, bo siedzą po dwóch stronach faktury. Ale brak przestrzeni do szczerej rozmowy o tych asymetriach gwarantuje transakcyjne podejście zamiast wspólnego celu. Wzorzec systemowy, nie zła wola żadnej strony.

Klasyczna manifestacja: dwie strony tej samej rozmowy o uruchomieniu sklepu. Agencja mówi "potrzebujemy 2 tygodnie na stabilizację". Klient mówi "mamy sezon, nie możemy czekać". Pisałem o tym wcześniej - skutkowało to spaloną kampanią za 25 000 PLN i 68% porzuconych koszyków w pierwszym tygodniu działania sklepu. Każda strona pilnowała swojego interesu, nikt nie pilnował wspólnego wyniku.

Co Michał widzi w przekazach agencji - 5 sygnałów

Michał nie czyta kodu ani ticketów. Czyta przekazy agencji. Te 5 sygnałów które rozpoznaję u klientów których audytuję, mówią więcej o stanie projektu niż formalne raporty status. Czerwone oznaczają, że projekt już ma problem operacyjny. Żółte to sygnał wczesnego ostrzegania.

Idealny format raportu wygląda inaczej. Co znaczy "inaczej"?

Jeśli widzisz 1 UWAGA i 1 ALARM jednocześnie, czas na Audyt Współpracy. Jeśli widzisz 2 ALARMy, już płacisz cenę, tylko jeszcze nie wiesz ile.

Decyzja której żałuję jako Head of Delivery

Nadzór wdrożenia e-commerce jako konsultant zewnętrzny ma jedną przewagę nad wewnętrznym PM-em: perspektywę zbudowaną na latach pracy i ponad dziesiątkach projektów. Ta perspektywa była przeze mnie marnowana przez znaczną część kariery.

Cykliczność wyglądała tak: raz na kwartał spotkanie strategiczne, raz w miesiącu rutynowe sprawdzenie projektu, częściej tylko gdy pojawiał się problem. Czyli reaktywnie. Brakowało rozmów proaktywnych w trybie "jest OK i stabilnie".

Cztery rzeczy które by się dzięki temu zmieniły:

• Lepsze dostosowanie naszej pracy do tego czego klient potrzebuje (a nie tego co mówi że potrzebuje). Te dwa zbiory rzadko są identyczne.
• Klient mógłby planować z większym wyprzedzeniem - inaczej poukładać klocki w swoich roadmapach biznesowych, jeśli wiedziałby z wyprzedzeniem co u nas powstaje i kiedy.
• Klient mógłby dowozić rzeczy wewnętrznie z większą przewidywalnością, bo rozmawialibyśmy strategicznie o jego planach.
• Mniej wzajemnych blokerów - klient nie czeka na nas bezczynnie, może zająć się czymś innym.

Nadzór Projektu retainer 4 900 PLN/mc jest operacyjną konsekwencją tej lekcji. Cotygodniowy kanał komunikacyjny w trybie "jest OK", nie kwartalny w trybie "jest dramat". Most pomiędzy obozami, którego brakowało, kiedy siedziałem po drugiej stronie biurka.

Partnership Over War - jeden klient, jedna toksyczna osoba, 1.5 roku

Partnership Over War jest centralną wartością mojej praktyki. Nie dlatego że agencje są zawsze święte, a klienci niewinni. Dlatego że konflikty operacyjne mają prawie zawsze przyczyny strukturalne, a mediacja na czas oszczędza setki tysięcy złotych po obu stronach.

Najlepszy znany mi case na to, czego mediacja nie naprawiła.

Wniosek strukturalny. Strukturalne źródło konfliktu siedziało w obu obozach - brakowało ścieżki eskalacji. Agencja nie miała formalnego prawa powiedzieć klientowi "twój sponsor techniczny niszczy projekt, potrzebujemy aby ktoś inny odpowiadał za kontakt". Klient nie wiedział, że jego konsultant zewnętrzny zjada zespół po stronie dostawcy. Każdy widział kawałek, nikt nie widział całości.

Konsultant nadzoru w takiej sytuacji ma jedną przewagę: jest poza operacyjną linią konfliktu. Może zaproponować mediację na poziomie sponsorów po obu stronach, przeniesienie kontaktu na innego decydenta po stronie klienta, formalizację zasad współpracy w aneksie do umowy. Trzy realne opcje. Żadnej nikt nie uruchomił, bo nikt nie patrzył z perspektywy mostu między obozami.

Dlatego w nadzorze retainer mam szerszą definicję sukcesu niż "projekt dowieziony w budżecie". Sukces to także moment, w którym obie strony kończą kontrakt z chęcią na kolejny. W tym przypadku obie straciły coś, czego nie musiały tracić: klient stracił zespół, który znał system od lat; agencja straciła stabilnego klienta na lata.

Liczby z biblioteki przypadków - tabela 8 przypadków

Każda z tych 8 historii to konkretna kwota straty, konkretna faza nadzoru gdzie ginie oraz konkretna diagnoza systemowa. Wszystkie z mojej praktyki i 13+ lat doświadczenia. Nazwy klientów i agencji są anonimizowane. Przykłady są realne.

Suma strat z tych 8 historii to ponad 1 100 000 PLN. Każda strata jest do uniknięcia strukturalnie. Każda kosztowała więcej niż 12 miesięcy Nadzoru Projektu (58 800 PLN). Matematyka jest dość prosta.

Kiedy potrzebujesz konsultanta nadzoru, a kiedy wystarczy zespół wewnętrzny

Nie każdy projekt wymaga zewnętrznego konsultanta do nadzoru wdrożenia e-commerce. Project Management Institute traktuje nadzór projektu jako formalną dyscyplinę z certyfikatami i frameworkami. Z mojego doświadczenia praktycznego: 5 sygnałów wystarczy do trafnej decyzji w 5 minut, bez certyfikatu.

Sygnał A: masz Product Ownera 100% dedykowanego projektowi

Wewnętrznie OK. Może wystarczyć Audyt Współpracy raz na kwartał jako kontrolny check. Sygnał: Product Owner ma mandat decyzyjny, zero innych odpowiedzialności w tym samym czasie, wie czego chce biznes i komu to dowieźć.

Sygnał B: Product Owner ma 10 innych tematów

Konsultant nadzoru taniej niż 120 000 PLN poprawek (case #1 z tabeli powyżej). 4 900 PLN/mc × 12 miesięcy to 58 800 PLN. Ryzyko? Pomnożone razy 2-3 w realnej skali.

Sygnał C: PM agencji jest jedynym źródłem informacji o projekcie

Konsultant krytyczny. Zasada drugiego kanału - case #2 z tabeli, 250 000 PLN ponad plan bez drugiego kanału klient-zespół. Im dłużej tak jedziesz, tym większy rachunek.

Sygnał D: 3 lub więcej dostawców (sklep + ERP + middleware + content + performance marketing)

Konsultant jako orkiestrator pomiędzy dostawcami. Tu mam świeże spostrzeżenie: w dobie LLM-ów raczej będziemy częściej korzystać z freelancerów o różnym typie specjalizacji niż z dużych zespołów lub etatowych zespołów wewnętrznych.

Performance marketing freelancer, PIM consultant, content marketing freelancer. Każdy z nich pracuje zupełnie inaczej. Koordynacja staje się jeszcze ważniejsza niż 5 lat temu.

Sygnał E: zmiana agencji w trakcie wdrożenia

Konsultant prowadzi weryfikację stanu i przejście do nowego dostawcy. Przypadek #3 z tabeli, 80 000 PLN awaryjnego transferu, bo dostępy do infrastruktury nie były klienta. Pełna checklista dostępów infrastruktury →

FAQ

Następny krok - co możesz zrobić sam w 30 minut

Te 2 kroki nie wymagają konsultanta. Wymagają 30 minut z raportami agencji i Twoim kalendarzem. Wynik powie Ci czy potrzebujesz nadzoru, czy radzisz sobie sam.

Krok 1: Wylicz koszt per typ roli z ostatnich 5 miesięcy

Weź raporty agencji z ostatnich 5 miesięcy. Wylicz koszt wdrożenia poszczególnych zadań z podziałem na typ roli zaangażowanych:

• Programista
• Tester
• PM
• Grafik
• DevOps
• Tech lead
• Konsultant

Zsumuj koszt per rola jako procent całości. Odpowiedz sobie: czy wydanie 40% budżetu na PM-a przy 25% na programistów ma sens? Czy 5% DevOps przy migracji infrastruktury wystarczy? Czy zero godzin grafika oznacza, że programiści naprawiali UI w kodzie zamiast w oparciu o mockupy?

Anomalie w procentowym mixie ról widać szybciej niż w samych stawkach. Rola, która zjada ponad 30% budżetu bez przejrzystego uzasadnienia, jest sygnałem do rozmowy z agencją.

Krok 2: Policz czas swojego zespołu

To strona, którą rzadko ktoś liczy. Cztery kategorie do dodania:

• Realizacja tasków po stronie klienta (Właściciel, e-commerce manager, content, IT)
• Rozmowy z agencją (statusy, demo, decyzje, eskalacje)
• Wypracowywanie założeń przed sprintami i doprecyzowanie w trakcie
• Obsługa założeń (testy, akceptacja, potwierdzanie wydań)

Pomnóż przez przeciętne stawki tych ludzi w Twojej organizacji. Dodaj do kosztu z Kroku 1. To jest faktyczny rachunek za wdrożenie.

Co jeśli nie możesz tego policzyć

Brak danych równa się brak diagnozy. Zasada "najpierw diagnoza" jest pierwszą lekcją zarówno analityki e-commerce, jak i nadzoru wdrożenia. Jeśli nie wiesz - to wiesz, że musisz zacząć od zmierzenia.