Yleinen oletus on, että suurin hukattu resurssi epäonnistuneessa tietojärjestelmäprojektissa on ihmisten tekemä työ. Todellisuudessa organisaatiolle kaikista kallein on aika, joka hukattiin turhan lopputuotteen tekemiseen — siis aika, jonka aikana olisi voitu toteuttaa jotain yritykselle oikeasti hyödyllistä lopputuotetta.

Tätä menetettyä resurssia organisaatiot eivät tule ikinä saamaan takaisin.

Myynnin teknologioiden kehityksen nopeassa muutoksessa on tärkeää löytää oleelliset ongelmat, joita sen avulla halutaan ratkaista. Kaikille kaikkea -tyyppinen lähestymistapa toimii harvoin ja kaatuu usein omaan mahdottomuuteensa resurssien ja ajan puutteessa.

Kehitystä ja uuden teknologian hyödyntämistä ei myöskään tule ajatella kertainvestointina. Jos organisaatio jää kehityksestä jälkeen, on hukatun ajan kiinni kurominen paitsi vaikeaa, myös kallista. Luonnollisesti epäonnistunut tietojärjestelmäprojekti aiheuttaa paljon myös erilaisia välillisiä kustannuksia etenkin nopeasti muuttuvassa ympäristössä.

CRM-järjestelmän on ensisijaisesti tuotettava arvoa sen käyttäjille


CRM on usein laaja ja helposti monimutkainen järjestelmä. Se vaatii käyttäjältä — usein myyjältä — opettelua ja perehtymistä ennen kuin sitä voidaan käyttää tehokkaasti. Yhtä usein tällaisen järjestelmän käyttöä ja sen toimintoja joutuu myös hieman perustelemaan sen käyttäjälle.

Lähtökohtana kuitenkin on, että järjestelmä tuottaa tehokkaasti käytettynä arvoa sen käyttäjille, ja että käyttäjä ymmärtää tämän perehtymisvaiheen jälkeen. Perusraportoinnin sijaan pitää CRM:n pystyä kattamaan myynnin eri vaiheen aktiviteetit tehokkaasti ja luotettavasti. CRM:stä tulee löytyä siis tieto nykyisestä myyntimenestyksestä ja ennuste tulevasta myyntimenestyksestä.

Näin CRM tukee sekä myyjää, että myyntijohtajaa.

Oma visiomme CRM:lle on lyhyesti se, että myyjän ei tarvitse käyttää työssään mitään muuta järjestelmää. Kaikki hänen työssään tarvitsema tieto tarjoillaan suoraan CRM:ssä. Tämä on toiminut meillä hyvin.
 

Ketterät prosessimallit mahdollistavat
paremmin toimimisen muuttuvassa ympäristössä


Nopeasti muuttuvassa vaatimusten ympäristössä tuotekehitysprojektit käyttävät usein jotain ketterän kehityksen periaatteita noudattavaa viitekehystä. Ketterän kehityksen vastakohtana nähdään usein vesiputousmalli, joka määrittelee suunnittelun, määrittelyn, toteutuksen, testauksen ja käyttöönoton lineaarisesti, vaihe vaihetta seuraavana prosessina.

Vesiputousmallin ongelma on usein prosessin lopussa oleva testaus ja käyttöönotto, jossa havaitaan mahdolliset puutteet ja virheet. Projektin loppuvaiheessa suunnitellun julkistuksen kynnyksellä muutokset ovat kalliita ja hitaita toteuttaa. Vesiputousmallissa siis projektin riskit ovat projektin loppuvaiheessa ja niitä on lähes mahdotonta ennustaa ja hallita ilman, että niitä validoidaan käyttäjillä.

Ketterät prosessimallit puolestaan ohjaavat lyhyihin kehityssykleihin, joiden tavoitteena on paljastaa mahdollisimman nopeasti puutteet ja virheet suunnittelussa. Kehitystyötä tehdään iteraatioissa, pieninä lisäyksinä ja muutoksina kehitettävässä järjestelmässä. Järjestelmän lopullinen käyttäjä pyritään samaan prosessiin mukaan jo kehitysvaiheessa testaamaan ja antamaan palautetta kehitystyön tuloksista.

Tällä tavoin käyttäjiltä saadaan palaute toteutuksesta jo kehitysprosessin aikana. Käyttäjien päästessä testaamaan vielä keskeneräistä, mutta yhtä tai muutamaa asiaa tekevää tuotetta saadaan nopea palaute ja enemmän aikaa korjaamiselle.
 

Ketterä kehitys Salesforcen alustalla


Salesforcen monet toiminnot tarjoavat mahdollisuuden ketterään kehitykseen myös Salesforcen kehityksessä. Salesforcen CRM tarjoaa epätavalliseen tapaan perinteisten CRM-toiminallisuuksien lisäksi käyttöön myös Salesforcen alustan ja sen low- ja no-code ratkaisut. Nämä itsessään mahdollistavat erittäin nopeat kehityssyklit, joka myös vaatii rinnalleen nopeaa kehitystä tukevat prosessit.

Näin varmistetaan, että nopeasti muuttuvassa ympäristössä pystytään keskittymään tärkeimpien liiketoiminnan ongelmien ratkaisemiseen. Sandbox-ympäristöt tarjoavat mahdollisuuden rakentaa prototyyppejä ja testata uusia ominaisuuksia käyttäjiltä rajoitetussa ympäristössä.

Myös ominaisuuksien siirto sandbox-ympäristöstä tuotantoympäristöön on nopeaa ja helppoa. Pientä jatkokehitystä voidaan tehdä myöhemmin tuotantoympäristössä ilman suurempia riskejä. Näiden toiminnallisuuksien avulla mekin olemme pystyneet ratkaisemaan useita kertoja tiedon käsittelyyn liittyneitä ongelmia omassa organisaatiossamme. Olemme pystyneet ratkaisemaan liiketoiminnan ongelmia ja toteuttamaan uusia ominaisuuksia, joiden ei alkujaan uskottu olevan edes mahdollisia.

Osittain näiden myötä Salesforce on noussut organisaatiossamme yhä enemmän potentiaaliseksi alustaksi eri liiketoimintojen IT-ratkaisuja ajatellen.
 

Ketterillä menetelmillä johtaminen vaatii tarkasti
mietittyä visiota ja tulosten mittaamista


Ketteryydellä siis käytännössä tarkoitetaan, että muutoksiin voidaan reagoida nopeasti. Siksi ketterät menetelmät soveltuvat paremmin nykyaikaisten tietojärjestelmäprojektien läpivientiin perinteistä vesiputousmallia paremmin. Näin pystytään vastaamaan nopeasti ja tehokkaasti myynnin ja eri liiketoimintojen monimutkaisiin tarpeisiin.

Tärkeintä on, että kehityksestä vastaavaa tiimiä ohjataan tavoitteiden ja vision kautta ja tiimille annetaan vapaat kädet toteuttaa tätä yhdessä.

Monesti tätä visiota yritetään ohjailla erilaisilla “tiekartoilla”, mutta etenkin liian pitkälle tehdyissä tiekartoissa piilee pieleen menemisen riski. Ympäristö saattaa muuttua niin nopeasti, että tiekartta vanhenee hetkessä. Tiekartoista myös muodostuu erittäin helposti epäselvä toiveiden tynnyri, joka sisältää valtavan määrän erilaisia toiminnallisuuksia. Tällöin tiekartta menettää merkityksensä, sillä sen tulisi ensisijaisesti kertoa millaisiin kokonaisuuksiin ja ongelmiin tiimi keskittyy. Tavoitteita tulee myös pystyä mittaamaan — se ei vielä riitä, että jokin toiminnallisuus on käytössä, tai ei ole.

Oman kokemukseni mukaan tietyn prosessimallin tarkka noudattaminen ei kuitenkaan varmuudella tuota haluttuja lopputuloksia, eivätkä ketterät menetelmät siksi vielä yksinään takaa onnistunutta järjestelmähanketta. Yleensä ne kuitenkin paljastavat kehitysprosessin puutteita ja nostavat esiin asioita, jotka vaativat muutosta niin tekijätiimissä kuin laajemminkin organisaatiossa. Ne auttavat tekijöitä löytämään ja keskittymään olennaiseen ja tarjoavat mahdollisuuden jatkuvaan suunnan tarkistamiseen ja korjaamiseen prosessin aikana.

Ketterien menetelmien arvot ovat siis tulleet jäädäkseen. Olen puhumassa Salesforcen No- ja Low-code alustan hyödyntämisestä Salesforce Basecamp -tapahtumassa 14. toukokuuta — tervetuloa kuuntelemaan!


Kirjoittaja Mikko Cavenius toimii Barona Oy:llä tuotepäällikkönä vastuualueenaan CRM ja myynnin teknologioiden kehitys koko organisaatiossa. Mikko toimii linkkinä myyntijohdon ja teknologian välillä.