Gdybym wiedział, gdzie się przewrócisz, nie tylko słomę bym podłożył, ale i dywanik rozwinął. Jednak życie i praktyka serwują takie niespodzianki, że nawet doświadczeni specjaliści czasem się mylą. A to może pokrzyżować wdrożenie nowego kompleksu sprzętowo-programowego albo otwarcie call-center. Oto historia oparta na prawdziwych wydarzeniach. Dzięki splotowi okoliczności zakończyła się dobrze. Wdrożenie przebiegło pomyślnie, ale wszystko mogło skończyć się źle. Dla jasności: nie prowadziliśmy tego wdrożenia, ale nie powtarzajcie cudzych błędów.
Artykuł dotyczy narzędzia dla kierownika
Wstęp
W firmie „Romashka” działało własne call-center na 200 stanowisk, które składało się z dwóch części. Umownie nazwijmy je działem sprzedaży i działem obsługi. Dział sprzedaży zajmował się pozyskiwaniem nowych klientów, obsługując połączenia przychodzące i zgłoszenia przez czaty za pomocą chmurowego systemu CRM.
Dział obsługi wspierał obecnych klientów, przetwarzając połączenia za pomocą Asterisk, i prowadził ich ewidencję w autorskim CRM (który, nawiasem mówiąc, jednocześnie korzystał aż z 4 systemów zarządzania bazą danych: MS SQL Server, Oracle, PostgreSQL i MySQL w zestawie, żeby nie było nudno).
A dział IT był odrębną jednostką organizacyjną i nie rozwijał ani nie utrzymywał własnego CRM; pracownicy obsługi sami okresowo go zmieniali — tak „wyszło historycznie”. Firma zajmowała się produkcją i dostawami sprzętu.
Kierownictwo podjęło decyzję o wdrożeniu platformy KC (uruchomienie contact-center w chmurze), aby pomóc kierownikom działów jakoś uporządkować „zoo” systemów informatycznych, w których dane oczywiście były synchronizowane, ale „jakoś nie tak”. Zakładano, że KC przejmie jednolite zarządzanie połączeniami, a systemy CRM — zarządzanie kontaktami; przy czym KC miał pobierać kontakt do obsługi i odsyłać go z powrotem do „właściwego” CRM, czyli mechanizm synchronizacji planowano zrealizować wewnątrz „wnętrzności” contact-center. W zasadzie taki schemat w pewnych warunkach jest możliwy, bo do środka „chmury” działu sprzedaży nie dało się wejść bezpośrednio, tylko przez API.
Trudności przy uruchamianiu call-center i ich rozwiązanie
Trudności przy uruchamianiu call-center pojawiły się od razu. Po wyborze platformy z powodów ideologicznych pojawiło się pytanie o integratora. Sformułowaliśmy wymagania techniczne, zaprosiliśmy cztery firmy o mniej więcej podobnym doświadczeniu, otrzymaliśmy cztery oferty z dużym rozrzutem cenowym — nawet trzykrotnym. Jak zdecydować, komu powierzyć pracę? Wybraliśmy najtańszego dostawcę SIP i, co zaskakujące, trafiliśmy — po prostu okazali się mniej bezwzględni, a jednocześnie mieli wystarczające kwalifikacje. Ale to było szczęście; ocena potencjału integratorów nie została przeprowadzona. A najgorsze w biznesie jest liczenie na szczęście.
Podpisaliśmy umowę i przystąpiliśmy do pracy. I wtedy okazało się, że po stronie zamawiającego odpowiedzialną jednostką wyznaczono IT (która działała w swoim własnym świecie i nic nie wiedziała o wewnętrznym CRM, i nie wiedziałaby, bo dokumentacja po prostu nie istniała). Poszliśmy do działu obsługi, a kierownik wyjaśnił, że zwyczajnie nie ma wystarczającej liczby godzin programistów, aby pomóc w integracji z platformą KC. Po prostu nie ma. Za to jest zatwierdzony plan generalny prac, które oczywiście wszystkie należą do kategorii „ważne-pilne”.
Poszliśmy do kierownika działu sprzedaży. Odpowiedział, że jest „za” obiema rękami, ale nie może kierować wdrożeniem, bo nie jest technikiem, tylko handlowcem, a poza tym ma… własny plan. Natarczywi przedstawiciele integratora, docierając do właściciela biznesu, wywalczyli godziny programistów z IT i działu serwisowego. Kierownikiem wdrożenia po stronie zamawiającego został wyznaczony… słusznie… główny sprzedawca!
Usiedliśmy, by pisać i zatwierdzać specyfikację techniczną. Wtedy ktoś zrozumiał, że stanowiska agentów mogą po prostu nie być kompatybilne z platformą call-center ze względu na wymagania dotyczące systemu operacyjnego. Przeszło… ale mogło nie przejść. Trzeba to sprawdzać na etapie konsultacji przedprojektowych, przed podpisaniem głównej umowy. Błąd popełnił menedżer po stronie integratora; według jego słów na stanowiskach, które widział na własne oczy, OS była taka, jak trzeba. A to, że mogą istnieć stanowiska, których nie widział — to mu umknęło.
Najpierw próbowano połączyć call-center z chmurowym CRM. Z pewnymi zgrzytami połączono to przez API i powstało spięcie… dopóki nie przetestowano go pod rzeczywistym obciążeniem. A tam — liczba zapytań do bazy danych chmury w jednostce czasu okazała się ograniczona, przy czym nigdzie o tym nie wspomniano; po prostu tak było. Ogólnie problem sprowadzał się do tego, że konkretna chmura nie unosi konkretnego call-center. Obliczyli budżet na rozwiązanie pudełkowe — płakali i prawie kupili. Prawie — bo tym razem integrator zadał właściwe pytanie o migrację danych z chmury do pudełka. Okazało się, że na migrację zasobów na pewno nie było i nie będzie. Dzięki kilku zabiegom udało się zmniejszyć liczbę zapytań do chmury. Pudełka nie kupiono.
Nadszedł czas, by połączyć KC z działem serwisu. Oczywiście jedyny programista z działu wsparcia, który mógł pomóc, poszedł na urlop trzy dni przed rozpoczęciem prac. Projekt stanął na dwa tygodnie (koniecznie sprawdzajcie grafiki urlopowe kluczowych specjalistów). Ale kiedy ta osoba wróciła — pracę wykonano.
Pojawiło się pytanie, co zrobić z danymi, które już istniały w obu chmurach, aby doprowadzić je do zgodności. Swoją drogą, istniała tam złożona ścieżka kontaktów zależna od tego, w którym CRM i ze statusem jakim kontakt został znaleziony, więc sprzeczności danych zapewniały klientom świetne doświadczenie, na przykład wiecznych cykli w IVR. Klienci płacili „Romashce” duże pieniądze i byli niezadowoleni, bo przy problemach ze sprzętem zakłócała się u nich ciągłość działania biznesu. Postanowiono istniejące dane „zostawić tak, jak są, i potem wyczyścić”, a dane nowych klientów prowadzić już poprawnie. To się udało, ale problemu oczywiście nie rozwiązało.
Prawie dotrzymując terminów i (z trudem) wymagań technicznych, ale nie specyfikacji technicznej, integrator postawił sobie za cel oddanie pracy. I właśnie wtedy okazało się, że raportowanie KC, w 100% zgodne ze specyfikacją, jest… mało atrakcyjne… nikt go nie lubi. Dlaczego jest brzydkie i jak je przerobić — nikt nie potrafił wyjaśnić; jest podejrzenie, że po prostu nie zostały pieniądze na przeróbkę. W ogóle przez kolejne kilka tygodni zamawiający prowadził z integratorem walkę o estetyczną atrakcyjność raportowania.
Było jeszcze wiele problemów, na przykład pojawiły się wewnętrzne konflikty między kierownikami działów po stronie zamawiającego. Ale — zrobiono. I to działa do dziś.
Wnioski
Morał tej bajki jest bardzo prosty: zakładajcie, że rzeczy mogą być ze sobą niekompatybilne. Albo pod względem parametrów (jak system operacyjny stanowisk agentów i oprogramowanie KC), albo w określonych warunkach (pod obciążeniem i bez niego), albo ze względu na czynnik ludzki. Na papierze wszystko zwykle wygląda dobrze, ale… Zawsze łatwiej powiedzieć niż zrobić.
