H-hetki on koittanut ja on aika tehdä Salesforce CRM-järjestelmän käyttöönotto. Huolellisen valmistelun ja nopean käyttöönottoprojektin jälkeen asiakas saa uuden järjestelmän käyttöönsä. Mielessä pyörii yksi kysymys: “mitä seuraavaksi?”
Minusta Salesforceen voi teknologia-alustana suhtautua ikään kuin elävänä dokumenttina. Se ei ole valmispaketti, joka syntyy yhdellä massiivisella kertarykäyksellä, vaan matka, joka alkaa järjestelmän käyttöönotosta.
Käyn tässä tekstissä läpi ajatuksia, mitä johdannossa esitettyyn kysymykseen pitäisi vastata. Itse asiassa väitän, että jos käyttöönoton jälkeen joutuu hamuilemaan seuraavia askelmerkkejä, jotain on todennäköisesti mennyt pieleen jo lähtötelineissä.
Salesforce CRM-järjestelmän käyttöönotto lähtee liikkeelle liiketoiminnan tarpeista
Me tunnemme Salesforce-teknologiat läpikotaisin ja tiedämme varsin tarkkaan, mitä kaikkea niiden avulla voidaan saada aikaan. Siksi meille Salesforcen käyttöönotto tarkoittaa lähtölaukausta. Varsinainen savotta on vasta edessäpäin.
Yhä useammin myös asiakkaat ovat nykyisin jo varsin valveutuneita ja tietävät, että Salesforce-alustaa voidaan hyödyntää liiketoiminnan kehittämisessä ja johtamisessa varsin laaja-alaisesti. Monesti he kuitenkin miettivät käyttöönoton jälkeen asioita teknologian näkökulmasta. Miten me voisimme paremmin hyödyntää Salesforcea?
Kysymys on täysin ymmärrettävä.
Ajaudun itsekin helposti mukaan tämäntyyppiseen keskusteluun siitä, mikä olisi teknisessä mielessä luonnollinen jatkumo käyttöönotolle.
”Oikea kysymys olisi, miten omaa liiketoimintaa tulisi jatkossa kehittää. Teknologia seuraa kyllä perässä.”
Väitän kuitenkin, että lähtökohta tällaiselle keskustelulle on väärä. Oikea kysymys olisi, miten omaa liiketoimintaa tulisi jatkossa kehittää. Teknologia seuraa kyllä perässä ja taipuu kaikkiin tarpeisiin, mutta se on oikeastaan vain yksi pieni osa isompaa kokonaisuutta.
Olet uniikki – unohda one size-ratkaisut
Fanfaarien ja konfettin keskellä olisi tärkeää miettiä omia liiketoimintatavoitteita. Niistä tavoitteista voidaan johtaa kehityskohteiksi reaalimaailman prosessit – ja vasta sitten päästään teknologiaan.
Tässä on hyvä muistaa, että usein teknologian hyödyntämisessä on kyse reaalimaailman asioiden digitaalisesta kuvaamisesta. Siitä syystä one size fits all -ajattelu ei yksinkertaisesti toimi.
”Usein teknologian hyödyntämisessä on kyse reaalimaailman asioiden digitaalisesta kuvaamisesta. Siitä syystä one size fits all -ajattelu ei yksinkertaisesti toimi.”
Jos esimerkiksi asiakkaan tavoitteena on kasvattaa liikevaihtoa kannattavasti, niin voimme alkaa määritellä asioita, joihin keskittymällä tavoitteeseen voidaan päästä.
Voimme esimerkiksi pyrkiä automatisoimaan monia aikaa vieviä työvaiheita, jolloin ihmisten aikaa vapautuu enemmän tuottavaan asiakastyöhön. Voimme myös määritellä myyntiprosessit tarkemmin ja kuvata ne kaikki CRM-järjestelmään, jotta myyjiä voidaan ohjata toimimaan tehokkaimmalla mahdollisella tavalla.
On siis paljon asioita, joita tekemällä voimme pyrkiä samaan tavoitteeseen. Kaikki riippuu kuitenkin asiakkaasta ja asiakkaan yksilöllisistä tarpeista.
Minun ei varmaan tarvitse sen tarkemmin kertoa, miksi esimerkiksi ravintolaketjun tarpeet ovat täysin erilaisia kuin vaikkapa raskaan teollisuuden.
Askel kerrallaan, mutta katse tulevaisuudessa
Kannustan kaikkia käyttöönoton jälkeen eteenpäin ponnistavia kertomaan kumppanille avoimesti omista tavoitteista ja haasteista sekä suhtautumaan avoimin mielin kumppaneiden ajatuksille, sillä osaava teknologiakumppani ymmärtää asiakastaan ja pystyy kertomaan kullanarvoisia näkemyksiä siitä, miten tavoitteisiin päästään parhaalla mahdollisella tavalla.
Jos olet ajautunut tilanteeseen, jossa kumppanilla ei ole käyttöönoton jälkeen esittää mitään selkeää ehdotusta liiketoiminnan tavoitteita tukevasta jatkokehityksestä, suosittelen kysymään asiasta. Eli kun CRM-järjestelmää otetaan käyttöön tai sen käyttöönottoa ollaan harkitsemassa, kehotan miettimään asioita jo muutamaa askelta pidemmälle.
”Kun CRM-järjestelmää otetaan käyttöön tai sen käyttöönottoa ollaan harkitsemassa, kehotan miettimään asioita jo muutamaa askelta pidemmälle.”
Onnistunut Salesforce CRM-järjestelmän käyttöönotto on monille pitkä loikka eteenpäin, mutta ei milloinkaan ratkaise yhdellä kertaa kaikkia haasteita. Se on enemmänkin hyvä pohjatyö, jota voi lähteä laajentamaan kerros kerrokselta.
Ketterästi eteenpäin
Salesforcea on alustana nopea jatkokehittää low code ja no code -mahdollisuuksien takia. Jatkokehitystä ei kannata siis lähestyä suurena ennalta määriteltynä projektina, jossa vasta käyttöönottovaiheessa nähdään, onko hommassa onnistuttu.
Jos liiketoiminnan tavoitteet ja prosessit on selvillä, niitä kannattaa yleensä lähteä toteuttamaan järjestelmään ketterästi yksitellen tärkeysjärjestyksessä.
Matkan aikana opitaan jatkuvasti siitä, mikä toimii ja mikä ei toimi. Näin voidaan nopeasti reagoida muuttuviin tarpeisiin. Ketterässä kehityksessä käyttäjät pääsevät jatkuvasti kehitysprojektin aikana validoimaan ja testaamaan järjestelmää, jolloin riski epäonnistumisesta pienenee huomattavasti.
”Ketterässä kehityksessä käyttäjät pääsevät jatkuvasti kehitysprojektin aikana validoimaan ja testaamaan järjestelmää, jolloin riski epäonnistumisesta pienenee huomattavasti.”
Kun jatkokehitys tulee aiheelliseksi ei kärpäsestä siis kannata tehdä härkästä, vaan ottaa rohkeasti yhteyttä kumppaniin ja käydä liiketoiminnan tavoitteet yhdessä läpi.
Kumppanin tehtävänä on ehdottaa ylätason tiekarttaa jatkokehitykselle, jota lähdetään vähitellen toteuttamaan pienissä palasissa. On hyvä huomioida, että roadmapin ei ole tarkoitus sitoa mihinkään, vaan se on kumppanin ja asiakkaan alustava näkemys siitä, miten asioita kannattaa lähteä kehittämään.
Ketterä kehitys on yhteispeliä, jolloin kehitystiimiä kannattaa ajatella molempien osapuolten sekoituksena, joka liiketoiminta edellä toteuttaa ne kehityskohteet, jotka tuottavat liiketoiminnalle eniten hyötyä – ilman ennalta määritettyä ja kahlitsevaa sisältöä.
Salesforce CRM-järjestelmän käyttöönotto yhteistyössä Biitin kanssa
Salesforcen käyttöönotto on siis paljon muutakin kuin napin painallusta. Saat parhaan hyödyn järjestelmästä irti, kun pelkän käyttöönoton sijaan järjestelmän käytölle määritellään pidemmän tähtäimen tarpeet.
Biit on Suomen ensimmäinen virallinen Salesforce-kumppani. Olemme auttaneet useita eri kokoisia yrityksiä eri toimialoilta Salesforcen käyttöönotossa. Jos sinäkin haluat saada järjestelmästä kaiken irti, lue lisää Salesforcen käyttöönoton konsultoinnista täältä tai lataa alla oleva opas.
Biit sai vuoden alusta jälleen riveihinsä uuden huipputekijän, kun Accenturella suuren kokoluokan Salesforce-projektien johtotehtävissä työskennellyt Timo Pasonen aloitti Biitin uutena operatiivisena johtajana. Halusimme selvittää Pasoselta, mitä onnistunut Salesforce-projekti edellyttää.
Timo Pasonen on kokenut teknologiaosaaja, joka on ollut eri rooleissa mukana lukuisissa erilaisissa Salesforce-hankkeissa pienistä käyttöönotoista massiivisiin transformatiivisiin hankkeisiin, joissa kansainvälisten suuryritysten toimintaa modernisoidaan.
Halusimme selvittää Pasoselta, olisiko olemassa universaaleja lakeja, joka pätevät yhtä lailla silloin, kun paikallisesti toimiva yritys haluaa ottaa Salesforcen käyttöön myyntityökaluna ja silloin, kun kansainvälinen suuryritys haluaa modernisoida liiketoimintaansa Salesforcen avulla?
”Tavoitteen määrittelyssä pitäisi olla mukana asiakkaan puolelta aina ne ihmiset, joita muutos oikeasti koskettaa.”
– Onnistunut hanke edellyttää aina selkeää tavoitetta, jonka tulee lähteä asiakkaan omista tarpeista. Tämän tavoitteen määrittelyssä pitäisi olla mukana asiakkaan puolelta aina ne ihmiset, joita muutos oikeasti koskettaa. Jos kehitetään esimerkiksi myyntiä, niin myynnin on osallistuttava hankkeeseen. Jos taas kehitetään asiakaspalvelua, niin asiakaspalvelun tulee olla mukana. Kun heti alkuvaiheessa saadaan oikeat ihmiset mukaan, niin hankkeen onnistumisedellytykset kasvavat merkittävästi, kertoo Timo Pasonen.
Väärälle raiteelle jo lähtöasemalla
Pasosen mielestä yksi Salesforce-hankkeiden helmasynneistä on se, että niitä tehdään usein liian IT-vetoisesti. Jos hankkeen vetovastuu ja omistajuus on IT-osastolla, joka myös osallistuu asiakkaan puolelta ainoana tahona tavoitteiden määrittelyyn, niin kehitystyö saattaa ajautua jo asemalta lähdettäessä väärälle raiteelle. Tällöin matkustajat huomaavat vasta pääteasemalla olevansa aivan väärässä paikassa.
– IT-osastolla saattaa olla selkeä kuva siitä, mitä uudelta järjestelmältä tai kehitystyöltä teknisesti vaaditaan, mutta osaako IT-osasto myös arvioida, miten esimerkiksi myyjät järjestelmää käyttävät tai minkälaisia toiveita heillä järjestelmää kohtaan on? Esimerkiksi IT:n vetämän myynnin kehittämishankkeen riskinä on se, että yritys ostaa hienon CRM-järjestelmän, joka jää heti vajaakäytölle, koska myyjät eivät koe hyötyvänsä sen käytöstä. Tätä tapahtuu valitettavan usein.
”IT:n vetämän myynnin kehittämishankkeen riskinä on se, että yritys ostaa hienon CRM-järjestelmän, joka jää heti vajaakäytölle.”
Pasonen siis muistuttaa, että jokaisessa järjestelmähankkeessa matkustajilta pitää ensin kysyä, mihin he ovat matkustamassa. Mikäli ne työntekijät, joita hanke loppujen lopuksi koskettaa, eivät pääse vaikuttamaan matkakohteeseen, he tuskin päätepysäkillä hyppivät riemusta tasajalkaa.
– Parhaat hankkeet ovat aina olleet sellaisia, joissa loppukäyttäjät on saatu mukaan alusta saakka. Kun alkuvaiheessa asioihin voi vielä suunsa avaamalla vaikuttaa, niin ihmisiltä tulee paljon konkreettisia ajatuksia siitä, kuinka asiat voitaisiin tehdä vielä paremmin.
Tällöin hanke ei jää pelkästään tekniseksi toteutukseksi, vaan sen avulla aidosti kehitetään organisaation toimintaa ja edesautetaan ihmisiä tekemään työnsä entistä paremmin.
Menneisyyden painolasti riesana
Miksi IT-osastot niin usein vetävät näitä kehityshankkeita, vaikka niiden tavoitteena on nimenomaan kehittää yrityksen muita toimintoja? Pasosen mielestä vastaus löytyy menneisyydestä.
– Tietyllä tavalla kyse on menneisyyden painolastista. Vanhassa maailmassa järjestelmien käyttöönotot ja niiden kehittäminen olivat teknisesti niin haastavia ja pitkäkestoisia operaatioita, että käytännössä niitä oli pakko tehdä tekniikkapuoli edellä.
Pasonen myös kertoo törmänneensä tilanteisiin, joissa IT on niin sitoutunut pitkään käytössä olleisiin järjestelmiin, etteivät he halua niihin koskettavan.
Usein näissä tilanteissa vanhoihin järjestelmiin tallennettua tietoa tarvitaan myös uuden järjestelmän, kuten Salesforcen prosesseissa, jolloin niihin rakennetaan integraatioita yhdessä IT-osaston kanssa.
Pasosen mielestä asetelma on usein kaukana ihanteellisesta. Elinkaarensa ehtoopuolella olevan järjestelmän integraatiolla saadaan korkeintaan muutaman vuoden aikalisä, jonka jälkeen järjestelmän käyttökelpoisuutta on arvioitava uudelleen.
Vertauskuvallisesti voitaisiin ajatella, että vanhojen järjestelmien loputon paikkailu on kuin yrittäisi pitää itsepintaisesti kiinni vanhasta puhelimesta, jota on tottunut käyttämään ja joka on täyttynyt kaikesta tärkeästä tiedosta. Jos tietojen siirtäminen uuteen puhelimeen olisi lisäksi hankalaa, niin kynnys vaihtaa puhelinta saattaisi nousta korkealle.
Uusi järjestelmä pystyyn parissa viikossa – ilman IT-osastoa
Palataanpa takaisin nykyhetkeen. Pasonen puhuu vanhasta maailmasta, jossa tekninen puoli nousi järjestelmähankkeissa ylikorostettuun asemaan. Onko maailma siis jotenkin merkittävällä tavalla muuttunut?
”Parhaimmillaan järjestelmän kehitysversiota päästään testaamaan jo hankkeen alkuvaiheista lähtien.”
– Järjestelmät ovat kehittyneet valtavasti. Nykyisiä järjestelmiä, kuten Salesforcea, voidaan kehittää nopeasti ja kevyesti, jolloin on mahdollista keskittyä aiempaa enemmän asiakkaan tarpeisiin ja loppukäyttäjien toiveisiin. Parhaimmillaan järjestelmän kehitysversiota päästään testaamaan jo hankkeen alkuvaiheista lähtien.
– Olen ollut mukana esimerkiksi hankkeissa, joissa myynnin käyttäjät ovat päässeet tallentamaan tietoa uuteen järjestelmään jo heti ensimmäisen kahden viikon jälkeen ja kenttähuolto on aloittanut uuden ohjausjärjestelmän kenttätestauksen kuukauden kuluttua hankkeen aloituksesta. Aina IT-osastoa ei ole edes tarvittu mukaan.
Minkälainen on tänä päivänä Salesforce-projektin Dream Team? Jos IT-osaston olisi syytä jäädä kulisseihin, niin ketkä nostetaan lavalle?
”Käyttäjien on oltava vahvasti edustettuina, puhuttiinpa sitten myyjistä tai huoltoteknikoista.”
– Täydelliseen projektiin osallistuu asiakkaan puolelta innostuneita ihmisiä, jotka tietävät asioista ja joilla on mandaatti tehdä päätöksiä. Käyttäjien on oltava vahvasti edustettuina, puhuttiinpa sitten myyjistä tai huoltoteknikoista. Erityisen kullanarvoisia ovat sellaiset ihmiset, jotka ymmärtävät bisneksen. Kun he kertovat, mitä tarvitaan, niin se helpottaa kaikkien työtä.
Organisaatioiden omat IT-osastot palvelevat asiakkaitaan – eli käyttäjiä – usein eri tavoin kuin myyjä palvelee omia asiakkaitaan. Vaikka asetelma onkin muuten hyvin samankaltainen. Ketteryys ja Salesforce auttavat tuomaan tähän muutoksen.
Olen juuri aloittanut työt Biitillä. Ennen siirtymistäni tänne toimin yrityksen omassa IT-organisaatiossa, jossa vastasin yrityksen Salesforce-ratkaisun kehittämisestä. Tässä roolissa olen painottanut aina yhtä asiaa: CRM:n tulisi tuottaa käyttäjilleen arvoa. Organisaatio maksaa IT:n kuluja, koska sen tulisi mahdollistaa muun organisaation tehokkuus ja toiminta. CRM-järjestelmää kehitettäessä IT-organisaation asiakkaita ovat siis myyjät, sillä tuotetta kehitetään heille.
”CRM-järjestelmää kehitettäessä IT-organisaation asiakkaita ovat siis myyjät, sillä tuotetta kehitetään heille.”
Harvoin IT kuitenkaan palvelee asiakkaitaan yhtä hyvin kuin esimerkiksi myyjä palvelee ostavia asiakkaitaan, vaikka asetelma on hyvin samankaltainen. IT:n on ollut liian helppo piiloutua teknisen jargoninsa taakse ja olla ymmärtämättä liiketoiminnan ja käyttäjän tarpeita.
Salesforcen mahdollistama nopeus ja ketteryys on kuitenkin tuonut tähän muutosta.
Lue lisää: Salesforcea. Ketterästi. – Kuinka ketterä kehitys sopii Salesforce-projekteihin?
Ketteryys auttaa keskittymään olennaiseen
Jotta IT voisi palvella omia asiakkaitaan, tulee siellä ymmärtää, mitä ongelmaa tietojärjestelmällä tai toiminnallisuudella yritetään ratkaista. Miten käyttäjälle tuotetaan mahdollisimman paljon lisäarvoa? Käyttäjät eivät kuitenkaan tiedä, mikä on teknologisesti mahdollista. Ja olisi mielestäni epäreilua olettaa, että heidän tulisi tietää.
Miten käyttäjälle tuotetaan mahdollisimman paljon lisäarvoa?
Ketterien menetelmien ytimessä onkin varmistaa yhdessä käyttäjien kanssa, että tehdään oikeita asioita.
Tässä nousee esiin yksi Salesforcen etu: monimutkainenkin toiminnallisuus voidaan toteuttaa pelkästään konfiguraatioilla tai pienellä määrällä koodia (low-code). Tämän ansiosta uusi ominaisuus voidaan rakentaa suoraan loppukäyttäjän kanssa ja siitä saadaan välittömästi palautetta.
Näin uusia ideoita voidaan kokeilla helposti ja uudet toiminnallisuudet saadaan käyttäjille nopeasti ilman erillisiä versiopäivityksiä.
Luovu nopeasti toimimattomista asioista
Ylätasolla projektia tai hanketta tulisi ohjata vision avulla ja ohjata kokonaisuutta tiekartan avulla kohti tätä visiota. Tiekartan tehtävänä on myös viestiä projektitiimille ja sidosryhmille, millaisiin liiketoimintaongelmiin ja kokonaisuuksiin keskitytään milläkin ajanjaksolla. Monesti tiekartat ovat kuitenkin keskittyneet lähinnä teknisiin ominaisuuksiin.
Olen myös huomannut, että käytännössä noin puolet kehitysideoista ei toimi. Syitä tähän on monia, mutta usein ne ovat joko liian vaikeita toteuttaa tai ne eivät tuota haluttua arvoa käyttäjille.
”Ollaan nopeasti tilanteessa, jossa uuden ominaisuuden toimimattomuus selviää vasta projektin loppuvaiheessa käyttäjätestauksessa.”
Kun nämä kaksi seikkaa yhdistetään, ollaan nopeasti tilanteessa, jossa uuden ominaisuuden toimimattomuus tai sopimattomuus liiketoiminnan tarpeisiin selviää vasta projektin loppuvaiheessa käyttäjätestauksessa. Usein jopa ketterien menetelmien kanssa unohdetaan fail fast -kulttuuri. Jos puolet ideoista ovat oletuksellisesti toimimattomia, pitää nämä ideat huomata nopeasti ja muuttaa lähestymistä tai jopa jättää uudet ominaisuudet toteuttamatta.
Käyttäjän tulee päästä kokeilemaan ja käyttämään toiminallisuuksia jo alkuvaiheessa. Kun kehityssyklejä pidetään lyhyinä, samalla koko ajan varmistaen käyttäjiltä ominaisuuksien toimivuutta, toimimattomat ideat huomataan jo toteutuksen alkuvaiheessa. Näin varmistutaan, että kehitys menee oikeaan suuntaan myös käyttäjien näkökulmasta.
Tässä Salesforce pääsee jälleen loistamaan: kun uusia ominaisuuksia voidaan kokeilla jopa samalla, kun käyttäjä kertoo tarpeistaan, huomataan toimimattomat ideat nopeasti.
Salesforce auttaa IT:tä palvelemaan omia asiakkaitaan paremmin
Hyvä myyjä auttaa asiakkaitaan onnistumaan ja kykenee esittelemään näkemyksiä siitä, miten yritys voisi käyttää hänen myymiä tuotteita tai palveluita saavuttaakseen liiketoimintansa tavoitteet paremmin. Aivan kuten IT-organisaation tulisi palvella omia asiakkaitaan: käyttäjiä.
Kun yhdistetään Salesforce ja ketterä kehitys, päästään tilanteeseen, jossa myös IT:n on helppo tuottaa lisäarvoa loppukäyttäjälle.
Raskaat prosessit uusien ideoiden ja ominaisuuksien kehittämisessä ja käyttöönotossa ovat menneisyyttä. Ketteryydellä saadaan parempi ja nopeampi sijoitetun pääoman tuotto, parempaa riskien hallintaa ja kasvatetaan asiakasymmärrystä.
Kuinka yrityksessänne toimitaan, jos esimerkiksi CRM-järjestelmään halutaan uusi ominaisuus tai yrityksen verkkosivuille uusi palvelu asiakkaille?
Jos uudet ideat puristetaan raskaan hyväksymisprosessin läpi ja tämän jälkeen ne rakennetaan perinteisellä vesiputousmallilla, jää matkalle luultavasti useita hyviä ideoita ja uusia asioita päästään hyödyntämään hitaammin. Tuotantoon asti päätyneet ominaisuudet ja palvelut eivät välttämättä vastaakaan käyttäjien todellisia tarpeita. Usein myös teknologia on jo ajanut ohi ratkaisusta.
Ketteryyden tuomat hyödyt pohjautuvat sykliin, joissa rakennetaan nopeasti, mitataan tuloksia, opitaan tämän pohjalta ja palataan syklin alkuun.
Uudet ideat nopeasti testiin
Ketterien kokeilujen idea on yksinkertainen: tehdään nopeasti esimerkiksi rajatut, mutta riittävät ominaisuudet omaava prototyyppi tai demo. Prototyyppiä testataan rajatulla yleisöllä ja tämän jälkeen jatketaan kehittämistä ja laajennetaan käyttöä.
CRM-järjestelmän kohdalla tämä voi tarkoittaa prototyypin konfigurointia niin sanottuun hiekkalaatikko-ympäristöön, eli järjestelmään, jossa kehittäjät voivat vapaasti kokeilla uusia asioita ilman, että vaikuttavat tuotannossa olevaan järjestelmään. Tämän jälkeen uutta ominaisuutta testataan suoraan loppukäyttäjien kanssa, muokataan tarvittaessa ja viedään nopeasti tuotantoon.
Verkkopalvelusta voidaan taas julkaista tärkeimmät ominaisuudet omaava versio rajatulle kohderyhmälle, kerätä palautetta ja tämän pohjalta jatkaa palvelun kehittämistä ja julkaista se suurelle yleisölle.
Kerää palautetta ja hylkää huonot ideat
Ketterien kokeilujen ytimestä löytyy kaksi tärkeää konseptia: minimun viable product (MVP) ja fail fast.
MVP tarkoittaa käytännössä nopeasti kehitettävää tuotetta tai ratkaisua, joka sisältää vain tärkeimmät ominaisuudet. Tällainen voidaan tuoda nopeasti käyttöön sopivalle käyttäjäryhmälle ja saada heiltä arvokasta palautetta.
Fail fast -ajattelu taas on välttämätöntä ketterissä kokeiluissa. Jokainen tehtävä kokeilu ei onnistu. Tällöin on tärkeää hylätä esimerkiksi turhan ominaisuuden tai tuotteen kehittäminen mahdollisimman nopeasti ja siirtyä hyödyllisempiin kohteisiin.
Uusi asiakkaille suunnattu verkkopalvelu voidaan näin julkaista edelläkävijöiksi tunnistetuille asiakkaille vain välttämättömät ominaisuudet omaavana versiona ja kerätä heiltä palautetta. Jos palautteen pohjalta vaikuttaakin, ettei palvelu ole hyödyllinen, voidaan sen kehitys lopettaa ajoissa.
Jatka kehittämistä ketterästi
Kun uuden verkkopalvelun hyödyt on validoitu minimum viable product -ratkaisun avulla ja palvelu lanseerattu suurelle yleisölle, kannattaa sen kehittämistä jatkaa ketterästi. Sen sijaan, että yritetään rakentaa valmista ratkaisua pitkässä projektissa, ketterässä kehityksessä tuodaan uusia ominaisuuksia käyttöön lyhyissä sprinteissä, priorisoiden tärkeimpiä.
Ketterä kehitys mahdollistaa myös reagoimisen ympäristön muutoksiin.
Ketterä kehitys mahdollistaa myös reagoimisen ympäristön muutoksiin. Jos asiakkaiden tarpeet muuttuvat tai teknologia mahdollistaa kokonaan uusia asioita, voidaan kehityksen suuntaa vaihtaa lennosta ja varmistaa, että lopputulos on loppukäyttäjälle mahdollisimman hyödyllinen.
Salesforce sopii erinomaisesti ketteriin kokeiluihin
Ketterät kokeilut toimivat parhaiten, kun uusi ominaisuus tai ratkaisu voidaan rakentaa nopeasti. Jos ratkaisu joudutaan koodaamaan nollasta, on selvää, että prototyypinkin rakentaminen vie oma aikansa.
Salesforce sisältää paljon valmiita toiminnallisuuksia.
Salesforce sisältää paljon valmiita toiminnallisuuksia. Uusi ominaisuus voidaan konfiguroida Salesforce Platformin päälle selaimella ja päästä testaamaan prototyyppiä loppukäyttäjien kanssa välittömästi. Pilvipalvelun ansiosta uudet ominaisuudet myös saadaan loppukäyttäjille käyttöön välittömästi.
Parhaimmillaan ketterät kokeilut mahdollistavat uusien, villienkin ideoiden testaamisen turvallisesti, ilman isoja investointeja tai suuria riskejä. Näin toimiva yritys voi saada uusia yllättäviä liiketoimintahyötyjä tuovia asioita ideasta käyttöön nopeasti.
Jos haluat lukea lisää Salesforcen hyödyntämisestä ketterässä kehityksessä, käy lataamassa uusi oppaamme Salesforcea. Ketterästi. – Kuinka ketterä kehitys sopii Salesforce-projekteihin?