HubSpot tai mikä tahansa markkinoinnin ja myynnin järjestelmä on otettu käyttöön. Tiimissä on koodareita, arkkitehteja ja kovan luokan asiantuntijoita, jotka hengittävät IT:tä. Lähtökohdat järjestelmän arvon lunastamiseen ovat niin hyvät kuin olla voi.
Käytännössä käy kuitenkin usein toisin. Sähköpostit eivät tallennu CRM:ään. Liidigenerointityökalu ei itsestään tuota liidejä. LinkedIn-mainonnan tulokset, Googlen mainosten tulokset ja prospektointilista elävät kukin omassa Excelissään. Uusi myyjä oppii prosessin vierestä katsomalla, kun kirjoitettua ohjetta ei ole. Raportteja on kyllä rakennettu, mutta niiden lukuihin ei voi luottaa.
Näen tätä kuviota asiakkaissa jatkuvasti. Paradoksaalista on se, että se toistuu juuri niissä taloissa, joissa tekninen osaaminen on huipputasolla — siis niissä, joissa pitäisi olla parhaat edellytykset hyödyntää systeemejä täysimääräisesti.
Syy ei löydy teknisestä osaamisesta, sitä on enemmän kuin tarpeeksi. Syy on siinä, ettei tekninen käyttöönotto yksin riitä — homma pitää orkestroida osaksi arkea.
Käyttöönotto on vain osa isompaa kokonaisuutta
Tässä on se kohta, jossa huippuosaava tekninen tiimi menee metsään. Käyttöönotto näyttää tekniseltä tehtävältä, ja tekniselle tiimille se onkin helppo juttu. Se on kuitenkin vain pieni pala koko paketista.
Varsinainen duuni liittyy kolmeen asiaan, joita teknisissä spekseissä ei mainita.
Ensimmäinen on käyttäjät. Miksi myyjä jättää tapaamisensa kirjaamatta? Painikkeen paikalla ei yleensä ole asian kanssa mitään tekemistä. Syyt ovat aitoja: hyötyä itselle ei näy, viikko on täynnä kiireellisempää tekemistä, kukaan ei tunnu lukevan raportteja, esimies ei seuraa asiaa. Tämän tyyppiset asiat eivät ratkea koodaamalla, vaan keskustellen, hyötyä näyttäen, kouluttaen ja seuraten.
Tärkeämpi kysymys on itse asiassa se, miksi myyjän ylipäätään pitäisi kirjata mitään käsin. Sähköpostien, tapaamisten ja keskustelujen yhteenvetojen kuuluu tallentua itsestään, ja järjestelmän on annettava myyjälle takaisin jotain hänen omaan arkeensa: muistutus unohtuneesta asiakaskeskustelusta, valmis kärki seuraavaan kontaktiin, coachausvinkki auki olevan diilin klousaamiseen. Jos kirjaaminen on vain velvollisuus, se jää tekemättä — eikä siitä kannata myyjää syyttää.
Toinen on prosessit. Järjestelmästä saadaan irti sen verran kuin prosessi taustalla kestää, ei tippaakaan enempää. Ja prosessi pitää tuntea kahdella tasolla: miten asiat arjessa todella tapahtuvat (ei miten jokin kolme vuotta sitten piirretty kaavio niistä kertoo) ja mihin suuntaan liiketoiminta on menossa. Huonosti ymmärretty prosessi johtaa huonosti palvelevaan järjestelmään.
Kolmas on sisu. Käyttöönotto ei ole kertaluonteinen projekti. Se on pitkä, välillä tylsäkin urakka, jossa viikko toisensa jälkeen joudutaan muistuttamaan, paikkaamaan ja iteroimaan. Ilman sisua suunnitelma hajoaa — tai vielä todennäköisemmin jää suunnitelmaksi eikä koskaan konkretisoidu.
Kun nämä kolme ovat kunnossa, järjestelmä alkaa oikeasti tuottaa. Kun yksikin niistä rakoilee, teknisesti hieno rakennelma jää arkkitehtuurikaavion koristeeksi.
Teknisesti huippuosaava tiimi menee metsään
On helppoa ajatella, että osaava tekninen tiimi hoitaa nämä kolme siinä sivussa — kun kerran vaativin osa sujuu, eihän muu voi olla vaikeaa. Juuri tähän kätkeytyy ansa.
Kun käyttöönotto vaikuttaa tekniseltä projektilta, tekninen tiimi ottaa sen vastuulleen. Koska tiimi osaa asiansa, teknisen puolen tulos on komeaa katseltavaa. Samalla koko käyttöönotto saa kuitenkin teknisen kehyksen, ja käyttäjät, prosessit ja sisu valuvat sivuseikoiksi. Myyjän vastahakoisuus on tässä kuvassa "käyttäjäongelma", jota ei kukaan ratko. Prosessin päivittäminen on "bisnesjuttu", jota odotetaan joltakulta muulta. Ja sisu kuluu uuden automaation rakentamiseen, ei sen seurantaan, tuottaako automaatio sitä mitä piti.
Tekninen pulma on aina kiehtovampi kuin toistuva ylläpito. Uudesta integraatiosta kertoo mielellään kahvipöydässä (tai todennäköisemmin Slackissa); siitä, että myyjille on lähetetty kuudennen kerran muistutus tapaamisten kirjaamisesta, ei kerrota yleensä kenellekään. Ja juuri tiimin parhaat ajautuvat herkimmin muualle, sillä heillä on poikkeuksetta päällä myös tärkeämmiltä tuntuvia töitä. Kun työviikko on ahdettu täyteen tehtäviä, karsiutuu ensimmäisenä se, minkä voi huoletta siirtää huomiseksi ilman välittömiä seurauksia. Rikkoutunut integraatio huomataan samana päivänä. Kolme kuukautta päivittämättä jääneeseen myyntiprosessiin ei havahduta ennen kuin raporttien numeroihin ei enää uskalleta nojata.
Tämä ei ole osaamiskysymys vaan rakenneongelma. Niin kauan kuin käyttäjät, prosessit ja sisu jäävät ilman nimettyä omistajaa, ne jäävät myös ilman tekijää — riippumatta siitä, kuinka taitava tiimi muuten on.
Tämä on kaksiosaisen blogisarjan ensimmäinen osa. Seuraavassa osassa käyn läpi, mitä tämä tarkoittaa johdon kannalta – ja vinkkaan yhden ratkaisevan päätöksen, joka poistaa suurimman osan ongelmista.
