Efter tre månader brukar den första förälskelsen ha lagt sig, både i privatlivet och i nya teknikinköp. Du har tillräckligt med data för att skilja tur från systematik, men du är fortfarande tidigt nog för att justera kursen utan att kostnaderna skenar. När företag ställer Mividas mot STV hamnar beslutet ofta i abstrakta jämförelser om funktioner och prislistor. Det är sällan där värdet bor. Värdet visar sig i användarnas beteende, i hur snabbt teamen får effekt, och i hur smidigt lösningen kliver in i den befintliga verkligheten av processer, säkerhet och ekonomi. Den sortens värde går faktiskt att mäta redan efter 90 dagar, om du sätter upp ramen rätt.
Den här texten är skriven ur perspektivet hos en som suttit på både affärs- och teknikstolen under införanden. Jag har sett ambitiösa roadmaps falla på en enda försummad integration, och sett enkla produktval lyfta en hel funktions rad för att tid till effekt halverades. Metoden nedan fungerar lika väl när debatten internt heter Mividas vs STV som när den uttrycks som STV vs Mividas. Vissa skriver Mivida i stället för Mividas, men resonemanget är detsamma.
Vad betyder värde efter 90 dagar?
Tre månader ger normalt nog observationer för att avgöra riktning. Det är inte slutbetyget, men det är tillräckligt för att svara på tre frågor: skapar lösningen faktisk effekt i vardagen, är den effekten repeterbar, och går kostnaden i rätt riktning. När jag säger effekt menar jag antingen mer intäkt, lägre kostnad, lägre risk, eller snabbare tid till leverans. Allt annat är mellanled.
Fällan här är att välja för breda indikatorer, då drunknar du i data och missar signalerna. Fällan är också att stirra på yttre glamour, som snygga dashboards, i stället för inre friktion, som antalet manuella handpåläggningar kvar i processen. Efter 90 dagar vill du kunna peka på konkreta beteendeförändringar: hur många använder produkten varje vecka, hur ofta blir arbetet klart på första försöket, och hur ofta behöver ni ringa supporten.
Förarbete dag noll: baslinje och hypotes
Innan du slår på första produktionsflödet behöver du en förankrad baslinje. Utan den blir jämförelsen mellan Mividas och STV i praktiken en diskussion om magkänsla. Baslinjen bör vara så nära verkligheten som möjligt: faktiska volymer, faktiska handläggningstider, faktiska felräntor. När en säljare säger att en konfiguration tar en timme, jämför det med hur lång tid motsvarande steg tar hos er i dag. I ett case hos ett bolag jag arbetat med var hävstången inte en enskild funktion, utan att onboarding av nya användare gick från 3 timmar per person till 45 minuter. På 180 användare blev det 465 timmar i besparing bara på tre månader, vilket täckte mer än halva licenskostnaden under samma period.
Skriv också ner en hypotes som går att pröva. Om hypotesen för STV är att den har mognare processautomation och därmed minskar manuella steg med 30 procent inom 90 dagar, då vet du exakt vad du ska mäta. Om hypotesen för Mividas är att plattformen har högre användarengagemang och därför når 60 procent veckovisa aktiva användare i pilotgruppen inom sex veckor, då är det en lika prövbar tes. Hypoteserna får gärna vara olika, de pekar ofta på styrkor i respektive produkt.
Datainsamling utan cirkus
Det ska vara enkelt att samla data, annars samlar du bara in vid högtider. Två spår behövs parallellt: kvantitativa loggar och kvalitativa observationer. Kvantitativt vill du fånga användaraktivitet, ledtider, antal fel och supportärenden, samt kostnadsdrivare som extra moduler eller konsulttimmar. Kvalitativt behöver du korta, tätare avstämningar med användare och drift. Hellre femton minuter varannan vecka än ett långt möte efter två månader.
Se till att samma mätpunkter gäller för båda alternativen. Om du mäter adoption på Mividas baserat på unika inloggningar, mät inte adoption på STV baserat på antal slutförda ärenden per användare. Välj en metod och håll fast vid den. Båda måtten kan vara relevanta, men jämförelsen kräver symmetri.
Sju mått som brukar avgöra utfallet
Ingen organisation är identisk med en annan, men vissa indikatorer återkommer. Om du bara orkar mäta en handfull saker under 90 dagar, välj de här.
- Tid till första värde: dagar från start till första meningsfulla användning, till exempel att ett team kan avsluta ett riktigt ärende utan hjälp. Aktiv användarandel vecka 4, 8 och 12: andel i pilotgruppen som loggar in och utför kärnaktivitet minst en gång per vecka. Fel per 100 transaktioner: en robust indikator på kvalitet och på hur ofta användarna fastnar. Supporttryck: ärenden per 10 användare och medianlösningstid. Löpande kostnadstakt: licens plus konsult och intern tid, per månad, samt hur mycket som är engångs- respektive återkommande.
I flera införanden har just tid till första värde blivit tungan på vågen. Den inte bara speglar produktens design, utan också hur väl säljarnas löften överlevt implementeringen. Ett system som ger första värde på dag 12 slår ofta ett som ger större värde men först på dag 45, åtminstone om projektrisk väger tungt i din organisation. 90-dagarsfönstret gynnar lösningar med låg startfriktion.
Ekonomi som går att förklara för CFO på tre minuter
CFO vill inte ha teknotermer, hen vill se en mini P&L. Jag använder en enkel modell med fyra rader: besparingstempo, intäktstempo, löpande kostnadstempo och en post för riskreduktion. Efter 90 dagar räcker det att uttrycka varje rad som ett månadsintervall, inte ett årsestimat. Exempelvis kan besparingstempot uttryckas som 60 till 90 timmar per månad i minskad manuell hantering, vilket vid en intern kostnad på 600 kronor per timme motsvarar 36 000 till 54 000 kronor per månad. Om licens och konsult vid samma tidpunkt landar på 42 000 kronor per månad har du en tät argumentation redan där.
Riskreduktion är STV vs Mividas knepigare att monetarisera tidigt. Jag brukar räkna defensivt, som minskad sannolikhet för allvarligt driftstopp eller efterlevnadsavvikelse. Om ni historiskt haft två incidenter per år med snittkostnad 200 000 kronor, och den nya lösningen under 90 dagar tydligt visar förbättrade kontroller eller lägre felhastighet, kan en försiktig ansats vara att kreditera 5 till 10 procent av den historiska årskostnaden i månadsform. Det är ingen exakt vetenskap, men det är bättre än att låtsas som att risk inte har ett pris.
Teknik som inte fastnar i övergången
En vacker produkt på fel plats i din arkitektur blir allt annat än vacker. På 90 dagar hinner du inte bygga hela drömmen, så du måste välja de integrationspunkter som ger mest signal. Tre riktlinjer brukar räcka.
Först, mät integrationsskuld. Räkna timmar för temporära script, manuella export och import, samt antalet manuella kontroller som måste utföras för att säkra kvalitet. Om Mividas kräver 20 timmar i manuella överenskommelser per månad för att fungera i ert datalandskap, medan STV kräver 8 timmar, syns det direkt i både kostnad och riskprofil. Skriv också ner vad som krävs för att eliminera skulden, så att ni inte normaliserar nödlösningar.
Sedan, granska identitet och behörighet. Single sign on, rollmodeller och spårbarhet påverkar allt från onboardingtid till revisionsarbete. I ett teambytet jag ledde stod valet och vägde tills vi såg att ena produkten gjorde rollhantering på gruppnivå i katalogtjänsten, medan den andra krävde dubbelkonfiguration. Skillnaden var 8 minuter per användare, vilket blev milt sagt kännbart i en miljö med många rörliga konsulter.
Slutligen, driftbarhet. Kan ni själva övervaka flöden, loggar och köer, eller är ni beroende av leverantörens svartlåda. Efter 90 dagar bör ni ha haft minst ett tillfälle att felsöka något verkligt. Mät tiden från larm till åtgärd, inte bara om det löstes.
Människor före funktioner
Ett vanligt misstag är att låta funktionstabellen vinna över arbetsvardagen. Om du inte lägger tid på att se hur arbetet faktiskt förändras, kan en funktion som sparar tre klick i ett flöde samtidigt lägga på en ny mental modell som kostar mer än den smakar. Det syns inte i release-notes, men syns i två typer av data: mikrotider och avbrott.
Mikrotider handlar om tiden det tar att utföra ett enskilt steg. Mät 30 slumpmässiga exekveringar och ta medianen. Avbrott handlar om hur ofta användaren måste byta kontext, fråga en kollega, eller vänta på ett yttre system. Två extra avbrott per ärende kan på papper bara vara fyra minuter, men i praktiken drar det fokuset ur arbetsflödet och förlänger totalcykeln betydligt mer.
När jag följde ett införande av ett workflow i en kundtjänst såg siffrorna bra ut i loggarna, men en enkel skärminspelning visade att agenterna växlade flik sju gånger för att komma åt ett fält. På 90 dagar hann de STV vs Mividas pros and cons vänja sig, men det var en vanans förbättring snarare än en faktisk produktivitet. Vi valde att väga det mot en snabb konfiguration i den andra lösningen, och det förändrade slutpoängen.
Två kontrasterande scenarier som ofta uppstår
I ett scenario vinner den lösning som är stark i konfiguration och mallar, där teamen snabbt kan få en fungerande standard. Det passar organisationer som vill få ut något bra nog, och finjustera senare. Efter 90 dagar syns det som hög adoption tidigt, få fel i standardflöden, och måttlig teknisk skuld. Ofta tenderar Mividas eller STV att placera sig här beroende på hur mycket färdiga paket de erbjuder i er nisch. Om ni hör till de som skriver Mivida i intern dokumentation, kan det ibland spegla att produkten upplevs personlig eller lättare att forma snabbt, men det är en anekdot, inte en sanning.
I det andra scenariot vinner den lösning som är stark i integrationer och långsiktig driftbarhet. Här blir de första veckorna tyngre, men efter månad två öppnas allt fler flöden. Efter 90 dagar syns det som fler automatiska överlämningar mellan system, lägre supporttryck, och en jämnare kostnadsprofil. Det här passar organisationer som lever på hög transaktionsvolym och där små fel får stora följder.
Poängen är inte att en av Mividas vs STV alltid är den ena eller den andra. Poängen är att du vill känna igen vilket scenario du står i, och värdera därefter.
Vecka för vecka utan att bygga en byråkrati
De mest effektiva 90-dagarsuppläggen jag sett har en rytm som både är tydlig och lätt. Vecka 1 sätter du upp mätpunkter, etablerar testdata och ringar in två riktiga användningsfall som ska köras live. Vecka 2 till 3 låter du en liten grupp köra skarpt i kontrollerad miljö, samtidigt som du dokumenterar mikrotider och avbrott. Vid vecka 4 tar du första delmätningen och städar bort uppenbara hinder. Vecka 5 till 8 skalar du till full pilotgrupp, förenklar integrationerna som gav mest skuld, och standardiserar utbildningen. Vecka 9 till 10 tittar du på ekonomisk takt, supportärenden och fel per 100 transaktioner. Vecka 12 sammanställer du, gör en jämförbar P&L-mini, och beslutar om justeringar eller skala upp.
Det låter mycket, men kräver i praktiken tre korta styrmöten, två längre arbetsdagar tidigt, och någon timme per vecka för uppföljning. Viktigast är att hålla jämförelsen ärlig mellan alternativen. Om Mividas får en vecka extra för konfiguration, ge samma till STV.
Beslutssignaler som ofta avgör STV vs Mividas
När datan väl ligger på bordet vill styrelsen ha en tydlig lutning. Följande signaler brukar väga tungt när du ställer STV mot Mividas, utan att säga att den ena alltid slår den andra.
- Först till första värde: lösningen som producerat verklig output för riktiga ärenden tidigare än vecka 3 har ett försprång som sällan hämtas in senare. Färre manuella mellanled: om ett alternativ kräver mindre integrationsskuld och färre manuella kontroller per ärende, ökar dess långsiktiga hävstång. Stabil adoption över 60 procent i vecka 8: när en lösning når det taket i pilotgruppen, pekar det på att beteendeförändringen faktiskt satt sig. Supportärenden som planar ut: den produkt där ärendekurvan går ner mot vecka 10 tenderar att bli billigare i drift, även om startkostnaden var högre. Transparent drift och mätbarhet: möjlighet att själva övervaka, larma och felsöka väger mer än en enskild extra funktion på pappret.
Det här är inte en poängmatris, men fem lampor som tänds eller inte. Två eller fler tända för en kandidat efter 90 dagar är ofta beslutsunderlag nog.
Vanliga fallgropar som snedvrider 90-dagarsbilden
En jämförelse blir snabbt skev om pilotgruppen inte speglar verkligheten. Om enbart superanvändare testar Mividas och en blandad grupp kör STV, kommer Mividas framstå som enklare än det är. Se till att piloterna matchar den förväntade mixen av erfarenhet och roller. På samma sätt, låt inte leverantörens konsulter bära upp vardagen för länge. Räkna bara det som värde om det är hållbart med er egen bemanning.
En annan fälla är att räta ut alla hinder genom att minska ambitionsnivån. Det kan behövas initialt, men dokumentera alltid vad ni förenklar. När ni senare skalar upp kan det ni skurit bort återkomma med full kraft. Resonera ärligt om vad som är essentiellt för din miljö. Jag var med i en jämförelse där båda lösningarna såg likvärdiga ut tills vi la tillbaka en säkerhetskontroll som krävde att roller arvdes från HR-systemet. Det dubblade konfigurationstiden i ena produkten, men var obetydligt i den andra. Bilden förändrades över en helg.
Överoptimism i kostnadsestimat är också vedertaget. Var tydlig med intern tid, inte bara fakturor. En tumregel som sällan slår fel är att 1 intern timme för varje 1 000 kronor i externa konsultkostnader dyker upp under de första 90 dagarna, särskilt i organisationer med tung förändringsledning. Testa den mot era siffror och justera.
Hur du kommunicerar resultatet utan att skapa läger
Debatter som Mividas vs STV blir lätt identitetspolitiska inom företaget. Team som investerat prestige i ett spår kan låsa sig. Motmedlet är att kommunicera i tre lager. Först en kort summering för ledning med de fem indikatorerna och P&L-mini, inga tekniska detaljer. Sedan en teknisk bilaga som redogör för integrationer, skuld och driftbarhet. Slutligen en användarrapport med mikrotider, avbrott och citat. När alla tre lager säger samma sak är beslutet okontroversiellt. När de säger olika, synliggör det kompromisserna.
Transparens här räddar ofta relationen med den leverantör som inte väljs. Om STV föll på att rollen måste dubbleras i två kataloger, säg det. Om Mividas föll på att adoptionen stannade vid 40 procent trots flera utbildningsinsatser, säg det. Leverantörer som får tydlig feedback blir ofta bättre, och du vill kunna återkomma om behoven ändras.
När 90 dagar inte räcker
Vissa domäner kräver längre tid för att uppvisa full effekt. Komplexa regulatoriska flöden, säsongsvariationer eller mycket långa affärscykler kan dölja värdet. Försök då att skapa artificiella men realistiska testfall, eller mäta ledande indikatorer. Exempel på ledande indikator är hur snabbt nya integrationer kan läggas till efter den första, eller hur lång tid det tar att släppa en ändring i en regelmotor från idé till produktion. Om Mividas släpper igenom en ny affärsregel på två dagar medan STV kräver en vecka, är det signal nog även om intäkten inte slagit igenom.
Det händer att båda alternativen faller på 90 dagar. Då är det inte ett nederlag, utan en viktig lärdom. Ofta har ni upptäckt att organisationens förutsättningar inte matchar någon av produkterna: för lite tid av nyckelpersoner, för otydlig process, eller för splittrad data. Då är det klokare att pausa, adressera grunderna, och komma tillbaka med en ny jämförelse när spelplanen är riggad.
Ett sista praktiskt grepp: jämställd exponering
Ska jämförelsen vara rättvis måste båda alternativen få likvärdig exponering mot verkligheten. Kör lika många timmar utbildning, lika många användare i piloten, och lika många integrationspunkter av samma typ. Om STV fick koppla upp sig mot ERP och CRM, men Mividas bara mot CRM, blir datan skev. Dokumentera även vilka genvägar som användes. Jag ber alltid teamen lista topp tre nödlösningar som införts under piloten och uppskatta tiden för att ta bort dem. Den listan säger ibland mer om framtida totalkostnad än någon offert.
När du summerar 90 dagar ska du kunna formulera ditt beslut i en enda tydlig mening, och ha tre datapunkter som stödjer den. Exempelvis: vi väljer Mividas för att den gav första värde på dag 11, uppnådde 64 procent veckovisa aktiva i vecka 8, och kräver 12 färre manuella timmar per månad i integrationer än STV. Eller: vi väljer STV för att den halverade fel per 100 transaktioner, gav en stabil supportkurva redan vecka 6, och möjliggör egen driftövervakning som minskar risk.
Det är lätt att göra jämförelser röriga. Det svåra och viktiga är att göra dem rättvisa. Efter 90 dagar behöver du inte veta allt, men du kan veta tillräckligt. Om du mäter där värdet uppstår, om du jämför lika med lika, och om du vågar skriva ner hypoteser och pröva dem, då spelar det mindre roll om det heter STV vs Mividas eller Mividas vs STV i kalenderinbjudan. Då har du ett beslutsunderlag som håller för både vardag och revision, och en väg vidare som faktiskt går att gå.