Drogo czy tanio
Zaawansowane systemy CRM czy ERP mają pewną specyfikę – otóż pozwalają na daleko idącą modyfikację pod kątem wymagań klienta. Z jednej strony taka możliwość budzi euforię ’..zrobimy sobie system dla nas!..’, z drugiej jednak warto mieć na uwadze doświadczenia innych firm wdrażających takie systemy, jak również trzeźwo ocenić: z jednej strony spójność systemu dostarczanego przez producenta, z drugiej – realną możliwość uzyskania takiej spójności dla systemu modyfikowanego oraz koszty uzyskania sprawnie działającego, zmodyfikowanego systemu.
Przykład – w hipotetycznym systemie ERP instalacja domyślna pozwala na raportowanie czasu pracy przez pracowników poprzez domyślnie zainstalowany z systemem portal WWW. Pracownik może raportować przepracowany czas tylko na aktywności, które zostały mu przypisane przez Project Managera, i wymaga to oczywiście większego nakładu pracy tegoż Project Managera na zadbanie o przypisanie odpowiednich zadań do odpowiednich osób. To rozwiązanie jest spójne, przetestowane przez dostawcę, nie ma luk z procesie. W przypadku kiedy hipotetyczna firma zechce ten proces zmienić tak, żeby każdy pracownik mógł raportować czas pracy na każdą z aktywności w systemie, uda się osiągnąć pewną wygodę (nie trzeba będzie przypisywać zadań do człowieka, Project Manager będzie miał więcej czasu) z punktu widzenia konkretnego człowieka czy działu, ale okaże się że inny człowiek / dział (tu: księgowość / finanse / PMO) nie maja pojęcia kto na jakiej podstawie raportuje jakie aktywności w jakim projekcie, i czy robi to świadomie czy przez pomyłkę. Mamy więc do czynienia ze zmianą domyślnej konfiguracji systemu przy założeniu że 'ułatwimy życie PM-om’, ale tworzymy w ten sposób luki z punktu widzenia szefa PM-ów czy księgowości – oni tracą informacje o alokacji kosztów i czasu pracy. Firma modyfikująca system jak wyżej ponosi koszty: najpierw na 'ułatwienie życia PM-om’, następnie na uszczelnianie powstałej luki, a na końcu na testowanie spójności całego rozwiązania.
Przykład powyższy jest nieco oderwany od rzeczywistości – ale pokazuje ryzyko związane z wprowadzaniem zbyt swobodnych zmian do wdrażanych systemów. Mając na uwadze powyższe można podzielić sposoby wdrożeń zaawansowanych systemów CRM / ERP na dwa modele:
1) Wdrożenie 'model A’ (jak w przykładzie wyżej), w którym modyfikujemy system tak, żeby dostosować go do bieżącego sposobu działania firmy, lub
2) Wdrożenie 'model B’, w którym staramy się dostosować czy zmienić istniejące procesy w firmie tak, żeby je 'dopasować’ do narzędzia i zminimalizować – bądź wręcz uniknąć – zmiany w systemie.
Wdrożenie 'model A’
To nadal najczęstszy model wdrożenia na rynku. Firmy decydując się na wdrożenie CRM / ERP zakładają, że prawdziwe benefity osiągną tylko poprzez dostosowanie narzędzia do swoich potrzeb. Doświadczenie jednak uczy że im większa firma tym ciężej znaleźć osobę która zna jej procesy od A do Z, wprowadzanie zmian w systemie prędzej czy później napotyka na sytuację w której jeden z interesariuszy chce przeforsować jakąś zmianę (’..bo teraz tak jest..’), a inny zauważa że dana zmiana jest bezcelowa bo (..lista argumentów..).
Powyższe wynika z faktu że – szczególnie w dużych organizacjach – można spotkać procesy nieco absurdalne, a z kolei pracownicy mają skłonność do upraszczania sobie życia i pomijania tychże absurdów. W efekcie możemy trafić na hipotetyczną sytuację w której system w wersji niezmienionej umożliwia wypełnienie i wysłanie informacji o przepracowanych przez pracownika godzinach w dowolnym momencie miesiąca. Pracownik wypełnia Kartę Czasu Pracy, klika 'Wyślij’, karta trafia do HR / Plac i sprawa załatwiona. Z drugiej strony mamy w firmie istniejący proces wg którego pracownicy pobierają od swoich przełożonych papierowe wydruki z projektami, i wpisują na nich ilość godzin – a następnie taką (papierową) kartę dostarczają przełożonemu do weryfikacji. Konflikt jaki się może pojawić sprowadzi się do odpowiedzi na pytanie: pozostawić to co system oferuje 'w standardzie’ (ze świadomością że to raczej standard w firmach), czy też wprowadzić modyfikację tak, aby Karty Czasu Pracy drukował (z systemu) przełożony, nadal je rozdawał (jaki papierowe wydruki) pracownikom, zbierał wypełnione i wysyłał dalej. W sytuacji takiej nie zawsze wygrywa rozsądek i efektywność – czesto do głosu dochodzi ’..ja chcę żeby było tak jak do tej pory / po mojemu..’. Jeżeli firma jest gotowa za takie zmiany zapłacić – dostawca zapewne się zgodzi, pytanie jednak czy takie ’..ja chcę żeby było tak jak do tej pory..’ ma sens, tak finansowo jak i procesowo?..
Wdrożenie 'model B’
Sposobem alternatywnym jest – jakkolwiek niepoprawnie brzmi – dostosowanie w tak wielu obszarach jak to możliwe istniejących procesów i sposobu działania firmy do funkcjonalności systemu. Czemu ma to sens?
– Uporządkowanie istniejących procesów; na ogól procesy przygotowane w firmie n- lat wcześniej podlegają naturalnym zmianom. Jeżeli w dobrą stronę – wszystko jest ok. Kłopot w tym że często ewoluują w stronę złą – przyczyniają się do tego zmiany w strukturze i sposobie działania firmy, za którymi najczęściej procesy nie nadążają. Przykładowo – zakupami zajmowała się osoba, która zmieniła stanowisko i przeszła do sprzedaży. Ponieważ chwilowo nie zatrudniono nikogo na jej poprzednie stanowisko, rola osoby która zajmuje się zakupami spadła na recepcję, ale część osób w firmie z przyzwyczajenia w sprawie zakupów kontaktuje się z poprzednią osobą. W ten sposób proces zakupowy przestaje istnieć, zmienia się, w przeciągu pewnego czasu staje się nieuregulowany – zakupy możemy załatwiać poprzez nową osobę (recepcję), bądź też po znajomości załatwi nam je dawna osoba z tego stanowiska. Dostosowanie takiego procesu do standardu oferowanego przez system spowoduje jego ponowne uregulowanie, w dodatku możemy założyć że to uregulowanie będzie wynikało z istniejących dobrych praktyk w danym zakresie, które to dobre praktyki przełożyły się na konkretny proces w systemie przygotowanym przez dostawce (standardowym).
Wdrożenie systemu może sprawić że: (a) zdeformowany proces trafi w ramy standardowych procesów w systemie i zostanie w ten sposób 'naprawiony’, lub (b) możemy tenże zdeformowany proces oprogramować w nowym systemie tak, aby w nowym systemie działał dokładnie tak jak przed jego wdrożeniem. Do osoby zarządzającej wdrożeniem należy znalezienie odpowiedzi na pytanie co jest właściwsze.
– Koszty; dostosowanie procesów działających w firmie do tego co oferuje system powoduje zminimalizowanie prac w trakcie wdrożenia (zwłaszcza programistycznych). Koszty wdrożenia spadają wtedy znacząco – nie musząc przygotowywać zmian programistycznych nie trzeba tez robić analizy biznesowej pokazującej ich działanie, nie trzeba się zastanawiać jak wprowadzane zmiany wpłyną na inne komponenty systemu, łatwiej jest utrzymać jego spójność.
– Utrzymanie systemu jak najbliżej jego domyślnej wersji oznacza łatwość (i taniość) robienia jego uaktualnień. Jest także ogromnym ułatwieniem przy ewentualnej zmianie wersji systemu na nowszą, czy wręcz inną. Standardowe funkcjonalności różnych systemów CRM / ERP są do siebie zbliżone, w efekcie utrzymanie systemu jak najbardziej zbliżonego do jego standardowej wersji zawsze będzie oznaczało łatwiejszą jego ewentualną zmianę na produkt innego dostawcy – unikamy w ten sposób przywiązania do jednego dostawcy na szereg lat.
Uproszczone porównanie obu modeli
Koszta wdrożenia są różne w zależności od firmy wdrażającej, ilości osób, czasu czy wreszcie miejsca wdrożenia – w efekcie ciężko operować kwotami. Z drugiej strony szacunkowa ilość czasu niezbędna na poszczególne etapy wdrożenia jest (procentowo) dla każdego wdrożenia podobna. Porównanie obu modeli wdrożenia (’model A’ i 'model B’) mogą Państwo podejrzeć tutaj.