Kunnianhimoiselle asiakkuudenhallinnan kehitysprojektille (”CRM-projektille”) asetettu aikataulu venyy ja paukkuu, ja ratkaisutoimittajan lisätyölaskut aiheuttavat pahenevaa ohimosuonien tykytystä projektista vastuussa olevan johtajan ohimoilla. Kuulostaako tutulta? Konsultin näkökulmasta kuulostaa perinteiseltä kehitysprojektilta. Ongelma ei rajaudu CRM-projekteihin vaan koskettaa käytännössä kaikkea operatiivisten tukijärjestelmien kehitystä.

Liiketoiminnan kehitysprojekteissa, ja varsinkin silloin kun IT-ratkaisut liittyvät olennaisesti tuohon kehitykseen, on aikataulujen ja kustannusten ylittyminen lähes arkipäiväistä huvia. Miksi me muuten niin viisaat ihmiset sorrumme samoihin virheisiin aina uudestaan? Seuraavassa muutama mahdollinen syy.

Syy 1: Vahva usko ymmärrykseen omista tarpeista

Jokainen CRM-projekti käynnistyy visiosta – haavekuvasta siitä, millainen tulevaisuuden on oltava. Tänä päivänä käytännössä jokainen CRM-visio on linkitetty yrityksen strategiaan ja tavoitteisiin, ja niin pitääkin olla. Jos visiona on hankkia väline, on projekti hävitty jo ennen kuin se alkoikaan.

Voimakkaaseen visioon liittyy usein vielä voimakkaampi näkemys tarpeiden käytännön toteutuksesta. Mitä useampia laajasti räätälöityjä toimintoja ollaan kehittämässä, sitä suuremmalla riskillä projektissa kuitenkin liikutaan. Onko todennäköistä, että esimerkiksi monimutkaista asiakaspalautejärjestelmää rakennettaessa osataan aidosti ennustaa kaikki käyttöskenariot ja käyttäjätarpeet ennen kuin ensimmäistäkään käyttöminuuttia on järjestelmällä takana?

Syy 2: Projektien kestot

Projektit, joissa aiotaan saada paljon aikaan, tapaavat myös kestää jonkin aikaa. Mitä enemmän räätälöityjä toiminnallisuuksia tai liittymiä muihin järjestelmiin toteutetaan, sitä enemmän tarvitaan työaikaa. Ei ole harvinaista, että laajan CRM-ratkaisun kehitykseen ja käyttöönottoon varataan vuosi tai puolitoista aikaa.

Silloin ennen, kun talvet olivat lumisia, lapset hyväkäytöksisiä ja työpaikalla ei ollut aina jatkuva kiire, tapasi bisneskin olla suht’ vakaata. Jos myytiin vaikkapa laivoja, niin niitä rakenneltiin totuttuun tapaan kuivatelakalla lohkoista, eikä siinä sen enempiä hötkyilty uusien liiketoimintamallien kanssa. Nykyään kaikki on toisin. Puhutaan muka-leikillisesti kevät- ja syysorganisaatioista, kvartterin loppu on aina nurkan takana ja seurantajaksona olevan kuukauden loppuun on keskimäärin aikaa 15 päivää. Strategioita tulee ja menee, ja tänä päivänä yrityksiä ja niiden johtajiakin tuntuu tulevan ja menevän.

Onko enää realistista luottaa pystyvänsä ennustamaan tilannetta vuoden tai puolentoista päästä, jos ensi kuun tavoitteetkin ovat vielä kaukaisia?

Syy 3: Kehitysmenetelmien heikko tuntemus

Jos haastateltaisiin sataa satunnaista esimiestä sellaisista organisaatioista, joissa ei tehdä mitään ohjelmistokehitykseen liittyvää, luultavasti 90 heistä antaisi samankaltaisen vastauksen kysymykseen, ”miten mielestäsi tietojärjestelmien tukema liiketoiminnan kehitysprojekti pitäisi toteuttaa?”

Vastaajat todennäköisesti kertoisivat, että ensin pitää asettaa tavoitteet ja kuvata prosessit. Saatujen aineistojen pohjalta tehdään vaatimusmäärittely, jonka toimittaja toteuttaa ratkaisuksi. Lopuksi testataan, viilataan ja jalkautetaan. Fiksummat muistaisivat lisätä, että eihän nämä mitään softaprojekteja ole, ja oikein fiksut saattaisivat muistaa sanoa ”ketterästi”, vaikka eivät olekaan täysin varmoja, mistä siinä oikein on kyse.

Useimmat kehitysprojektit ostetaan sillä kehitysmenetelmällä, minkä ratkaisutoimittaja tuo tullessaan. Monet toimittajat vielä tänäkin päivänä käyttävät perinteistä vesiputousmallia, jossa projektin vaiheet (esim. tavoitteet –> vaatimukset –> määrittely –> toteutus –> testaus –> käyttöönotto) seuraavat toistaan, ja jokainen vaihe toteutetaan täydellisenä ennen etenemistä seuraavaan vaiheeseen. Pienenä turvaverkkona projektissa saattaa olla ositus kahteen tai kolmeen osaan, jotta kaikki munat eivät olisi samassa korissa.

Jos asiakas ei tunne muita menetelmiä riittävällä tarkkuudella eikä omaa kokemusta niistä, miten hän pystyisikään haastamaan toimittajaa ja ehdottamaan muita malleja.

Syy-yhteenveto

Liiketoiminnan kehitystä tekevät siis näkemykselliset, vahvatahtoiset ja osaavat ihmiset. Poikkeuksetta heillä on hyvä tarkoitus ja luottamus siihen, että he eivät sorru tavanomaisiin virheisiin.

CRM-projektien yksi ikiaikaisista ongelmista on, että niitä ei haluta uskoa tietojärjestelmäprojekteiksi. ”Ei tämä ole mikään järjestelmäprojekti, tämä on liiketoiminnan kehitystä!” kuuluu jo vertynyt lausahdus. Totta sekin. CRM-projektissa on ensisijaisesti kyse liiketoiminnan kehityksestä, ja välineiden kuuluukin olla enemmän tai vähemmän sivuseikka. Käytännössä kuitenkin, kun tehdään johonkin järjestelmään mittavia toiminnallisia, rakenteellisia tai liittymällisiä räätälöintejä, on pakosti kyse myös ohjelmistoprojektista – haluttiin sitä tai ei.

Ohjelmistoprojektissa on huomioitava ohjelmistojen kehitykseen liittyvät reunaehdot ja sopimustekniset näkökulmat. ”Hyväksyntä”, ”muutos” ja ”lisätyö” ovat varmasti tulleet useimmille tutuiksi käytännön kautta.

Seuraavassa esitän pari ratkaisumahdollisuutta tälle ongelmavyyhdille.

Ratkaisu 1: Ei räätälöidä lainkaan

Helpoin vaihtoehto välttää ohjelmistoprojektiin joutuminen ja siihen liittyvät kehitysriski on jättää kaikki räätälöinti ja muu kehitys tekemättä. CRM-projektin tapauksessa etsitään siis mahdollisimman kattavat toiminnot omaava CRM-järjestelmä ja otetaan se käyttöön sellaisenaan. Siis ihan sellaisenaan. Eli on luovuttava unelmasta aika-akselilla taivutetusta ristiintaulukoidusta myyntisuppilosta – ellei järjestelmässä ole sellaista valmiina.

Monelle räätälöinnin tekemättä jättäminen on vaikea päätös, sillä räätälöintitarpeet useimmiten kumpuavat pitkäaikaisista visioista ja unelmista.

Vuosien varrelta tulee mieleen yksi projekti, jossa alkuun ei räätälöity yhtään mitään. Asiakas otti valmisohjelmiston käyttöön juuri sellaisena kuin se oli, ilman yhtään lisättyä pilliä tai kelloa. Käyttöönotossa oli mukana toistakymmentä maata, ja pitkälle päästiin, ennen kuin oli pakko lisätä jotain toiminnallisuutta. Projektina tuo käyttöönotto oli palkitseva: keskityimme olennaiseen, eli organisaation toiminnan siltaamiseen CRM-järjestelmän kanssa ja käyttöosaamisen varmistamiseen. Asiakaskin oli tyytyväinen.

Ei räätälöintikiellossa tarvitse ikuisesti olla. Kun peruskäyttö on solidifioitu koko organisaatiossa, voidaan jalkauttaa kaikenlaista räätälöityä toiminnallisuutta. Räätälöintien määrittelyssäkin ollaan viisaampia, kun ymmärretään se konteksti, johon räätälöinnit asettuvat.

Ratkaisu 2a: Tunnustetaan oma rajallisuus

Meille konsulteille oman rajallisuuden tunnustaminen on usein mahdoton tehtävä. Konsultin on osattava kaikkea ja pystyttävä melkein mihin vain, ja jos ei pystytä, on se kuolemansynnin veroinen virhe. Sama ongelma on monella liiketoimintaa kehittävällä asiantuntijalla.

Liiketoiminnan järjestelmien kehityksessä rajallisuus tulee vastaan siinä, miten paljon räätälöityä toiminnallisuutta pystytään ennustaa ilman, että järjestelmää käytetään samalla. Eli kun on suunniteltava prosessityökalu, joka tukee 18-vaiheista prosessia, onko todennäköistä, että vaiheet 5–18 ovat realistisesti suunniteltuja, jos ensimmäistäkään vaihetta ei olla päästy kokeilemaan reaalimaailmassa? Ohjelmistoprojekteissa lisäongelmana on, että ei riitä, että jokin vaihe on suunniteltu suht’ hyvin ja sinne päin. Sen pitää olla millintarkasti suunniteltu, jotta kalliilta ja aikaa vievältä muutostyöltä vältytään.

Väitän, että edes fiksuimmat CRM-kehittäjät ja -konsultit (minä mukaan lukien) eivät pysty suunnittelemaan kovin laajaa toiminnallisuutta pelkästään paperilla. Prosesseja on päästävä kokeilemaan aidoilla työkaluilla, ja vasta sen jälkeen osataan sanoa, miten asioiden oikeasti pitäisi olla.

Ratkaisu 2b: Räjäytetään kehitysmenetelmät täysin

Reilun tuhannen sanan johdannon jälkeen päästään varsinaiseen asiaan: ohjelmistokehityksen välineistä vesiputousmalli on täysin aikansa elänyt ja käyttökelvoton useimpiin liiketoiminnan tietojärjestelmien kehitysprojekteihin. Mitä laajempi projekti on, sitä todennäköisempää on, että vesiputouksen avulla epäonnistutaan.

Edes hieman viritettynä, eli projektia osittamalla, vesiputous ei käytännössä näytä tuottavan haluttuja hyötyjä ilman raskaita muutoskierroksia. On siis syytä heittää menetelmä kokonaan romukoppaan ja keksiä jotain muuta.

Ketterät kehitysmenetelmät tarjoavat oivan tavan tuoda ryhtiä kehitysprojektille ja varmistaa, että sisältö on muutettavissa radikaalistikin ilman järkyttäviä lisäkustannuksia tai sopimusneuvotteluita.

Käsitteenä ketterät menetelmät aiheuttavat sekaannuksia, sillä luullaan, että on olemassa yksi ”ketterä menetelmä”, jolla on toimittava. Käytännössä kuitenkin ketterät menetelmät on ylätason käsite samaan tapaan kuin autot. Yhtä lailla kuin pakettiauto poikkeaa avoautosta, poikkevat ketterät menetelmät toisistaan. On XP:tä (eXtreme Programming), TDD:tä (Test Driven Development), Scrumia, Kanbania ym. Kaikissa on hyvät puolensa ja heikkoutensa, eikä yhtä voi pitää ehdottomasti parempana kuin toista. Joskus on kuljetettava iso sohvakalusto ja toisinaan päästävä nauttimaan auringonpaisteesta ja tuulesta.

Toinen harhaluulo ketteristä menetelmistä on, että ne ovat kuin vesiputousmalli, mutta toistettuna useampaan kertaan. Tässä ajatuksessa ollaan vaarallisilla vesillä, sillä ketterän kehityksen johtoajatus ei rakennu pelkästään siitä, että suunnitellaan, määritellään ja kehitetään asioita pienissä paloissa. Ajattelemalla ketteriä menetelmiä fiksumpana vesiputousmallina lähdetään helposti tielle, jossa toimitaan vesiputousmallin tapaisesti, paljon tehottomammin ja raskaammin vain.

Iso hyöty ketteristä menetelmistä on siinä, että ne tuovat projektille ryhdikkään toimintatavan, selkeät roolit ja tilan jokaiselle roolille tehdä sitä, mihin se parhaiten pystyy. Eli esimerkiksi Scrumissa tuoteasiantuntija (virallisesti ”tuoteomistaja”) saa keskittyä miettimään, missä järjestyksessä toiminnallisuutta on kehitettävä ja mitä asiakkaan toiveita siihen liittyy. Vastaavasti kehittäjälle luodaan rauhallinen työrupeama, jonka aikana hän saa rakentaa mielestään parhaan mahdollisen toiminnallisuuden asiakkaan ongelmaan – asiakkaan antamilla reunaehdoilla toki. Kehittäjä tietää, että hänen on toimitettava sprintin eli kehitysrupeaman päättyessä toimiva ja ehjä kokonaisuus, joka on otettavissa tuotannolliseen käyttöön heti. Loppuasiakkaalle annetaan puolestaan lupa muuttaa mieltään ihan niin monta kertaa kuin tämä haluaa, kunhan mielenmuutos tapahtuu ennalta sovituissa kohdissa.

Edellä mainitsemani 18-vaiheisen prosessin tukena toimiva työkalu voidaan Scrumin oppeja soveltaen toteuttaa esim. 12:ssa yhden kuukauden mittaisessa sprintissä. Asiakkaalla on siis 12 sprinttiä tilaa pohtia, millaisia eri vaiheet ja niiden sisällöt ovat. Jo ensimmäisen sprintin jälkeen asiakas saa konkreettista käytettävää, jonka avulla tämä voi suunnata kehityspanoksia juuri niihin asioihin, jotka ovat kaikkein hyödyllisimpiä. Ja kun asiakkaalle lopulta selviää, että vaiheet 12–18 eivät enää sovikaan yllätyksellisesti muuttuneeseen strategiaan, onnistuu projektin suunnan muutos kuin huomaamatta – ja miellyttävän pienillä lisäkustannuksilla.

Lopuksi

CRM-, ERP- ja muissa projekteissa useimmiten päädytään siis tekemään ohjelmistokehitystä, vaikka sitä ei haluta myöntää. Toimittajien lupauksista huolimatta projekteja ei voi lähestyä kevytmielisesti ja omaan näkemykseen sokeasti luottaen. Entä jos maailma muuttuukin, ja strategia sen mukana? Miten varmistetaan, että muutoksesta selvitään ilman satojen tuhansien tai miljoonien lisätyökustannuksia?

On aika etsiä ja ottaa käyttöön uusia menetelmiä. Vesiputous on jo nähty, eikä sieltä valunut paljoa muuta kuin lisätyölaskuja.