Dlaczego firmy kupują systemy, których później nie wykorzystują?

Kiedy system jest, ale nikt z niego nie korzysta

Jeden z częściej powtarzających się obrazów w firmach średniej wielkości wygląda tak: dział IT raportuje, że system działa, dostawca potwierdza, że wdrożenie zostało zakończone, a jednocześnie dyrektor sprzedaży prowadzi swoją własną ewidencję szans sprzedażowych w Excelu, bo „w CRM-ie nie ma tego, co potrzebne”. Formalnie projekt się udał. Biznesowo – nie zmienił niczego.

Niewykorzystane systemy to jeden z tych kosztów, które rzadko trafiają na agendę zarządu, bo są rozproszone. Licencje idą w koszty operacyjne, czas ludzi w wynagrodzenia, utracone decyzje w ogóle nie są mierzone. Dopiero gdy zsumować abonamenty, roczne wsparcie, godziny pracy poświęcone na podwójne wprowadzanie danych i opóźnienia w raportowaniu, pojawia się kwota, która potrafi zaskoczyć.

Warto od razu odrzucić najprostsze wyjaśnienie. To zwykle nie jest kwestia „złego wyboru narzędzia” ani „oporu pracowników przed zmianą”. Z naszych doświadczeń wynika, że przyczyny są bardziej systemowe i pojawiają się na długo przed wdrożeniem.

Zakup zamiast decyzji o zmianie

Najczęstszy mechanizm jest taki: firma rozpoznaje problem – brak przewidywalności sprzedaży, chaos w zamówieniach, brak danych do zarządzania marżą – i przechodzi bezpośrednio do wyboru narzędzia. Pomiędzy rozpoznaniem problemu a zapytaniem ofertowym nie pojawia się etap, w którym ktoś opisuje, jak firma ma działać inaczej po wdrożeniu.

To różnica fundamentalna. System nie zmienia sposobu pracy. On go utrwala. Jeżeli proces sprzedaży nie jest zdefiniowany, CRM nie zdefiniuje go za organizację – jedynie odwzoruje istniejący bałagan, dodając do niego obowiązek wypełniania pól. Jeżeli nie ma zgody co do tego, jak liczy się rentowność zlecenia, system BI wygeneruje kilka wersji prawdy zamiast jednej.

Stąd bierze się zjawisko, które w praktyce widać najczęściej: system jest formalnie używany, ale tylko w tej części, która nie wymagała zmiany zachowań. Dane podstawowe wprowadzone, faktury wystawiane, resztę funkcjonalności pominięto.

Kto naprawdę jest właścicielem wdrożenia

Drugą przyczyną jest umiejscowienie odpowiedzialności. W wielu firmach projekt technologiczny trafia do IT, bo dotyczy oprogramowania. IT odpowiada wtedy za działanie systemu, integracje i bezpieczeństwo – i te zadania zwykle realizuje dobrze. Nikt natomiast nie odpowiada za to, czy sprzedaż faktycznie prognozuje lepiej, a operacje skróciły czas realizacji zamówienia.

Gdy nie ma właściciela biznesowego – dyrektora sprzedaży, operacji czy finansów, który ma w celach nie „wdrożenie systemu”, ale konkretny wynik – projekt kończy się w momencie uruchomienia. A to jest moment, w którym praca nad zmianą dopiero się zaczyna.

Pomocne bywa proste rozróżnienie:

- Cel projektowy: wdrożyć system w terminie i budżecie. - Cel biznesowy: skrócić cykl sprzedaży, zwiększyć konwersję, obniżyć poziom zapasów, uwolnić czas menedżerów z raportowania.

Jeżeli w dokumentacji projektu istnieje tylko pierwszy, można z dużym prawdopodobieństwem założyć, że po roku system będzie wykorzystywany częściowo.

Nadmiar funkcjonalności jako źródło porażki

Paradoksalnie im bogatszy system, tym większe ryzyko, że pozostanie niewykorzystany. Podczas wyboru dostawcy porównuje się listy funkcji, a przewagę uzyskuje ten, kto ma ich więcej. Później okazuje się, że organizacja nie jest dojrzała do korzystania z 80% z nich – nie ma danych, kompetencji ani procesów, które te funkcje obsługują.

W praktyce lepiej sprawdza się podejście odwrotne: zdefiniować kilka procesów, które mają realnie zmienić wynik, wdrożyć je porządnie, a rozbudowę zaplanować jako kolejne etapy powiązane z gotowością organizacji. Wdrożenie „wszystkiego naraz” najczęściej kończy się tym, że ludzie wracają do narzędzi, które znają.

Sygnały, że system nie pracuje na wynik

Kilka obserwacji, które warto sprawdzić w swojej firmie:

- równolegle do systemu funkcjonują arkusze kalkulacyjne, na których opierają się decyzje, - raporty zarządcze są przygotowywane ręcznie, mimo dostępnego modułu raportowego, - dane w systemie są niekompletne lub nieaktualne, a nikt nie odpowiada za ich jakość, - pracownicy wprowadzają te same informacje w dwóch miejscach, - kluczowe informacje o klientach nadal znajdują się w głowach lub skrzynkach mailowych handlowców, - po zmianie osoby na stanowisku część wiedzy o procesie znika.

Ostatni punkt ma bezpośredni wpływ na wartość przedsiębiorstwa. Firma, w której procesy są zapisane w systemach, a nie w ludziach, jest mniej ryzykowna, łatwiej skalowalna i inaczej wyceniana.

Jak diagnozować, zanim się kupi

Zanim pojawi się rozmowa z dostawcami, warto odpowiedzieć na kilka pytań. Brzmią prosto, ale w praktyce właśnie one decydują o powodzeniu:

1. Jaki konkretny wynik biznesowy ma się zmienić i jak go zmierzymy przed i po? 2. Które procesy muszą zostać zmienione, żeby ten wynik był możliwy – i czy są opisane? 3. Kto z zarządu lub kadry dyrektorskiej odpowiada za efekt, a nie za wdrożenie? 4. Jakie kompetencje trzeba zbudować, żeby system był używany zgodnie z założeniem? 5. Co przestaniemy robić po wdrożeniu? Jeżeli nic – zmiana nie nastąpi. 6. Jak będzie wyglądał sposób pracy menedżerów po sześciu miesiącach?

Pytanie piąte jest najczęściej pomijane, a bywa najbardziej diagnostyczne. Technologia, która wyłącznie dodaje pracę, a niczego nie zabiera, spotka się z cichym bojkotem – i będzie to reakcja racjonalna, nie oporowa.

Transformacja cyfrowa nie zaczyna się od systemu

Większość nieudanych wdrożeń nie jest problemem technologicznym, lecz problemem zarządzania zmianą, procesami i kompetencjami. Dlatego sensowna kolejność wygląda inaczej niż w typowym projekcie zakupowym: najpierw diagnoza tego, gdzie faktycznie tracone są pieniądze i czas, potem projekt docelowego sposobu pracy, następnie wybór narzędzia, które ten sposób pracy wspiera, a na końcu wdrożenie połączone z pracą z ludźmi i pomiarem efektów.

Taka kolejność bywa mniej efektowna i wymaga więcej pracy na początku. Zwykle jednak kosztuje mniej niż drugie wdrożenie tego samego systemu po dwóch latach.

W projektach, w których wspieramy firmy, punktem wyjścia jest zazwyczaj nie technologia, a odpowiedź na pytanie, co w organizacji musi działać inaczej, żeby wynik się zmienił. Dopiero wtedy widać, czy potrzebny jest nowy system, lepsze wykorzystanie istniejącego, czy uporządkowanie procesów i sposobu zarządzania – i w jakiej kolejności to robić.

Jeżeli w Twojej firmie działają systemy, które miały zmienić sposób pracy, a nie zmieniły, warto sprawdzić, gdzie zatrzymała się ta zmiana. Zwykle nie w oprogramowaniu.