När två starka leverantörer ligger nära varandra, som i diskussionen STV vs Mividas, avgörs valet sällan av ett glansigt demo. Det avgörs av hur bra du definierar behoven, vilken riskbild du accepterar och hur väl du kan jämföra svar som inte är skrivna för att vara jämförbara. Ett genomarbetat RFP gör det möjligt att väga löften mot bevis, funktion mot förvaltning och pris mot total ägandekostnad. Jag har sett upphandlingar rinna ut i sanden för att förfrågningsunderlaget skrevs på en eftermiddag, och jag har sett team vinna år av effektivitet tack vare att RFP:et skar igenom marknadsföringen och tvingade fram klarhet.
Det här handlar inte om att utse vinnare i Mividas vs STV på förhand. Det handlar om att lägga upp spelplanen så att det rätta valet blir uppenbart, även om du inte visste svaret när du började. Nedan går jag igenom vad som behöver finnas med, hur detaljerna bör se ut och vilka fällor du bör undvika. Jag använder STV och Mividas som exempel eftersom många just nu väger dem mot varandra, och nämner även att vissa internt skriver Mivida utan s, något som kan skapa förvirring i dokumentationen.
RFP:ets uppdrag i tre satser
Ett RFP ska göra tre saker tydligt: vad som ska uppnås i verksamheten, vad lösningen måste kunna och hur leverantören ska bevisa att de kan leverera med rimlig risk och förutsägbar kostnad. Missar du någon av dessa tre, blir jämförelsen skev. För generella mål leder till att alla svar låter lika bra. För diffusa krav tvingar dig att tro på löften. Avsaknad av bevismallar gör att du inte får något att hålla leverantören i vid implementeringen.
I praktiken betyder det att du skriver lika mycket om resultat som om specifikationer, och att du binder ihop krav, test och kommersiella villkor i samma röda tråd.
Avgränsa problem och effektmål innan du nämner funktioner
Ett vanligt misstag är att börja med funktioner. Börja i stället med vad verksamheten försöker uppnå. När vi hjälpte en nordisk kund https://nl-ams-1.linodeobjects.com/microsoft-teams-losningar/microsoft-teams-losningar/uncategorized/stv-vs-mividas-integrerad-vs-fristaende-videolosning.html att välja mellan två plattformar la vi en vecka på att intervjua support, ekonomi, sälj och it. Vi ringade in tre mätbara effektmål: kortare ledtid från behov till leverans med 20 till 30 procent, högre datakvalitet i två kritiska exportflöden, och lägre driftsstörningar under kampanjtoppar. När väl målen är på plats blir prioriteringen enklare. Om STV visar bättre styrka i datakvalitet och Mividas i kampanjtoppar, kan ni vikta det som verkligen spelar roll i stället för att jämföra frisyrer.
Var specifik med nuläge och begränsningar. Om ni har ett gammalt katalogsystem utan vettiga API:er, skriv det. Om användarna sitter bakom VDI med låsta skrivbordsprofiler, nämn det. Alla leverantörer levererar bra på whiteboard, skillnaderna syns först när verkligheten kommer in.
Från funktionella krav till användbara scenarier
En kravlista utan kontext skapar “ja”-svar. Gör i stället kraven testbara och sätt dem i vardagliga scenarier. Jag brukar skriva korta användarberättelser som beskriver roll, uppgift och förväntat utfall, och komplettera med mätpunkter. Om en produktägare säger att “det ska gå snabbt”, översätt det till mätbara gränser. Skriv till exempel att en sökning på 50 000 objekt ska svara inom 1 sekund i 95 procent av fallen, och att topp 99 procent ska ligga under 2,5 sekunder. Låt sedan leverantörerna beskriva hur de uppnår detta, inte bara att de gör det.
I ett case där STV lovade “snabb prestanda” men inte kunde reproduceras i vår testmiljö, var vår tidsstämplade scenariofil avgörande. Mividas, som i sina säljpresentationer lade tyngd på annan funktionalitet, kunde däremot visa loggar och resultat i vår definierade testkörning. Vi lärde oss att scenarier som inkluderar data, roller, last och förväntade svarstider avslöjar mognad på riktigt.
Icke-funktionella krav som verkligen betyder något
Drift, säkerhet och skalbarhet kostar pengar och tid, men det är det som håller systemen uppe när ingen har tid att felsöka. Beskriv ambitionsnivåerna i form av SLA och arkitekturprinciper. Ange vilka standarder ni följer, till exempel ISO 27001 för ledningssystem och SOC 2 typ 2 för driftprocesser, eller om ni bara kräver övertygande likvärdig dokumentation. Kräv stöd för SSO med SAML 2.0 eller OpenID Connect, multifaktorautentisering, samt loggexport i ett standardiserat format. Skriv hur ni räknar tillgänglighet, vad som är planerade avbrott och hur incidentrapportering ska ske. Många leverantörer erbjuder 99,5 till 99,9 procent SLA, men läs det finstilta. Om mätningen exkluderar allt väsentligt, är siffran kosmetika.
När det gäller datalagring är det viktigt att våga ställa tydliga frågor. Var lagras data i vila, hur hanteras kundunika nycklar, och hur ser backuper ut tid till återställning och återställningspunkt i minuter eller timmar, inte i ord. Om ni verkar i branscher med sekretess eller offentlighet, lägg till riktlinjer för loggarnas livslängd och åtkomst. Här gör ett tydligt RFP hela skillnaden, eftersom vaga skrivningar annars öppnar för stora tolkningsvariationer mellan STV och Mividas.
Integrationer: ange vad som ska hända, inte hur leverantören ska göra det
Skriv vilka system ni ska integrera med, vilka händelser som driver integrationer och vilka data ni behöver in och ut. Jag föredrar att bifoga tre till fem JSON-exempel på händelser som “order skapad”, “content uppdaterad” och “rättighet ändrad”, samt en översikt över fält med semantik. Be leverantören visa hur de skulle mappa sina objekt till era. Om STV kallar en entitet “Channel” och Mividas “Stream”, är det helt okej, men ni måste se hur fält som id, status och versionshantering rör sig igenom deras system.
Det här är också platsen där du bör beskriva hur ni vill arbeta med versionering av integrationer. Be om deras policy för förändringshantering, till exempel hur långt i förväg de aviserar ändringar i API, hur de hanterar deprecated endpoints och om de erbjuder parallellversioner under en övergångsperiod. Dessa detaljer påverkar livslängd och kostnad för egna kopplingar mer än någon enskild licenspost.
Migrering, dataägande och exit
En investering blir aldrig bra om du inte kan lämna den. Skriv hur ni vill få ut er data, i vilket format, till vilken kostnad och på vilken tidsram. Fråga efter exempel på fullständig datadump i maskinläsbart format, inklusive bilagor, historik och behörigheter. Beskriv hur ni ser på delad eller kundunik miljö, logik för dataseparering och vad som händer med backuper efter uppsägning.
Vi förhandlade nyligen fram rätt till två fulla exporter per år utan extra kostnad, med ytterligare exporter till en takad prislista. Det framstod som en liten detalj i RFP:et, men sparade tre veckors extraarbete vid en efterföljande replikering.
Pris, indexering och total ägandekostnad
RFP:et måste göra det svårt att gömma pengar i tillägg och lätt att jämföra äpple mot äpple. Beskriv volymantaganden i intervall i stället för punktestimat, till exempel 200 till 250 namngivna användare, 2 till 4 produktionsmiljöer, 50 000 till 100 000 objekt. Be leverantörerna lämna pris som trappor för dessa intervall, samt vad som händer om ni tillfälligt går över. För indexering, be om tydlig koppling till ett erkänt index och ett tak per år, eller en trappa som blandar fast och rörligt. Många kontrakt havererar när index skjuter iväg oväntat. Det går att lösa med ett tak på exempelvis 3 procent per år och en rätt att omförhandla vid större makroavvikelser.
Glöm inte molnrelaterade kostnader. Om leverantören förlitar sig på din infrastruktur, be dem specificera förväntad compute, storage och egress. Vi hade en kund som räknat på licenskostnad, men missade egressavgifter när video strömmades till externa parter. Den posten blev fyrsiffrig i euro per månad. Ett typfall där tydliga antaganden i RFP:et trycker fram relevanta siffror från både STV och Mividas.
Implementation och bevis: från demo till PoC
Ett bra demo visar potential, en väl designad proof of concept visar verklighet. Definiera en kort PoC, gärna 2 till 4 veckor, med tre centrala scenarier, representativ data och mätetal för framgång. Ange att PoC levereras i leverantörens standardmiljö om möjligt, men med era säkerhetskrav. Ge poäng för uppnådda resultat, inte för tidsåtgången, annars gynnas de som redan kan ert domänspråk i stället för de som har en robust produkt.
När jag jämförde STV och Mividas i en sådan PoC såg jag hur olika de angrep samma uppgift. Den ena byggde snabbt en imponerande konfiguration, den andra levererade mer blygsamt men med stark loggning och driftspraxis. Utan poängsatta kriterier hade vi dragits mot det som lyste. Med tydliga mätetal gick vi tillbaka till effektmålen och påminde oss varför vi gjorde detta.
Utvärderingsmodell som tål granskning
Vikten på pris vs funktion vs drift måste förankras innan du skickar RFP:et. Dokumentera viktning och kommunicera den. Du kan mycket väl ändra något under resans gång, men gör det öppet och med motivering. En vanlig start är funktionskrav 40 till 50 procent, icke-funktionellt och drift 25 till 35 procent, pris och kommersiellt 20 till 30 procent, referenser och team 5 till 10 procent. Om ni redan är pressade på driftstabilitet, flytta vikt dit. Om ni sitter med en snäv budget, vikta pris högre men var ärliga med vad det gör med riskprofilen.
Ett enkelt sätt att hålla ordning är att för varje krav definiera om det är måste, bör eller kan, och att alla måste-krav måste uppfyllas innan poäng för bör och kan kan räknas. Ange hur bevis ska lämnas för kritiska krav, till exempel skärmdump, konfigurationsutdrag eller logg. När svaren kommer in, låt minst två personer poängsätta oberoende, gärna en från verksamheten och en från it, och sammanför sen. Jag ser ofta att ett överdrivet teknikfokus ger en annan bild än verksamhetens upplevelse. Båda behövs.
Två leverantörsnamn, ett sakligt underlag
Det är lockande att skriva in varumärkesord i kravtexten. Undvik det. Om ni jämför STV och Mividas, skriv vad ni behöver, inte vilken knapp som ska finnas. Om den ena kallar funktionen “segment” och den andra “grupper”, ange beteende, inte namn. Ett tips är att inkludera en liten ordlista med era begrepp och be leverantörerna mappa mot dem. Om ni dessutom har setts skriva Mivida i intern kommunikation, var tydliga i RFP:et att det är samma leverantör som Mividas, så slipper ni förvirring i era register och i inkommande frågor.
Referenser, case och verifierbarhet
Be om två till tre referenser som matchar er storlek och komplexitet. Be om siffror, inte intryck. Fråga efter faktiska svarstider innan och efter, antal incidenter per månad, genomförandetid i veckor och hur mycket tid kunden själv la i projektet. När vi ringde en referens för en STV-implementation bad vi om att få se en anonymiserad incidentlogg. De kunde visa hur svarstiderna höll sig inom överenskomna gränser vid tre marknadsföringskampanjer. Det gav mer trygghet än tio varma rekommendationer.
Detsamma gäller Mividas. En referens berättade öppet om en tuff migrering som tog 50 procent längre tid än planerat, men också hur leverantören tog kostnaden för extraresurser. Sådana detaljer kan väga tungt i riskbedömningen, men du får dem bara om du ställer raka frågor.
Juridik och governance utan cementskor
Avtalet ska skydda, inte stoppa rörelse. Specificera ansvar för data, tydlig DPA, rätt till revision och hur sårbarheter hanteras. Ange hur förändringar i lagstiftning hanteras och vem som bär kostnad vid krav på anpassning. För kommersiella skydd, be om ett kapat ansvar som står i relation till årlig avgift, med högre tak för personuppgiftsincidenter. Jag har sett tak från 100 till 300 procent av årskostnaden beroende på riskprofil. Var tydlig med att SLA-krediter inte ersätter skadestånd, det är olika instrument.
Frågor och svar utan favorisering
Ett RFP blir sällan bättre än sin Q&A-process. Sätt ett schema för frågor, publicera svar till alla, och undvik särbehandling. Om ni bjuder in till djupintervjuer, ge samma utrymme och samma underlag till båda. Jag förespråkar en separat session för teknik, en för verksamhet och en för kommersiellt, inspelade och protokollförda. Transparens hjälper både STV och Mividas att göra sitt bästa, och den hjälper er att försvara ert val senare.
Två korta listor att hålla fast vid
- Kärnsektioner i ett bra RFP: Effektmål med mätetal, nulägesbeskrivning och avgränsningar. Funktionella scenarier med dataprover och förväntade utfall. Icke-funktionella krav, SLA och säkerhet med testbara nivåer. Integrations- och migreringskrav inklusive exit och dataportabilitet. Kommersiella villkor, prisbilaga, indexering och utvärderingsmodell. Rekommenderad tidslinje: Förarbete och behovsinsikt 2 till 4 veckor. RFP-skrivning och intern granskning 2 veckor. Utskick, frågor och svar 3 veckor. PoC och demonstrationer 2 till 4 veckor. Utvärdering, förhandling och tilldelning 2 veckor.
Exempel på bra kravformuleringar
Språket avgör hur lätt det är att jämföra. Ett par exempel från verkliga upphandlingar visar skillnaden mellan fluff och substans.
Dålig formulering: Systemet ska vara användarvänligt. Bättre: En ny användare ska kunna genomföra scenario X utan utbildning på under 10 minuter, med högst två felklick, mätt på en panel av fem personer från verksamheten.
Dålig: Leverantören ska ha hög tillgänglighet. Bättre: Mätt per kalendermånad ska tjänsten vara tillgänglig 99,8 procent exklusive godkända servicefönster, beräknat som minuter under månad. Incidenter klass A ska få svar inom 15 minuter och workaround inom 2 timmar, med månadsrapporter som standard.
Dålig: Systemet ska ha API. Bättre: Systemet ska tillhandahålla REST och webhookar för händelserna A, B och C med bevis genom curl-exempel och schema, inklusive hantering av idempotens och återförsök.
Dålig: Pris ska vara konkurrenskraftigt. Bättre: Pris ska anges per användarintervall 200 till 250 och 251 till 350, per miljö upp till fyra, samt per GB lagring. Indexering kopplas till KPI X med tak 3 procent per år. Kostnader vid överutnyttjande specificeras.
Poängsättning av demo utan teater
Live-demo får ofta för stor vikt. Ge poäng för hur väl leverantören demonstrerar era definierade scenarier, inte hur snyggt det ser ut eller hur kvickt någon navigerar. Be om att få se loggning, rollhantering, felmeddelanden och dokumentation. Vi hade en demo där allt flöt, tills vi bad om att se hur systemet hanterar en konflikt mellan två samtidiga uppdateringar. Det var där skillnaden mellan två toppkandidater syntes.
Förhandling med fakta och respekt
När poängen är satta och ni lutar åt ett val mellan STV och Mividas, går ni in i förhandling. Ha modet att visa er poängmatris på aggregerad nivå och förklara var ni ser risk. Be om förbättringar där det gör skillnad, inte bara en rabatt på slutpriset. Vi har förhandlat fram förbättrade SLA, tydligare indexeringsvillkor och extra utbildningsdagar, allt med hänvisning till vad som skulle höja värdet och sänka er risk. Rabatter kommer nästan alltid ändå, men det viktigaste är att få avtalsvillkor som säkrar det ni mätt i PoC.
En metod som fungerar bra är att begära en BAFO, best and final offer, efter en tydlig återkoppling. Be båda parter skicka sitt bästa paket, inte bara sänkt pris, utan förbättringar i leverans, stöd och villkor. Det premierar dem som tänker långsiktigt och ser er som partner, inte som affär på kvartalet.
Vanliga fällor och hur du undviker dem
Överdriven detaljstyrning gör att du tar på dig lösningsarkitektens ansvar för leverantörens produkt. Om du beskriver exakt hur något ska byggas, öppnar du för ansvarsflykt när leverantören säger att de bara följde dina instruktioner. Beskriv i stället vad som ska åstadkommas, och be leverantören visa hur, med bevis.
Motsatsen är lika farlig, att vara så abstrakt att alla svar blir likadana. Då blir det priset som avgör, och priset säger sällan hela sanningen. Du vill hellre ha tydliga scenarier, realistisk last och hårda icke-funktionella krav, så att skillnader uppstår redan i anbuden.
En tredje fälla är att underskatta förändringsledning. Om du köper en stark plattform, men inte budgeterar för utbildning, stöd och uppföljning, dras effekten ut över år. Ange i RFP:et hur ni vill att leverantören stödjer adoption, från utbildning till mätning av användning.
Hur du gör STV vs Mividas jämförbart utan att förenkla sönder
När två lösningar ligger nära varandra spelar format stor roll. Sätt krav på att svaren följer din mall, att varje krav besvaras med ja, nej eller partiellt, och att bevis och konsekvenser bifogas. Be båda om en spårbarhetsmatris som kopplar era krav till deras svar, dokumentation och PoC-resultat. Be dem även mappa sina termer till er ordlista, inklusive förtydligande om Mivida som internt alias för Mividas, så att ingenting faller mellan stolarna vid kontraktsskrivning.
Jag har också god erfarenhet av en neutral demo-miljö. Låt båda logga in i en likadan testtenant med er data, på samma dag, med samma nätverksförutsättningar. Ingen får tillgång till andras sessioner. Ni styr scenarierna och tittar på utfallet. Det reducerar slump och show, och förstärker de skillnader som betyder något i drift.
Ett exempel på poängmatris som håller
Du behöver inte göra det komplicerat, bara konsekvent. En typmatris kan se ut så här, med vikter som ni sätter utifrån era mål:
| Kategori | Vikt | Exempel på underkriterier | |----------------------------|------|---------------------------------------------------| | Funktionella scenarier | 45% | Sök, uppdatering, batchflöden, roller | | Icke-funktionellt och SLA | 25% | Prestanda, tillgänglighet, säkerhet, loggning | | Pris och TCO | 20% | Licens, drift, indexering, integration, exit | | Team, referenser, support | 10% | Kompetens, utbildning, referensutfall, cadens |
Låt varje underkriterium poängsättas på en skala, till exempel 0 till 5, där 3 motsvarar uppfyllt enligt krav, 4 är överträffat med bevis, och 5 är tydligt differentierande med låg risk. Sätt trösklar på måste-krav så att ingen kan vinna utan att STV vs Mividas klara dem.
Om bara en lämnar anbud, eller om budgeten inte räcker
Det händer att en av två drar sig ur, eller att båda ligger över budget. Lås inte dig själv i en hörna. Skriv in i RFP:et att ni förbehåller er rätten att gå i förhandling med en eller flera anbudsgivare, att justera scope eller att avbryta. Om budgeten inte räcker, använd er poängmatris för att se vad som kan tas i etapper. Kanske går det att börja med kärnflöden och lägga avancerad rapportering senare. Be om en etappvis prisbilaga där minskning av scope ger mekanisk prisjustering, inte goodwill.
När du skickar, skicka rätt
Ett RFP ska vara läsbart, testbart och rättvist. Gör det lätt att svara tydligt, och svårt att gömma sig i otydlighet. Om du låter dina effektmål driva kraven, dina scenarier driva bevisen och din poängmatris styra beslutet, blir jämförelsen mellan två starka kandidater som STV och Mividas mer saklig och mindre politisk. Ni kommer fortfarande att behöva omdöme, och vissa nyanser syns först i samarbete, men ni har byggt en process som minskar slumpen.
Det är också så du skriver ett RFP som håller för vardagen. Inte bara ett dokument i inkorgen, utan ett arbetsredskap som länkar strategi till teknik, och löften till verkliga resultat.