Key user to nie super-użytkownik. To tłumacz między firmą a systemem

Kiedy firma decyduje się na wdrożenie nowego systemu – ERP, TMS, CRM – w naturalny sposób pojawia się pytanie: kto będzie key userem?

I tu zaczyna się problem.

Bo najczęściej szukamy kogoś, kto „zna się na systemie”. Kto potrafi szybko klikać, pamięta skróty klawiszowe, orientuje się w ustawieniach. Kogoś, kto będzie „super-użytkownikiem”.

To fundamentalny błąd.

Key user to nie specjalista IT w przebraniu. To osoba, która rozumie, jak działa firma – nie jak działa system.

Czego naprawdę potrzebujemy od key usera?

Dobry key user nie musi znać wszystkich zakładek w menu. Nie musi pamiętać, gdzie są ukryte zaawansowane opcje konfiguracyjne. Nie musi być najszybszy w nawigacji po interfejsie.

Dobry key user musi rozumieć trzy rzeczy:

Gdzie proces pęka.

To znaczy: w którym momencie rzeczywistość przestaje pasować do założeń. Gdzie pojawiają się obejścia, arkusze Excela „na boku”, telefony „żeby dopilnować”. Gdzie ludzie tracą czas na ręczne przeklejanie danych albo na wyjaśnianie, co się wydarzyło.

Key user widzi te miejsca, bo sam pracuje w procesie. Albo pracował – na tyle niedawno, żeby pamiętać, co naprawdę się dzieje, gdy nikt nie patrzy.

Kto naprawdę wykonuje pracę.

Nie chodzi o nazwiska w organigramie. Chodzi o to, kto faktycznie wprowadza dane, kto je weryfikuje, kto je poprawia, gdy coś pójdzie nie tak. Kto dzwoni do klienta, gdy system nie wypluje dokumentu. Kto zostaje po godzinach, żeby „domknąć dzień”.

Key user zna te osoby. Rozmawia z nimi. Rozumie, czego potrzebują, żeby móc dobrze pracować – nie tylko, co im się wydaje, że potrzebują.

Co się wydarzy dzień po go-live.

Bo wdrożenie to nie moment, w którym system „rusza”. To moment, w którym firma zaczyna na nim pracować – często z opóźnieniami, z brakującymi danymi, z niejasnym podziałem obowiązków.

Dobry key user wie, że w pierwszym tygodniu pojawi się chaos. I wie też, czego będą potrzebować ludzie, żeby przez ten chaos przejść. Nie technicznych instrukcji – tylko wsparcia, cierpliwości i jasnych odpowiedzi na pytanie: „co mam teraz zrobić?”.

Key user jako tłumacz

System mówi językiem pól, tabel, relacji, logiki warunkowej.

Firma mówi językiem: „ale przecież zawsze robiliśmy to tak”, „klient się nie zgodzi”, „jak ja mam to wprowadzić, skoro nie mam tych danych?”.

Key user tłumaczy między tymi dwoma światami.

Nie po to, żeby „nauczyć ludzi klikać”. Po to, żeby znaleźć sposób, w jaki system może wspierać pracę – zamiast jej komplikować.

To wymaga czegoś więcej niż znajomości funkcji. Wymaga empatii. Zrozumienia, że to, co w teorii wygląda logicznie, w praktyce może być niemożliwe do wykonania. Że skrót, który zaoszczędzi 2 minuty analitykowi, może kosztować 20 minut magazyniera.

Key user nie przekonuje ludzi, że muszą się dostosować. Pomaga zaprojektować rozwiązanie, które będzie dla nich użyteczne.

Dlaczego to się myli z rolą „super-użytkownika”?

Bo w firmach wciąż panuje przekonanie, że wdrożenie to kwestia techniczna.

Że wystarczy dobrze skonfigurować system, przeszkolić ludzi, włączyć – i będzie działać.

Ale systemy nie działają w próżni. Działają w organizacji, która ma swoje przyzwyczajenia, swoje niepisane reguły, swoje wąskie gardła. I jeśli system nie będzie do tego dopasowany, ludzie znajdą sposób, żeby go ominąć.

Key user to osoba, która zapobiega temu omijaniu – nie przez zmuszanie ludzi do używania systemu, tylko przez zaprojektowanie go tak, żeby naprawdę im pomagał.

A to wymaga czegoś, czego nie nauczy żadne szkolenie techniczne: znajomości firmy od środka.

Kiedy key user naprawdę się sprawdza?

Prawdziwy test key usera nie dzieje się podczas wdrożenia. Dzieje się miesiąc później.

Gdy okazuje się, że:

• Część danych jest wprowadzana niepoprawnie – bo nikt nie wyjaśnił, dlaczego mają być wprowadzone w określony sposób.
• Proces, który miał być prostszy, zajmuje więcej czasu – bo zabrakło jednego pola albo jednego kroku.
• Ludzie wracają do starych nawyków – bo nowy system „nie pasuje” do tego, jak naprawdę wygląda ich dzień pracy.

Dobry key user przewidział te problemy. I albo zaproponował rozwiązanie jeszcze przed go-live, albo wie, jak szybko zareagować, gdy problem się pojawi.

Zły key user – nawet jeśli zna system na wylot – nie ma pojęcia, co się stało. Bo nigdy nie rozumiał, jak działa firma.

Co to ma wspólnego z analitykiem biznesowym?

Bo to właśnie analityk biznesowy – wewnętrzny albo zewnętrzny – robi dokładnie to samo, co dobry key user. Tylko na większą skalę.

Analityk biznesowy nie projektuje systemu od strony technologicznej. Projektuje go od strony ludzi, którzy będą na nim pracować.

Zadaje pytania:

• Jak ten proces wygląda teraz? Nie „jak powinien wyglądać” – jak faktycznie wygląda?
• Kto jest w niego zaangażowany? Kto wprowadza dane, kto je weryfikuje, kto musi je znać, żeby móc dalej pracować?
• Co się dzieje, gdy coś pójdzie nie tak? Kto to naprawia? Jak długo to trwa?
• Jakie są wąskie gardła? Gdzie ludzie tracą czas? Gdzie popełniają błędy – nie dlatego, że są nieuważni, tylko dlatego, że proces jest źle zaprojektowany?

Analityk biznesowy działa jak key user dla całej firmy. Tłumaczy między strategią a operacjami. Między założeniami zarządu a codzienną pracą zespołów. Między tym, co system potrafi, a tym, czego firma naprawdę potrzebuje.

I – co najważniejsze – wie, kiedy system nie jest rozwiązaniem problemu. Wie, że czasem problem nie leży w technologii, tylko w procesie. Że czasem nie potrzeba nowego CRM-a – tylko jednej rozmowy między działami.

Jak pracuje dobry analityk biznesowy?

Nie zaczyna od funkcji systemu. Zaczyna od mapowania procesów.

Rozmawia z ludźmi, którzy wykonują pracę. Pyta, co robią, dlaczego tak robią, co im przeszkadza. Notuje, gdzie są przerwy, gdzie dane gubią się między działami, gdzie pojawiają się „przeklejki” i „obejścia”.

Potem porównuje to z tym, jak procesy zostały zaprojektowane. I niemal zawsze okazuje się, że różnica jest ogromna.

Dobry analityk nie ocenia ludzi za to, że „nie trzymają się procedur”. Rozumie, że jeśli wszyscy omijają procedurę, to znaczy, że procedura jest zła – nie ludzie.

I wtedy zaczyna projektować rozwiązanie – ale nie od razu systemowe. Czasem wystarczy zmienić kolejność kroków. Czasem wystarczy zdefiniować, kto za co odpowiada. Czasem wystarczy jeden automatyczny mail, który eliminuje godzinę dziennie na „pilnowanie, czy ktoś coś zrobił”.

System pojawia się dopiero wtedy, gdy wiadomo, co ma robić. I jak ma to robić, żeby naprawdę wspierać ludzi, a nie ich blokować.

Dlaczego firmy tego nie robią?

Bo wydaje się to wolniejsze. Droższe. Bardziej skomplikowane.

Przecież można po prostu kupić system, przeszkolić zespół i… ruszyć.

Ale potem okazuje się, że:

• Wdrożenie trwa dwa razy dłużej niż planowano.
• Zespół wraca do starych nawyków po miesiącu.
• System jest używany „na pół gwizdka” – połowa funkcji nigdy nie zostaje włączona, a połowa danych jest wprowadzana niekompletnie.

I wtedy firma płaci dwa razy: raz za system, drugi raz za konsultanta, który ma „naprawić wdrożenie”.

Gdyby od początku ktoś zajął się zrozumieniem, jak firma naprawdę działa, większość tych problemów by nie wystąpiła.

Key user nie musi wszystkiego wiedzieć

To może brzmieć paradoksalnie: dobry key user nie musi znać wszystkich funkcji systemu.

Musi wiedzieć, kogo zapytać, gdy czegoś nie wie. Musi umieć przetłumaczyć problem ludzi na język, który zrozumie dostawca systemu. Musi potrafić ocenić, czy proponowane rozwiązanie naprawdę rozwiąże problem – czy tylko przeniesie go w inne miejsce.

Najlepsi key userzy nie są tymi, którzy najszybciej klikają. Są tymi, którzy zadają najlepsze pytania:

• Czy to naprawdę musimy robić ręcznie?
• Co się stanie, jeśli ktoś zapomni o tym kroku?
• Jak to będzie wyglądać za pół roku, gdy zespół się powiększy?

Te pytania brzmią prosto. Ale zadanie ich we właściwym momencie – przed wdrożeniem, a nie po – oszczędza miesiące pracy i dziesiątki tysięcy złotych.

Co z tego wynika?

Jeśli myślisz o wdrożeniu nowego systemu – nie szukaj key usera, który „zna się na IT”. Szukaj kogoś, kto zna się na firmie.

Kogoś, kto rozumie, gdzie procesy pękają. Kto wie, kto naprawdę wykonuje pracę. Kto przewidzi, co się wydarzy dzień po go-live.

A jeśli myślisz o key userze jak o „super-użytkowniku”, który ma wszystkich nauczyć klikać – przygotuj się na rozczarowanie. Bo system, który nie wspiera ludzi w ich pracy, nie będzie używany. Bez względu na to, jak dobre będzie szkolenie.

Key user to tłumacz. Między firmą a systemem. Między codziennością a technologią. Między tym, co jest, a tym, co mogłoby być.

I to właśnie – ta umiejętność tłumaczenia – decyduje o tym, czy wdrożenie się uda.

Czy w Twojej firmie są osoby, które rozumieją procesy na tyle dobrze, żeby zaprojektować system, który naprawdę będzie działał?