Välja IT-leverantör: 9 frågor och checklista

Att välja IT-leverantör handlar om att hitta en partner som kan leverera rätt lösning till rätt risk, rätt kostnad och med rimliga villkor om något går fel.

Många företag ställer för mjuka frågor i upphandlingen. Därför blir viktiga delar av beslutet otydliga: hur priset fungerar i praktiken, vem som äger koden, vad som ingår i supporten, hur du lämnar samarbetet och vilka risker som dyker upp efter signering.

I den här guiden får du nio frågor som ger verkligt beslutsstöd när du ska välja IT-leverantör för systemutveckling, integrationer eller vidareutveckling av en befintlig produkt.

Så använder du checklistan

Be varje leverantör svara skriftligt på frågorna nedan. Då blir det mycket lättare att jämföra svaren sida vid sida och upptäcka undvikande formuleringar.

Du letar efter tydliga svar med konkreta avgränsningar, risker och ansvar. En bra leverantör kan förklara detta rakt och begripligt med ett språk som går att fatta beslut på.

1. Har ni gjort liknande projekt tidigare, med liknande risknivå?

Branscherfarenhet är bra, men det viktigaste är om leverantören har löst problem som liknar ditt. Ett bolag kan vara starkt inom din bransch men ändå sakna erfarenhet av just integrationer, legacy-modernisering eller produktutveckling i den skala du behöver.

Det är också klokt att skilja mellan "vi har jobbat med liknande kunder" och "vi har levererat det ni faktiskt behöver". Det senare är betydligt mer värdefullt när projektet väl börjar.

Be dem visa:

• 2 till 3 projekt som liknar ditt i komplexitet
• Vad som faktiskt byggdes
• Vad som gick fel under projektet
• Hur de hanterade förseningar, scope-förändringar eller tekniska problem
• Vilken roll de hade i leveransen

Bra svar innehåller konkreta exempel, ansvarsfördelning och lärdomar. Svaga svar blir ofta allmänna och handlar mer om teknikord än om verkligt genomförande.

2. Hur ser ert prisupplägg ut i praktiken?

Det här är en av de viktigaste frågorna, och samtidigt en av de mest förbisedda. Många projekt ser rimliga ut i offert men blir dyra genom otydligt scope, löpande timmar med svag styrning eller oklara tillägg.

Du vill förstå både vad projektet kostar i dag och hur kostnaden kan förändras när projektet drar ut på tiden, ändrar riktning eller går in i förvaltning.

Fråga specifikt:

• Arbetar ni fast pris, löpande räkning eller en hybridmodell?
• Vilka delar ligger uttryckligen inom priset, och vilka delar ligger utanför?
• Hur hanterar ni ändringsförfrågningar och nytt scope?
• Hur följer ni upp budgetförbrukning under projektet?
• Vilka kostnader tillkommer efter leverans, till exempel drift, licenser, support eller jour?

När leverantören kan visa hur budgeten styrs vecka för vecka blir det lättare att behålla kontroll över ekonomin genom hela projektet.

3. Vem äger koden, dokumentationen och det som byggs?

Det här måste vara glasklart innan projektstart. Om ägandet är otydligt kan du bli låst till samma leverantör långt efter att samarbetet slutat fungera.

Många företag upptäcker för sent att de saknar full kontroll över repo, molnkonton eller teknisk dokumentation. Då blir ett framtida byte både dyrare och långsammare än det hade behövt vara.

Fråga om:

• Vem äger källkod, design, dokumentation och infrastrukturdefinitioner?
• Finns det delar som leverantören behåller rättigheterna till?
• Får ni full tillgång till repos, CI/CD, molnkonton och tredjepartstjänster?
• Dokumenteras lösningen så att en annan partner kan ta över?

Om svaret är otydligt eller om ni bara får "användningsrätt" bör du gräva vidare direkt.

4. Hur ser support, förvaltning och SLA ut efter lansering?

Många leverantörer är bra på att bygga nytt men svagare på att ta ansvar efter go-live. Därför behöver du förstå exakt vad som händer när något slutar fungera i drift.

Det gäller särskilt om lösningen används i verksamhetskritiska flöden. Då behöver både ansvar, tillgänglighet och prioriteringsnivåer vara tydligt definierade från början.

Be om tydliga svar på:

• Svarstider och åtgärdstider vid incidenter
• Vad som räknas som kritisk incident
• Om support ingår eller debiteras separat
• Hur ofta säkerhetsuppdateringar, förbättringar och buggrättningar görs
• Vem som äger driften och vem som tar första linjen vid problem

Om du är beroende av lösningen i den dagliga verksamheten behöver du faktiska servicenivåer, tydliga ansvar och en supportmodell som fungerar i praktiken.

5. Hur minskar ni risken i projektet innan vi går live?

Det viktiga här är leverantörens sätt att identifiera risk tidigt och skapa en process där problem upptäcks i god tid.

En leverantör med bra riskhantering försöker göra det osäkra tydligt så fort som möjligt. Det sparar både tid och pengar, särskilt i projekt där beroenden och kravbild fortfarande utvecklas.

Fråga därför om:

• Hur de bryter ner projektet i levererbara steg
• Hur de kvalitetssäkrar kod och lösning
• Hur testning går till innan release
• Hur de jobbar med demo, avstämning och beslutsunderlag
• När de brukar rekommendera en förstudie eller PoC

Ett bra svar visar att leverantören aktivt arbetar med att minska osäkerhet och skapa hållbar framdrift.

6. Hur hanterar ni integrationer, data och befintliga system?

De flesta projekt blir svårare i integrationerna än i själva gränssnittet. Om ni redan har affärssystem, CRM, ERP, e-handel eller specialsystem måste leverantören förstå beroenden, datakvalitet och felhantering.

Du vill ha en tydlig beskrivning av hur leverantören tänker kring robusthet, spårbarhet och vad som händer när ett system i kedjan beter sig oväntat.

Be dem beskriva:

• Vilka system de ser som mest kritiska i integrationen
• Hur de hanterar fel, retries och loggning
• Hur de jobbar med datamigrering och datakvalitet
• Hur de testar integrationer med minimal påverkan på verksamheten
• Hur de tänker kring spårbarhet och ansvar mellan system

Vill du fördjupa dig i integrationsrisker kan du också läsa vår artikel om fallgropar vid systemintegration.

7. Hur ser en möjlig exit ut om vi vill byta leverantör?

Det här är en viktig fråga att ställa tidigt. En seriös leverantör kan beskriva hur ett överlämnande skulle fungera på ett lugnt och tydligt sätt.

Ett bra samarbete bygger på att ni redan från början pratar om hur det kan avslutas på ett ordnat sätt. Tydliga svar här brukar också ge en bra bild av risken för framtida lock-in.

Fråga om:

• Uppsägningstid och vad som händer vid avslut
• Hur kunskapsöverföring och dokumentation går till
• Om de hjälper en ny partner att ta över
• Hur tillgångar, behörigheter och miljöer lämnas över
• Om något i upplägget gör er beroende av just dem

Tydliga och sakliga svar här stärker förtroendet direkt.

8. Kan ni ge relevanta referenser, och får vi prata direkt med dem?

Case på hemsidan är en bra start. Samtal med kunder ger en mycket tydligare bild av hur samarbetet faktiskt fungerade över tid, även i pressade lägen.

Försök också få referenser från projekt som påminner om ditt i storlek, komplexitet och beroenden. Annars blir jämförelsen lätt missvisande.

Be om referenser där ni får ställa frågor som:

• Höll leverantören tidplan och budget?
• Var de transparenta när något gick fel?
• Tog de ansvar även efter lansering?
• Var dokumentation, kodkvalitet och överlämning tillräckligt bra?
• Skulle ni anlita dem igen?

Bra referenser är konkreta och relevanta. Om du bara får prata med "perfekta" kunder från enkla projekt ska du vara försiktig.

9. Vilka risker ser ni i vårt projekt redan nu?

Det här är ofta den mest avslöjande kontrollfrågan i hela processen. En bra leverantör ser risker tidigt, beskriver dem tydligt och hjälper dig förstå vad de betyder för projektet.

Det är värdefullt att leverantören kan resonera nyktert om osäkerheter, beroenden och sådant som kan påverka budget, tidplan och kvalitet, även när svarsbilden fortfarande utvecklas.

Lyssna efter risker som:

• Otydligt scope eller målbild
• Svag datakvalitet
• Beroenden till gamla system
• Intern flaskhals hos beställaren
• Orealistisk tidplan
• Otydligt beslutsmandat
• Hög integrationskomplexitet

Ju mer konkret riskbild, desto mer sannolikt att leverantören faktiskt förstår vad ni står inför.

Snabb checklista innan du väljer

Innan du skriver avtal bör du kunna svara ja på följande:

Checklistan fungerar bäst som en sista kontroll innan beslut. Om flera punkter fortfarande känns oklara är det ofta klokare att pausa än att hoppas att detaljerna löser sig senare.

• Vi förstår hur priset fungerar och vilka tillkommande kostnader som finns
• Det är tydligt vem som äger kod, dokumentation och miljöer
• Support, SLA och ansvar efter lansering är definierade
• Vi vet hur ett avslut eller leverantörsbyte skulle gå till
• Vi har pratat med minst två relevanta referenskunder
• Leverantören har pekat ut verkliga risker och möjligheter

Om flera av dessa punkter fortfarande är oklara är du sannolikt för tidigt ute med att välja partner.

Vanliga red flags när du utvärderar en IT-leverantör

Här är några tydliga varningssignaler:

Flera signaler tillsammans är en stark anledning att stanna upp och granska upplägget närmare. Det gäller särskilt om svaren blir otydliga kring ansvar, kostnad eller överlämning.

• De svarar vagt på frågor om pris och scope-förändringar
• De föreslår att repo, molnkonto eller produktionsmiljö ska ligga hos dem, men ger svag motivering till upplägget
• De ger otydliga svar om hur överlämning eller exit fungerar
• De pratar mycket om teknik, men lite om risk, ansvar och affärsmål
• De undviker att låta dig prata direkt med referenskunder
• De lovar väldigt mycket innan de förstått nuläge, data eller beroenden

En leverantör ska inge förtroende genom tydlighet, ansvar och saklighet.

Vanliga frågor om val av IT-leverantör

Vad är viktigast att fråga en IT-leverantör om?

De viktigaste frågorna rör prisupplägg, ägande av kod och dokumentation, support efter lansering, exitmöjlighet, relevanta referenser och vilka risker leverantören ser i projektet. Det är oftast där de stora problemen annars uppstår senare.

Det är också bra att tänka i termer av ansvar och kompetens tillsammans. Många leverantörer kan bygga, och de starkaste teamen är tydliga med vad de faktiskt tar ansvar för när projektet förändras eller när något går snett efter lansering.

Hur jämför man två IT-leverantörer på ett rättvist sätt?

Låt båda svara skriftligt på samma frågor och jämför svaren sida vid sida. Fokusera mindre på säljpresentationen och mer på tydlighet i ansvar, risk, ekonomi, leveransmodell och support.

Om ni vill få mer jämförbara offerter är nästa steg ofta att skriva en tydlig kravspec för mjukvaruutveckling.

Om du vill göra jämförelsen ännu bättre kan du vikta kriterierna i förväg. Då minskar risken att du väljer den som känns bäst i mötet i stället för den som passar bäst för uppdraget.

När bör man göra en förstudie innan man väljer leverantör?

En förstudie är särskilt värdefull när scope är otydligt, många system ska integreras eller det finns stor osäkerhet kring data, process eller teknisk lösning. Då blir det lättare att jämföra leverantörer på rätt grund.

Den är också värdefull när flera interna intressenter har olika bild av vad som faktiskt ska byggas. En bra förstudie skapar då ett tydligare beslutsunderlag innan ni går in i utveckling eller upphandling.

Ska man välja fast pris eller löpande räkning?

Det beror på hur tydligt projektet är definierat. Fast pris passar bättre när scope är stabilt. Löpande räkning kan fungera bra i mer osäkra projekt, men kräver stark styrning, tät uppföljning och tydliga prioriteringar för att behålla kontroll över budgeten.

I praktiken väljer många en mellanväg, där vissa delar är tydligt avgränsade och andra hanteras mer flexibelt. Det viktiga är att modellen stödjer verkligheten i projektet och fungerar väl även i avtalet.

Hur vet man om man riskerar att bli låst till leverantören?

Titta på ägande av kod, åtkomst till system, dokumentationsnivå, hur driften är uppsatt och vad avtalet säger om överlämning. Om mycket är bundet till leverantörens egna konton, processer eller odokumenterade lösning ökar lock-in-risken direkt.

Ett bra stresstest är att fråga hur snabbt en annan partner skulle kunna ta över med låg påverkan på verksamheten. Om svaret blir svävande eller bygger på att leverantören själv "alltid finns kvar" är det en varningssignal.

Om du vill ha hjälp att reda ut scope, risker eller rätt leveransupplägg innan du väljer partner kan vi på Fiive hjälpa till med systemutveckling, förstudier och teknisk rådgivning.