En IT-leverantör består av lager av arbete som har lite med varandra att göra. Det finns byggande och underhåll av kod, det finns hantering av ärenden och incidenter, det finns arkitektur och design, det finns projektledning gentemot kunden, och det finns presales: offerter, proof of concepts, teknisk underbyggnad av en upphandling. Timmarna för dessa kategorier varierar enormt per uppdrag. En supportavdelning drivs av volym och upprepning. Ett arkitekturteam drivs av ett litet antal personer med mycket erfarenhet. Utfallet av en affär styrs av vilket av dessa lager kunden lägger störst vikt vid, och det varierar per upphandling, per kund och per tidpunkt i projektet.
De tre kategorierna som gäller överallt — AI övertar uppgiften, AI arbetar fram ett resultat som en människa godkänner eller avvisar, eller arbetet förblir mänskligt arbete — löper tvärs igenom IT-sektorn, och inte jämnt fördelat. Ärendehantering för kända problem går delvis att automatisera; den första triageringen, igenkänningen av ett mönster, framtagandet av en lösning från tidigare ärenden. Kodgenerering för rutinmässiga delar av mjukvara förskjuts mot AI med en granskare som godkänner resultatet. Arkitekturbeslut, översättningen av en vag kundönskan till ett fungerande system, och upprätthållandet av förtroende hos en uppdragsgivare förblir tills vidare mänskligt arbete, eftersom det där krävs ett omdöme som inte går att hämta ur ett mönster i befintliga data.
Den förskjutning som detta orsakar handlar inte om huruvida AI är bra på att koda. Den handlar om vad som händer med jämförelsen mellan leverantörer så snart en del av det arbetet sköter sig självt. Svarstid på support var ett resultat av bemanning och planering; om triageringen till stor del sker automatiserat är hastighet inte längre beviset på ett bra team, utan på ett väl konfigurerat system, och det systemet går för konkurrenter lika bra att köpa eller bygga. Det som då återstår som särskiljande faktor är inte hastigheten i sig, utan vad som händer i de fall där systemet inte löser problemet — vem som tar sig igenom det och vem som låter en kund vänta.
Samma mönster finns i offertprocesser. Att sätta samman ett tekniskt förslag utifrån befintliga komponenter är arbete som delvis kan automatiseras. Så snart det sker hos flera parter i en upphandling förskjuts det där en kund fortfarande ser skillnad: inte i förslagets snabbhet, utan i frågan om förslaget stämmer för just denna specifika situation, och i vem som kan förklara det utan att falla tillbaka på en mall.
Om ett IT-företag redan har organiserat detta på det sättet beror på var det sätter in sina medarbetare. En aktör som fortfarande i stor utsträckning sätter sina erfarna arkitekter på att skriva standardkod har lite kapacitet kvar för samtalet med kunden där affären avgörs. En aktör som redan har förskjutit det arbetet — AI för den rutinmässiga delen, människor för omdömet — har frigjort just de timmarna för den del som segern nu avgörs på. Det är inget val som görs på ett kvartal; det följer av tidigare beslut om verktyg, om vem som gör vilken typ av arbete, och om hur mycket förtroende en organisation har för tillsynen av automatiserade resultat. Vad en arbetsgivare gör med sin personalstyrka i det sammanhanget är upp till arbetsgivaren; där gäller egna lagstadgade krav, oberoende av frågan om vilket arbete som tekniskt sett går att överföra.
Denna dynamik är inte unik för IT. Samma förskjutning — från volym och hastighet till omdöme och förklaring — utspelar sig annorlunda inom finansiella tjänster, där rådgivning och riskbedömning är angreppspunkten, och återigen annorlunda inom byggbranschen, där planering och kalkylering förskjuts men utförandet på byggplatsen förblir mänskligt arbete. Frågan om vilket arbete i just detta specifika företag som redan har förskjutits och vilket som inte har det, går att besvara med [en arbetsskanning som per uppgift bedömer om AI övertar den, delvis övertar den med tillsyn, eller inte](https://ftetoai.nl) — ett separat steg, fristående från jämförelsen med konkurrenter.
Risken med denna förskjutning är inte att en leverantör förlorar, utan att den inte vet på vad. En offert som säger sig vara snabbare, en webbplats som lovar stabilitet, en säljpitch som lutar sig mot expertis — det är alla påståenden, och påståenden är först en fördel när de går att underbygga gentemot vad en kund ser på annat håll. Den som väl har konstaterat ett underläge på en dimension kan läsa mer om alternativen i ett tillvägagångssätt för att ta igen ett underläge på en specifik dimension, och den som vill styrka ett påstående innan en kund frågar efter det hittar i en prövning av egna kvalitetspåståenden mot underbyggnad hur det görs systematiskt.
Definiera vad ert företag tror sig vinna på — hastighet, pris, expertis, tillförlitlighet — och pröva vilka av dessa påståenden ni idag kan styrka med bevis gentemot en konkurrent. Det är exakt vad den kostnadsfria dimensionskontrollen gör: ingen fullständig benchmark, men väl en första bild av vilka påståenden som står stadigt och vilka som fortfarande hänger löst i luften. Den fullständiga konkurrensbenchmarken, med bevismatris per dimension, är under uppbyggnad.