När två system står mot varandra i en upphandling, STV vs Mividas, fastnar diskussionen ofta i funktionslistor. Det är begripligt men vilseledande. Valet mellan plattformar avgörs i praktiken av hur snabbt, säkert och kostnadseffektivt ni kan driftsätta, samt vilka interna och externa resurser som krävs för att hålla farten hela vägen. Den som underskattar implementeringstiden eller resursläckaget upptäcker det först när projekttåget redan rullar och kalendern fylls av omplaneringar.
I den här texten går jag igenom hur skillnaderna mellan Mividas och STV brukar slå mot kalender, bemanning och riskbild, utan att göra antaganden om exakt funktionalitet som varierar mellan produktversioner och leverantörspaket. Poängen är att ge er ett sätt att tänka och räkna som håller även när detaljerna skiljer sig. Jag använder exempel med rimliga intervall, hämtade från faktiska införanden i nordiska organisationer de senaste åren.
Vad vi faktiskt jämför
Båda namnen förekommer i svenska upphandlingar och RFP:er inom närliggande områden, ofta där realtidskommunikation, video, ärendehantering eller säkerhetsnära processer ingår. I vissa dokument skrivs Mividas som Mivida. Den här genomlysningen rör inte en viss modulespecifikation, utan implementeringsresan i bred mening: miljöförberedelser, integrationer, datamigrering, test, utbildning och driftsättning. När jag skriver Mividas vs STV menar jag två konkurrerande plattformar med olika leveransmodeller och arkitekturella val, vilket får tydliga konsekvenser för hur snabbt ni kommer i mål och var ni lägger arbetstimmarna.
Implementeringstid: kalendern som styr allt annat
Det första många frågar efter är en siffra: hur lång tid tar det? Ett ärligt svar är ett intervall med förbehåll, för att skillnaden mellan ett smalt pilotomfång och en fullskalig utrullning är dramatisk. I praktiken ser jag tre lägen:
- Smal pilot i en avdelning, begränsade integrationer, standardkonfiguration. Mellanskala med två till tre kärnintegrationer, viss datamigrering, utbildning i flera team. Fullskalig utrullning i flera länder eller enheter, anpassad behörighetsmodell, fler än fem integrationer och formell change management.
I det första läget handlar det ofta om 4 till 8 veckor, förutsatt att miljöerna är redo och styrgruppsbeslut kan tas veckovis. Mellannivån landar oftare på 3 till 5 månader, där den kritiska flaskhalsen är integrationernas ledtider och organisationens förmåga att frigöra nyckelpersoner. Fullskalig utrullning spänner mellan 6 och 12 månader, ibland längre, särskilt när flera verksamhetsprocesser ska standardiseras innan tekniken kan låsas.
Skillnaden mellan STV och Mividas i tid handlar sällan om ren prestanda, utan om implementationsmönstret. En plattform som är stark i färdig paketering vinner ofta de första åtta veckorna, den som är mer modulär vinner när omfånget blir komplext. Om STV i ert fall kommer med mer “out of the box” för era driftsförutsättningar, och Mividas erbjuder flexiblare gränssnitt för integrationer, då blir valet av vägkarta mer än en teknisk preferens. Det avgör hur många beslut ni måste ta, i vilken ordning, och med vilken trygghet ni kan fasa ut befintliga verktyg.
Ett konkret exempel: ett bolag i energisektorn som skulle ersätta ett äldre videomötes- och ärendehanteringsflöde valde en snabbstart med standardkonfiguration i STV, två integrationer mot AD och kalender, och tog produktion i ett pilotområde på sex veckor. När de senare behövde ett mer avancerat behörighetsupplägg och historisk datamigrering växte backloggen. En annan kund i offentlig sektor började i stället med Mividas, ritade integrationer mot fem källor och byggde en tydlig datamodell. Första produktionssättningen kom efter fyra månader, men de klarade å andra sidan migrationssteg och utökad utrullning med marginella fördröjningar. Båda var nöjda, men av olika skäl. Kalendern följde arkitekturen.
Resursbehov: timmarna ni inte ser i budgetraden
Många budgetar tar höjd för licenser och konsulttimmar, men missar intern tid i nyckelroller. Det är här projekt snubblar. Tre roller underskattas systematiskt:
Systemägare eller produktägare. Personen som prioriterar backlogg, beslutar om avvägningar och fångar upp beroenden. Räkna med 30 till 60 procent av en heltid i intensiva faser, oavsett plattform.
Integrationstekniker eller arkitekt på kundsidan. Leverantören bygger, men er arkitekt tar ansvar för riktning, namngivning, säkerhetsnivåer och överlämning till förvaltning. I en mellanstor utrullning summerar detta ofta till 100 till 200 timmar över tre månader.
Superanvändare eller utbildningsambassadörer. Två till fem personer som översätter processer till praktik, testar på riktigt data och stöttar vid driftsättning. De behöver tid före, under och efter go live. Första kvartalet bör ni avsätta 40 till 80 timmar per superanvändare.
På leverantörssidan varierar timinsatsen beroende på hur väl plattformen matchar er standardmiljö. En förkonfigurerad STV-leverans med tydliga mallar kan hålla sig på 80 till 150 konsulttimmar för pilot, medan en här Mividas-implementation som bygger fler kopplingar hamnar på 150 till 300 timmar innan första driftsättning. Vid fullskala rör det sig lätt om 400 till 800 timmar sammantaget, fördelat över flera roller. Det här är inte “rätt” eller “fel”, bara olika vägar till samma mål. Korta vägar kräver färre val, längre vägar ger mer kontroll.
Tekniska förutsättningar som förkortar eller förlänger vägen
Ett projekt som ser lätt ut på pappret blir komplext när det möter verkligheten. Tre tekniska områden avgör tempot mer än någon enskild funktion:
Identitet och åtkomst. Finns en uppdaterad katalog, tydliga grupper, rollbeskrivningar och processer för livscykel? Om svaret är ja, oavsett om det kopplas via SAML, OIDC eller LDAP, går onboarding snabbare. Om ni samtidigt måste städa AD, räkna med 2 till 6 veckors glapp som visar sig sent om ni inte frontlastar det.
Integrationer. Om plattformen har färdiga anslutningar till era vanligaste källor, läggs timmarna i konfiguration och test. Om API:erna är öppna men inte standardiserade för just era system, krävs arkitektur- och datamodelleringsarbete. Båda vägar fungerar, men den första ger en snabbare första leverans, den andra kan ge en mer exakt spegling av era processer.
Nätverk och säkerhet. On-prem, hybrid eller ren moln, det avgör brandväggsregler, certifikat, loggning och hur ni testar fel. En ren molnimplementation i en välordnad tenant med CIAM/IdP på plats går fortare att få upp. Hybrid kräver ofta fler beslutsmöten med IT-säkerhet och fler testrundor för loggkedjor.
När jämförelsen handlar om STV mot Mividas blir arkitekturstilen viktig. Om STV erbjuder en mer låst men snabb anslutning till ert ekosystem sparar ni veckor. Om Mividas ger större frihet i datamodell och gränssnitt, tjänar ni vid komplex processharmonisering. Välj det som bäst matchar era beroenden, inte det som låter mest imponerande i en demo.
Riskbild: var fel uppstår och hur de fångas
De flesta risker är inte tekniska utan organisatoriska. Tekniska risker går nästan alltid att testa bort med tid och discipline, men tid är en ändlig resurs. Tre mönster återkommer:
Oklar prioritering skapar mikropauser. När projektledaren inte har mandat att fatta små beslut stannar allt upp i väntan på veckomöten. Lösningen är en tydlig beslutsmatris med låga trösklar för vardagsval, och bara de riktigt tunga frågorna till styrgruppen.
Skuggprojekt. Parallella initiativ i andra team drar nyckelpersoner och ändrar förutsättningar. En förändrad schema- eller katalogstruktur mitt i ett testfönster kostar veckor, inte dagar. Koordinera roadmaps i början och lås fönster för förändringar under kritiska perioder.
Datakvalitet. Dåliga register är den klassiska tidsboven. Därför fungerar en tvåstegsmigrering ofta bäst: en provmigrering med stickprov på 5 till 10 procent av datat, följt av en justerad fullmigrering. Hoppa inte över det steget.
Tekniskt sett handlar riskreducering om att inte hoppa direkt till fullskala. Ett “walking skeleton”, en minimal men hel flödeskedja i testmiljö, fångar fler fel än isolerade enhetsprov. Loggning, spårbarhet och syntetiska testkonton sparar timmar när något bryts vid en versionsuppgradering.
Två arbetssätt: paketväg och byggväg
När jag kartlägger projekt lägger jag nästan alltid alternativen i två korgar. Paketvägen, typiskt för en mer standardiserad STV-leverans, och byggvägen, oftare det naturliga valet med en modulär Mividas-approach. Ingen av dem är per definition bättre, men de passar olika lägen.
Paketvägen bär på ett löfte om fart. Ni köper ett väl beprövat upplägg och följer en definierad plan. Utmaningen kommer när verksamheten vill töja på ramarna. Ni vinner veckor i början, men kan hamna i omtag om processerna inte anpassas.
Byggvägen kräver mer beslutsarbete tidigt, men är snällare mot komplexa processer och legacymiljöer. Ni förlorar initial fart, men minskar risken för sena återvändsgränder. Nyckeln är att inte öppna alla ventilationsluckor samtidigt, utan ringa in vad som måste vara konfigurerbart nu och vad som kan vänta.
I många projekt landar den kloka kompromissen i en paketstart följd av kontrollerade utbyggnader. Det kräver dock att både STV och Mividas kan bära ett etappvis införande, och att ni sätter versionsstyrning och testregim så att varje etapp är en produktionsklar helhet.
Casevinjetter från fältet
En privat vårdgivare med 1 200 användare ville snabbt fasa ut ett åldrande samarbetsverktyg. De valde en STV-leverans med förkonfigurerade mallar, SSO via OIDC och två integrationer. Första kliniken gick live på fem veckor, driftstörningar var få. När STV vs Mividas de senare behövde mer granulär åtkomst och rapportering blev backloggen större än planerat, och nästa etapp tog elva veckor. Totalt var de i mål på fyra månader, men tyngdpunkten försköts efter pilot.
En regional myndighet med tre förvaltningar prioriterade i stället tydliga dataflöden och revisionsspår. De valde Mividas, byggde fem integrationer inklusive ett äldre dokumentflöde och skissade en egen rollkarta. Första driftsättningen tog fyra månader, andra och tredje rullades ut med tre veckors mellanrum. De sparade tid i slutet, men betalade med fler beslutsmöten i början. Kostnadsbilden över tolv månader blev likartad, men timmarna låg på olika kvartal.
Syftet med exemplen är inte att kröna en vinnare, utan att visa hur Mividas vs STV påverkar rytmen i projektet. När ni läser in er på referenser, läs mellan raderna: var låg arbetstoppen och vem bar den?
Kostnad och TCO ur ett implementeringsperspektiv
Det är lockande att jämföra licenskostnad per användare och stoppa där. För att få en rättvis bild behöver ni kalkylera tre komponenter under implementeringen:
Intern tid i nyckelroller. Ett projekt med 300 interna timmar a 700 kronor per timme kostar lika mycket som 210 000 kronor i synliga konsulttimmar. Den posten smyger ofta in i “övrigt”.
Förseningarnas alternativkostnad. Om ett system som ska frigöra 10 procent handläggartid försenas tre månader för 150 användare, försvinner 1 500 till 2 000 arbetstimmar i värde, beroende på kalkyl. Den kostnaden syns inte i projektbudgeten, men är reell.
Teknisk skuld. Att välja den snabba vägen nu kan skapa en skuld som måste betalas när ni expanderar. Två extra veckor i början för att definiera API-kontrakt och loggningsstandarder kan spara månader vid nästa etapp. Boka in den tiden, räkna den som investering.
När ni jämför STV och Mividas, titta på hur mycket konsultstöd som ingår, hur utbildning paketeras, och hur överlämning till förvaltning ser ut. En dyrare offert kan bära mer färdigt innehåll och därmed mindre risk, men bara om innehållet matchar er process och inte behöver skrivas om.
Styrning och förändringsledning
Tekniken blir klar snabbare än människorna. Det viktigaste i förändringsledningen är att inte gömma besluten i projektet. Gör driftsättningen till en verksamhetshändelse, inte en IT-nyhet. Låt superanvändare visa korta demoinslag i linjemöten, lägg utbildning i kalendern före go live, och ha en synlig supportkanal som svarar samma dag. Om ni byter arbetssätt i samband med ny plattform, frys det gamla verktyget tidigt för de flöden som ska över, annars blir det dubbelarbete som drar ut på tiden.
Ett litet knep som fungerar: formulera tre meningar som svarar på varför bytet sker, vad som blir bättre för användaren och vad som blir annorlunda första veckorna. Upprepa dem i varje kommunikation. Det låter enkelt, men är ofta det som gör att teamen faktiskt byter beteende.
Due diligence-frågor att ställa innan ni väljer
- Vilka färdiga integrationer finns mot våra källsystem, och vilka behöver byggas? Visa en karta med dataägare och uppdateringsfrekvens. Hur ser standardmigrering ut för vår typ av data? Beskriv provmigrering och fullmigrering, samt hur rollback hanteras. Vilken teststrategi följer ni, från enhetstest till end-to-end i produktionslik miljö? Visa exempel på testrapporter. Hur löses identitet, behörighet och livscykelhantering i vår katalog, inklusive avvikande roller? Vad ingår i utbildningspaketet, och hur säkras förvaltning och versionsuppgradering utan driftpåverkan?
Syftet är att få bort dimridåer tidigt. Om svaren saknar konkreta artefakter, räkna med extra tid i projektet.
En praktisk checklista inför driftsättning
- Är minsta helhetsflöde testat med syntetiska och riktiga användarkonton, inklusive loggning och larm? Finns superanvändare namngivna, utbildade och schemalagda första två veckorna efter go live? Är datamigrering godkänd via stickprov med dokumenterad toleransnivå? Har vi en reverseringsplan om något fallerar, med tydliga trösklar för beslut? Är supportvägar och ansvar under de första 14 dagarna tydligt beskrivna för hela teamet?
Fem ja-svar innebär att ni är klara, allt annat är optimering eller chansning.
När STV är rätt, när Mividas är rätt
Om ert främsta mål är att snabbt ersätta ett befintligt verktyg med snarlik funktionalitet, med begränsad komplexitet i integrationer och en relativt homogen användarbas, talar mycket för en mer paketerad leverans. I många upphandlingar är det här styrkan som tillskrivs STV. Ni nyttjar fördelarna med färdiga mallar och kan stödja användarna när allt fortfarande är färskt.
Om ni däremot ska harmonisera processer över flera enheter, knyta ihop flera datakällor och skapa en anpassad struktur för roller och rapportering, tjänar ni ofta på en modulär väg. I flera situationer är det bilden som kopplas till Mividas, där ett öppet gränssnitt och en flexibel datamodell bär bättre i längden. Det gör startsträckan längre, men minskar överraskningarna senare.
Det avgörande är att matcha vägvalet med era begränsningar. Har ni snäva fönster och en trött organisation, välj snabbhet och stabilitet. Har ni tid att designa och ett tydligt behov av särskiljning, välj arkitekturell frihet.
Vanliga fallgropar och hur ni undviker dem
Att försöka “smuggla in” extra krav efter att planen satts. Lägg en förändringsbuffert i varje sprint eller etapp, gärna 10 till 15 procent, och tvinga in nya idéer i nästa fönster. Den disciplinen håller tempot.
Att undervärdera utbildning. En timmes genomgång per roll räcker sällan. Räkna med två till tre korta pass, inspelad mini-demo och lättåtkomlig FAQ. Styr uppföljning första veckan.
Att missa lasttest och samtidighet. Även om plattformen skalar, är er nätverksmiljö och kringliggande system inte alltid lika följsamma. Kör en toppbelastningssimulering med realistiska scenarier. Det fångar flaskhalsar i proxy, brandväggar eller loggflöden.
Att tro att driftstart är slutet. De första 30 dagarna avslöjar det ni inte visste att ni behövde. Planera för en hypercare-period med tät närvaro och snabba förändringar. Stäng inte projektet förrän ni sett mönstret i felanmälningar och beteendedata.
Om ordvalet Mivida, och varför det spelar mindre roll
I dokumentationen syns ibland Mivida som benämning, ibland Mividas. Oavsett stavning är frågan densamma: vad betyder valet för era kalendrar, era resurser och er riskaptit? Blanda inte ihop varumärkesdetaljer med vägval i implementationen. En bra leverans löser rätt problem i rätt ordning, med tydliga gränser mellan det som måste vara klart nu och det som kan vänta till nästa etapp.
Slutlig orientering inför beslut
Titta på tre saker när ni står mellan STV och Mividas. Först, era viktigaste beroenden under de kommande sex månaderna. Om andra förändringar i katalog, nätverk eller datakällor redan ligger planerade, välj den plattform och leveransmodell som är mest förlåtande mot förändring. Andra, den interna kapaciteten i erbetsledande roller. Om ni har starka produktägare och arkitekter, kan ni utnyttja en byggväg. Om ni saknar den tiden, välj en paketerad väg och håll hårt i omfattningen. Tredje, affärsrisken för försening. Om varje vecka utan nytt system kostar mycket i produktivitet eller kundvärde, betala för snabbstart och standardisering, och finjustera senare.
När ni gör er egen bedömning, låt inte rubriken STV vs Mividas skymma det som verkligen styr utfallet. En tydlig karta, ärliga resursantaganden och ett disciplinerat arbetssätt vinner över vilken tekniklogga som än står på lådan. Det är inte mindre tekniskt, bara mer professionellt. Och professionella projekt kommer i mål.