Za kulisami wdrożeń Zarządzanie projektem

Kto naprawdę odpowiada za sukces wdrożenia

Spotkanie otwierające projekt. Prezes wygłasza dwie minuty o tym, jak ważne jest wdrożenie, po czym mówi zdanie, które przesądza o wszystkim: „Panie Jakubie, zostawiam to w pana rękach, wy jesteście specjalistami”. Wstaje i wychodzi. Zostaje sala pełna ludzi, którzy właśnie usłyszeli, że to nie jest ich projekt. I dostawca, który za chwilę zostanie obarczony odpowiedzialnością za coś, czego nie kontroluje.

Jakub Tuszyński Architekt systemów MES / WMS • 11 lat w branży

12 lipca 2026 · 14 min czytania

To zdanie — „zostawiam to w pana rękach” — brzmi jak wyraz zaufania. W rzeczywistości jest to najczęstszy pierwszy krok do porażki wdrożenia. Bo w tym jednym zdaniu prezes robi rzecz, która wydaje się rozsądna, a jest zabójcza: przekazuje odpowiedzialność za zmianę sposobu pracy własnej organizacji komuś, kto tej organizacji nie prowadzi.

Dostawca może dostarczyć działające narzędzie. Może przeszkolić ludzi, skonfigurować procesy, uruchomić system. Nie może jednej rzeczy: sprawić, żeby ludzie w firmie zaczęli pracować inaczej. Bo zmiana nawyków, priorytetów i decyzji wewnątrz organizacji to coś, co można wymusić tylko od środka, z pozycji władzy. A tę władzę właśnie wyniesiono z sali.

Sedno sprawy: wdrożenie systemu nie jest projektem informatycznym. Jest projektem zmiany sposobu, w jaki firma pracuje. Narzędzie da się kupić. Zmiany sposobu pracy nie da się kupić — trzeba ją przeprowadzić, a przeprowadzić ją może tylko ktoś z wnętrza organizacji, kto ma władzę i naprawdę tego chce.

W tym artykule odpowiemy na pytanie, które pada rzadko, a rozstrzyga o wszystkim: kto naprawdę odpowiada za to, czy wdrożenie się uda. Podpowiedź: nie ten, kogo o to zwykle obwiniamy, gdy się nie udaje.

Mit, w który wygodnie wierzyć: „to robi dostawca”

Najwygodniejszym przekonaniem w całym projekcie jest to, że skoro płacimy dostawcy, to dostawca odpowiada za sukces. To przekonanie jest fałszywe, a jego atrakcyjność bierze się z tego, że zdejmuje odpowiedzialność z firmy i przenosi ją na zewnątrz.

Warto rozdzielić dwie rzeczy, które w tym micie są sklejone w jedno: co dostawca może dostarczyć i za co dostawca może odpowiadać.

Za co odpowiada dostawca

Działające, poprawnie skonfigurowane narzędzie
Odwzorowanie uzgodnionych procesów w systemie
Szkolenie i wsparcie techniczne
Integracje i migrację danych zgodnie z ustaleniami
Doradztwo — pokazanie, jak robią to inni

Za co dostawca odpowiadać NIE MOŻE

Czy ludzie zaczną używać systemu tak, jak trzeba
Czy zarząd wymusi porzucenie starych nawyków
Czy kluczowe osoby dostaną czas na projekt
Czy spory kompetencyjne zostaną rozstrzygnięte
Czy firma naprawdę chce się zmienić

Lewa kolumna to narzędzie i wiedza. Prawa to zmiana organizacyjna. Dostawca ma pełną kontrolę nad lewą i zerową nad prawą. A o sukcesie wdrożenia decyduje niemal wyłącznie prawa kolumna. Można dostać idealny system i całkowicie ponieść porażkę — o tym rozdźwięku pisałem szerzej w Sukces techniczny, porażka biznesowa.

Dostawca odpowiada za to, żeby system dał się używać. Firma odpowiada za to, żeby był używany. To dwie różne odpowiedzialności i tylko jedną da się kupić.

Ten sam projekt oczami pięciu osób

Żeby zobaczyć, gdzie odpowiedzialność się rozmywa, warto usłyszeć, jak każdy uczestnik projektu rozumie swoją rolę. Uderzające jest to, że prawie każdy widzi siebie jako uczestnika, a nie właściciela — i w tej luce ginie sukces.

Prezes / sponsor: „Zdecydowałem, podpisałem, dałem budżet. Moja rola się skończyła — teraz niech to działa. Nie mam czasu chodzić na spotkania projektowe, od tego są ludzie.” To najgroźniejsze nastawienie, bo to właśnie sponsor jest jedyną osobą, która nie może się wycofać.

Kierownik projektu: „Prowadzę projekt, pilnuję terminów, koordynuję. Ale kiedy dwa działy się kłócą, kto ma rację, nie mam władzy, żeby rozstrzygnąć. Mogę tylko eskalować do sponsora — a sponsor jest nieosiągalny. Więc spór wisi tygodniami.”

Dostawca: „Dostarczam narzędzie i doradzam. Widzę, że firma nie jest gotowa organizacyjnie, ale nie mam mandatu, żeby zmuszać zarząd do zaangażowania. Mówię o tym — i słyszę, że mam się skupić na systemie. Więc robię system, choć wiem, że to nie wystarczy.”

Kierownik działu: „Mam swoje cele operacyjne i do tego dorzucono mi projekt bez odjęcia obowiązków. Wybieram to, z czego jestem rozliczany na co dzień, a projekt idzie na drugi plan. Nie dlatego, że go nie doceniam — dlatego, że doba ma 24 godziny.”

Użytkownik końcowy: „Nikt mnie nie pytał, nikt nie tłumaczył, po co to. Dostałem nowy program i polecenie, żeby go używać. Skoro to nie mój pomysł i nie moja odpowiedzialność, to będę pracował po staremu, aż mnie ktoś zmusi. A na razie nikt nie zmusza.”

Zauważ: w tej piątce nikt nie mówi „to mój projekt i biorę za niego odpowiedzialność”. Sponsor się wycofał, kierownik projektu nie ma władzy, dostawca nie ma mandatu, kierownik działu nie ma czasu, użytkownik nie ma poczucia sprawczości. Projekt jest niczyj — a projekt niczyj zawsze przegrywa z codziennością. Ten sam mechanizm oporu użytkownika rozłożyłem w Dlaczego operator produkcji nie ufa nowemu systemowi.

Sponsor — jedyna rola, której nie da się delegować

W każdym udanym wdrożeniu, jakie widziałem, była jedna wspólna cecha: istniała konkretna osoba z władzą, która osobiście chciała, żeby zmiana się wydarzyła, i traktowała ją jak swoją. To sponsor. I to jego obecność lub nieobecność najlepiej przewiduje wynik projektu — lepiej niż budżet, lepiej niż wybór systemu, lepiej niż jakość dostawcy.

Warto rozdzielić dwie role, które w firmach notorycznie się myli.

Aspekt	Sponsor projektu	Kierownik projektu
Główne zadanie	Chcieć zmiany i brać za nią odpowiedzialność	Koordynować zadania i terminy
Władza	Wysoka — może rozstrzygać spory i przydzielać zasoby	Ograniczona — działa z mandatu sponsora
Zaangażowanie w czasie	Niskie ilościowo, wysokie jakościowo — kluczowe decyzje	Wysokie — codzienna praca operacyjna
Sygnał dla organizacji	„To jest ważne dla zarządu”	„Ktoś tego pilnuje na co dzień”
Co się dzieje bez tej roli	Projekt staje się niczyj i przegrywa z codziennością	Chaos operacyjny, ale projekt może przetrwać

Kierownika projektu da się zatrudnić albo wyznaczyć. Sponsora nie da się mianować na siłę — sponsorem trzeba chcieć być. Kiedy zarząd wyznacza sponsora, który nie wierzy w projekt albo nie ma na niego czasu, dostaje sponsora na papierze. A sponsor na papierze to gorzej niż brak sponsora, bo organizacja szybko wyczuwa, że mandat jest pusty.

Test prawdziwego sponsora: zapytaj, czy jest gotów osobiście przyjść na spotkanie, spojrzeć zespołowi w oczy i powiedzieć „to jest priorytet, a spory rozstrzygam ja”. Jeśli tak — projekt ma fundament. Jeśli deleguje nawet to zdanie — projekt nie ma sponsora, ma tylko nazwisko w dokumencie.

Dlaczego firmy tak chętnie zrzucają odpowiedzialność

Zrzucanie odpowiedzialności na dostawcę albo na IT nie wynika ze złej woli. Wynika z bardzo ludzkich i zrozumiałych mechanizmów, które warto nazwać, bo dopóki działają w ukryciu, będą sabotować każdy projekt.

„Zapłaciliśmy, więc niech zrobią”: logika transakcyjna. Skoro wystawiono fakturę, to po drugiej stronie jest pełna odpowiedzialność. Działa przy kupnie maszyny — maszyna nie wymaga, żebyśmy zmienili sposób pracy. Nie działa przy systemie, który tego wymaga.

Ucieczka od trudnej pracy: zmiana nawyków organizacji jest ciężka, konfliktowa i niewdzięczna. Uruchomienie systemu technicznego jest konkretne i policzalne. Firmy podświadomie wybierają łatwiejszą część i nazywają ją całością projektu.

„To sprawa techniczna, więc dla IT”: ponieważ system działa na komputerach, wygląda na projekt informatyczny. To błąd kategorii. Serwer nie zmieni tego, jak magazynier rejestruje wydanie — to robią ludzie i procesy, za które IT nie odpowiada.

Strach przed przyznaniem, że problem jest w nas: wzięcie odpowiedzialności oznacza uznanie, że to nasze procesy i nasze nawyki trzeba zmienić. Łatwiej powiedzieć „system nie zadziałał” niż „nie zmieniliśmy sposobu, w jaki pracujemy”.

Wszystkie cztery mechanizmy prowadzą do tego samego: odpowiedzialność wędruje na zewnątrz albo w bok, byle nie zostać tam, gdzie powinna — u sponsora i w organizacji. A projekt bez właściciela wewnątrz firmy jest jak łódź bez steru: płynie tam, gdzie zniesie ją prąd codziennych spraw.

Co się dzieje, gdy odpowiedzialność jest niczyja

70%

porażek wdrożeń ma źródło w organizacji, nie w technologii

tygodnie

tyle wiszą nierozstrzygnięte spory, gdy sponsor jest nieobecny

2×

dłużej trwa projekt bez zaangażowanego sponsora

zaangażowany sponsor — najsilniejszy pojedynczy predyktor sukcesu

Bez właściciela projekt nie umiera nagle. Umiera powoli, przez zaniedbanie. Decyzje nie zapadają, bo nikt nie ma mandatu. Spory wiszą, bo nie ma kto rozstrzygać. Kluczowe osoby wybierają codzienne obowiązki, bo nikt nie chroni ich czasu na projekt. Użytkownicy wracają do starych nawyków, bo nikt nie egzekwuje nowych. Po roku system stoi uruchomiony, ale nieużywany tak, jak trzeba, a firma mówi: „wdrożenie się nie udało”. I szuka winnego — zwykle dostawcy, który jako jedyny nie mógł tego uratować.

Gorzka prawda: większość „nieudanych wdrożeń” to udane dostawy narzędzia, którego organizacja nie wzięła na własność. System działał. Nie działała zmiana, którą tylko firma mogła przeprowadzić — i której nie przeprowadziła, bo nikt nie wziął za nią odpowiedzialności.

Jak ustawić odpowiedzialność, żeby projekt się udał

Krok 1: Wskaż prawdziwego sponsora — i sprawdź, czy chce nim być

Sponsor to osoba z władzą i budżetem, która osobiście chce zmiany. Nie mianuj kogoś, kto „ma czas”. Mianuj kogoś, komu naprawdę zależy i kto jest gotów wziąć projekt na własność wobec całej organizacji.

Krok 2: Rozdziel role sponsora i kierownika projektu

Sponsor daje mandat i rozstrzyga spory. Kierownik prowadzi codzienną pracę. To dwie różne osoby o różnych kompetencjach — łączenie ich w jedną najczęściej oznacza, że żadna z ról nie jest pełniona dobrze.

Krok 3: Przydziel realny czas kluczowym osobom

Jeśli ktoś ma pracować przy projekcie, odejmij mu część codziennych obowiązków. Projekt dorzucony do pełnego etatu zawsze przegra z zadaniami, z których człowiek jest rozliczany na bieżąco. Czas to najtwardszy dowód, że zarządowi zależy.

Krok 4: Włącz użytkowników na etapie analizy

Ludzie bronią tego, co współtworzyli, i odrzucają to, co im narzucono. Zaproś operatorów i magazynierów do rozmowy o procesie, zanim cokolwiek zostanie zbudowane. Współautorstwo zamienia opór w zaangażowanie taniej niż jakiekolwiek szkolenie.

Krok 5: Ustal jasne zasady rozstrzygania sporów

Konflikty kompetencyjne są nieuniknione. Ustal z góry, kto i w jakim czasie je rozstrzyga — zwykle sponsor. Spór, który wisi tygodniami, zabija tempo i morale projektu skuteczniej niż jakikolwiek problem techniczny.

Zwróć uwagę, że żaden z tych kroków nie dotyczy technologii. Wszystkie dotyczą ludzi, władzy i czasu. Bo tam, a nie w systemie, rozstrzyga się sukces. Dobrze zaprojektowany proces przygotowania organizacji do zmiany opisałem też w Jak przygotować firmę do automatyzacji.

Sygnały ostrzegawcze, które widać już na starcie

O tym, czy projekt ma szansę się udać, dużo mówią pierwsze tygodnie — zanim jeszcze cokolwiek zostanie zbudowane. Są zdania i zachowania, które słyszę na spotkaniu otwierającym i które z dużym prawdopodobieństwem przepowiadają wynik. Warto je znać, bo wychwycone na czas dają się jeszcze naprawić.

„Zostawiam to w waszych rękach”: sponsor właśnie zszedł z pokładu. Jeśli w pierwszym zdaniu deleguje odpowiedzialność na dostawcę albo na kierownika projektu, projekt startuje bez właściciela. To najsilniejszy pojedynczy sygnał ostrzegawczy ze wszystkich.

„Ludzie zrobią to po godzinach”: nikt nie dostał odjętych obowiązków. Projekt jest traktowany jako dodatek do pełnych etatów, co oznacza, że przegra z codziennością w pierwszym tygodniu, w którym pojawi się jakikolwiek pilny problem operacyjny.

„To projekt IT, oni się tym zajmą”: błąd kategorii już na wejściu. Projekt biznesowy został przypisany działowi, który odpowiada za technologię, a nie za procesy i ludzi. Działy operacyjne czują się zwolnione z odpowiedzialności, choć to one decydują o sukcesie.

„Nie zawracajmy głowy operatorom, i tak zrobią, co im każą”: użytkownicy zostali wykluczeni z analizy. To gwarancja, że rozwiązanie powstanie bez ich wiedzy o realnej pracy, a oni odrzucą je jako narzucone. Opór jest w tym momencie już zaprogramowany.

Cisza zarządu po spotkaniu otwierającym: jeśli po starcie sponsor znika z radaru i nie pojawia się przy pierwszych trudnych decyzjach, organizacja szybko odczyta, że projekt nie jest priorytetem — i potraktuje go dokładnie tak, jak zasygnalizował zarząd.

Wspólny mianownik tych sygnałów: wszystkie oznaczają to samo — odpowiedzialność właśnie odpłynęła z miejsca, w którym powinna zostać. Dobra wiadomość jest taka, że na starcie da się to jeszcze odwrócić. Wystarczy, że ktoś nazwie problem głośno i poprosi sponsora o jedno konkretne zobowiązanie zamiast ogólnego „powodzenia”.

Warto z tych sygnałów zrobić rozmowę, a nie ciche zmartwienie. Najlepszy moment, żeby ustawić odpowiedzialność, jest właśnie wtedy, gdy słychać pierwsze „zostawiam to wam” — bo później, gdy projekt już się toczy, przesunięcie właściciela jest znacznie trudniejsze. Ten sam mechanizm rozjazdu oczekiwań między stronami opisałem w tekście Co naprawdę dzieje się pomiędzy analizą a wdrożeniem.

Checklista: czy Twój projekt ma właściciela

Istnieje konkretna osoba z zarządu, która mówi „to mój projekt i biorę za niego odpowiedzialność”

Sponsor jest osiągalny i rozstrzyga spory w dniach, nie tygodniach

Role sponsora i kierownika projektu są rozdzielone

Kluczowe osoby mają odjęte obowiązki, a nie dołożony projekt

Użytkownicy końcowi byli włączeni już na etapie analizy

Cała firma wie, że projekt jest priorytetem zarządu — bo to widać, nie tylko słychać

Uwaga, jeśli hasłem startowym było „zostawiam to w waszych rękach”

Uwaga, jeśli projekt jest traktowany jako „zadanie dla IT” lub „sprawa dostawcy”

Podsumowanie: kupić można narzędzie, nie zmianę

Wróćmy do sali ze spotkania otwierającego. Prezes wyszedł, zostawiając projekt „w rękach specjalistów”. To był moment, w którym projekt stracił właściciela — zanim jeszcze się zaczął. Bo specjaliści mogą zbudować i uruchomić system. Nie mogą zmienić firmy, która ich zatrudniła.

Odpowiedź na tytułowe pytanie jest niewygodna, bo przenosi odpowiedzialność tam, gdzie nikt jej nie chce: sukces wdrożenia zależy przede wszystkim od sponsora i od tego, czy organizacja wzięła zmianę na własność. Dostawca odpowiada za działające narzędzie. Za to, czy narzędzie zmieni sposób pracy firmy, odpowiada firma — a konkretnie ten jeden człowiek z władzą, który naprawdę tego chce.

Jeśli miałbym zostawić jedną myśl: zanim kupisz system, znajdź w swojej organizacji osobę, która powie „biorę to na siebie” — i będzie miała władzę, żeby dotrzymać słowa. Bez niej najlepszy system i najlepszy dostawca dadzą ci sprawnie uruchomione narzędzie, którego nikt nie będzie używał tak, jak trzeba. A to nie jest sukces. To najdroższy sposób, żeby zostawić wszystko po staremu.

Jedno zdanie do zapamiętania: narzędzie dostarcza dostawca, ale sukces bierze na własność firma — a konkretnie ten, kto ma odwagę powiedzieć „to mój projekt”.

Najczęstsze pytania

Kto naprawdę odpowiada za sukces wdrożenia systemu?

Sponsor projektu po stronie firmy — zwykle członek zarządu lub właściciel, który realnie chce zmiany i ma władzę, żeby ją wymusić. Dostawca odpowiada za działające narzędzie, ale za sukces biznesowy odpowiada organizacja, która z niego korzysta. Wdrożenie to zmiana sposobu pracy ludzi, a tej nikt z zewnątrz nie przeprowadzi za firmę. Bez zaangażowanego sponsora nawet najlepszy dostawca nie uratuje projektu.

Dlaczego zrzucenie odpowiedzialności na dostawcę kończy się porażką?

Bo dostawca może dostarczyć działający system, ale nie może zmienić nawyków, priorytetów i decyzji wewnątrz firmy. Kiedy organizacja mówi „to wasz projekt, wy to wdrażacie”, tak naprawdę zdejmuje z siebie odpowiedzialność za jedyną rzecz, której dostawca nie kontroluje — za to, czy ludzie zaczną pracować inaczej. System zostaje uruchomiony technicznie, ale nikt go nie używa tak, jak trzeba, i projekt uznaje się za porażkę.

Czym różni się sponsor projektu od kierownika projektu?

Kierownik projektu zarządza zadaniami, terminami i koordynacją na co dzień. Sponsor to osoba z władzą i budżetem, która chce, żeby zmiana się wydarzyła, i bierze za nią osobistą odpowiedzialność wobec organizacji. Sponsor rozstrzyga spory kompetencyjne, wyznacza priorytety i pokazuje całej firmie, że projekt jest ważny. Kierownik prowadzi projekt, sponsor daje mu do tego mandat i osłonę. Bez sponsora kierownik nie ma jak przełamać oporu.

Jaka jest rola działu IT we wdrożeniu systemu biznesowego?

IT odpowiada za warstwę techniczną: infrastrukturę, integracje, bezpieczeństwo, dostępy. Ale wdrożenie systemu produkcyjnego czy magazynowego to projekt biznesowy, nie informatyczny. Kiedy firma traktuje go jako „zadanie dla IT”, popełnia podstawowy błąd — o sukcesie decydują procesy i ludzie z działów operacyjnych, a nie serwery. IT jest niezbędnym uczestnikiem, ale nie może być właścicielem odpowiedzialnym za zmianę sposobu pracy.

Jak zapewnić zaangażowanie organizacji we wdrożenie?

Trzy warunki: widoczny sponsor, który osobiście pokazuje, że projekt jest priorytetem; przydzielenie kluczowym osobom realnego czasu na projekt zamiast dokładania go do pełnych etatów; oraz włączenie użytkowników na etapie analizy, żeby czuli się współautorami, a nie ofiarami zmiany. Zaangażowanie nie bierze się z apeli — bierze się z tego, że ludzie widzą, że zarządowi naprawdę zależy, i że ich zdanie ma wpływ na kształt rozwiązania.

Zaczynasz wdrożenie i chcesz je dobrze ustawić?

Pomagam firmom poukładać odpowiedzialność w projekcie, zanim ruszy technologia — wskazać prawdziwego sponsora, rozdzielić role i zaangażować organizację. To ten etap decyduje o sukcesie, a najczęściej jest pomijany. Umów bezpłatną rozmowę wstępną.

Umów rozmowę o wdrożeniu