Scenka z życia: „Kupiliśmy super narzędzie, a ludzie i tak siedzą w Excelu”
Na sali konferencyjnej stoi tort z logo nowego narzędzia SaaS, jest prezentacja, demo od handlowca, kilka żartów o tym, jak w końcu „pożegnamy te wszystkie Excela”. Mija tydzień, dwa, trzy. Gdy zaglądasz ludziom przez ramię, widzisz znajomy widok: otwarte arkusze, makra, kolorowe komórki. System świeci pustkami, a raport z „wdrożenia” wygląda jak żart.
Tak najczęściej wygląda mini-klęska wdrożeniowa: duże oczekiwania, kilka entuzjastycznych dni, a potem cichy powrót do starych nawyków. Na początku kilka osób próbuje korzystać z narzędzia SaaS, ale szybko się frustrują. Coś nie działa tak, jak w prezentacji, czegoś nie rozumieją, nie ma czasu dopytać. W kalendarzu gonią terminy, więc wracają do tego, co znają najlepiej – do Excela.
W międzyczasie menedżer przestaje zaglądać do systemu, bo i tak nie ma tam aktualnych danych. Handlowiec, który obiecywał cuda, przysyła link do dokumentacji. Zespół zaczyna traktować nowe oprogramowanie jak kolejny modny gadżet z góry, który „przeczekamy, aż przestanie być ważny”. Po kilku miesiącach płacisz abonament za narzędzie, które poprawnie działa tylko w prezentacjach sprzedażowych.
Kluczowy wniosek pojawia się dopiero wtedy, gdy ktoś spojrzy na sytuację chłodniej: rzadko kiedy winne jest samo narzędzie. Zdecydowanie częściej problem leży w sposobie, w jaki zostało wybrane, przygotowane, zakomunikowane i osadzone w codziennych procesach. To dobra wiadomość – bo oznacza, że da się to odwrócić bez wyrzucania systemu do kosza i bez kupowania kolejnego „cudownego” SaaS.
Cała sztuka polega na tym, by zrozumieć, dlaczego ludzie uciekają do Excela, jak rozpoznać, czy narzędzie jest w ogóle sensowne dla Twojej firmy oraz jak krok po kroku przeprowadzić realne wdrożenie, a nie jednorazowy pokaz slajdów.
Diagnoza: czy problem jest w narzędziu, czy w sposobie jego użycia?
Rozróżnienie: „narzędzie nietrafione” vs „narzędzie wdrożone byle jak”
Zanim zaczniesz cokolwiek naprawiać, potrzebna jest uczciwa diagnoza. Inaczej będziesz gasić pożar konewką tam, gdzie w ogóle nie ma ognia – albo przeciwnie: zmienisz dostawcę SaaS, choć wina leży po Twojej stronie. Najpierw odpowiedz sobie na pytanie: czy kupione narzędzie SaaS w ogóle pasuje do charakteru firmy i do sposobu, w jaki pracuje Wasz zespół?
Jeżeli narzędzie jest np. bardzo złożonym systemem do zarządzania projektami, a w firmie do tej pory nie było nawet prostych tablic z zadaniami, to być może przeskok jest za duży. Jeżeli SaaS jest zorientowany na korporacyjne procesy, a Ty prowadzisz małą, zwinną firmę – też może być zgrzyt. Tu chodzi o dopasowanie filozofii pracy, nie tylko listy funkcji.
Z drugiej strony, bardzo często okazuje się, że system jest sensowny, sprawdzony w innych firmach i – teoretycznie – powinien zrobić robotę. Problem w tym, że został „wrzucony” na ludzi bez przygotowania: brak opisu procesów, brak właściciela wdrożenia, brak pilotażu. W efekcie użytkownicy są pozostawieni sami sobie, a wtedy naturalnym odruchem jest powrót do Excela.
Rozpoznanie, w której z tych kategorii jesteś, to pierwszy krok. Bez tego wszystkie dalsze działania będą zgadywaniem.
Trzy szybkie testy oceniające sensowność narzędzia
Prosta, trzystopniowa „diagnostyka” pomaga odsiać przypadki, w których naprawdę trzeba zmienić narzędzie, od tych, gdzie kluczowe jest poprawne wdrożenie.
Test 1: Czy narzędzie realnie wspiera choć jeden kluczowy proces?
Zastanów się, jakie są dla Was najważniejsze procesy: sprzedaż, obsługa klienta, zarządzanie projektami, logistyka, rozliczenia? Czy nowe narzędzie SaaS usprawnia chociaż jeden z nich w zauważalny sposób, gdy spojrzysz na jego projekt? Nie chodzi o subiektywne odczucia, tylko o potencjał. Przykładowo: system CRM, który pozwala śledzić lejek sprzedażowy, generować oferty i monitorować kontakt z klientem – ma sens. Jeżeli jednak kupiłeś narzędzie „do wszystkiego”, a w praktyce nie da się nim wygodnie odtworzyć Waszych podstawowych działań, to znak ostrzegawczy.
Test 2: Czy ktoś w firmie używa go z sukcesem?
Czasem wystarczy, że jedna lub dwie osoby naprawdę „klikną” z systemem. Jeżeli w Twoim zespole istnieje choć jeden użytkownik, który:
- regularnie korzysta z narzędzia,
- potrafi w nim zrobić to, co robił kiedyś w Excelu (lub lepiej),
- deklaruje, że – gdyby reszta zespołu też była w systemie – jego praca byłaby łatwiejsza,
to zazwyczaj problem nie leży w samym SaaS, tylko w przyzwyczajeniach, komunikacji i procesie wdrożenia. Tą osobą można uczynić ambasadora zmiany.
Test 3: Czy istnieje sensowna alternatywa w obecnych warunkach?
Zadaj sobie brutalne pytanie: gdybyś dziś zrezygnował z tego narzędzia i wrócił na stałe do Excela, co by się stało? Czy Excel (plus np. prosty dysk sieciowy) jest w stanie bezpiecznie i sensownie „udźwignąć” Waszą skalę biznesu w najbliższych latach? Jeśli nie – to nawet jeżeli nowe narzędzie SaaS jest niedoskonałe, może być ono koniecznym krokiem do uporządkowania firmy. Wtedy zamiast uciekać z powrotem do arkuszy, sensowniej jest zbudować lepsze wdrożenie.
Rozmowy z zespołem: pytania, które prowadzą do sedna
Po stronie zarządu czy menedżera łatwo o uproszczenia: „Nie chcą korzystać, bo im się nie chce”, „Są oporni na zmiany”. Taka etykietka niczego nie rozwiązuje. Potrzebne są konkretne rozmowy z osobami, które uciekają do Excela.
Kilka dobrych pytań, które pomagają wyciągnąć przyczyny, a nie tylko narzekania:
- „Pokaż mi, co robisz w Excelu, czego – Twoim zdaniem – nie da się zrobić w nowym narzędziu.” – Prośba o ekran, nie o opinię. Zobaczysz realne przypadki użycia.
- „W którym momencie pracy przechodzisz z systemu do Excela?” – Wskazuje na konkretne etapy procesu, gdzie SaaS jest niewygodny lub niedoinformowany.
- „Co sprawia, że w Excelu czujesz się bezpieczniej lub szybciej?” – Odsłania emocjonalne i praktyczne powody (kontrola, szybkość, znajomość narzędzia).
- „Gdybyś miał zostawić ten Excela, czego potrzebujesz w systemie, żeby było OK?” – Przekierowuje z narzekania na rozwiązania.
Nie pytaj ogólnie: „Dlaczego nie korzystasz z systemu?”. To otwarte zaproszenie do ogólników. Proś o przykłady, ekrany, konkretne sytuacje z ostatnich dni. Z tych historii zbudujesz listę rzeczy do poprawy: konfiguracji narzędzia, brakujących integracji, kiepskiego szkolenia czy po prostu błędnych oczekiwań.
Dlaczego jasna diagnoza jest ważniejsza niż szybka akcja
Presja czasu i frustracja pchają do nerwowych decyzji: „To narzędzie jest do niczego, kupujemy inne”, „Każę wszystkim korzystać, a jak nie, to…”. Tyle że zmiana systemu bez zmiany podejścia powtórzy cały problem za pół roku, tylko pod inną marką.
Jasna diagnoza pozwala odróżnić objawy od przyczyn. Objawem jest powrót do Excela, omijanie funkcji, puste raporty w SaaS. Przyczyna może tkwić w:
- braku jasnych procesów,
- chaotycznym onboarding’u,
- braku integracji,
- brakującym czasie na naukę,
- złym dopasowaniu narzędzia do skali i kultury firmy.
Bez nazwania tych elementów kręcisz się w kółko. Gdy już wiesz, gdzie dokładnie boli, możesz dobrać odpowiednie działania zamiast liczyć, że „czas zrobi swoje”.
Typowe powody, dla których zespół ucieka do Excela
Excel jako „bezpieczna przystań” – siła nawyku i poczucia kontroli
Excel jest jak stary, wygodny dres – może nie wygląda najlepiej, ale zna się go na pamięć. Dla wielu specjalistów jest podstawowym narzędziem pracy od lat. Znają skróty, formuły, swoje sposoby na obejście kłopotów. Nowe narzędzie SaaS jest nieprzewidywalne, nieznane i wymaga uwagi. Excel daje poczucie całkowitej kontroli: plik jest „mój”, mogę go zapisać gdzie chcę, zmienić jak chcę, nikt mi go nie dotknie.
Nawyk jest niezwykle silny. Jeżeli ktoś przez 5–10 lat opierał swoją pracę o arkusze, przejście na system wymaga od niego mentalnej zmiany sposobu myślenia, a nie tylko kliknięcia w inny przycisk. Nawet jeśli nowe narzędzie jest obiektywnie lepsze, mózg w pierwszej kolejności wybiera to, co znane i sprawdzone.
W praktyce dla części ludzi Excel jest też narzędziem budowania własnej pozycji w firmie: „Ten plik jest skomplikowany, tylko ja się w nim orientuję”. System SaaS rozkłada tę wiedzę na wielu użytkowników, standaryzuje proces, odbiera trochę aury „niezastąpionej osoby od Excela”. Taka zmiana bywa trudna do przyjęcia, szczególnie bez odpowiedniej rozmowy o roli i oczekiwaniach.
Skomplikowany interfejs kontra elastyczna tabelka
Drugą przyczyną powrotu do arkuszy jest poczucie, że nowe narzędzie jest zbyt skomplikowane lub zbyt sztywne. W Excelu można w minutę dodać nową kolumnę, policzyć formułą jakąś wartość, pokolorować kilka komórek i mieć szybki „raport” pod spotkanie. W systemie SaaS często trzeba:
- poszukać odpowiedniej funkcji,
- poprosić administratora o dodanie pola,
- poczekać na update schematu danych,
- zrozumieć, jak filtrować i raportować.
Dla osoby przyzwyczajonej do pełnej swobody w arkuszu jest to irytujące. W efekcie system jest postrzegany jako „hamulec”, a nie wsparcie. Szczególnie gdy interfejs jest przeładowany funkcjami, których zespół nie potrzebuje.
Dochodzi do tego różnica filozofii: Excel służy do dowolnego modelowania danych, system SaaS służy do konsekwentnego realizowania powtarzalnych procesów. Jeśli firma próbuje w systemie odwzorować każdy niuans przypadków, które kiedyś ogarniała ręcznie w arkuszu, powstaje potwór. Ludzie czują, że nowe narzędzie krępuje ich ruchy, więc przenoszą kreatywne elementy pracy z powrotem do Excela.
Nieopisane procesy: porządek w narzędziu kontra chaos w głowach
Wiele firm inwestuje w nowy SaaS z nadzieją, że „wprowadzi porządek”. Problem w tym, że narzędzie tylko odwzorowuje to, co już istnieje – nie wymyśli za zespół sensownych procesów. Jeśli w organizacji:
- nie ma opisanych kroków działań,
- rolę każdego etapu zna tylko jedna osoba,
- terminy i odpowiedzialności są „na czuja”,
to system, który wymusza pola, statusy i przypisanie odpowiedzialnych, bywa odczuwany jak atak na święty spokój.
Ludzie nie wiedzą, jak mają teraz pracować, bo nikt im nie pokazał nowego procesu. Słyszą tylko: „Korzystajcie z narzędzia”. W rezultacie logują się, klikają kilka razy, gubią się w strukturyzowanym modelu danych i wracają do prostego Excela, który nie zadaje pytań o kategorie, statusy, etapy.
Jeśli proces istnieje tylko w czyjejś głowie, żadne narzędzie nie zadziała. Trzeba najpierw narysować „mapę drogową”: od czego zaczynamy, jakie są etapy, kto za co odpowiada, jakie dane zbieramy, co jest efektem końcowym. Dopiero to można przenieść do systemu, a później pokazać ludziom w praktyce.
Brak czasu na szkolenie i realne wdrożenie
Kolejną typową przyczyną jest iluzja: „To jest proste, ogarną sami”. Menedżer, który spędził kilka godzin z handlowcem, ma wrażenie, że wszystko jest intuicyjne. Zapomina, że:
- ludzie w zespole nie uczestniczyli w tych rozmowach,
- widzieli narzędzie góra raz, przez 30 minut,
- mają pełne kalendarze bieżących zadań.
Przy takim starcie większość pracowników traktuje system jako dodatkowy obowiązek, a nie zmianę sposobu pracy. Czas poświęcony na eksperymenty kończy się szybko, bo priorytetem jest „dowiezienie” aktualnych zadań. Gdy napotykają pierwszą trudność, po prostu wracają do Excela, który ich nie spowalnia.
Problemu nie rozwiązuje też jednorazowe szkolenie. Ludzie zapamiętują niewielką część z takiego spotkania. Potrzebują:
- konkretnych, krok po kroku scenariuszy pracy,
- możliwości zadawania pytań po kilku dniach realnego używania,
- kogoś „na miejscu”, kto pomoże, gdy utkną.
Bez takiego wsparcia wdrożenie narzędzia SaaS kończy się na poziomie haseł, a nie zmiany nawyków.
Dobry efekt daje też prosta sekwencja: krótkie wprowadzenie, wspólne przejście przez 2–3 typowe scenariusze (np. „jak rozliczamy kampanię”, „jak planujemy sprint”), a potem zadanie domowe z konkretnym celem: „Do piątku wszystkie nowe sprawy wprowadzamy już tylko przez system”. Po kilku dniach trzeba wrócić do zespołu i omówić realne trudności na przykładach z ich pracy, zamiast wyświetlać ten sam slajd z funkcjami.
W mniejszych firmach sprawdza się podejście „pilotaż + wewnętrzni ambasadorzy”. Najpierw 2–3 osoby testują system na prawdziwych zadaniach, a dopiero potem pokazują reszcie, jak go używają. To zupełnie inny odbiór, gdy handlowiec widzi ekran kolegi z zespołu, a nie demo od vendor’a. Taki ambasador szybciej wyłapie też, kiedy ktoś „odpływa” z powrotem do Excela i pokaże mu prostszy sposób w narzędziu.
Szkolenie nie powinno kończyć się w momencie wylogowania trenera. Dobrze, gdy na pierwsze tygodnie wdrożenia ustalony jest „czas ochronny”: mniej zadań ad hoc, jasna zgoda, że można pracować wolniej, byle w nowym systemie. Bez tego ludzie naturalnie wybiorą ścieżkę najmniejszego oporu, czyli dotychczasowe pliki i własne szablony.
Jeżeli zespół zobaczy, że nauka narzędzia jest wpisana w normalną pracę – a nie wciśnięta między maile wieczorem – traktuje zmianę poważnie. Sam komunikat: „To jest teraz nasze główne środowisko pracy, uczymy się go razem i mamy na to przestrzeń” robi większą różnicę niż najbardziej efektowna prezentacja funkcji.
Gdy nowe SaaS faktycznie pomaga ludziom szybciej domykać sprawy, a nie tylko produkować kolejne raporty, Excel staje się dodatkiem, a nie ucieczką. Klucz leży mniej w samym narzędziu, a bardziej w decyzjach menedżera: jak jasno nazwał procesy, jak uczciwie dobrał system do zespołu i jak konsekwentnie prowadzi ludzi przez zmianę, zamiast liczyć, że „jakoś to się samo ułoży”.
Błędy po stronie menedżera przy wyborze i zakupie narzędzia
Decyzja oparta na obietnicach sprzedawcy, nie na realnej pracy zespołu
Na prezentacji vendor klika kilka magicznych przycisków, pokazuje piękne dashboardy i obiecuje „automatyzację wszystkiego”. Menedżer patrzy na to z perspektywy celów kwartalnych, a nie codziennej pracy zespołu, więc słyszy głównie: „oszczędność czasu” i „lepsza kontrola”. Po wdrożeniu okazuje się, że droga do tych korzyści wymaga szeregu dodatkowych kroków, konfiguracji i dyscypliny, na którą nikt nie był gotowy.
Przy wyborze narzędzia zbyt rzadko padają pytania typu:
- „Jak dokładnie w tym systemie robimy to, co dziś robimy w Excelu?”
- „Które kroki będą dla ludzi <emtrudniejsze
- „Czy możemy przejść po jednym realnym case’ie z naszej firmy od A do Z?”
Zamiast tego skupiamy się na ogólnych możliwościach systemu. Różnica między „da się” a „da się wygodnie” wychodzi dopiero po podpisaniu umowy – wtedy, gdy ludzie masowo uciekają z powrotem do starych szablonów.
Im mniej rozmów o konkretnych, powtarzalnych sytuacjach z życia zespołu przed zakupem, tym większe rozczarowanie przy pierwszym starciu z rzeczywistością.
Brak rozmowy z ludźmi, którzy będą w narzędziu „mieszkać”
Decyzja o narzędziu często zapada w wąskim gronie: menedżer, IT, czasem finansowy. Osoby, które potem spędzą w systemie kilka godzin dziennie, są o wszystkim informowane dopiero po fakcie. Dostają komunikat: „Wybraliśmy to narzędzie, od przyszłego miesiąca na nim pracujemy”. Trudno oczekiwać entuzjazmu i zaangażowania, gdy ludzie czują, że zmiana „spadła z góry”.
Ominięcie zespołu na etapie wyboru ma trzy konsekwencje:
- pomijane są realne potrzeby i ograniczenia użytkowników,
- tworzy się ciche nastawienie „to nie nasze, to ich projekt”,
- każda niedogodność narzędzia jest później traktowana jako dowód na „oderwanie szefostwa od rzeczywistości”.
Zdecydowanie lepiej działa prosty ruch: włączenie 2–3 osób z różnych ról do testów i poproszenie ich o szczerą opinię. Nie chodzi o demokratyczne głosowanie, tylko o informację zwrotną: co ich spowolni, co jest niezrozumiałe, czego brakuje, żeby mogli zostawić Excela.
Jeśli ci „ludzie z okopów” powiedzą: „W tym systemie wreszcie mogę zobaczyć X bez grzebania po pięciu plikach”, masz pierwszych ambasadorów. Jeżeli natomiast już na etapie testu kręcą nosem i pokazują konkretne przeszkody – lepiej to usłyszeć przed, niż po podpisaniu trzyletniej umowy.
Zakup „pod funkcje”, nie pod proces
Lista funkcji w folderze reklamowym wygląda imponująco: workflow, SLA, AI, automatyczne powiadomienia, integracje, zaawansowane raporty. Łatwo ulec wrażeniu, że im więcej opcji, tym lepiej. Tymczasem zespół potrzebuje na start dobrze ogarniętych trzech rzeczy, np.:
- wprowadzenia spraw w jednym miejscu,
- jasnego statusu i odpowiedzialnego,
- prostego raportu tygodniowego.
Jeżeli podstawowe scenariusze są ukryte pod warstwą konfiguracji, modułów i zaawansowanych ustawień, ludzie szybko tracą cierpliwość. Z ich perspektywy system staje się „klockiem LEGO bez instrukcji”, a Excel – jedyną drogą, żeby w ogóle dowieźć zadania.
Sensowna selekcja narzędzi zaczyna się od jednego pytania: „Jaki konkretny proces chcemy usprawnić w pierwszej kolejności?”. Dopiero później dobieramy funkcje, które realnie wspierają ten proces. Resztę można dobudowywać później, kiedy zespół już oswoi nowe środowisko.
Niedoszacowanie kosztów „poza licencją”
W kalkulacjach biznesowych najczęściej pojawia się koszt licencji, wdrożenia i ewentualnych integracji. Rzadziej uwzględnia się:
- czas zespołu na naukę i przeprojektowanie pracy,
- dodatkowe obowiązki dla administratora lub lidera,
- spadek produktywności w pierwszych tygodniach.
Na Excel nikt nie liczy takich kosztów, bo jest „już opanowany”. Nic dziwnego, że nowy system wypada blado w percepcji pracowników, jeśli próbuje się go wcisnąć „po godzinach”, bez zmiany oczekiwań co do wyników.
Menedżer, który nie wkalkuluje czasu na adaptację, sam tworzy grunt pod bunt wobec narzędzia. Ludzie nie odmawiają zmiany, oni odmawiają robienia drugiego etatu: stare procesy + nowy system równolegle, bez żadnej ulgi.
Słaby „po co” – narzędzie kupione dla menedżera, nie dla zespołu
Częste jest myślenie: „Potrzebuję lepszej kontroli i raportów, więc kupimy system”. Z perspektywy zarządu czy managera to ma sens. Z perspektywy specjalisty oznacza jednak: „Teraz będą mnie bardziej śledzić”. Jeśli głównym komunikatem jest: „Będziemy mieć lepszą widoczność i dashboardy”, trudno oczekiwać zachwytu wśród osób, które już dziś czują się przytłoczone raportowaniem.
Zdrowy balans wygląda inaczej: zespół dostaje konkretne usprawnienia w codziennej pracy (np. mniej ręcznego kopiowania danych, mniej maili z ustaleniami), a menedżer – pochodną w postaci spójnych danych. Jeżeli w narracji dominują tylko korzyści kontrolne, Excel będzie wciąż atrakcyjną „strefą cienia”, gdzie nie trzeba wszystkiego dokumentować.
Gdy osoby operacyjne słyszą: „Dzięki temu narzędziu szybciej zamkniemy tematy X i Y, a ja nie będę was zasypywał dodatkowymi excelowymi tabelkami do raportów, bo wszystko będzie w systemie” – rośnie szansa, że potraktują zmianę poważnie.
Błędy wdrożeniowe: jak zabić nawet dobre narzędzie w 4 prostych krokach
1. Wrzucić narzędzie „z dnia na dzień” i udawać, że nic się nie zmieniło
Znany scenariusz: w piątek maila z linkiem do logowania i krótką instrukcją, w poniedziałek oczekiwanie, że zespół będzie już działał „na nowym”. Do tego żadnej rezerwacji czasu, zero zmiany priorytetów, zwykłe targety. Ludzie próbują coś klikać między jednym mailem a drugim, gubią się, frustrują – i wracają do swoich starych plików, bo tam przynajmniej wiedzą, gdzie co jest.
Taka „zimna woda” komunikuje jasno: wdrożenie narzędzia to kosmetyka, a nie realna zmiana sposobu pracy. Skoro jest to tylko „dodatek”, naturalnym odruchem jest jego marginalizowanie. Excel wygrywa, bo pozwala dowieźć cele bez szarpania się z nowym interfejsem.
2. Skupić się na funkcjach, a nie na konkretnych scenariuszach pracy
Na wdrożeniu pada często zbyt dużo słów o możliwościach: widoki, filtry, automaty, integracje. Ludzie słuchają tego jak katalogu IKEA – ładne, ale nie wiadomo, co z tym zrobić w swojej kawalerce. Brakuje przejścia przez prostą ścieżkę: „Masz zadanie X, co dokładnie klikasz od momentu zgłoszenia do zamknięcia sprawy?”.
Jedna z firm usługowych przez miesiąc uczyła ludzi, jak konfigurować raporty i budować własne dashboardy. Po tym czasie okazało się, że nikt nie wie, jak poprawnie wprowadzić nowe zlecenie od klienta. Efekt: Excel do operacyjnej roboty, system do „raportów na zarząd”. Narzędzie nie było złe – zabrakło przełożenia na jasne, powtarzalne scenariusze dnia codziennego.
Im szybciej ludzie zobaczą, że w systemie da się „po prostu zrobić swoją robotę”, tym mniejsza pokusa ucieczki do arkusza.
3. Zostawić ludzi samych z pierwszymi problemami
W pierwszych tygodniach każdy system generuje pytania: gdzie to się klika, czemu tego nie widzę, co zrobić, jak zapomnę hasła albo pomylę status. Jeżeli w tym momencie odpowiedź brzmi: „Napisz do supportu vendor’a” albo „Zgłoś ticket do IT”, większość ludzi odpuszcza po pierwszej próbie. W czasie, gdy czeka na odpowiedź, musi i tak pracować dalej – czyli wraca do Excela.
Dużo lepiej działa rola „pierwszej linii wsparcia” po stronie zespołu. To może być lider, product owner, koordynator – ktoś, kto:
- zna proces i narzędzie wystarczająco dobrze,
- ma odgórnie daną przestrzeń czasową na pomaganie innym,
- jest dostępny na szybki call albo podejście do biurka.
Bez takiej osoby system staje się od razu „formalnym obowiązkiem” zamiast realnym środowiskiem pracy. Gdy użytkownik widzi, że po jednym telefonie dostaje konkretne rozwiązanie i już wie „jak to ogarniać”, kolejny raz chętniej spróbuje w systemie niż w arkuszu.
4. Brak czytelnych zasad: co od dziś robimy w systemie, a co jeszcze w Excelu
Jednym z najskuteczniejszych „zabójców” wdrożenia jest szara strefa. Część osób wprowadza dane do systemu, część dalej działa w arkuszach. Czasem coś ląduje tu, czasem tam. Nie ma jasnego kryterium: od kiedy konkretne typy zadań „muszą” przechodzić przez nowe narzędzie. W efekcie po kilku tygodniach:
- nikt nie ufa danym w systemie, bo widzi, że są niepełne,
- Excel wydaje się bezpieczniejszy – „przynajmniej mam wszystko u siebie”,