Fra 70 %-løsninger til skræddersyet kode.

Når en løsning vurderes, bliver den vurderet på sin pris. Men prisen er kun den første post. Den fulde ejerudgift, TCO, består af licenser, implementering, tilpasning af arbejdsgange, uddannelse, vedligeholdelse, fejlretning, tabt omsætning under skift og til sidst omkostningen ved at komme ud igen.

Det er de sidste poster, der afgør, om en løsning var billig. En app til 500 kr. om måneden, der kræver tyve timers manuelt arbejde om måneden for at passe, er ikke en app til 500 kr. Den er en app til 500 kr. plus tyve timers løn. Over tre år er det sjældent den billigste beslutning, man har taget.

En 70 %-løsning dækker de fleste tilfælde. Udfordringen er, at forretninger sjældent består af de fleste tilfælde, de består af deres egne. De ordrer, der ikke passer i skabelonen, bliver ikke afvist. De bliver håndteret manuelt, og hver manuel håndtering er en lille, fast afgift, der aldrig forsvinder.

Sådan ser de 30 % ud

• Priser, der rettes i hånden, fordi rabatmotoren ikke kan udtrykke aftalen.
• Ordrer, der flyttes mellem systemer med CSV-filer og copy-paste.
• Kundeservice, der skal slå op i to dashboards for at svare på ét spørgsmål.
• En månedlig rapport, der bygges i et regneark, fordi systemet ikke kan levere den.

Når de 30 % først håndteres uden for systemet, opstår der et integrationslag uden en arkitekt. En Zap her, en eksportfil der, et regneark der bindes sammen af en medarbejder, der ved hvordan. Forretningen begynder at køre på midlertidige aftaler mellem systemer, og hver ny løsning skal forbindes til alle de foregående.

Det er der, TCO'en eksploderer. Hvert knudepunkt er et sted, hvor data kan blive forkerte, og ingen kan svare på, hvilken version af en kunde der er den rigtige. Ikke fordi nogen har gjort noget dumt, men fordi intet af det var tænkt som en samlet arkitektur, det var bare altid den hurtigste vej videre.

Og de skjulte omkostninger forsvinder ikke, når systemet skifter. De flytter med. En ny platform uden de rigtige integrationer arver de samme manuelle arbejdsgange og de samme fejlkilder, nu bare med en ny brugerflade og en ny faktura. Derfor skal TCO’en regnes på forretningens processer, ikke på produktets funktionsliste.

Den enkle tommelfingerregel er: lej det, der er almindeligt, og byg det, der er dit. Betalingsgateway, fragt, faktura og e-mail er infrastruktur, alle har brug for, og hvor det rigtige svar næsten altid er at købe. Købsflow, prissætning, loyalitetslogik, kundedata og de arbejdsgange, der gør forretningen speciel, er derimod steder, hvor en standardløsning sjældent kan udtrykke det, der gør dig anderledes.

Spørgsmålene, der afgør det

1. Er funktionen en del af det, kunderne vælger os for? Så byg den.
2. Er den en livline, vi kan skifte ud uden skade? Så lej den.
3. Hvad koster det at komme ud igen, hvis vi vælger forkert?
4. Hvor mange arbejdstimer flytter løsningen over på mennesker, hver måned, de næste tre år?

Svaret er sjældent alt eller intet. De fleste forretninger ender med en hybrid: infrastrukturen lejes, og de processer, der gør dem specielle, bygges. Det er den fordeling, der skal være bevidst, ikke tilfældig.

Sæt alle poster ind i samme regnestykke: licenser over tre år, implementeringstid, de manuelle timer i dag, den forventede fejlrate, den tabte omsætning ved en forsinket lancering, og hvad det vil koste at trække data ud igen. Først når de tal står side om side med et skræddersyet alternativ, er valget et valg, og ikke en vane.

Den dyreste løsning er sjældent den, der står på fakturaen. Det er den, ingen skrev ned, fordi den var midlertidig.