„Dajmy temu jeszcze dwa tygodnie przejściowe”. Jeśli kiedykolwiek powiedziałeś to zdanie podczas wdrożenia nowego programu, wiesz już, jak to się kończy: te dwa tygodnie zamieniają się w dwa miesiące, a nowe narzędzie nigdy nie rusza na dobre. Spędziłem około dziesięciu lat jako kierownik IT, budując firmowe oprogramowanie, i to właśnie to zdanie — wypowiadane w najlepszej wierze — stało za większością moich nieudanych wdrożeń.
Krótka odpowiedź
Jak sprawić, żeby zespół zaczął korzystać z nowego programu? Zaangażuj ludzi od początku, wybierz intuicyjne narzędzie, szkol na prawdziwej pracy i świętuj pierwsze sukcesy. Tak mówi podręcznik i nie jest to nieprawda. Wdrożenie to w takim samym stopniu problem zarządzania zmianą, co problem doboru narzędzia.
Tyle że sam podręcznik nigdy nie wystarczał. To, co naprawdę zadziałało, było prostsze — i dużo mniej wygodne:
Usunęliśmy stary system.
Za każdym razem, gdy wdrażaliśmy nowy program albo zmienialiśmy proces, zabieraliśmy ze stołu stary sposób pracy. Arkusz blokowany, stary formularz wyłączony. Ludzie narzekali przez dwa tygodnie, a potem się przestawiali. A kiedy już każdy proces szedł przez nowy program, mogliśmy wreszcie zautomatyzować ogrom ręcznej roboty — bo jedyna droga przez proces prowadziła przez oprogramowanie, które sami kontrolowaliśmy.
Najpierw przejdę przez standardowy plan działania, bo nadal go potrzebujesz. Potem opiszę technikę twardego przełączenia — łącznie z tym, jak ją przeprowadzić, żeby zespół cię nie znienawidził.
Dlaczego zespoły bronią się przed nowym programem
To prawie nigdy nie jest wina programu.
Objaw. Przez dziesięć lat wdrażania firmowego oprogramowania prawie nigdy nie spotkałem użytkownika, który podważałby nowe narzędzie na gruncie merytorycznym. To, na co trafiałem raz za razem, to zwykły strach przed zmianą.
Przyczyna. Stary arkusz bywa wolny i sklejony z kopiuj-wklej, ale jest ich własny. Wiedzą, gdzie co leży, są w nim szybcy. Nowy program, nawet ewidentnie lepszy, przez dwa tygodnie sprawia, że czują się powolni i niekompetentni, a na to uczucie nikt nie zgłasza się na ochotnika. Często cytowany szacunek McKinseya mówi, że około 70% programów zmiany nie osiąga swoich celów, a winowajcą jest zwykle opór osób, które muszą z tą zmianą żyć. Każde badanie pracownicze, które ostatnio widziałem, powtarza wersję tego samego: ludzie już czują się zasypani narzędziami i zakładają, że każde kolejne oznacza dla nich więcej pracy.
Rozwiązanie nie leży w programie — leży w potraktowaniu wdrożenia jako tego, czym naprawdę jest: projektu zarządzania zmianą, w którym przypadkiem pojawia się technologia. Wszystko poniżej wynika właśnie z tego.
Standardowy plan działania (zrób to najpierw)
Standardowe rady są standardowe, bo działają. Pomiń je, a żadna sztuczka z przełączeniem cię nie uratuje.
1. Zaangażuj zespół od początku
Ludzie, którzy będą siedzieć w tym programie codziennie, powinni pomóc mu nadać kształt. Wciągnij do budowy dwie albo trzy osoby, które będą z niego korzystać najwięcej, pokaż im prototypy, pozwól im coś popsuć. Kto pomógł ukształtować narzędzie, ten potem go broni — i to właśnie te osoby uczą później wszystkich dookoła.
Tu też widać przewagę budowania własnego programu nad kupowaniem gotowca. Kiedy ktoś prosi o zmianę i widzi ją wdrożoną w tym samym tygodniu, zaczyna czuć, że to jego program. Dostawca odpowiadający „jest w planach rozwoju” działa dokładnie odwrotnie.
2. Wybierz intuicyjny program
Każde dodatkowe kliknięcie kosztuje cię wdrożenie. Jeśli do najprostszej codziennej czynności potrzebna jest instrukcja, wdrożenie już się sypie. Moja poprzeczka zawsze była prosta: nowy użytkownik przechodzi główny proces za pierwszym razem, bez pomocy. Jeśli nie daje rady, napraw najpierw program, a dopiero potem szkolenie.
3. Szkol na prawdziwej pracy, nie na funkcjach
Nikogo nie obchodzi wycieczka po ekranie ustawień. Szkol każdy zespół na jego konkretnej robocie: „tak rejestrujesz reklamację klienta”, „tak zatwierdzasz zamówienie zakupu”. Na prawdziwych danych i prawdziwych przypadkach brzegowych. Trzydzieści minut zbudowane wokół czyjegoś rzeczywistego wtorku daje więcej niż dwie godziny przechodzenia przez każdą funkcję systemu.
4. Świętuj pierwsze sukcesy
Znajdź pierwszy moment, w którym nowy program wyraźnie wygrał ze starym sposobem — raport, który zajmował cztery godziny, a teraz zajmuje dziesięć minut, coś w tym stylu. Opowiedz o tym wszystkim i wymień z nazwiska osoby, które to zrobiły. Pierwsze sukcesy dają niezdecydowanym dowód, że ruch jest bezpieczny, a zarządowi powód, żeby dalej stać za projektem.
Technika, która naprawdę zadziałała: usuń stary system
Dziesięć lat wdrożeń nauczyło mnie czegoś niewygodnego: możesz zrobić wszystkie cztery kroki powyżej bezbłędnie i tak patrzeć, jak wdrożenie umiera. Z jednego powodu.
Objaw. Za każdym razem, gdy uruchamialiśmy nowy program obok starego „na czas okresu przejściowego”, działo się to samo: w pierwszym tygodniu użycie strzelało w górę, a potem spływało z powrotem do starego arkusza.
Przyczyna. Dopóki stary sposób istnieje, ludzie będą z niego korzystać. Okres przejściowy nigdy nie kończy się sam. Wdrożenie „dla chętnych” to tak naprawdę powolne „nie”.
Rozwiązanie polegało na zaprzestaniu utrzymywania dwóch systemów równolegle. W dniu przełączenia stary arkusz przechodził w tryb tylko do odczytu, a stary formularz znikał. Nowy program stawał się jedyną drogą do wykonania pracy.
I za każdym razem działo się to samo: dyskusja o tym, czy się przesiadać, po prostu się kończyła, a cała ta energia szła prosto w naukę nowego programu. Te niewygodne dwa tygodnie naprawdę się kończyły, bo cały zespół przechodził przez nie razem, zamiast odkładać je w nieskończoność. Prawdziwe problemy wychodziły na jaw w ciągu kilku dni, bo wszyscy trafiali na nie jednocześnie, i naprawialiśmy je, póki uwaga była jeszcze wysoka. A wszystkie dane wreszcie leżały w jednym miejscu.
To zasada palenia za sobą mostów przeniesiona na oprogramowanie biurowe. Cortés miał podobno zatopić własne statki, żeby odwrót przestał być opcją. Nie potrzebujesz niczego tak dramatycznego — ustawienie arkusza na tryb tylko do odczytu w zupełności wystarczy.
Dywidenda z automatyzacji
To część, którą większość artykułów o wdrożeniach pomija, a dla nas była zdecydowanie największą wygraną.
Kiedy jedyną drogą przez proces stał się nowy program, każdy krok tego procesu stał się widoczny dla systemu — a to znaczyło, że wreszcie można go było zautomatyzować. Zatwierdzenia zaczęły krążyć same. Raporty tygodniowe przestały być czyimś piątkowym popołudniem. Wcześniej nic z tego nie było możliwe, bo połowa każdego procesu żyła rozsypana po skrzynkach mailowych i prywatnych arkuszach, których żaden system nie widział.
Wdrożenie nigdy nie było dla nas celem końcowym. Było warunkiem wstępnym. Prawdziwa nagroda przychodzi później, kiedy cały proces siedzi w systemie, który faktycznie kontrolujesz.
Jak przeprowadzić twarde przełączenie, nie wykańczając zespołu
Dla jasności: usunięcie starego systemu nie jest wymówką, żeby pominąć pracę z ludźmi. Wręcz przeciwnie — podnosi stawkę, więc przygotowanie musi być lepsze, nie gorsze. Oto plan, do którego doszliśmy po kilku pomyłkach.
- Nie zabieraj niczego, dopóki nowy program nie jest naprawdę gotowy. Twarde przełączenie na coś niedokończonego spala zaufanie, którego nie odzyskasz łatwo. Główny proces musi być solidny i przetestowany z prawdziwymi użytkownikami, zanim cokolwiek zablokujesz.
- Ogłoś datę z kilkutygodniowym wyprzedzeniem i powtarzaj ją. „15-go stary rejestr przechodzi w tryb tylko do odczytu”. Żadnych niespodzianek. To niespodzianek ludzie się boją; do daty można się przygotować.
- Przenieś dane samodzielnie. Nigdy nie proś użytkowników, żeby przenosili własne rekordy. Jeśli ich historia jest w nowym systemie już pierwszego dnia, usunąłeś największy racjonalny zarzut.
- Zablokuj stary system, nie kasuj go. Ludzie się odprężają, wiedząc, że nic nie przepadło, a ty przy okazji zachowujesz ślad audytowy.
- Przesadź ze wsparciem w pierwszym tygodniu. Dyżury, dedykowany kanał na czacie, ktoś fizycznie chodzący po biurze. Większość oporu rozpuszcza się, kiedy pomoc przychodzi w mniej niż pięć minut.
- Trzymaj linię. Ktoś poprosi o „tylko jeden wyjątek”. Ten pierwszy wyjątek staje się nowym starym systemem. Odpowiedź musi brzmieć: uprzejme, ale stanowcze nie — plus realna naprawa tego, co tę prośbę wywołało.
- Naprawiaj zgłoszenia szybko i na widoku. Pierwszy tydzień po przełączeniu przynosi lawinę szczerych uwag. To dostarczanie poprawek w ciągu kilku dni przekonuje sceptyków.
Gdzie w tym wszystkim jest AgentUI
Twarde przełączenie działa tylko wtedy, gdy nowy program jest naprawdę lepszy i gdy potrafisz go poprawiać w tempie, w jakim spływają uwagi. To jest ta trudna część — i dokładnie tu wchodzi AgentUI.
AgentUI pozwala zespołom biznesowym budować własne programy dla firmy z pomocą AI: około 30 minut do pierwszej działającej wersji, a potem dalsze dopracowywanie w miarę reakcji użytkowników. To tempo zmienia całą arytmetykę wdrożenia: kiedy ktoś zgłasza brak w poniedziałek i widzi go naprawionego w środę, program zdobywa zaufanie szybciej niż jakiekolwiek szkolenie. AgentUI daje też od pierwszego dnia opiekę wdrożeniową z dedykowaną pomocą — prawdziwy zespół ludzi, który pomaga zaplanować wdrożenie i przenieść dane, żebyś nie dźwigał całej zmiany sam.
Skupienie procesów na jednej platformie jest też tym, co otwiera drogę do dywidendy z automatyzacji. Kiedy praca płynie przez jeden nadzorowany system zamiast rozsypanych arkuszy, powtarzalne części wreszcie da się zautomatyzować.
Najczęściej zadawane pytania
Czy zmuszanie ludzi do zmiany nie psuje nastrojów?
Z mojego doświadczenia: bezterminowa niejasność psuje nastroje bardziej niż czyste przełączenie z jasną datą. To, co naprawdę szkodzi, to wepchnięcie ludzi w program, który nie działa, bez wsparcia i bez prawa głosu. Jeśli narzędzie jest gotowe, wsparcie jest na miejscu, a zgłoszenia widocznie zamieniają się w poprawki, większość zespołów czuje ulgę — decyzja zapadła i wszyscy ruszyli razem.
A jeśli mój zespół naprawdę nie może pracować w nowym programie?
To znaczy, że przełączyłeś za wcześnie. Przywróć dostęp, uzupełnij braki razem z użytkownikami pilotażowymi i wyznacz nową datę. Technika brzmi „usuń stary system, kiedy nowy jest gotowy”, a nie „usuń stary system i licz na najlepsze”.
Jak długo stary i nowy system powinny działać równolegle?
Dni, jeśli dasz radę. Krótkie okno równoległe służy tylko do sprawdzenia danych — nadaj mu publicznie ogłoszoną datę końca i trzymaj się jej. Okres równoległy, w którym robi się wygodnie, zwykle staje się trwały.
Jak zmierzyć, czy wdrożenie naprawdę się udało?
Patrz na trzy rzeczy: aktywne użycie (czy wszyscy docelowi użytkownicy wchodzą do programu co tydzień?), domykanie procesu (czy praca przechodzi przez niego od początku do końca?) i systemy w cieniu (czy po cichu wracają nowe arkusze?). To trzecie to sygnał wczesnego ostrzegania, o którego sprawdzeniu większość zespołów zapomina.
Jak szybko da się zbudować program, dla którego warto się przesiąść?
W AgentUI pierwsza działająca wersja zajmuje zwykle około 30 minut, a gotowy do produkcji program firmowy — mniej więcej tydzień. To obejmuje cykle iteracji z użytkownikami pilotażowymi, które w ogóle umożliwiają pewne przełączenie.
Gotowy, żeby zbudować program, z którego twój zespół naprawdę będzie korzystał, i odesłać arkusz na emeryturę?
Wypróbuj AgentUI za darmo — zbuduj swój pierwszy program dla firmy w kilka minut.