Miksi uuden CRM:n tai ERP:n siirto on vaikeampaa kuin miltä se näyttää — ja mikä todella saa sen toimimaan

On olemassa CRM- tai ERP-siirron tarinan versio, joka sujuu hyvin. Yritys päättää vaihtaa, vie tietonsa, karttaa kentät, suorittaa validoinnin, ratkaisee ongelmat ja siirtyy tuotantoon kiinteänä päivänä. Tiimi on koulutettu. Vanha järjestelmä poistetaan käytöstä. Muutaman viikon kuluttua uusi järjestelmä on muuttunut toimintaympäristöksi, eikä kukaan kaipa vanhaa.

Tämä versio on olemassa, mutta se ei ole tyypillinen. Useammin siirto kestää kaksi-kolme kertaa suunniteltua pidempään, siihen liittyy merkittäviä tietolaatuongelmia, ja se johtaa järjestelmään, jota tiimin merkittävä osa hiljaisesti jatkaa kiertämään. Ymmärtääksesi miksi ja mikä onnistuneessa versiossa on yhteistä, täytyy ensin tunnistaa, että suurin osa riskistä ei liity teknologiaan.

Viivästysongelma: Liian pitkä pysyminen siitä, mikä toimii riittävän hyvin

Yritykset, jotka ovat kasvaneet nykyisen järjestelmänsä ulkopuolelle, harvoin vaihtavat heti, kun ne huomaavat sen. Ne vaihtavat kuukausien tai vuosien jälkeen kertyneiden kiertotapojen jälkeen: lisätaulukot, jotka täyttävät aukot, sähköpostiketjut, jotka kuljettavat tietoa, jonka järjestelmä ei voi käsitellä, sekä manuaalinen kaksinkertainen syöttö työkalujen välillä, joita ei alun perin ole suunniteltu kommunikoimaan keskenään. Viivästys on yksilöllisesti rationaalinen — vaihto on häiritsevää ja kiertotavat toimivat riittävän hyvin viikon läpikäymiseksi — mutta se vahvistaa perusongelmaa.

Jokaisena kuukautena, kun yritys käyttää järjestelmää, jota se on ylittänyt, data kertyy muotoihin, jotka eivät vastaa sitä, minne sen pitäisi mennä. Käytännöt muuttuvat enemmän implisiittisiksi. Lisää työnkulkuja uppoutuu nykyisen järjestelmän rajoitusten ympärille. Kun siirto päätetään viimein, ongelma on huomattavasti suurempi kuin se olisi ollut ensimmäisellä selvällä ylityksen hetkellä.

Tämä näkyy erityisesti siirryttäessä taulukoista strukturoituun järjestelmään. Mikä alkoi yhtenä pääasiakaslistana, on muuttunut viidentoista version joukoksi, jota eri henkilöt eri osastoissa ylläpitävät, ja jossa on epäjohdonmukaiset sarakeotsikot, erilaiset suhteiden seurannan käytännöt ja vaihteleva täydellisyystaso. Siirron tekemiseen vaadittava työ riippuu osittain siitä, kuinka kauan siirtoa on viivästetty — ja taulukkopohjaisissa yrityksissä viive on lähes aina pidempi kuin sen pitäisi olla.

'Puhdas data ensin' -ansu

Luotettavin siirtoa viivästyttävä uskomus on, että datan tulee olla puhdas ennen siirron aloittamista. Perustelu on ymmärrettävä: kukaan ei halua tuoda sotkua uuteen järjestelmään ja joutua käsittelemään seurauksia. Käytännössä 'puhdas data ensin' muuttuu projektiksi, joka ei pääty.

Datan puhdistustyö vie odotettua enemmän aikaa. Reunatapaukset lisääntyvät. Ihmiset havaitsevat epäjohdonmukaisuuksia, joista he eivät tienneet. Vanhaan järjestelmään luodaan puhdistusjakson aikana uusia tietueita, jotka myös vaativat puhdistusta. Päätökset siitä, mikä lasketaan kaksoiskappaleeksi, mitä tehdä yhteyshenkilöille, jotka eivät ole olleet aktiivisia kolmeen vuoteen, ja miten käsitellä tietueita, jotka ovat yhdessä järjestelmässä mutta eivät toisessa, muuttuvat kiistellyiksi organisaatiokysymyksiksi teknisten tehtävien sijaan. Kun data todetaan valmiiksi, on kulunut kuukausia ja uuden järjestelmän käyttöönotto on menettänyt vauhtinsa ja usein myös projektin omistajan.

Siirtoa varten aidosti puhtaiksi tarvittavat tietueet ovat aktiiviset. Kahden vuoden aikana ei aktiivisia ollut historialliset yhteyshenkilöt, korvatut tuotteet, kolme vuotta vanhat suljetut kaupat — nämä voidaan siirtää sellaisinaan, arkistoida tai jättää kokonaan huomiotta. Yritys voi toimia täydellisen hyvin uudella järjestelmällä, jossa on puhtaat aktiiviset tietueet ja pysäköity arkisto historiallisesta datasta, jota kukaan ei säännöllisesti konsultoi.

Mitä oikeasti tulee siirtää — ja mitä ei

Yksi siirron vastakäytännöllisimmistä vaistoista on halu siirtää kaikki. Jos läpikäyt siirron aiheuttamaa häiriötä, sinun tulisi siirtää kaikki tietueet, koko historia ja kaikki liitetiedostot — ja mieluiten jälleenrakentaa kaikki raportit ja automatisoidut työnkulut, joita edellisessä järjestelmässä oli, uudessa järjestelmässä. Tämä maksimoida siirron laajuuden, kustannukset ja keston ilman, että saatu hyöty kasvaa suhteellisesti.

Useimmat kaksi–kolme vuotta vanhemmat historialliset tiedot eivät ole tavallisessa käytössä. Perinteisten raporttien jälleenrakentaminen, jotka eivät enää palvele nykyisiä liiketoimintapäätöksiä, lisää aikaa ilman arvon lisäystä. Aiempaan työnkulkuun rakennetut mukautetut automaatiot heijastavat usein sitä, miten yritys toimi aiemmin, eivätkä sitä, miten se toimii nyt — niiden uskollinen jälleenrakentaminen toistaa rajoituksia, jotka olisi voitu poistaa.

Parempi kysymys ei ole 'mitä vanhassa järjestelmässä on?', vaan 'mitä tiimin täytyy tehdä työnsä aloittaakseen uudessa järjestelmässä?' Vastaus on tyypillisesti: aktiiviset yhteyshenkilöt ja asiakkaat, avoimet kaupat ja mahdollisuudet, nykyinen hinnoittelu ja tuotetiedot sekä riittävä historia keskustellakseen merkittävästi asiakkaan kanssa, joka soittaa kysymyksen kanssa. Tämä on yleensä vain osa siitä, mitä vanhassa järjestelmässä on — ja osan siirtäminen on nopeampaa, vähemmän riskialtista ja helpompaa vahvistaa kuin koko tiedon siirtäminen.

Kaksi siirron epäonnistumistyyppiä: tekninen ja inhimillinen

Tekninen siirron epäonnistuminen on se, josta keskustellaan eniten. Virheelliset tietueet, kenttien kartoitusvirheet, jotka sijoittavat puhelinnumeron yritysosoitekenttään, tietueiden väliset suhteet, jotka rikkoutuvat koska vierasavaimen rakenne eroaa järjestelmien välillä, integraatiot, jotka toimivat vanhaa API:ta vastaan mutta joilla ei ole vastaavaa uutta API:ta vastaan. Nämä epäonnistumiset ovat todellisia ja tapahtuvat, erityisesti siirroissa järjestelmistä, joilla on omaleimaiset tietomallit tai taulukoista, joiden rakenne on epäjohdonmukainen ja käytännöt ovat oletettuja eikä pakotettuja.

Inhimillinen siirron epäonnistuminen on vähemmän näkyvää ja yleisempää. Se tapahtuu, kun tekninen siirto onnistuu täysin — data on uudessa järjestelmässä, kentät on kartattu oikein, validoinnit läpäisty — mutta ihmiset eivät käytä sitä. He kirjautuvat sisään ajoittain täyttääkseen esimiehen pyynnön. He pitävät oikeat tietueensa muualla. He löytävät syitä, miksi heidän erityinen tilanteensa ei oikein sovi uuden järjestelmän työnkulkuun, mikä on eri asia kuin väite 'uusi järjestelmä puuttuu ominaisuudesta' — se tarkoittaa, että järjestelmällä on ominaisuus, mutta se toimii eri tavalla kuin he odottivat, ja uuden työnkulun kitka ylittää muuttamisen motivaation.

Rinnakkainen käyttö -ansu

Standardi siirron neuvonta on ajaa vanha ja uusi järjestelmä rinnakkain, kunnes luottamus uuteen on saavutettu. Periaatteessa tämä vähentää riskiä: jos uusi järjestelmä epäonnistuu tai tuottaa epäluotettavaa dataa, vanha järjestelmä jää saataville. Käytännössä rinnakkainen käyttö on yksi luotettavimmista epäonnistuneen siirron ennustajista.

Kun ihmiset voivat päivittää kumpaa tahansa järjestelmää, he eivät päivity kumpaakaan johdonmukaisesti. Data eroaa päivissä. Uusi järjestelmä näyttää yhden avoimen kaupan summan; vanha näyttää eri summan. Asiakkaan tietue uudessa järjestelmässä osoittaa viimeisen yhteydenoton kahden viikon takaa; vanha järjestelmä näyttää eilen tehdyn puhelun, joka on kirjattu sinne tapana. Päätös, joka perustuu uuteen järjestelmään, eroaa samasta päätöksestä, joka perustuu vanhaan järjestelmään. Tiimi menettää luottamuksen kumpaankaan, koska kumpikaan ei ole auktoritiivinen — mikä on päinvastainen kuin mitä siirron piti tuottaa.

Organisaatiot, jotka siirtyvät onnistuneesti, tekevät sen tyypillisesti kovaa katkosta: tietty päivä, jonka jälkeen vanha järjestelmä on vain luku- tai käyttökelvoton, ja uusi järjestelmä on ainoa vaihtoehto. Tämä poistaa turvaverkon ja korvaa sen kiireellä. Jos uudessa järjestelmässä on ongelmia, ne ratkeavat, koska vaihtoehtoa ei ole. Säätöön liittyvä epämukavuus etukäteen ladataan ja ratkaistaan. Rinnakkainen käyttö jakaa epämukavuuden kuukausille ilman, että se koskaan ratkaisee grunderoottista kysymystä, kumpi järjestelmä on todellinen.

Excel-pakoaukko

Yrityksille, jotka siirtyvät taulukoista eivätkä toisesta strukturoidusta järjestelmästä, on olemassa vikaantumistapa, joka ei koske järjestelmästä-järjestelmään siirtoja: Excel-pakoaukko. Koska kaikki jo osaavat käyttää taulukkoa, ja koska taulukot ovat todella kykeneviä tiettyihin tehtäviin — ad hoc -analyysi, joustava asettelu, ei sisäänkirjautumista, ei käyttöoikeusmallia — ihmiset, jotka pitävät uutta järjestelmää vieraina, palaavat niihin välittömästi. Ei sen vuoksi, että uusi järjestelmä puutuisi kyvystä. Koska mentaalimalli ja lihasmuisti ovat jo olemassa, ja sen työnkulun uudelleenoppimisen kitkakustannus, jonka he jo osaavat, on todellinen vaikka lopputulos olisi sama.

Excel-pakoaukko on erityisen vaikea sulkea, koska taulukoilla on laillisia käyttötarkoituksia. Et halua estää ihmisiä mallintamasta skenaarioita Excelissä tai rakentamasta ad hoc -pivot-taulukoita. Mitä haluat estää, on taulukon käyttö ensisijaisena tietueena aktiivisille asiakkaille, avoimille kaupoille, varastotasolle tai mille tahansa muulle, mitä uusi järjestelmä olettaa omistavansa. Raja on usein epäselvä, ja ilman selkeää täytäntöönpanopolitiikkaa siitä, mitä järjestelmässä saa olla versus mitä henkilökohtaisessa taulukossa saa olla, järjestelmä vähitellen tyhjenee, kun ihmiset huomaavat henkilökohtaiset versionsa nopeammin ylläpidettäviksi. Uusi järjestelmä muuttuu raportointitasoksi käyttöympäristön sijasta — mikä on sama dynamiikka, joka saa CRM:n käyttöönoton epäonnistumaan, vain eri suunnasta lähestyttynä.

Mitä hyvä käyttöönotto todella näyttää

Onnistuneet käyttöönotot jakavat usein ominaisuuksia, jotka eivät riipu valitusta alustasta.

Ensimmäinen on nimetty liiketoiminnan omistaja siirrolle — ei IT-johtaja, jonka tehtävä on suorittaa tekninen projekti, vaan liiketoiminnan henkilö, jonka tehtävä on varmistaa käyttöönotto. Tämä henkilö määrittelee, mitä dataa on merkitystä, päättää, mitä siirretään ja missä tilassa, asettaa ja toteuttaa katkospäivän sekä käsittelee tilanteita, joissa osasto haluaa jatkaa vanhan järjestelmän käyttöä tai omaa taulukkoaan. Ilman tätä henkilöä siirto on tekninen projekti eikä toiminnallinen muutos, ja tekniset projektit ilman toiminnallista vastuuta jäävät luotettavasti alle odotusten.

Toinen on toimiva järjestelmä kiinteänä päivänä vaiheittaisen käyttöönoton sijaan, joka venyy. Kun uusi järjestelmä käynnistyy keskeneräisessä tilassa — joitakin ominaisuuksia on saatavilla, muita tulee myöhemmin, joitakin integraatioita ei ole vielä valmis — ihmiset kiertävät aukkoja vanhoilla työkaluilla. Tapa kiertää uuden järjestelmän aukkoja vakiintuu ennen kuin järjestelmä on täysin toimiva, ja se jatkuu aukkojen sulkemisen jälkeen. On huomattavasti helpompaa ottaa käyttöön täydellinen järjestelmä selkeänä päivänä kuin vähitellen ottaa käyttöön keskeneräinen useiden kuukausien aikana.

Kolmas on tuontiprosessin käsitteleminen tietolaadun vaiheena eikä porttina sen edellä. Parhaat käyttöönoton työkalut näyttävät, miten tietosi on kartattu uuden järjestelmän rakenteeseen ennen kuin mitään vahvistetaan, korostavat tietueet ja kentät, jotka rikkovat kohdemallia, antavat mahdollisuuden ratkaista tai ohittaa jokainen ongelma ja säilyttävät peruutusmahdollisuuden kohtuullisen ajan vahvistuksen jälkeen. Yritys ei tarvitse puhdasta dataa tähän prosessiin sisäänmennessä — sen sijaan se tarvitsee prosessin, joka tekee datasta puhdasta tulossa ulos.

Alustan kysymys siirron aikana

Siirrot ovat käänteitä. Yritys, joka on päättänyt siirtyä Excelistä tai ensimmäisen sukupolven CRM:stä, on sillä hetkellä enemmän huomiota omille tiedoilleen ja enemmän organisatorista lupaa uudelleenjärjestellä tietojen tallentamista ja käyttöä kuin se tulee olemaan missään vaiheessa seuraavaan siirtoon asti. Kysymys siitä, mihin siirtää, ei ole pelkkä ominaisuusvertailu — se on rakenteellinen päätös siitä, pitäisikö hajautuneisuutta käsitellä samanaikaisesti alustojen siirron kanssa vai lykätä se jälleen.

Yritys, joka siirtää CRM-tietonsa alustalle, jossa samat tietueet ovat myös saatavilla laskutukselle, varastonhallinnalle, varausjärjestelmälle ja asiakaspalvelulle, on tehnyt integrointityön kerran ja poistanut jatkuvan kustannuksen erillisten järjestelmien synkronoinnissa. Yritys, joka siirtää CRM:n uuteen itsenäiseen CRM-alustaan ja pitää kirjanpidon, varaston ja asiakaspalvelun erillisinä järjestelminä, lykkää integrointityön ja jatkaa integraation ylläpitokustannusten maksamista määräämättömän ajan — insinöörityönä, yhteen sovituspyrkimyksenä ja päätösten laaduna epätäydellisillä tiedoilla.

Useimmille yrityksille siirtopisteessä integroitu lähestymistapa on parempi pitkäaikainen päätös, vaikka se tekee siirron itsestään monimutkaisemmaksi. Kahdesta tai kolmesta järjestelmästä yksiin alustaan siirtämisen kompleksisuus yhdellä hetkellä on rajoitettu ja tilapäinen. Kahden tai kolmen järjestelmän ylläpitäminen piste-integrointien kautta on rajoittamaton ja pysyvä. Siirrot ovat tilanteita, joissa tämä valinta tehdään — ja ne ovat helpompia tehdä, kun organisaatio on jo valmis muuttamaan toimintaansa kuin missään muussa ajankohdassa.

---