Miten tekoälykonsultit määrittelevät talon sisäisen SaaS-korvaajan laajuuden

Jokainen päiväpalkkansa arvoinen konsultti kartoittaa talon sisäisen SaaS-korvaamisen samalla tavalla: jakamalla jokaisen työkalun osiin, jotka voit nähdä, ja osiin, joiden on oltava aina oikein. SaaS (kuukausivuokralla hankittava ohjelmisto) koostuu pääasiassa näytöistä, työnkuluista ja raporteista, jotka sijaitsevat pienemmän kirjanpidollisen ytimen päällä. Tekoäly on tehnyt ensimmäisen puolikkaan uudelleenrakentamisesta halpaa. Toisessa puolikkaassa korvaushankkeet kuolevat, ja hyvän laajuusmääritelmän tarkoitus on mitata, kuinka suuri osa tilauslaskustasi todellisuudessa asuu siellä.

Nämä ovat vaiheet, joilla talon sisäisen SaaS-korvaushankkeen laajuus muodostuu, sekä se yksi kysymys, joka ratkaisee suurimman osan siitä. (Alla olevat toimittajien nimet ja kyselytulokset pitävät paikkansa julkaisuhetkellä; suhtaudu yksityiskohtiin tilannekatsauksena.)

Mitä SaaS-korvaushankkeen laajuusmääritelmä todellisuudessa sisältää?

Luettelon tehtävistä, ei ominaisuuslistaa. Konsultti listaa jokaisen työkalun suorittaman tehtävän, kuka kumpaankin koskee ja mitä tapahtuu, kun sen tulos on väärä. Hyväksyntäketjut, koontinäytöt ja lomakkeet menevät yhteen sarakkeeseen. Rahansiirrot, varastosaldot, verot ja työntekijätiedot menevät toiseen. Toimitettava tulos on kyseinen kartta, riskiluokitus tehtävää kohden ja lista jokaisesta järjestelmästä, johon työkalu on vähin äänin kytketty.

Arviointikysymys ratkaisee kaiken: jos tämä tulos olisi väärä, miten saisit sen selville ja mitä se maksaisi? Vanhentunut koontinäyttö huomataan silmäyksellä eikä se maksa mitään. Väärä tilityksen loppusumma huomataan veroaikaan ja se maksaa oikeaa rahaa.

Miksi tuote kannattaa jakaa kahteen kerrokseen?

Koska tekoäly romahdutti toisen kerroksen kustannukset ja jätti toisen ennalleen. Käyttöliittymäkerros (lomakkeet, koontinäytöt, sisäiset työkalut, hyväksyntätyönkulut) on nyt nopea rakentaa uudelleen; nykyiset mallit luovat toimivia verkkosovelluksia tunneissa, minkä huomasimme kysyessämme, voiko GPT-5.6 rakentaa toimivan POS-järjestelmän. Infrastruktuurikerros on toisenlainen: maksunvälitys, PCI-vaatimustenmukaisuus (maksukorttiturvallisuuden säännöt, joita maksunvälittäjät edellyttävät), varastonhallinta samanaikaisuustilanteissa (kaksi kassaa myymässä samaa viimeistä tuotetta) ja täsmäyttävät raportit (loppusummat, jotka täsmäävät pankkitalletukseesi). Kyseinen kerros ei ole vaikea siksi, että koodia olisi paljon. Se on vaikea siksi, että 'melkein oikein' ei ole siellä minkään arvoista, ja oikeellisuuden todentaminen maksaa enemmän kuin koodin generointi.

Paremmatkaan mallit eivät poista tätä rajoitetta. Pullonkaulana on varmentaminen ja vastuullisuus, ei koodin generointi, joten rehellinen laajuusmääritelmä hinnoittelee varmentamisen. Generointi on demo. Varmentaminen on lasku.

Mitä Klarnan SaaS-korvaushanke todellisuudessa todisti?

Äänekkäin "korvasimme SaaS-järjestelmämme tekoälyllä" -tarina on todellisuudessa opetus laajuuden määrittelystä. Vuoden 2024 lopussa Klarnan toimitusjohtaja ilmoitti yhtiön luopuvan Salesforcesta ja Workdaysta osana tekoälyuudistusta, ja otsikoissa uutisoitiin tekoälyn korvaavan SaaS-järjestelmät täysin. Jälkiraportointi paljasti jotain rajatumpaa: Klarna siirsi henkilöstöhallinnon toiselle toimittajalle ja kattoi CRM-tarpeensa vaihtoehtoisten työkalujen ja sisäisten liitoskoodien yhdistelmällä, jonka päälle kerrostettiin tekoälyä¹. Toimiluvan saanut pankki, joka toteuttaa yhtä fintech-alan aggressiivisimmista tekoälyohjelmista, piti silti järjestelmänsä (liiketoimintatietojesi virallisen kantaversiot) koetuilla alustoilla ja rakensi uudelleen vain reunoilta.

Kyse ei ollut rohkeuden puutteesta. Kyse oli siitä, että laajuusmääritelmä toimi.

Mitkä luvut oikeuttavat korvaushankkeen?

Ensin hukan karsinta, sitten vasta rakentaminen. Zylon vuoden 2026 SaaS Management Index, joka perustuu yli 40 miljoonan hallinnoidun lisenssin dataan, osoittaa SaaS-menojen mediaaniksi 9 455 dollaria työntekijää kohden vuodessa, paljastaa keskimäärin 36 prosentin lisensseistä olevan käyttämättöminä ja näyttää liiketoimintayksiköiden hallitsevan 81 prosenttia SaaS-menoista IT-osaston hallitessa suoraan vain 15 prosenttia². Konsultti suhteuttaa ohjelmistopinon näihin lukuihin ennen minkään ehdottamista: peruuta käyttämättömät lisenssit, yhdistä päällekkäiset työkalut ja valitse vasta sitten ehdokkaat uudelleenrakentamiseen.

Jatkoon pääsevillä työkaluilla on yhteinen profiili: korkea toistuva kustannus, tehtävät jotka sijoittuvat pääosin käyttöliittymäkerrokseen, ja pieni vaikutusalue, jos jokin rikkoontuu. Hanke hyväksytään, kun tilauskustannus kasvaa nopeammin kuin rakentamis- ja ylläpitokustannus, ja jokainen 'aina oikein' -tehtävä voi pysyä infrastruktuurissa, jota joku muu jo pyörittää.

Mihin kohtaan POS sijoittuu tässä laajuusmääritelmässä?

Asteikon armottomimpaan päähän. Kassajärjestelmä (POS) näyttää käyttöliittymähankkeelta – painikeristikolta ja ostoskorilta – joten omistajat olettavat sen määrittyvän kuin koontinäyttö. Suhde on kuitenkin päinvastainen. Kassatapahtuma-näyttö on vain pieni siivu tuotteesta; loppuosa on maksuja, sertifioitua korttimaksulaitteistoa, varastonhallintaa, joka kestää kahden kassan samanaikaisen myynnin, verosääntöjä ja päivänpäätösraportteja, jotka täsmäävät. Kun POS-järjestelmä on väärässä, se on väärässä rahasta – päivittäin.

Konsultit määrittelevät POS-uudelleenrakentamisen laajuuden samalla tavalla kuin Klarna määritteli pääkirjanpitonsa: mukautettu käyttöliittymä, koettu infrastruktuuri. Tämä jako vaati ennen kehitystiimin. Nyt se on tuotekategoria: Final's Build muuttaa selkokielisen kehotteen kassavuoksi, jota voit esikatsella ja ottaa käyttöön, ja voit yhdistää oman tekoälysi MCP:n kautta rakentaaksesi samaa kaupankäyntiin tarkoitettua infrastruktuuria vasten. Maksut, varastonhallinta, raportointi ja laitteisto pysyvät kerroksessa, joka on jo todennettu.

Miten talon sisäisen SaaS-korvaamisen laajuus siis pitäisi määritellä?

Jaa jokainen työkalu sen kahteen kerrokseen, luokittele jokainen tehtävä havaitsemattoman virheellisen tuloksen kustannusten mukaan ja hinnoittele koodin sijaan varmentaminen. Rakenna käyttöliittymät ja työnkulut vapaasti uudelleen; jätä järjestelmät infrastruktuuriin, jonka oikeellisuudesta joku muu huolehtii. Ennen kuin rakennat mitään työkalua uudelleen talon sisällä, kysy: jos sen tulos olisi väärä, kuinka nopeasti tietäisit sen? Jos vastaus on "en nopeasti", kyseinen tehtävä pysyy koetuilla raiteilla.

Ja jos järjestelmäpinosi kaupankäyntipää on se osa, jonka haluat rakentaa uudelleen, aloita tarkastelemalla rehellisesti sitä, mitä nykyiset mallit voivat ja eivät voi rakentaa itse: Claude vs ChatGPT vs Gemini aidossa POS-rakennuksessa tai kaksi no-code-reittiä artikkelissa miten käyttää Gemini 3.6 Flashia mukautetun POS-järjestelmän rakentamiseen.