Begrepp som liknar varandra har en märklig förmåga att glida ihop i beslutsrummet. Namnkombinationen STV vs Mividas är ett typiskt exempel. Två aktörer, ibland med överlapp i erbjudanden, ibland med tydligt olika fokusområden, hamnar i jämförelse trots att de löser något olika problem. I vissa upphandlingar gäller det videoplattformar, i andra service och drift, i några fall helhetsåtaganden inom kommunikation eller säkerhet. Det skapar ett dilemma: hur jämför man rättvist utan att hitta på detaljer som inte stämmer med de två specifika alternativen?
Erfarenheten säger att det viktigaste inte är en teoretisk matchning rad för rad i ett kalkylark, utan ett tydligt problemformulerat varför. Vad behöver ni åstadkomma, inom vilken tidshorisont, med vilka risker och krav på kontroll? När det klarnar blir Mividas vs STV inte en tävling om tekniska broschyrer, utan en strukturerad prioritering av verkliga begränsningar, mål och valbarhet.
Vad jämförelsen egentligen handlar om
När en ledningsgrupp ber att få se en jämförelse STV vs Mividas är det sällan en fråga om kosmetik. Det handlar om tre saker: kontroll, sammanhang och konsekvens.
Kontroll betyder att ni vill veta hur mycket som hamnar i er egen verktygslåda och hur mycket som outsourcas. Sammanhang handlar om hur lösningen passar in i era befintliga system, processer och människors arbetssätt. Konsekvens gäller vad som händer när något bryts: en integration, ett kontrakt, ett nyckeltal.
Det kan vara ett nav för videomöten, ett övervakningssystem, en kommunikationsplattform eller ett driftåtagande. Benämningen skiftar, men jämförelsemetoden håller. Därför fokuserar texten på praktiska kriterier och prövade sätt att avväga dem, snarare än antaganden om exakt produktkatalog hos STV eller Mivida. Målet är att ge beslutsfattare ett underlag som fungerar även när produktnamn, versioner och licenspaket byts ut nästa kvartal.
Behovsbilden först, alltid
Fler beslut går fel för att behoven var halvt formulerade än för att kalkylen saknade en rad. Gör er själva en tjänst och skriv ner varför ni gör bytet eller införandet. Är det en kvalitetsfråga, exempelvis kravet att få upp till 99,9 procents upptid i primär funktion? Är det en kostnadsfråga, exempelvis att sänka den totala ägandekostnaden med 15 till 20 procent inom två år? Eller finns det en regelefterlevnadsfråga, där loggning, datalagring och åtkomstmodell måste anpassas till en ny tolkning av GDPR eller NIS2?
Ett logiskt sätt att ringa in behovsbilden är att beskriva tre scenarier, ett för normal drift, ett för toppbelastning och ett för incident. Normal drift visar om vardagen går smidigt. Toppbelastning avslöjar flaskhalsar och potentiella skuldfrågor i supportkedjan. Incidentläget testar återställningstider och ansvarsfördelning. När dessa tre scenarier går att spela upp på bordet, med siffror och tider, börjar en jämförelse mellan STV och Mivida bli skarp.
En tumregel: insistera på att varje leverantör demonstrerar alla tre scenarier i en provmiljö eller pilot. Den som inte vill, kan inte, eller säger att det inte behövs har sannolikt problem i kanterna som dyker upp först när ni rullar ut i full skala.
Teknisk arkitektur och designprinciper
Få beslut slår lika hårt mot framtida handlingsutrymme som arkitekturen ni säger ja till. Några områden återkommer oavsett bransch:
Modularitet. En modulär lösning låter er byta en komponent när den blir för dyr, osäker eller föråldrad. Monoliter har sin lockelse i lägre startfriktion men blir ofta dyra att anpassa. Fråga båda parter hur deras system bryts ner i tjänster, hur gränssnitten dokumenteras och om ni kan byta exempelvis analysmotor, lagringslager eller identitetsmodul utan att riva allt.
API och integration. Dokumentationen måste vara läsbar, versionerad och testbar. Be om Postman‑samlingar eller likvärdiga provpaket, och sätt upp ett enkelt use case som kräver skrivande, inte bara läsning av data. Ett API som är snällt att läsa men trögt att skriva mot blir flaskhals när den första automationsidén dyker upp.
Dataägande och portabilitet. Formulera i avtalet vad som händer med data och metadata vid avslut. Definiera exportformat och tidsramar, inte bara principer. Fler än en organisation har suttit med låsta loggar eller proprietära index som inte går att återbygga.
Prestanda nära verkligheten. Kräv siffror under belastning med era typfall. Om en leverantör visar millisekunder i labb, men inte kan återskapa era nätförhållanden, er klientmix eller era säkerhetskrav, så är det marknadsföring, inte prestanda.
Säkerhet och efterlevnad utan att fastna i formalia
Säkerhet blir ofta ett dokumentmaraton. Det behövs, men resultatet blir bättre när ni testar kontrollerna praktiskt. Begär in revisionsrapporter om sådana finns, men kör också en egen granskning: hur mappas roller och behörigheter mot er identitetsplattform, hur loggas administratörsåtgärder, hur separeras kundmiljöer i multi‑tenant drift, och hur visas detta i en live‑session?
Två detaljer avgör ofta mer än ett helt säkerhetsdokument. För det första, hur snabbt ni kan stänga av en komprometterad integration utan att ligga nere i flera timmar. För det andra, hur väl leverantören hanterar säkerhetsrådgivning vid en incident, inklusive vem som ringer upp vem, och med vilket underlag. Att få se en tydlig incidentrunbook i en genomgång skär genom många floskler.
På efterlevnadssidan bör ni fastställa geografisk dataplatsering, retention‑policy per datatyp och hur rätten att bli glömd realiseras i praktiken. Ingen lösning är perfekt här, men tydlighet om vad som går och inte går är guld värd. Dokumentera kompromisserna.
Drift, SLA och kostnadsmodeller som håller i verkligheten
Ett av de vanligaste misstagen i Mividas vs STV är att blanda ihop listpris, första års rabatt och total ägandekostnad över tre till fem år. Det gäller att räkna på rätt nivå av verklighet. Ta med kostnader för migrering, integration, intern förändringsledning, utbildning och eventuella premiumtillägg som behövs för att nå era egna mål.
SLA ser ofta lika ut på pappret, men skiljer sig i undantag, mätmetod och ersättningsmekanismer. Be om exempelrapporter från faktiska incidenter, avidentifierade men med tidsstämplar. Bevaka särskilt skillnaden mellan tillgänglighet i kärnfunktion och tillgänglighet i integrerade delmoment. Om kärnan har 99,95 procent men en kritisk integration bara mäts best effort, blir det ni som får ta skadan i praktiken.
Kostnadsmodeller flyttar risk mellan parterna. Per användare passar miljöer med relativt stabil volym och låg variation i nyttjande. Konsumtionsbaserat pris glänser när era belastningstoppar är sällsynta men stora. Paketpris ger trygghet i budget, men bäddar ibland för överlicensiering. En hyfsat säker tumregel är att be om två alternativ och räkna dem mot tre scenarier: konservativt, troligt och aggressivt nyttjande. Med det på plats kan man välja prislogik, inte bara prislista.
Support och kompetensöverföring
Det går att köpa bra teknik och ändå misslyckas för att kompetensen inte följer med. Bedöm supporten utifrån vem som faktiskt svarar, på vilka tider och med vilket ansvar. Får ni tillgång till seniora tekniker vid komplexa felsökningar, eller fastnar ni i en frontlinje som mest skapar ärendenummer? Hur ser eskaleringsstegen ut, Hoppa över till den här webbplatsen med namn och roller, inte bara funktionsbrevlådor?
Kompetensöverföring är särskilt känsligt om ni byter från ett hemmasnickrat system till en mer produktifierad tjänst. Planera för utbildningsvåg i tre steg: administratörer, superanvändare och bredd. Det låter som självklarheter, men tidsättningen avgör. Om superanvändarna får sin utbildning för sent blir de inte de ambassadörer ni behöver när vardagsproblem står på rad de första veckorna.
Integration i ett ekosystem ni redan äger
Nästan alla införanden hamnar i en väv av redan existerande plattformar. Identitetshantering, loggning, övervakning, ärendehantering, dokumentation och rapportering till ledning. Jämför STV och Mivida inte bara på vad de kan, utan på hur de låter er fortsätta använda det ni redan har.
En praktisk övning är att rita upp en enkel tjänstekarta: användare och enheter till vänster, kärnfunktion i mitten, dataflöden till höger. Placera in era nuvarande system och markera var adaptrar krävs. När detta görs med båda alternativen brukar en bild träda fram: det ena passar era vägar med färre adaptrar, det andra kräver fler bryggor men kan ge bättre långsiktig skalbarhet. Det är inga rätt eller fel här, men bilden gör konsekvenserna synliga.
Datakvalitet och mätbarhet från dag ett
Det som inte mäts, förbättras sällan. Både vid val av STV och Mivida vinner ni på att definiera mätpunkter tidigt. Tekniska KPIer som svarstid, felprocent och resursutnyttjande är nödvändiga. Men missa inte affärsmåtten: hur mycket tid spar en ny process, hur snabbt rullar en ny användare igång, hur ofta behöver support kontaktas för ett standardflöde? Koppla mätningarna till dashboards ni redan använder, så att rapporteringen inte blir en extrauppgift som tappas efter kvartal ett.
I praktiken är datakvalitet ofta en frågan om små vardagliga disciplinfrågor. Att enhetliga namnstandarder följs, att dokumentation inte läggs i personliga mappar, att ändringsloggar skrivs i en gemensam plats och inte bara i mejltrådar. När ni gör piloten, låt dessa vardagsvanor ingå och bedöm leverantörernas förmåga att stödja och förstärka beteendena, snarare än att anta att de uppstår magiskt efter driftsättning.
Två realistiska scenarier som ofta avgör
Tätt planerad migrering. En kommun med 3 500 användare skulle på tre månader lämna en blandmiljö av äldre system för en enhetlig tjänst. Oavsett om valet stod mellan STV eller Mivida visade det sig att den kritiska faktorn var migreringsförmåga. Den leverantör som kunde visa en konkret batchplan med 200 användare per natt, tydlig fallback om batch fyra misslyckas, samt en bemannad hotline på morgonteamen tog ledningen. Tekniken var nära likvärdig. Migreringsdisciplin gav utslagsrösten.
Snabbförändrande kravbild. Ett industribolag med säsongstoppar till dubbla volymen behövde flexibilitet. Här vann prissättning per faktisk användning under månaden, och möjligheten att parkera icke‑aktiva licenser utan full kostnad. Den andra leverantören hade bättre enhetspris, men sämre möjlighet att nedväxla utan omförhandling. Över två år sparade flexibiliteten minst 12 procent mot det billigare enhetspriset.
Poängen i båda fallen: jämförelsen avgörs av att höra hur väl en leverantör kan möta era särskilda väggar och svängar, inte hur fint lösningen ser ut i katalog.
Vanliga fallgropar och hur de undviks
Övertro på referenser. Kundreferenser är värdefulla, men filtrera dem. Be särskilt om en referens där det skavde. Det är lärorikt att höra hur en svår period hanterades, hur ansvar delades och vad som förbättrades. Enbart perfekta historier säger sällan något om ert framtida samarbete.
Pilot utan skarpt mål. En pilot som körs för att man brukar göra piloter är bortkastad tid. Sätt en lista på tre tydliga utvärderingsfrågor och mätdata. Koppla dem till beslutspunkter. Om frågorna inte kan besvaras efter piloten, ändra upplägget eller låt bli.
Luddiga ägarbilder. Om ingen äger resultatet hamnar beslutet i limbo. Sätt en produktägare på beställarsidan, med mandat att prioritera och att säga nej. Säkerställ att produktägaren har en backup. Det låter administrativt, men det räddar tempo när nya krav dyker upp.
Glömma livscykeln. Skriv inte bara ett införandekontrakt. Planera uppgradering, avveckling och dataexport. Definiera rollerna när tekniken når end‑of‑life. Då slipper ni panikåtgärder fyra år senare.
Förhandlingsläget: var värdet faktiskt sitter
Priset avgörs ofta av paketering och tidpunkt. Men värdet avgörs av villkor. Försök att lägga kraften på tre avtalsdelar: exit, mätbarhet och incitament.
Exit är er fallskärm. Den ska beskriva datastruktur, exportfönster och support under övergångsperiod. Utan det blir ett bra avtal en inlåsning när verkligheten ändras. Mätbarhet handlar om vad som räknas som fel eller avvikelse och hur det bevisas. Incitament kan vara allt från bonus vid uppnådda effektmål till malus vid missade milstolpar.
Ibland går det att byta en procentenhet i rabatt mot förbättrad exit eller tydligare mätbarhet. Det är sällan en dålig affär. Den som vinner på transparent uppföljning har oftast högre kvalitet, och ni minskar risken att bli sittande med undermålig leverans.
En kompakt jämförelsechecklista
- Problemformulering: Kan leverantören återge ert behov med egna ord, inklusive tre realistiska scenarier? Arkitektur: Finns dokumenterade och testbara APIer, med möjlighet till modulära byten? Data och efterlevnad: Är dataplatsering, retention och exportformat preciserade och testade? Drift och SLA: Finns historiska rapporter, tydliga undantag och ersättningslogik som faktiskt biter? Migrering och support: Är migreringsplanen detaljerad och supporteskalering namngiven med tider och roller?
En beslutsram ni kan använda imorgon
För att landa valet mellan STV och Mivida på ett sätt som går att försvara i ledningsgrupp och nämnd, samla fyra dataposter och lås beslutsprocessen till dem.
Först, affärseffekt målad i siffror. Vad ska bli snabbare, billigare eller säkrare, med vilka innan‑ och eftervärden? Här räcker två till tre KPIer, exempelvis onboardingtid för en ny användare, incidenttid till lösning, eller andel automatiserade flöden. Skriv upp nuläget och mål inom sex månader.
Second, riskpalett med åtgärder. Lista de tre största riskerna och den avtalade motåtgärden. Om en risk saknar motåtgärd, förklara varför den är acceptabel. Att göra detta öppet skapar trygghet när något går snett, vilket det gör förr eller senare.
Third, tekniskt bevis i pilot. Bygg ett smalt men skarpt pilotcase. Ingen demo ersätter en pilot där era system, er nätmiljö och era användare är med. Resultatet ska ha mätvärden och observationer, inte bara stämningslägen.
Fourth, total ägandekostnad över minst tre år. Kör en konservativ och en offensiv användningsprognos. Inkludera migreringskostnad, utbildning, integrationer, eventuella premiumtillägg och intern tid. Med båda kurvorna på bordet undviker ni att bli överraskade.
När dessa fyra delar är fyllda brukar valet klarna. Ibland väljer ni den tekniskt eleganta vägen. Ibland väljer ni det som enklast landar i organisationen. Båda kan vara rätt. Skillnaden är att ni gör det med öppna ögon.
Nästa steg i praktiken
Många team fastnar här, mellan analys och handling. Det är bättre att ta tre fokuserade steg än att skriva ytterligare en 40‑sidig jämförelse. Gör så här, och lås kalendern för att bli klar inom sex veckor.
- Sätt pilotomfång och mål på två sidor, inga fler. Agera som om ni måste fatta beslutet på detta underlag. Avropa en teknisk genomgång med båda leverantörerna, där era tre scenarier körs live. Spela in sessionerna. Kör piloten med tydlig stoppregel. Om en kritisk mätpunkt faller under tröskeln, pausa och justera, eller avbryt.
Notera att dessa tre steg inte ersätter upphandlingsregler, men de fokuserar energi där den gör störst skillnad. De gör också att ni får en rättvis bild av hur samarbetet med STV eller Mivida faktiskt känns i vardagen.
Varför detta resonemang håller även när villkoren ändras
Teknikskiften, versionssprång och nya paketeringar gör jämförelser snabbt daterade. Ändå håller strukturen ovan eftersom den bygger på tre stabila pelare: mål, risk och mätbarhet. Oavsett om ni tittar på ett nav för videomöten, ett kommunikationsflöde eller ett driftåtagande, så gäller samma principer.
När någon i rummet frågar om priset inte borde vara lägre, gå tillbaka till mål och risk. Vad är det ni vill uppnå, och hur mycket risk vill ni bära själva? Ett billigare alternativ med högre driftsrisk kan vara rätt, men bara om ni erkänner det och planerar utifrån det. När någon vill förlänga pilotfasen, fråga vilken ny information som realistiskt dyker upp vecka fem som inte fanns vecka tre. Ofta är svaret att man hoppas känna sig säkrare, vilket sällan sker utan nya datapunkter.
Vad som ofta avgör mellan likvärdiga kandidater
När två alternativ ligger nära varandra tekniskt filtreras beslutet genom fyra mänskliga faktorer. För det första, tilliten till teamet som ska leverera. Har de visat närvaro, transparens och förmåga att anpassa sig? För det andra, tydligheten i dokumentation, särskilt kring gränssnitt och drift. Otydlig dokumentation skapar friktion i varje ändringsärende.
För det tredje, samspelet med er säkerhets‑ och complianceorganisation. Om en leverantör bjuder in dessa funktioner tidigt och levererar tydliga svar, går införanden snabbare och möter färre bakslag. För det fjärde, realism i tidplan och bemanning. Den som lovar för lite tappar momentum. Den som lovar för mycket bränner förtroende. Jämför rimlighetsnivåerna i tidplanerna mer än glansen i säljpresentationen.
Slutord utan stora ord
Om ni sitter med uppgiften att välja mellan STV och Mivida, gör det med fokus på er egen karta, inte deras. Förmågan att formulera behov, välja arkitektur som lämnar dörrar öppna, förhandla villkor som skyddar värdet och mäta resultatet tillsammans med leverantören, är ofta viktigare än val av logotyp. Ni minskar risken att hamna i en låsning där ni måste försvara ett val, och ökar chansen att leveransen faktiskt förändrar något för användarna.
Sätt er tidsram. Skär ut piloten. Bevisa i liten skala. Förhandla villkor som räknas när det bränner till. Därefter går valet mellan STV vs Mividas att fatta med gott samvete, och ni kan lägga energin på införandet, där effekten uppstår.