Når virksomheder sammenligner IT-løsninger, begynder samtalen ofte med prisen. Hvad koster licensen? Hvad koster implementeringen? Hvor mange konsulenttimer kræver projektet? Og hvilken leverandør kan levere det billigst?
Det er selvfølgelig relevante spørgsmål. Ingen virksomhed har ubegrænsede penge, og IT bør ikke være fritaget for almindelig økonomisk disciplin, bare fordi teknologien er kompleks. Problemet opstår først, når prisen på indkøbstidspunktet bliver forvekslet med den reelle omkostning ved beslutningen.
For teknologi har en irriterende egenskab: Den bliver hængende.
Den løsning, der ser billigst ud i budgetarket i år ét, kan påvirke organisationens omkostninger, kompetencebehov, sikkerhed, integrationsmuligheder og handlefrihed i mange år frem. Og nogle af de dyreste konsekvenser står sjældent på leverandørens tilbud.
Det er derfor, jeg mener, at den billigste IT-løsning sagtens kan være den dyreste beslutning.
Pris og omkostning er ikke det samme
Der er en vigtig forskel på, hvad noget koster at købe, og hvad det koster at eje.
Det lyder næsten banalt, men i praksis bliver forskellen ofte overset, fordi anskaffelsesprisen er nem at måle. Den står på en faktura og kan placeres direkte i et budget. Omkostningerne ved kompleksitet, drift, integrationer, kompetencer og fremtidige ændringer er langt vanskeligere at sætte et præcist tal på.
Det gør dem ikke mindre virkelige.
En løsning med en lav licenspris kan eksempelvis kræve mere manuel administration. Et billigt standardsystem kan have begrænsede integrationsmuligheder, så virksomheden senere skal bygge og vedligeholde specialintegrationer. En platform kan være billig i starten, men kræve kompetencer, som organisationen ikke allerede har. Eller en løsning kan være så tæt koblet til en bestemt leverandør, at prisen på at skifte senere bliver langt højere end den oprindelige besparelse.
Det interessante spørgsmål er derfor sjældent bare:
Hvad koster løsningen?
Det mere nyttige spørgsmål er, hvad beslutningen kommer til at koste organisationen over tid.
Den billigste løsning kan skabe dyr kompleksitet
Jeg har gennem mange år arbejdet med IT-miljøer, hvor næsten hver enkelt teknisk beslutning isoleret set kunne forklares fornuftigt. Problemet opstod først, når man så på summen, hvilket der stort set aldrig var nogen i ledelsen, der gjorde.
Et system blev valgt, fordi det var billigere. Et andet fordi det kunne implementeres hurtigt. En tredje løsning blev købt, fordi en afdeling havde et akut behov, og en fjerde fordi den allerede var dækket af en eksisterende rammeaftale.
Ingen af beslutningerne behøvede at være dårlige.
Men efter nogle år stod organisationen måske med flere identitetsløsninger, overlappende værktøjer, forskellige integrationsmønstre, parallelle databaser og en samling specialprocesser, som kun ganske få mennesker forstod.
Den enkelte besparelse var reel.
Det var kompleksiteten også.
Og kompleksitet fungerer lidt som renter. Den bliver betalt igen og igen gennem længere fejlsøgning, vanskeligere ændringer, flere kompetencebehov, højere sikkerhedsrisiko og et større antal afhængigheder, som skal forstås, hver gang noget skal ændres.
Det er en af grundene til, at lokal optimering kan være farlig i IT. En afdeling kan sagtens spare penge på sin egen løsning og samtidig gøre virksomheden som helhed dyrere at drive.
IT-økonomi er mere end licenser
Begrebet Total Cost of Ownership er ikke nyt, og de fleste større virksomheder arbejder selvfølgelig allerede med det i en eller anden form. Alligevel synes jeg ofte, at TCO-beregninger bliver for snævre.
Vi tager licenserne med. Implementeringen. Måske drift og support.
Men de mere indirekte omkostninger er vanskeligere.
Hvad koster det eksempelvis, at løsningen kræver en sjælden kompetence, som kun to medarbejdere har? Hvad koster det, hvis onboarding tager længere tid, fordi teknologilandskabet er fragmenteret? Hvad koster en platform, der gør integrationer mere komplekse? Hvad koster det, hvis udviklingsteams bruger mere tid på platformproblemer end på at skabe funktionalitet for kunderne?
Og måske vigtigst: Hvad koster løsningen den dag, virksomheden vil noget andet?
Den sidste del synes jeg ofte bliver undervurderet.
En teknologisk beslutning har nemlig ikke kun en driftsomkostning. Den har også en forandringsomkostning.
Hvad koster det at ændre mening?
Jeg synes, en af de mest interessante økonomiske egenskaber ved IT-arkitektur er, hvor dyrt det kan blive at ændre en tidligere beslutning.
Hvis en virksomhed vælger et CRM-system, en cloud-platform, et ERP-system eller en integrationsarkitektur, bliver beslutningen gradvist vævet ind i organisationen. Data flytter ind. Processer bliver bygget omkring løsningen. Integrationer kobles på. Medarbejdere uddannes, og andre systemer begynder at forudsætte, at platformen eksisterer.
Efter nogle år er prisen på produktet måske den mindst interessante del af relationen.
Det dyre er at komme væk.
Det betyder ikke, at leverandørafhængighed altid er forkert. Nogle gange er det fuldstændig rationelt at acceptere lock-in, hvis gevinsterne er store nok. Alle teknologiske valg skaber på den ene eller anden måde afhængigheder.
Men afhængigheden bør være en bevidst del af beslutningen.
Hvis en løsning sparer virksomheden en million kroner i dag, men samtidig gør en fremtidig ændring ti millioner dyrere, er det relevant at vide, før man fejrer besparelsen.
God arkitektur handler derfor blandt andet om at forstå, hvilke døre en beslutning åbner, og hvilke den langsomt lukker.
Billig drift kan være dyr for forretningen
Der findes også en anden form for besparelse, som jeg synes er interessant: Den lokale IT-besparelse, der flytter omkostningen ud i resten af organisationen.
Forestil dig, at IT vælger en billigere løsning, som kræver lidt flere manuelle trin. Hvis de ekstra trin kun tager fem minutter, virker det måske ubetydeligt. Men hvis 2.000 medarbejdere udfører dem hver uge, er besparelsen pludselig ikke længere kun et spørgsmål om IT-budgettet.
Det samme gælder dårlige brugeroplevelser, langsomme systemer og processer, der kræver unødvendig dobbeltregistrering. De står sjældent som en linje i IT-regnskabet, men virksomheden betaler stadig regningen i form af arbejdstid, frustration og lavere produktivitet.
Det er derfor, jeg bliver skeptisk, når IT udelukkende bliver målt på, om afdelingens egne omkostninger falder.
En IT-afdeling kan godt blive billigere, samtidig med at virksomheden bliver dyrere at drive.
Hvis økonomistyringen ikke kan se den forskel, risikerer vi at optimere præcis den forkerte ting.
Besparelser kan også skabe teknisk gæld
Der er selvfølgelig situationer, hvor den hurtige og billige løsning er den rigtige.
Hvis virksomheden skal teste et nyt marked, løse et midlertidigt problem eller reagere hurtigt på en ændring, kan det være helt rationelt at acceptere en løsning, som ikke er perfekt på lang sigt. Jeg har tidligere skrevet om teknisk gæld, og pointen er den samme her: Gæld er ikke nødvendigvis et problem, hvis man ved, at man tager den på sig.
Problemet opstår, når en midlertidig besparelse bliver permanent arkitektur uden nogen egentlig beslutning.
Vi vælger den billige løsning nu og lover at rydde op senere. Næste år kommer der andre prioriteter. Systemet får flere brugere, flere integrationer og flere afhængigheder, og efter nogle år er den løsning, der oprindeligt skulle være midlertidig, blevet så central, at ingen længere tør røre den.
Så har den oprindelige besparelse fået renter.
Og IT ender ofte med at betale dem gennem drift, kompleksitet og langsommere udvikling.
Det er ikke nødvendigvis teknikkens skyld. Det er et resultat af de prioriteringer, organisationen har lavet over tid.
Procurement og arkitektur skal tale sammen
Indkøb spiller naturligvis en vigtig rolle i større teknologibeslutninger. Gode indkøbsfolk kan skabe konkurrence, presse leverandører og sikre kontraktmæssige vilkår, som IT selv måske ikke ville få på plads.
Men der opstår et problem, hvis teknologikøb primært behandles som køb af almindelige varer.
En server, platform eller SaaS-løsning kan måske ligne endnu et produkt på et regneark, men de arkitektoniske konsekvenser kan være meget forskellige. To løsninger, der tilsyneladende løser den samme funktion, kan skabe vidt forskellige behov for integration, sikkerhed, kompetencer og drift.
Derfor bør procurement, økonomi og arkitektur ikke være modstandere i en teknologisk beslutning. De ser forskellige dele af samme problem.
Indkøb kan spørge, om prisen er konkurrencedygtig.
Økonomi kan spørge, om business casen hænger sammen.
Arkitekturen bør spørge, hvad beslutningen gør ved resten af teknologilandskabet.
Ingen af perspektiverne er tilstrækkelige alene.
Vi skal heller ikke romantisere den dyre løsning
Det modsatte argument er selvfølgelig lige så vigtigt.
At den billigste løsning kan være dyr, betyder ikke, at den dyreste automatisk er god.
IT-branchen har bestemt også sin del af overengineering, prestigeprojekter og teknologivalg, hvor organisationer køber enterprise-løsninger til problemer, der kunne være løst langt enklere.
Nogle gange er den billige løsning faktisk den bedste.
Hvis to produkter reelt løser det samme problem, skaber de samme afhængigheder og kræver omtrent den samme indsats at drive, er det svært at argumentere imod at vælge den billigste.
Pointen er derfor ikke, at virksomheder skal stoppe med at fokusere på pris.
Pointen er, at pris skal vurderes i den rigtige kontekst.
En dyr løsning uden tilsvarende værdi er bare dyr.
En billig løsning, der skaber store følgeomkostninger, er heller ikke billig.
God teknologiledelse handler om at forstå forskellen.
Hvilken omkostning flytter vi?
Jeg synes, et af de bedste spørgsmål i diskussioner om IT-besparelser er:
Hvilken omkostning flytter vi?
Hvis vi reducerer licensomkostningen, stiger driftsarbejdet så?
Hvis vi standardiserer på en billigere platform, øger vi behovet for specialudvikling?
Hvis vi outsourcer en funktion, mister vi så kompetencer, som bliver dyre at genopbygge senere?
Hvis vi udskyder en modernisering, betaler vi så mere gennem teknisk gæld?
Og hvis vi sparer penge i IT, bruger medarbejderne så mere tid på manuelle processer?
Det er ikke sikkert, at der er noget galt med at flytte omkostningen. Det kan sagtens være den rigtige beslutning. Men vi bør vide, at det er det, vi gør. For organisationer bliver let begejstrede over en besparelse, hvis den forsvinder fra ét budget, selv om regningen bare dukker op et andet sted.
Den økonomisk bedste løsning understøtter strategien
I sidste ende synes jeg, teknologiske investeringer bør vurderes i forhold til det, virksomheden faktisk forsøger at opnå.
Hvis strategien handler om hurtig vækst, kan skalerbarhed og time-to-market være vigtigere end den laveste driftspris. Hvis virksomheden opererer i et stærkt reguleret marked, kan sikkerhed og compliance vægte langt mere. Hvis konkurrenceevnen afhænger af konstant produktudvikling, kan developer experience og evnen til hurtigt at ændre systemerne have en meget reel økonomisk værdi.
Der findes derfor ikke én universel definition på den billigste teknologi.
Den afhænger af, hvad virksomheden værdsætter.
En løsning, der er økonomisk attraktiv for én organisation, kan være dyr for en anden, fordi deres risici, kompetencer og strategiske mål er forskellige.
Det er også derfor, jeg synes, IT-økonomi bliver interessant, når den bevæger sig væk fra kun at handle om budgetter og begynder at handle om muligheder.
Besparelser må ikke ødelægge handlefriheden
En af de værdier, jeg synes er sværest at sætte på et regneark, er handlefrihed.
Hvad er det værd, at virksomheden relativt hurtigt kan ændre retning? At et nyt produkt kan lanceres uden først at genbygge halvdelen af IT-landskabet? At en leverandør kan udskiftes? At en virksomhed kan opkøbe en anden og faktisk integrere systemerne uden et treårigt projekt?
Det er svært at sætte et præcist beløb på den slags, og derfor taber det nemt til en konkret besparelse, der kan dokumenteres her og nu.
Men manglende handlefrihed bliver meget konkret den dag, virksomheden får brug for den.
På det tidspunkt er det for sent at købe den billigt.
Det er en af grundene til, at jeg ser arkitektur som mere end en teknisk disciplin. Den handler også om økonomi, fordi de beslutninger, vi træffer i dag, påvirker prisen på de muligheder, virksomheden har i morgen.
Den billigste beslutning findes først bagefter
Det paradoksale ved teknologiske beslutninger er, at vi sjældent kan kende deres fulde økonomi på forhånd.
Vi laver business cases, estimater og TCO-modeller, og det skal vi selvfølgelig fortsætte med. Men verden ændrer sig. Virksomheden ændrer sig. Teknologien ændrer sig. Nogle af de vigtigste omkostninger og muligheder viser sig først flere år senere.
Derfor tror jeg ikke, målet bør være at finde den løsning, der på papiret er billigst.
Målet bør være at træffe en beslutning, hvor vi forstår så meget som muligt af det, vi køber os ind i: prisen, kompleksiteten, afhængighederne, driften, risikoen og den fremtidige handlefrihed.
Det kræver, at IT kan tale økonomi uden kun at tale licenspriser, og at økonomi kan diskutere teknologi uden kun at se på den næste budgetperiode. Det kræver også arkitekter, der kan forklare tekniske konsekvenser som forretningsmæssige konsekvenser i stedet for at forvente, at resten af organisationen bliver begejstret for et arkitekturdiagram.
For den dyreste teknologiske beslutning er ikke nødvendigvis den med den største faktura.
Det kan lige så godt være den billige beslutning, som organisationen kommer til at betale for igen og igen.
Pris fortæller os, hvad løsningen koster i dag. En god teknologisk beslutning kræver, at vi også spørger, hvad den kan komme til at koste os i morgen.