Dwa momenty, które łatwo pomylić
Go-live jest ważny. Daje widoczny punkt w czasie, mobilizuje zespoły, zamyka fazę przygotowań i pozwala powiedzieć: „system działa". Ale z perspektywy change managementu to dopiero początek właściwej pracy — szczególnie w środowisku globalnego marketingu, gdzie sieć interesariuszy rozciąga się między zespołami centralnymi, rynkami, agencjami, właścicielami procesów i użytkownikami końcowymi. Poniżej opisuję ten rozjazd na przykładzie rolloutu, w którym uczestniczyłem — razem z trzema błędami, które popełniliśmy mimo dobrego przygotowania. Piszę „my", bo lessons learned zaczynają się od własnego podwórka.
Kontekst: mieliśmy prawie wszystko
Wdrażana platforma nie była kolejnym narzędziem — miała stać się standardowym punktem startowym pracy z contentem marki: jednym miejscem łączącym playbooki, materiały wzorcowe, wyszukiwanie i przekazanie zlecenia do realizacji. Zmiana obejmowała około trzech tysięcy osób: zespoły centralne, huby, rynki, agencje.
I trzeba to powiedzieć uczciwie: elementów sukcesu było dużo. Platforma działała. Były playbooki, e-learning, wideo przeglądowe, demo end-to-end, hub wiedzy, przewodniki kontekstowe w aplikacji, dashboard adopcji, komunikacja wzmacniająca. Na papierze — wzorcowy zestaw. A mimo to adopcja szła wolniej, niż zakładał program. Dlaczego? Trzy mechanizmy.
Błąd 1: oddaliśmy narzędzie, na które można popatrzeć
Funkcjonalności były udostępniane etapami — decyzja zrozumiała projektowo, ale zabójcza adopcyjnie. Użytkownik, który wszedł do systemu i nie mógł w nim dokończyć swojej pracy, dostał de facto demo. A demo ogląda się raz. Kiedy brakujące funkcje w końcu doszły, pierwsze wrażenie było już zbudowane — i było to wrażenie „ładne, ale jeszcze nie dla mnie". Odbudowa tego pierwszego wrażenia kosztowała więcej komunikacji niż cały start.
Lekcja: nie uruchamiaj „czegoś" dla wszystkich. Uruchom kompletną ścieżkę end-to-end dla przynajmniej jednej grupy użytkowników — nawet wąskiej — i dopiero potem poszerzaj. Adopcję buduje pierwsze ukończone zadanie, nie pierwsze logowanie.
Błąd 2: change management wszedł trzy miesiące przed startem
Dedykowane zarządzanie zmianą pojawiło się w programie na ostatniej prostej — na kwartał przed globalnym rolloutem. Strategia powstała szybko, ale trzy rzeczy były już nie do odrobienia: nawyki wczesnych użytkowników zdążyły ułożyć się wokół obejść, kluczowe decyzje projektowe zapadły bez perspektywy adopcyjnej, a kalendarz komunikacji trzeba było budować od zera w biegu. Change manager wchodzący na etapie „przygotujcie komunikację startową" nie zarządza zmianą — obsługuje jej ogłoszenie.
Lekcja: CM wchodzi wtedy, gdy projektuje się proces i role, nie wtedy, gdy projektuje się plakat. Koszt trzech miesięcy konsultanta na etapie discovery jest niewidoczny przy koszcie odzyskiwania adopcji po starcie.
Błąd 3: kaskada bez menedżerów
Najciekawszy — bo strukturalny — problem: decyzją programu komunikacja nie mogła angażować menedżerów liniowych. Dotarcie miało być centralne, bezpośrednio do wszystkich użytkowników. Intencja była zrozumiała (spójność przekazu, tempo, odciążenie menedżerów), ale konsekwencje dla adopcji były poważne. Badania PROSCI od lat pokazują ten sam wzór: ludzie chcą słyszeć „dlaczego firma to robi" od sponsora, ale „co to znaczy dla mnie" — od bezpośredniego przełożonego. Kaskada czysto centralna zostawia to drugie pytanie bez nadawcy. A to właśnie na nim wyrasta opór.
Łataliśmy tę lukę protezami: siecią ambasadorów i punktów kontaktowych na rynkach, bezpośrednimi mailami do grup użytkowników, sesjami drop-in, kanałami społecznościowymi. Protezy działają — częściowo. Żadna z nich nie zastępuje momentu, w którym przełożony mówi zespołowi: „od poniedziałku zaczynamy tu, a nie w mailu, i ja też tak pracuję".
Lekcja: jeśli organizacja z jakiegoś powodu wyklucza menedżerów z kaskady, potraktuj to jako ryzyko projektowe najwyższej wagi i nazwij je na piśmie — wraz z konsekwencją: wolniejszą i płytszą adopcją. A potem świadomie inwestuj w najlepsze dostępne protezy, wiedząc, że to protezy.
Zasięg to nie adopcja
Najbardziej pouczający pojedynczy obrazek z tego wdrożenia: społeczność projektowa licząca ponad 1200 członków — i cisza w komentarzach. Zasięg wyglądał świetnie w raporcie; zaangażowanie nie istniało. To samo dotyczyło komunikacji: wyświetlenia rosły, a wskaźniki zachowań — pierwsze ukończone zadanie, powrót w drugim tygodniu, odsetek pracy zaczynanej w nowym narzędziu — opowiadały inną historię.
Dlatego przesunięcie rozmowy z „czy ludzie wiedzą, że system istnieje?" na „czy ludzie faktycznie zaczynają od niego pracę?" było najważniejszym ruchem całego programu. Awareness to pierwszy krok drabiny, nie jej szczyt. Adopcja dzieje się wtedy, gdy użytkownik rozumie po co, wie co zrobić, ma materiały pod ręką, słyszy spójny komunikat od liderów i widzi, że organizacja naprawdę oczekuje nowego zachowania — a stara ścieżka przestaje być bezkarna. Praktyczna rama, której od tamtej pory używam, to lejek adopcji: świadomość → pierwsze wejście → pierwsze ukończone zadanie → powrót w drugim tygodniu → nawyk. Na każdym szczeblu obowiązuje inne pytanie i inna interwencja: przy świadomości działa komunikacja, przy pierwszym wejściu — prostota startu, przy pierwszym zadaniu — kompletność ścieżki i pomoc w momencie potrzeby, przy powrocie — reinforcement i wygaszanie starej ścieżki, przy nawyku — sponsor i konsekwencja. Programy najczęściej wpadają w pułapkę optymalizowania pierwszego szczebla, podczas gdy wąskie gardło siedzi trzy szczeble niżej.
Co działało — żeby było uczciwie
Lessons learned złożone z samych błędów byłyby nieuczciwe wobec zespołu i bezużyteczne dla czytelnika, więc druga strona bilansu. Podpowiedzi kontekstowe w aplikacji miały najlepszy stosunek efektu do kosztu w całym programie: pomoc pojawiała się przy kroku, na którym użytkownik właśnie stał, a nie w szkoleniu sprzed miesiąca. Precyzyjnie targetowane maile do wąskich grup z jednym konkretnym wezwaniem do działania biły broadcast o rzędy wielkości — im węższy adresat i im bliżej jego zadania, tym lepszy wynik. Sesje drop-in miały niską frekwencję i wysoką wartość: prawie każdy uczestnik wychodził z odblokowanym własnym zadaniem i zostawał nieformalnym ambasadorem w swoim zespole. Dashboard zachowań zmieniał rozmowy z programem: dyskusja o opiniach zamieniała się w dyskusję o liczbach i decyzjach. I wreszcie widoczna pętla „zgłosiliście — naprawiliśmy": nic nie buduje zaufania do zmiany szybciej niż bloker użytkownika usunięty w kilka dni i zakomunikowany z podziękowaniem.
Wspólny mianownik jest wyraźny: działa to, co jest blisko zadania użytkownika. Im dalej od zadania — ogólne webinary, plakatowa komunikacja, wydarzenia „awarenessowe" — tym słabszy i krótszy efekt. To prosta heurystyka do priorytetyzacji budżetu adopcyjnego.
Cztery zasady globalnego rolloutu
1. Prosta obietnica. Użytkownik nie powinien dekodować strategii programu. Jedno zdanie — „to jest Twój standardowy punkt startowy" — powtarzalne przez sponsorów, właścicieli produktu i wsparcie.
2. Wiele punktów kontaktu. Jedna wiadomość i jedna sesja awarenessowa nie wystarczą nikomu. Przypomnienia, Q&A, drop-iny, bezpośrednie maile, materiały self-service, pętle feedbacku, szybka reakcja na blokery.
3. Mierz zachowania, nie zasięg. Wyświetlenia i liczebność społeczności to metryki komunikacji. Metryki zmiany to: pierwsze ukończone zadanie, powrót, odsetek pracy w nowym procesie, liczba obejść.
4. Zmiana musi mieć właścicieli. Product owner od platformy, process owner od procesu, change manager od przeprowadzenia ludzi — i widoczny sponsor od nadania temu wszystkiemu statusu. Brak któregokolwiek z tych czterech ról nie „utrudnia" adopcji. On ją limituje.
Najważniejsza lekcja
Sukces wdrożenia nie polega na tym, że organizacja uruchomiła narzędzie. Sukces polega na tym, że organizacja zaczęła pracować inaczej — i robi to nadal, kiedy nikt już nie patrzy.
Nie projektuj change managementu pod dzień startu. Projektuj go pod trzeci, szósty i dwunasty tydzień po go-live — bo wtedy organizacja pokazuje, czy naprawdę się zmieniła.
Two moments that are easy to confuse
Go-live matters: a visible point in time, mobilized teams, preparations closed. But from a change management perspective it is only the beginning of the real work — especially in global marketing, where stakeholders stretch across central teams, markets, agencies, process owners and end users. Below is that gap illustrated with a rollout I worked on — including three mistakes we made despite solid preparation. I say “we”, because lessons learned start at home.
Context: we had almost everything
The platform was to become the standard starting point for brand-content work: one place connecting playbooks, master assets, discovery and handoff to execution, for roughly three thousand people across central teams, hubs, markets and agencies. And honestly: many success ingredients were in place — a working platform, playbooks, e-learning, an end-to-end demo, a knowledge hub, in-app guidance, an adoption dashboard, reinforcement communication. A textbook set on paper. Adoption still moved slower than the programme assumed. Three mechanisms explain why.
Mistake 1: we shipped a tool to look at
Functionality was released in stages — understandable from a project standpoint, lethal for adoption. A user who entered the system and could not finish their work there effectively received a demo. And a demo gets watched once. By the time missing features arrived, the first impression was set: “nice, but not for me yet”. Rebuilding that impression cost more communication than the entire launch.
Lesson: do not launch “something” for everyone. Launch a complete end-to-end path for at least one user group — however narrow — then widen. Adoption is built by the first completed task, not the first login.
Mistake 2: change management arrived three months before launch
Dedicated change management joined on the home straight — a quarter before the global rollout. The strategy came together fast, but three things were beyond recovery: early users’ habits had already settled around workarounds, key design decisions had been made without an adoption lens, and the communication calendar had to be built from zero at full speed. A change manager brought in at the “prepare the launch comms” stage is not managing change — they are servicing its announcement.
Lesson: the CM joins when the process and roles are being designed, not when the poster is. Three months of a consultant at discovery is invisible next to the cost of recovering adoption after launch.
Mistake 3: a cascade without managers
The most interesting — because structural — problem: by programme decision, communication could not involve line managers. Reach was to be central, direct to all users. The intent was understandable (message consistency, speed, sparing managers), but the adoption consequences were serious. PROSCI research has shown the same pattern for years: people want to hear “why the company is doing this” from the sponsor, but “what it means for me” from their direct supervisor. A purely central cascade leaves that second question without a sender — and that is exactly where resistance grows.
We patched the gap with prosthetics: an ambassador network and market-level contact points, direct emails to user groups, drop-in sessions, community channels. Prosthetics work — partially. None of them replaces the moment a supervisor tells the team: “from Monday we start here, not in email, and I work this way too.”
Lesson: if an organization excludes managers from the cascade for any reason, treat it as a top-severity project risk, name it in writing along with its consequence — slower, shallower adoption — and then invest deliberately in the best available prosthetics, knowing they are prosthetics.
Reach is not adoption
The most instructive single image from this rollout: a project community of more than 1,200 members — and silence in the comments. Reach looked great in the report; engagement did not exist. The same held for communication: views grew while behavior metrics — first completed task, second-week return, share of work started in the new tool — told a different story.
That is why shifting the conversation from “do people know the system exists?” to “do people actually start their work there?” was the most important move of the programme. Awareness is the first rung of the ladder, not its top. The practical frame I have used ever since is the adoption funnel: awareness → first entry → first completed task → second-week return → habit. Each rung has its own question and its own intervention: communication works at awareness, ease of start at first entry, path completeness and in-context help at first task, reinforcement and retiring the old path at return, sponsorship and consistency at habit. Programmes most often over-optimize the first rung while the bottleneck sits three rungs lower.
What worked — to be fair
Lessons learned made only of mistakes would be unfair to the team and useless to the reader, so the other side of the ledger. In-app contextual guidance had the best effect-to-cost ratio in the whole programme: help appeared at the step the user was standing on, not in a training from a month ago. Precisely targeted emails to narrow groups with a single call to action beat broadcast by orders of magnitude — the narrower the audience and the closer to their task, the better the result. Drop-in sessions had low attendance and high value: nearly every participant left with their own task unblocked and became an informal ambassador. The behavior dashboard changed conversations with the programme: opinion debates turned into decisions about numbers. And the visible “you reported — we fixed” loop: nothing builds trust in a change faster than a user’s blocker removed within days and acknowledged with thanks.
The common denominator is clear: what works is what sits close to the user’s task. The further from the task — generic webinars, poster communication, awareness events — the weaker and shorter the effect. A simple heuristic for prioritizing an adoption budget.
Four principles of a global rollout
1. A simple promise — one repeatable sentence, not a strategy to decode. 2. Many touchpoints — reminders, Q&A, drop-ins, direct emails, self-service, feedback loops. 3. Measure behavior, not reach — first completed task, returns, share of work in the new process, workarounds. 4. Change needs owners — product owner, process owner, change manager, and a visible sponsor granting it all status. A missing role does not “hinder” adoption. It caps it.
The lesson
Implementation success is not that the organization launched a tool. It is that the organization started working differently — and still does when nobody is watching. Don’t design change management for launch day. Design it for week three, six and twelve after go-live — that is when the organization shows whether it truly changed.
