Viime kuukausien asiakaspalavereissa on toistunut sama kuvio. Joku avaa keskustelun, ja jossain vaiheessa nousee esiin kysymys: ”Te varmaan jo käytätte tekoälyä? Miten se nopeuttaa meidän Salesforce-projektia?”
Hyvä kysymys. Kun on käynyt asian läpi kymmenien organisaatioiden kanssa, alkaa hahmottua, että asiakkailla on kuva siitä, mitä tekoäly tarkoittaa Salesforce-kehityksessä. Ja usein tämä kuva ei vastaa täysin todellisuutta.
Yksinkertaisin oletus menee näin: kehittäjälle annetaan Claude tai vastaava työkalu, ja kehittäjä koodaa nopeammin. Tehokas konsultti + Claude = kaksinkertaisen tehokas konsultti.
Tämä oletus ei ole väärä. Se on vain karkea.
Kiinnostaako tekoäly? Lataa täältä maksuton ”Tekoälyagentin ostajan opas” →
Salesforce on iso kokonaisuus
Olen tehnyt pitkään asiakasprojekteja, joissa Apex-luokat, Flow-rakenteet, Lightning Web Componentit ja integraatiot syntyivät iteroinnin ja peer review:n kautta. Sandboxien välillä siirryttiin testattuna. Päivän muutos saattoi käydä viikon Sharing Rule -säätöjen kautta UAT:ssa ennen tuotantoa. Salesforce-ekosysteemissä on omat säännöt: governor limit -rajat, declarative-ratkaisujen suosiminen, Trust Layer, managed packages, ALM-prosessi. Tämä on syvä konteksti, jonka harva LLM tuntee ulkoa.
Salesforce-ekosysteemissä on omat säännöt. Tämä on syvä konteksti, jonka harva LLM tuntee ulkoa.
Mitä silloin tapahtuu, kun konsultille annetaan Claude ja sanotaan ”tee nopeammin”? Olen ehtinyt nähdä muutaman tyypillisen ongelman:
Demoissa näyttää hyvältä, tuotannossa kompastutaan esimerkiksi org-spesifeihin asioihin: custom fieldien rajoituksiin, validation rule -konflikteihin, integraatioiden timeouteihin. Asioihin, jotka eivät näy mock-pohjaisesta yksikkötestistä. Tekoäly on hyvä piirtämään puhdasta ratkaisua. Se ei piirrä niitä satoja pikkujuttuja, jotka sisäinen admin tietää ulkoa.
Hallusinaatiot ovat Salesforcessa erityisen ovelia. Kun Claude generoi Apex-koodia, se saattaa kutsua API:ta jota ei ole olemassa, tai viitata custom objektiin nimellä joka kuulostaa loogiselta mutta ei ole asiakkaan orgissa. Yleisessä Java- tai Python-tilanteessa kääntäminen nappaa tyypilliset virheet. Apex-deployment voi mennä läpi näennäisen puhtaasti ja paljastua vasta käytössä, koska väärä koodi näyttää melkein aina oikealta.
Vastuukysymys jää helposti epäselväksi. Kuka vastaa siitä, että tekoälyn tekemä koodi menee tuotantoon? Onko code review tehty? Onko arkkitehtuuripäätös jäljitettävissä jälkikäteen, jos asiakas kysyy puolen vuoden päästä, miksi jokin asia tehtiin tietyllä tavalla?
Skaalassa ongelma kasvaa. Yksi konsultti yhden tiketin kanssa Claude-avusteisesti on hallittavissa. Kun samassa orgissa on viisi konsulttia, kaksi sisäistä kehittäjää ja jokainen pyytää Claudelta mitä lystää, päädytään tilanteeseen jossa sama ongelma ratkaistaan kymmenellä eri tavalla. Salesforce-ekosysteemissä, jossa declarative-ratkaisut ja yhtenäisyys ovat kullanarvoisia, tämä ei ole pieni asia.
Tekoäly vaatii uuden tavan tehdä
Kun aloimme pohtia, miten tekoäly hyödyttäisi Salesforce-toimituksia, tulimme aika nopeasti siihen tulokseen, että uusi työkalu vaatii uuden toimitusmallin. Sähköposti ei ollut vain nopeampi kirje. AI ei ole vain nopeampi kehittäjä. Se muuttaa tekemistä.
Kun aloimme pohtia, miten tekoäly hyödyttäisi Salesforce-toimituksia, tulimme aika nopeasti siihen tulokseen, että uusi työkalu vaatii uuden toimitusmallin.
Lähdimme rakentamaan toimitusmallia, jota kutsumme nimellä Loikka Way. Se lähtee yksinkertaisesta työnjaosta: ihminen päättää, AI tekee. Loikan asiantuntija vetää projektia, tekoäly toimii kehittäjänä, QA on ihminen ja AI yhdessä, ja yksikään muutos ei mene tuotantoon ilman ihmisen hyväksyntää.
Kuulostaa yksinkertaiselta. Käytännössä se vaatii muutaman muun asian päälleen:
- Sprintit ovat päivän mittaisia, eivät kahden viikon. Kun AI generoi merkittävän osan koodista, palautteen pitää tulla nopeasti tai riskinä on rakentaa väärää asiaa nopeammin. Päivän sykli pakottaa pieniin, hallittaviin aaltoihin.
- Definition of Done sisältää pakollisen tuotantotestauksen ennen sulkua. Live-verify oikealla datalla, jotta ne org-spesifiset ongelmat eivät jää lurkkimaan käyttöönoton alle. Tämä on se kohta joka käytännössä erottaa ”demoissa toimii” -ratkaisut tuotantokelpoisista.
- Päätökset kirjataan Architecture Decision Record -järjestelmään, jokainen niistä. Tekoäly ei muista, miksi jokin asia tehtiin tietyllä tavalla, eikä asiantuntijan tarvitse luottaa muistinsa varaan kuusi kuukautta myöhemmin. Vastaus löytyy gitistä.
- Hinnoittelu on kiinteä per vaihe. Asiakkaan budjetti on tiedossa ennen aloitusta. Iso ero T&M-malliin, jossa tekoälyn tehokkuus näkyy myynnin marginaalissa eikä asiakkaan hyödyssä. Jos malli oikeasti nopeuttaa kehitystä, sen pitää näkyä myös lopullisessa hinnassa.
Tämän päälle malli nojaa siihen mitä olemme rakentaneet sisäisesti vuosien aikana: asiantuntijatiimin yhteiseen työkalupakkiin joka oppii joka projektissa, ja jonka ansiosta sama kuri pysyy kasassa kun sama malli toistuu kymmenissä toimituksissa.
Lopputuloksena tyypillinen kokonaisprojekti vie noin 5–8 viikkoa siinä missä perinteinen toteutus 3–4 kuukautta. Tärkeämpää on kuitenkin se, että lopputulos on laadultaan parempi, koska kuri pakottaa vastaamaan niihin kysymyksiin joista tekoäly itsessään ei välitä.
Mutta eikö riittäisi yksi senior + Claude?
Tämä kysymys nousee esiin aina jossain vaiheessa, ja se ansaitsee suoran vastauksen. Jos malli on noinkin yksinkertainen (päivän sprintit, ADR, tuotantotesti, ihminen hyväksyy) miksi asiakas ei vain palkkaisi Suomen kovinta SF-arkkitehtia, antaisi hänelle Claude Maxin ja säästäisi konsulttihintojen päältä?
Kysymys on hyvä ja olen pyöritellyt sitä itsekin. Vastaus on, että Loikka Way ei ole sääntökirja jonka voi monistaa yhdelle ihmiselle. Se on neljän asian summa.
- Sisäinen työkalupakki. Vuosien aikana meille on kertynyt kerros työkaluja, malleja ja muistia, jonka päälle uusi projekti rakennetaan. Yksittäisen seniorin pitäisi rakentaa tämä itse työn ohella, ja siihen kuluu vuosia.
- Portfolio-oppi. 15 konsulttia näkee 20+ orgia samanaikaisesti. Yksittäinen senior näkee yhtä kerrallaan. Joka kerta kun joku tiimissämme ratkaisee jotain uutta, oppi siirtyy seuraaviin projekteihin heti. Yksin tätä ei saa.
- Jatkuvuus ja vastuu. Yksi rockstar sairastuu, irtisanoutuu tai lukkiutuu yhteen näkemykseen. Talo kantaa toteutusvastuun viideksi vuodeksi eteenpäin, kahdellakymmenellä asiantuntijalla, prosessi takana. Tämä on iso asia varsinkin isoissa organisaatioissa, jossa GRC-puoli ei salli yhden henkilön riippuvuutta.
- Skaalautuvuus. Iso projekti tarvitsee samaan aikaan integraatiokerroksen, datakerroksen ja UI-kerroksen tekijät. Yksi senior on pullonkaula. Tiimi joka pelaa saman Loikka Way -kurin alla pystyy rinnakkaistamaan ilman että lopputulos hajoaa.
Yksi kova kaveri + Claude on hyvä kombo SMB-projektiin tai yhden moduulin laajentamiseen.
Yksi kova kaveri + Claude on hyvä kombo SMB-projektiin tai yhden moduulin laajentamiseen. Ison organisaation SF-muutosohjelmaan se ei vain riitä, vaikka kaveri olisi miten kova.
Mitä Salesforce-asiakkaan kannattaa miettiä
Jos olet itse pohtimassa, miten tekoäly voisi auttaa teidän Salesforce-projekteissa, kannattaa ajatella laajemmin kuin ”miten saamme konsulteille Claude käyttöön”. Kysymys jota itse haastaisin on tämä: mitä toimitusmallinne vaatisi muuttuakseen, jotta tekoäly oikeasti tuottaisi arvoa? Mihin haluatte panostaa, mitä jättää AI:lle? Miten asiakkaan oma admin sopii kuvioon?
Salesforce-ekosysteemissä on iso etu siinä, että pohja on jo olemassa. ALM-prosessi, sandboxit, declarative-työkalut, Trust Layer. Nämä eivät katoa tekoälyn myötä, vaan ovat se runko, jonka päälle tekoäly saadaan toimimaan luotettavasti. Kunhan vain rakenne, roolit ja kuri ovat kunnossa.
Salesforce-ekosysteemissä on iso etu siinä, että pohja on jo olemassa. Nämä eivät katoa tekoälyn myötä.
Tekoäly ei korvaa kahdenkymmenen vuoden Salesforce-osaamista. Se kerryttää sitä, mutta vain jos osaa ohjata sitä siellä missä se oikeasti hyödyttää. Loput on toimitusmallin tehtävä.
Jos tämä herätti ajatuksia tai haluat sparrata oman organisaation tilanteesta, ole rohkeasti yhteydessä. Loikka tapaa Salesforce-asiakkaita ja partnereita Agentforce World Tourilla 12. toukokuuta Helsingissä. Voit myös varata 30 minuutin maksuttoman sparrauksen loikka.com/way.
