
Huomioi vähintään nämä
- Pahin lukko ei aina ole alustassa. Sitovin riippuvuus syntyy kumppanista, joka Salesforcen rakensi — ei Salesforcesta.
- Tekoäly voi myös pahentaa sitä. Jos kumppanin työkalun tuotos jää kumppanin puolelle, vaihdat vain yhden mustan laatikon toiseen.
- Kolme asiaa ratkaisee: dokumentaatio syntyy kehityksen sivutuotteena, asiakas omistaa kaiken koko ajan, ja tieto kattaa myös liiketoimintalogiikan — ei vain teknistä toteutusta.
- Jälkihoito on koetinkivi. Ylläpito ja jatkokehitys ovat se hetki, jossa läpinäkyvä toimitus maksaa itsensä takaisin — tai jossa lukko napsahtaa kiinni.
- Kysy tämä kilpailutuksessa: mitä meille jää käteen, kun projekti päättyy? Ja testaa se — kuinka nopeasti täysin uusi ihminen pääsee kärryille?
Tiivistelmä luotu Claude Opus 5:llä.
Sitovin lukko Salesforce-hankkeessa ei useinkaan ole alusta vaan kumppani, joka sen rakensi. Kun tieto asuu konsultin päässä, et pääse lähtemään vaikka haluaisit. Tekoäly voi purkaa tämän riippuvuuden, mutta yhtä hyvin se voi syventää sen. Ratkaisevaa ei ole mallin älykkyys vaan se, kenelle tieto jää, kun projekti päättyy.
Kun puhutaan lock-inista Salesforce-hankkeissa, ajatus menee helposti alustaan: lisensseihin, dataan, siihen kuinka vaikeaa järjestelmää olisi vaihtaa. Se on yksi kysymys, mutta se ei ole se, joka useimmin on isoin ongelma yrityksille. 20-vuotisen Salesforce-urani aikana olen huomannut, että usein isoin riippuvuus ei synny Salesforcesta vaan kumppanista, joka sen rakensi.
Usein isoin riippuvuus ei synny Salesforcesta vaan kumppanista, joka sen rakensi.
Varmasti tuttu asetelma: ratkaisu toimii, mutta kukaan omassa talossa ei täysin tiedä, miten se on tehty tai miksi juuri niin. Dokumentaatio on ohutta tai vanhentunutta, koska se on aina ollut erillistä työtä, joka jää tekemättä kiireen keskellä. Osaaminen on muutaman konsultin päässä. Kun paras heistä vaihtaa työpaikkaa, vuosien historia lähtee samasta ovesta. Uuden kumppanin sisäänajo veisi kuukausia, joten et vaihda, vaikka haluaisit.
Haluatko kuulla lisää tekoälyn hyödyntämisestä Salesforcen kehityksessä? Katso tästä maksuton webinaari Tekoäly Salesforce-kehityksessä →
Tekoäly voi myös pahentaa lukkoa
Rehellisyyden nimissä on huomioitava myös kolikon toinen puoli: tekoäly voi syventää kumppaniriippuvuutta yhtä hyvin kuin purkaa sen.
Hyvällä kumppanilla saa ja pitääkin olla oma menetelmä ja työkalupakki. Asiakkaalle tämä näkyy esimerkiksi toimitusten laadun tasaisuutena ja henkilövaihdosten (joita vääjäämättä joskus tulee) helppoutena.
Silloin olet vaihtanut yhden mustan laatikon, konsultin muistin, toiseen: kumppanin työkaluun. Lopputulos on sama: olet jumissa.
Ongelma ei ole siinä, että kumppanilla on oma tapa tehdä. Ongelma syntyy silloin, kun sen tuotos jää kumppanin puolelle: kun projektin logiikka, päätökset ja koodi elävät työkalussa tai kansiossa, johon et näe. Silloin olet vaihtanut yhden mustan laatikon, konsultin muistin, toiseen: kumppanin työkaluun. Lopputulos on sama: olet jumissa.
Siksi oikea kysymys päättäjälle ei ole ”käyttääkö kumppani tekoälyä”, eikä edes ”onko kumppanilla oma moottori”. Se on: jääkö sen moottorin tuotos sinun käsiisi vai kumppanin? Rakentaako kumppani riippuvuutta itsestään vai antaako se sinulle kaiken, mitä tarvitset ollaksesi riippumaton?
Mikä lukon oikeasti purkaa?
Ratkaiseva ero ei ole mallissa vaan siinä, miten kumppani tekee työnsä. Kolme asiaa kääntää tekoälyn sinun eduksesi.
Ensimmäinen on dokumentaatio, joka syntyy kehityksen sivutuotteena. Kun jokainen muutos, arkkitehtuuripäätös ja sen perustelu tallentuu automaattisesti työn edetessä. Esimerkiksi meillä jokainen päätös kirjautuu omaan päätöshistoriaansa sitä mukaa kun se tehdään ja dokumentaatio ei ole enää erillinen vaihe, joka jää tekemättä. Se elää ja on ajan tasalla, koska se syntyy samalla kun ratkaisu syntyy. Tieto ei asu kenenkään päässä vaan järjestelmässä.
Toinen on omistajuus. Kaiken materiaalin, koodin ja dokumentaation kuuluu olla asiakkaan hallussa koko ajan. Asiakkaan omassa repossa, ei kumppanin kansioissa. Kun lähtökohta on, että sinä omistat kaiken ja pääset siihen käsiksi milloin tahansa, kumppanilla ei ole mitään pantiksi otettavaa. Tämä on periaatteellinen valinta, ei tekninen yksityiskohta.
Kolmas on se, että tieto kattaa myös liiketoimintalogiikan, ei vain teknisen toteutuksen. Uusi sinun tai kumppanin työntekijä pääsee tekoälyn avustamana sisään päivissä eikä kuukausissa. Näin hän ymmärtää paitsi sen, miten ratkaisu on rakennettu, myös miksi: minkä prosessin se palvelee ja mikä on liiketoimintasyy sen takana. Juuri tämä ”miksi” on se, joka ennen katosi ihmisten mukana.

Jos paras konsultti lähtee, tieto jää.
Yhdessä nämä muuttavat osaamisen henkilöriippuvuudesta organisaation pääomaksi. Jos paras konsultti lähtee, tieto jää. Jos haluat vaihtaa kumppania, voit tehdä sen, koska historia on sinulla luettavassa ja ymmärrettävässä muodossa.
Entä kun projekti on ohi?
Kysymys, joka tulee vastaan lähes joka keskustelussa: ”Osaatte varmaan tehdä projektin, mutta mitä sen jälkeen, kun ympäristöä pitää ylläpitää ja kehittää eteenpäin?” Se on oikea kysymys ja juuri se paikka, jossa lock-in yleensä puree kovimmin. Projekti päättyy, mutta järjestelmä elää: tulee uusia tarpeita, integraatioita, Salesforcen kolme vuosipäivitystä, ja jonkun on ymmärrettävä mitä konepellin alla on. Perinteisessä mallissa se joku on kokonaisuuden rakentanut kumppani.
Esimerkiksi meillä Loikka Wayssa jälkihoito kääntyy päinvastoin, samasta syystä kuin lukko purkautuu: tieto on jo sinun hallussasi ja luettavassa muodossa. Kun ympäristöä pitää jatkokehittää, kuka tahansa osaava käsi, kuten oma adminisi, uusi Loikan tekijä tai vaikka kokonaan toinen kumppani, pääsee kiinni päivissä, koska päätöshistoria ja liiketoimintalogiikka ovat tallessa, eivät kadonneet edellisen tekijän mukana.
Sama malli myös estää ympäristöä rapautumasta. Jokainen jatkokehityksen aalto lisää dokumentaatioon sen sijaan että söisi sitä: muutokset kirjataan samalla kurilla kuin ensimmäiselläkin kerralla, joten tekninen velka pysyy näkyvissä eikä ylläpidosta tule vuosien takaisen koodin arkeologiaa. Jatkokehitys etenee samalla aaltorytmillä ja kiinteällä hinnalla kuin projekti, ei erillisenä, hämäränä ylläpitosopimuksena.
Ja jos haluat pitää meidät mukana, se on valinta eikä pakko. Jatkuvan palvelun malliimme kuuluu oma näkymä, josta tiimisi näkee ympäristön dokumentaation ja saa tekoälyavusteisesti vastauksen siihen miten mikäkin on rakennettu ja miksi. Lisäksi malliin kuuluu katselmointijono, jonka kautta jokainen muutos kulkee ihmisen tarkastuksen läpi ennen tuotantoa. Vastuu ei lepää yhden ihmisen varassa vaan talon ja prosessin, mikä ratkaisee erityisesti silloin kun hallinto ja compliance eivät salli henkilöriippuvuutta.
Ylläpito ja jatkokehitys eivät ole se hetki, jossa lukko napsahtaa kiinni. Ne ovat se hetki, jossa läpinäkyvä toimitus maksaa itsensä takaisin.
Ylläpito ja jatkokehitys eivät siis ole se hetki, jossa lukko napsahtaa kiinni. Ne ovat se hetki, jossa läpinäkyvä toimitus maksaa itsensä takaisin.
Mitä tämä tarkoittaa sinulle päättäjänä?
Käytännön johtopäätös on yksinkertainen. Valitessasi Salesforce-kumppania tekoälyn aikakaudella, älä kysy vain, kuinka nopeasti tai halvalla tämä tekee toimituksen. Kysy, mitä sinulle jää käteen, kun projekti päättyy.
Vaadi, että dokumentaatio syntyy työn mukana, ei erillisenä lupauksena ”projektin lopussa”. Vaadi, että kaikki materiaali ja koodi ovat omistuksessasi ja saatavillasi jatkuvasti. Ja testaa se aidosti: pyydä nähdä, kuinka nopeasti täysin uusi ihminen pääsee kärryille projektin tilanteesta. Jos vastaus on päiviä eikä kuukausia, riippuvuus on aidosti purettu.
Kannattaa valita kumppani, joka tekee itsestään korvattavan.
Tässä on lopulta terveellinen paradoksi. Kannattaa valita kumppani, joka tekee itsestään korvattavan. Se, joka ei pidä sinua panttivankina tiedon epäsymmetrialla vaan antaa kaiken käteesi, on juuri se, jonka kanssa todennäköisesti haluat jatkaa, koska valinta on silloin sinun. Tekoäly ei poista kumppanin tarvetta. Se muuttaa suhteen luonteen: lukosta luottamukseen.
Haluatko nähdä konkreettisesti, mitä teille jäisi käteen? Varaa aika suoraan kalenteristani →, niin käydään läpi, miltä läpinäkyvä Salesforce-toimitus näyttää.

