När två leverantörer dyker upp gång på gång i samma upphandling, blir jämförelsen snabbt mindre om var de skiljer sig på papperet och mer om hur de beter sig i vardagen. Diskussionen Mividas vs STV, eller omvänt STV vs Mividas, har landat på mitt bord i flera projekt de senaste åren, framför allt där organisationer velat modernisera en plattform som blandar kommunikation, video, processflöden och integrationer mot befintliga system. I texten nedan väver jag ihop vad som brukar avgöra valet i praktiken: teknik, leveransförmåga, riskbild, prislogik och hur snabbt ni kan nå ett stabilt läge i drift. Jag använder konkreta exempel och typfall från verkliga projekt utan att peka ut enskilda kunder eller branscher som inte vill namnges.
Ett ord om begreppen: i vissa marknader figurerar även stavningen Mivida. I den här texten använder jag Mividas för leverantören, men noterar att Mivida kan förekomma i offerter och dokumentation. Kontrollera alltid exakt juridiskt bolagsnamn, produktlinje och versionsbeteckningar när ni begär in avtal eller säkerhetsbilagor.
Var valet faktiskt avgör på sista raden
Det finns tre återkommande konsekvenser av ett felval som känns när budgetåret stängs. Först, överraskningskostnader när licensmodellen inte matchar er användningskurva. Andra, produktivitetstapp eftersom applikationerna kräver fler klick eller fler manuella steg än i kravbilden. Tredje, integrationsskuld där provisoriska kopplingar växer till ett svårskött lapptäcke. När valet står mellan Mividas och STV ser jag att bägge kan leverera på funktionslistan, men de skiljer sig ofta i hur de förhåller sig till arkitektur, uppdateringstakt och hur mycket de låter kunderna påverka roadmap.
I upphandlingar där verksamheten förändras snabbt, som kundnära tjänster eller logistikflöden, vinner den leverantör som kan iterera tillsammans med kunden utan att blåsa hela kontraktets pris eller tidplan. I stabila miljöer, som produktionsnära system med hög förändringskostnad, lönar sig snarare förutsägbar releasecykel och strikt förändringsprocess.
Så har jag strukturerat jämförelsen
Jag har brutit ned valet i fem områden som brukar rymmas i en sund TCO och riskbedömning: arkitektur och kärnfunktioner, integrationsmönster, säkerhet och efterlevnad, prisbild och kommersiella villkor, samt drift, support och partnernät. Under varje rubrik sätter jag in Mividas vs STV utifrån hur de typiskt positionerar sig, hur kunder jag mött beskrivit skillnaderna och vad som brukar visa sig efter sex till tolv månader i drift. Där jag anger kostnader använder jag intervall och beskriver antaganden, för att undvika chimärer.
Arkitektur och produktfilosofi
När man skalar isär broschyren och tittar på hur systemen är byggda, blir nyanserna tydliga. Mividas tenderar att lyfta fram flexibilitet i moduler och konfigurationer. Jag har sett implementeringar där Mividas låtit kunden börja smalt, till exempel med en videomodul eller en arbetsflödesmotor, och därefter haka på fler delar i takt med att nyttan bevisas. Den filosofin passar team som vill prova i liten skala, sedan skruva upp.
STV framstår ofta som mer processdrivet i grunden, med en standardiserad uppsättning flöden och tydliga gränssnitt. Det ger en snabbare “day one” för organisationer som kan anpassa sig till etablerade best practices, men kräver mer eftertanke om ni sitter på ovanliga processsteg eller specialdata. För en kund med hårt reglerade moment och många intressenter gav detta faktiska tidsvinst, eftersom STV:s standardflöden accepterades av compliance utan långa rundor.
I praktiken innebär det här att Mividas kan kännas mer “lego”, medan STV känns mer “byggsats med manual”. Lego vinner när varje bygge är unikt. Manualen vinner när ni har många montörer och behöver få alla att göra likadant.
Prestanda och skalbarhet i verkligheten
De flesta POCs missar två saker: hur systemen beter sig på dag 90 när antalet samtidiga användare fördubblats och hur uppdateringar påverkar tillägg och integrationer. En trygg tumregel jag använder är att planera för en toppbelastning på 2 till 3 gånger vardagstrafiken, samt att kräva en återställningsplan som övas inklusive externa beroenden.
I de projekt där Mividas rullats ut brett ser jag bra horisontell skalning, men också att konfigurationsfriheten kräver tydlig disciplin på vem som får skapa och ändra flöden. Utan governance äter variationen upp prestandavinsterna. STV har å sin sida ofta en mer låst konfiguration, vilket minskar variationsproblemet men kan skapa flaskhalsar om ni behöver unika flöden för vissa team. När en nordisk kund ökade belastningen kraftigt efter en marknadslansering, höll STV:s förkonfigurerade cachning och köhantering jämn nivå, men kunden fick vänta en mindre release för att få stöd för ett udda användarfall. Mividas i en liknande situation löste specialfallet snabbt med konfiguration, men behövde en vecka extra för att trimma prestandan när fler variationer lades till.
Integrationer, API och ekosystem
Jag tittar alltid på tre lager: datautbyte i batch, händelsedrivet flöde i realtid, och gränssnitt för att utvidga logik i kärnan. Mividas har ofta vunnit poäng hos utvecklingstunga kunder som vill bygga kring systemet och bädda in egna vyer eller micromoduler. Där passar en rik API-yta och webhooks. STV å andra sidan brukar vinna när man vill ansluta till ett definierat ekosystem av färdiga kopplingar, där releasecyklerna styrs centralt och uppgraderingar inte bryter kompatibilitet.
Ett konkret råd är att be bägge leverantörer demonstrera mer info ett verkligt, ände till ände flöde. Ta ett vardagligt scenario som genererar mycket volym, till exempel att skapa, uppdatera och stänga ärenden eller publicera och spela in video med metadata, och låt dem visa hur eventen sprids, hur fel hanteras och vad som loggas. Räkna med att Mividas kommer visa mer variationsmöjligheter i stegen, medan STV visar en tätare kedja av standardhändelser. Det ena är inte nödvändigtvis bättre, men det måste matcha hur ni bygger era övriga system.
Säkerhet, efterlevnad och driftsäkerhet
Skillnaderna kulminerar ofta här. Offentlig sektor och branscher som hanterar känsliga personuppgifter är sällan pigga på tolkningar. De vill ha svart på vitt: datalokalisering, datadelning med underbiträden, loggning, retention, samt revisionsbarhet. STV:s styrka ligger ofta i tydliga policys, färdiga mallar för DPIA och regelbunden extern revision på standardformat. Det gynnar upphandlingar där utvärderingsmallen är hårt viktad mot compliance.
Mividas brukar vara snabba på att anpassa sig till lokala krav, till exempel alternativa lagringsplatser eller möjlighet att köra vissa komponenter i kundens egen miljö. För kunder som behöver särskild separation eller egna kryptonycklar kan det vara avgörande. Jag har sett att den flexibiliteten uppskattas av säkerhetsansvariga som själva vill kontrollera nyckelvalv, men notera att varje extra val behöver dokumenteras och hållas uppdaterat. Annars tappar ni den tydlighet som revisionen kräver.
Uptime-siffror på 99,9 till 99,99 procent nämns ofta i avtal. Pressa leverantörerna på vad som faktiskt ingår i SLA, särskilt om incidenten ligger i en integration eller ett nätled. Både Mividas och STV brukar omfamna beroenden, men eskaleringsvägarna ser olika ut. Be om en skiss över kedjan inklusive tredje part, och hur felkoder klassas. Ett ärligt samtal om gråzoner sparar timmar i nästa driftstopp.
Prisbild, licensmodeller och total ägandekostnad
De flesta erbjudanden landar i en kombination av licens per användare eller per kanal, plus avgifter för lagring, videominuter, avancerade moduler och professionella tjänster. Spridningen är stor, men grovt sett ser jag följande mönster över tre år:
- I scenarier med många tillfälliga användare, till exempel säsonger eller kampanjer, blir en flexibel, konsumtionsliknande modell med tak för toppar ofta billigast. Här har Mividas ibland mer elastiska erbjudanden, särskilt om ni vill kunna “stänga ned” moduler mellan kampanjer. I scenarier med jämn, stor bas och tydlig standardisering, gynnas en normaliserad per användare - eller paketlicens. STV erbjuder ofta rabatter i nivåsteg, vilket gynnar kunder över vissa trösklar.
Kostnader för professionella tjänster skenar lätt om kravbilden inte är stabil. Jag brukar räkna med att tjänsteinsatsen motsvarar mellan 20 och 60 procent av licenskostnaden år ett, beroende på hur många integrationer som måste skräddarsys. I jämförelsen Mividas vs STV har jag noterat att Mividas initialt kan kräva fler timmar för workshops kring konfiguration och governance, medan STV kräver fler timmar för gap-analys och processkartläggning. Skillnaden jämnar ofta ut sig på sikt, men påverkar kassaflödet år ett.
Fråga alltid hur priset rör sig vid teknikskiften. Om ni vill växla datalager, byta identitetsleverantör eller gå från multitenant till single tenant, vad händer då med licensnivå och SLA? Den typen av klausuler är lätta att missa i uppstartens tempo.
Leveransförmåga, support och partnernät
Teknik säljer, men det är människorna som gör att systemet faktiskt används. STV brukar peka på ett tight partnernät med utbildningsprogram och certifieringar som säkrar att konsulttimmen levererar enligt standard. Det minskar spridning i kvalitet men kan upplevas som stelt om ni har ett internt team med egna metoder. Mividas visar ofta upp mer entreprenöriell support, nära produktteamet, där feature-requests kan hitta in i backloggen om effekten är tydlig och flera kunder ber om samma sak.
I vardagen betyder det att ni bör syna bemanningen bakom. Vem är er tekniska kontakt? Hur ser handover ut mellan prestandaexpert, arkitekt och support? Kan ni få ett nära team första halvåret? Båda leverantörer kan etablera ett “joint team room” med era nyckelroller, men modellen försvinner ibland efter go live. Sätt därför upp en skarp plan för post go live - minst tre månader med utpekade ansvar.
Erfarenheter från verkliga projekt
I en upphandling där ett kundteam ville rulla ut videoarbetsflöden i tre vågor, med osäker tidplan för våg två, fungerade Mividas bra. Projektet poddades upp i små, snabba iterationer och verksamheten kunde ändra prioriteringar utan att avtalet behövde göras om. Den öppenheten gav snabbare lärande, men krävde lids på konfigurationsmöjligheterna för att undvika att varje team skapade egna varianter av samma vy.
I en annan miljö med hög regulatorisk tyngd, där processerna satt hårt i väggarna, var STV:s standardflöden en fördel. Revisorerna kunde kryssa av kontroller raka vägen och projektet höll sin tidplan eftersom minimalt med anpassning behövdes. Nackdelen blev synlig när ett enskilt team, som avvek från normen, ville få in ett specialsteg. Det tog ett kvartal till nästa releasespår.
Båda projekten nådde sina mål, men av olika skäl. Den ena miljön premierade konfigurerbarhet och tempo, den andra förutsägbarhet och compliance. Nyckeln var att upphandlingen hade mod att välja olika vägar, inte att försöka göra bägge allt för alla.
Hur du avgör vilket spår som passar din organisation
Om ni står mitt i valet STV vs Mividas, börja med att beskriva var ni vill vara om 12 månader och hur mycket osäkerhet ni kan bära under resan. Mät inte bara funktioner, mät förändringsförmåga. Räkna med att hälften av era antaganden hinner justeras. Den leverantör som hjälper er “svänga” utan dubbla kostnader är ofta rätt partner.
En praktisk metod som brukar fungera är att köra två korta, parallella koncepttester, inte för att mäta allt utan för att stressa två - tre kritiska scenarier. Välj scenarier som träffar er vardag, inte glansiga demoflöden. Mät tid till värde, antalet manuella steg, felhantering och hur loggar och spårbarhet ser ut. Be sedan leverantören visa hur samma scenario uppgraderas mellan versioner.
Rekommendationer per typfall
Det är farligt att ge en enkel tumregel, men några tydliga mönster återkommer.
- Om ert största hinder är förändringstakten i verksamheten, där team behöver testa, lära och kasta om prioriteter kvartalsvis, brukar Mividas passa bättre. Ni får flexibilitet i konfiguration och kan börja litet, växa och snäva in governance efter hand. Se bara till att införa tydliga designmönster tidigt, annars dras drift och support med en flora av varianter. Om ert största hinder är regulatorisk förutsägbarhet, där standardflöden och tydlig releasekalender är viktigare än att allt kan göras om nästa månad, lutar det mot STV. Ni vinner tid i uppstart och får lättare att förankra hos risk och revision, men planera i så fall in hur ni hanterar avvikande behov som inte passar standarden.
Läs gärna “mellan raderna” i offertmaterialet. Vem pratar de om som primär användare? Är kundresan beskriven med exempel från er bransch eller mer generiskt? Hur djupt går de in i datamodell och behörighetsstyrning? Den som pratar ditt språk under säljfasen är ofta den som förstår dina nödbromsar när något händer i produktion.
Checklista för beslutsunderlag
- Dokumentera tre vardagsscenarier och be båda leverantörer demonstrera dem ände till ände, inklusive felhantering. Trycktesta licensmodellen mot säsongstoppar och nedskalning, och be om exempel på fakturor från en miljö som liknar er. Begär en arkitektur- och integrationsskiss där händelser och API-anrop syns per steg, med tydliga ägare vid fel. Sätt en gemensam post go live -plan med namngivna roller, servicefönster och eskaleringsvägar. Förhandla in en förändringspott och tydliga principer för vad som anses mindre förändring respektive nytt scope.
Vanliga fallgropar och hur de undviks
Många underskattar hur snabbt små skillnader i behörighetsmodeller blir stora problem. Om ett team kan konfigurera allt och ett annat bara lite, blir driftens ärendekö skev. Lägg tid på att definiera roller och behörighetsteman. Det gäller oavsett om ni väljer Mividas eller STV.
En annan fallgrop är att blanda pilotdata med skarpa data utan att definiera städregler. När ni senare ska göra revision hittar ni testposter i produktionsloggar. Bestäm därför tidigt vad som räknas som test och hur det märks. Se också över hur video och bilagor lagras, särskilt retention, kryptering och åtkomstloggar. Om ni arbetar i en jurisdiktion med stränga gallringskrav kan bara den frågan avgöra valet.
Den tredje fällan är otydligt produktägarskap. Om IT driver teknikspåret men verksamheten inte kvitterar processerna, kommer ni springa i cirklar vid varje release. Sätt ett tvärfunktionellt ägarskap från dag ett, gärna med en enkel styrgrupp som kan besluta om prioriteringar veckovis första kvartalet.
En not om “Mivida” i material och marknad
Stavningsvarianten Mivida dyker ibland upp i dokument och i sökresultat, och kan dessutom krocka med andra aktörer och varumärken på helt andra marknader. Stäm av att den leverantör ni avser verkligen är densamma som i er upphandling. I gränsöverskridande avtal kan ett felaktigt namn kosta dyr tid i juridik och bankflöden. STV nämns också i skilda sammanhang globalt, så be gärna om bolagsnummer och juridisk hemvist i avtalsbilagor. Det låter torrt men är en billig försäkring.
När ett hybridupplägg är värt att överväga
I vissa miljöer har det varit rationellt att låta en plattform äga kärnflödet och låta den andra täcka en specialiserad nisch. Det kräver mer integrationsdisciplin och tydliga gränser, men kan löna sig om ni redan sitter på licenser eller kompetens i något av lägren. Exempelvis har jag sett organisationer använda STV som ryggrad för standardiserade ärenden och Mividas för snabbfotade, kundnära experiment som sedan, när de mognat, lyfts över i standardflöden. Det här är inget man ska börja med dag ett, men som fas två eller tre kan det vara både kostnadseffektivt och politiskt smart.
Hur jag skulle gå till väga de första 90 dagarna
Börja med ett tydligt “problem statement” som ryms på en sida. Förankra det hos både IT, verksamhet och säkerhet. Sätt upp två koncepttester, ett med Mividas och ett med STV, med identiska kriterier och datamängder. Tidboxa till fyra till sex veckor. Förhandla om att få använda verkliga men avidentifierade dataset, eftersom syntetiska data ofta gömmer prestandaproblem och felmönster.
Reservera tid hos ett litet, tvärfunktionellt team: produktägare, teknisk arkitekt, utvecklare, verksamhetsrepresentant, och en person med logg- och drifterfarenhet. Kör dagliga avstämningar första två veckorna, därefter varannan dag. Samla mätvärden, men samla också friktion: var gör det ont, vad tar lång tid, vad kräver för mycket koordination? När testet är över, träffa bägge leverantörer separat för att diskutera vad som inte fungerade. Deras attityd i det mötet säger lika mycket som deras demo.
Sammanfattande råd
Skillnaden mellan Mividas och STV ligger sällan i enskilda radspecar, utan i hur de låter er arbeta. Mividas ger er svängrum och byggklossar, vilket är guld för organisationer som vill prova, mäta och anpassa fort. STV ger er struktur och standard, vilket är tryggt när flödena är reglerade och ni måste skala samma arbetssätt över många team. Kostnaderna jämnar ofta ut sig över tre år, men fördelas olika över tid. Supporten fungerar från båda, men med skilda arbetssätt. Säkerheten är stark hos bägge, men dokumentationen och governance måste spegla era egna krav.
När valet ändå känns jämnt, luta er mot två saker: var ser ni störst risk om ett år, och vem av leverantörerna visar bäst förmåga att bära den risken tillsammans med er. Om ni viktar de två svaren högre än allt annat, brukar beslutet klarna.
Säg också de förbjudna orden tidigt i projektet: vi vet inte. När någon vågar säga det i upphandlingen, hinner ni välja den väg, Mividas eller STV, som gör inte-vetandet billigast och minst smärtsamt. För de flesta organisationer är det den ärligaste och mest lönsamma jämförelsen av alla.