Hvordan implementere ny programvare i bedriften din i 2026

Å implementere ny programvare i bedriften din er ikke primært en programvareoppgave. Det er en endring i driftsmodellen.

Kjøpet er den enkle delen. De vanskelige delene er å bestemme hvilken prosess som må endres, rydde opp i dataene programvaren vil basere seg på, koble til systemene den må kommunisere med, trene personene som skal bruke den, og sørge for at utrullingen forbedrer virksomheten i stedet for å legge til enda en innlogging ingen stoler på.

Nåværende søkeatferd viser praktisk hensikt. Folk leter ikke etter abstrakt digitaliseringsspråk. De vil ha en plan for programvareimplementering, en sjekkliste for utrulling, eksempler på hvordan man migrerer data, måter å trene ansatte på og en måte å unngå forstyrrelser. Kildene peker i samme retning. Microsoft-materiale vektlegger planlegging og organisatorisk beredskap. NIST-veiledning gjør sikkerhet og styring til en del av driftsmodellen. Atlassian og Asana ramme programvareutrulling som endringsledelse. HubSpot, Brevo, Shopify og Zapier viser hvordan moderne verktøy er avhengige av integrasjoner, automatiseringsutløsere og tilkoblede arbeidsflyter.

Denne guiden gjør den forskningen om til en praktisk implementeringsplan.

Kortversjonen

For å implementere ny programvare i bedriften din:

1. Definer forretningsmålet før du ser på funksjoner.
2. Kartlegg den nåværende arbeidsflyten programvaren vil endre.
3. Tildel én utrullingsansvarlig med beslutningsmyndighet.
4. Bygg et kravkort for brukere, data, integrasjoner, sikkerhet, støtte og kostnad.
5. Velg utrullingsmodell: pilot, trinnvis utrulling, parallellkjøring eller direktelansering.
6. Forbered datamigrering, tilgangsroller og integrasjoner før opplæring starter.
7. Pilottesting med ekte brukere og ekte forretningsposter.
8. Fiks prosess-, data-, tillatelse- og rapporteringsproblemer før full lansering.
9. Tren hver rolle på de oppgavene de faktisk utfører.
10. Lanser med støttedekning, adopsjonsmetrikker og en stabiliseringsplan for 30 til 90 dager.

Ikke implementer programvare ved å sende en bedriftsomfattende kunngjøring og håpe at folk tar den i bruk. Implementering lykkes når arbeidsflyten er klarere etter lansering enn den var før lansering.

Start med forretningsmålet

Ny programvare bør knyttes til et målbart forretningsmål.

Svake mål høres slik ut:

Svakt mål	Hvorfor det feiler
”Vi trenger et bedre CRM”	Ingen vet hvilket CRM-problem som betyr mest
”Vi bør automatisere markedsføring”	Automatiseringsomfanget kan vokse uten en forretningseier
”Teamet trenger prosjektledelsesprogramvare”	Adopsjon vil mislykkes hvis arbeidsflyten fortsatt er uklar
”Det nåværende verktøyet er gammelt”	Alder alene definerer ikke implementeringsmålet

Bedre mål høres slik ut:

Bedre mål	Suksessmåling
Reduser uoppfylgte salgsfølgeopp	Færre forsinkede oppgaver og raskere ledrespons
Forbedre gjenoppretting av forlatte handlekurver	Høyere gjenopprettede inntekter og færre manuelle eksporter
Sentraliser kundedata	Færre duplikate kontakter og renere segmentering
Øk hastigheten på støttetriage	Raskere første respons og færre feilrute-billetter
Reduser regnearkrapportering	Færre manuelle timer og mer pålitelige dashbord

Før du vurderer verktøy, skriv én setning:

Vi implementerer denne programvaren slik at [team] kan [forretningsmål] innen [dato], målt med [metrikk].

Eksempler:

Programvaretype	Implementeringsmål
CRM	Salg kan se alle leads, eiere, livssyklusstadier og neste handling i ett system
Markedsføringsautomatisering	Livssykluskampanjer utløses fra nøyaktige kunde- og ordredata
Kundestøtte	Billetter rutes etter kundestatus, problemtype og hast
E-handelsautomatisering	Ordre-, lager- og lojalitetshendelser utløser oppfølgingsarbeidsflyter
Prosjektledelse	Tverrfunksjonelt arbeid har tydelige eiere, status og frister
Analyse	Ledelsen kan stole på ett sett med operasjonelle metrikker

Hvis du ikke kan si hva målet er, stopp implementeringen. Du er ikke klar til å velge programvare ennå.

Kartlegg den nåværende arbeidsflyten

Programvareimplementering mislykkes når team hopper over kartet over nåværende tilstand.

Du trenger å vite hvordan arbeidet skjer i dag før du kan forbedre det. Et arbeidsflytskart trenger ikke å være komplekst, men det bør være spesifikt nok til å avdekke eiere, systemer, overføringer, datagap og manuelt arbeid.

Bruk denne malen:

Felt	Hva som skal dokumenteres
Arbeidsflyttnavn	Prosessen programvaren vil endre
Utløser	Hva starter arbeidsflyten
Inndata	Poster, meldinger, filer, hendelser eller kundehandlinger som brukes
Nåværende systemer	Verktøy og regneark som er involvert i dag
Eier	Team eller person som er ansvarlig for resultatet
Overføringer	Der arbeid flyttes mellom personer eller systemer
Beslutninger	Regler eller skjønnsavgjørelser i prosessen
Unntak	Manglende data, duplikatposter, godkjenninger, eskaleringer
Utdata	Oppgave, melding, rapport, ordre, segment, billett eller statusendring
Smertepunkt	Hva som er tregt, upålitelig, dyrt eller risikabelt
Suksessmåling	Hvordan forbedring vil måles

Eksempel:

Felt	Eksempel
Arbeidsflyttnavn	Ny Shopify-kunde legges inn i velkomstsekvens
Utløser	Første ordre er betalt
Inndata	Kundeprofil, produkt, samtykke, ordreverdi, lojalitetsstatus
Nåværende systemer	Shopify, Brevo, regnearkeksporter
Eier	Livssyklusmarkedsføring
Overføringer	E-handel til markedsføring til støtte
Beslutninger	Hvilket segment, hvilken e-postsekvens, om SMS er tillatt
Unntak	Manglende samtykke, duplikat e-post, refundert ordre
Utdata	Kunden lagt til i riktig velkomstflyt
Smertepunkt	Forsinkelser og duplikatprofiler forårsaker feil meldinger
Suksessmåling	Raskere innmelding og høyere gjenkjøpsrate

Dette er der Tajo ofte passer inn. Hvis implementeringen berører kunde-, ordre-, produkt-, lojalitets-, samtykke-, segment- eller kampanjedata, kan utdatert synkronisering ødelegge utrullingen selv om programvaren i seg selv er god. Å fikse dataflyten er en del av implementeringen, ikke et separat oppryddingsprosjekt.

Velg riktig utrullingsansvarlig

Alle programvareimplementeringer trenger én ansvarlig eier.

Den eieren trenger ikke å gjøre alle oppgavene, men de må kunne ta beslutninger, koordinere interessenter, fjerne hindringer og bestemme når utrullingen er klar.

For en liten bedrift kan eieren være grunnleggeren, driftsleder, markedsføringsleder eller salgssjef. For et større team kan det være en prosjektleder, RevOps-leder, IT-eier, e-handelsdriftsleder eller systemadministrator.

Eieren bør kontrollere denne implementeringsregistreringen:

Område	Eierens beslutning
Omfang	Hva er inkludert i denne utrullingen og hva er utsatt
Tidslinje	Pilotdato, lanseringsdato og stabiliseringsvindu
Brukere	Hvem blir med i piloten og hvem lanseres senere
Data	Hvilke poster migreres og hvilke arkiveres
Integrasjoner	Hvilke systemer må kobles til før lansering
Tilgang	Roller, tillatelser, administratorbrukere og godkjenningsflyter
Opplæring	Hvem trenger opplæring og hvordan opplæring leveres
Støtte	Hvor brukere rapporterer problemer etter lansering
Metrikker	Hvilke adopsjon- og forretningsresultater spores

Ikke del endelig myndighet mellom en komité. Komiteer kan rådgi, teste og godkjenne, men én person må eie implementeringskvaliteten.

Bygg et kravkort

Funksjonslister blir rotete. Et kravkort holder utvalget knyttet til arbeidsflyten.

Separer krav i må-ha, bør-ha og hyggelig-å-ha. Deretter scorer du hver leverandør eller verktøy mot arbeidsflyten du kartla.

Kravområde	Spørsmål å stille
Arbeidsflyttilpasning	Kan verktøyet støtte den eksakte prosessen vi trenger?
Brukeropplevelse	Kan teamet fullføre hyppige oppgaver uten midlertidige løsninger?
Datamodell	Støtter det postene, feltene og relasjonene vi trenger?
Integrasjoner	Kobles det til Shopify, Brevo, CRM, støtte, analyse eller interne verktøy?
Automatisering	Kan utløsere, betingelser og handlinger matche virkelige forretningsregler?
Migrering	Kan vi importere historiske poster rent?
Rapportering	Kan vi måle implementeringsmålet?
Sikkerhet	Kan vi konfigurere roller, tillatelser, revisjonslogger og tilgangskontroller?
Støtte	Er det innføring, dokumentasjon eller migreringshjelp?
Kostnad	Fungerer prissettingen fortsatt etter at brukere, kontakter, hendelser, plasser eller bruk vokser?

Bruk en enkel poengmodell:

Poeng	Betydning
0	Støtter ikke kravet
1	Støtter det bare med tung midlertidig løsning
2	Støtter det med konfigurasjon
3	Støtter det godt og matcher arbeidsflyten

Den beste programvaren er ikke den med den lengste funksjonslisten. Det er den som kan støtte målarbeidsflyten din med minst operasjonell friksjon.

Bestem utrullingsmodellen

Det er fire vanlige måter å rulle ut ny programvare på.

Utrullingsmodell	Best for	Avveining
Pilot	Nye arbeidsflyter, usikker adopsjon eller risikabel migrering	Saktere start, men tryggere læring
Trinnvis utrulling	Flere team, steder, merker eller avdelinger	Krever nøye sekvensering
Parallellkjøring	Systemer med finansiell, kunde- eller operasjonell risiko	Mer arbeid midlertidig, men tryggere overgang
Direktelansering	Enkle verktøy med lav datarisiko	Rask, men mindre rom til å oppdage problemer

De fleste forretningsprogramvarer bør ikke lanseres til alle på dag én. En pilot gir deg virkelig tilbakemelding fra virkelig arbeid mens konsekvensene fortsatt er små.

Bruk direktelansering bare når:

Signal for direktelansering	Hvorfor det betyr noe
Datamigrering er liten	Færre poster kan feile
Arbeidsflyten er enkel	Opplærings- og støttebelastningen er lav
Brukere er få	Problemer kan håndteres raskt
Det eksisterende systemet er ikke kritisk	Midlertidige feil er tolerble
Tilbakeføring er enkel	Du kan gå tilbake til den gamle prosessen ved behov

Bruk pilot, trinnvis utrulling eller parallellkjøring når programvaren påvirker inntekter, kundekommunikasjon, ordreoperasjoner, tillatelser, analyse, overholdelse eller kjernearbeidsflyter.

Planlegg datamigrering før konfigurasjon

Datamigrering er der mange programvareprosjekter blir dyre.

Før du importerer noe, svar på disse spørsmålene:

Migreringsspørsmål	Hvorfor det betyr noe
Hvilke poster må flyttes?	Unngå import av utdatert eller irrelevant historikk
Hvilke felt er påkrevd?	Forhindre ødelagte poster etter lansering
Hvilke felt er valgfrie?	Reduser migreringskompleksitet
Hvilke poster er duplikater?	Unngå å forurense det nye systemet
Hvilket system er kilden til sannhet?	Stopp motstridende oppdateringer
Hvilke poster trenger samtykke- eller personverngjennomgang?	Unngå overholdelsesfeil
Hvilke historiske poster må forbli søkbare?	Bevar forretningskontekst
Hvilke felt er kartlagt annerledes i det nye verktøyet?	Forhindre rapporteringsfeil

For kunde- og e-handelssystemer er kilden-til-sannhet-beslutningen kritisk.

Eksempel:

Datatype	Mulig kilde til sannhet
Kundeidentitet	CRM eller e-handelsplattform
E-postsamtykke	Markedsføringsplattform eller samtykkeplattform
Ordrehistorikk	E-handelsplattform
Lojalitetspoeng	Lojalitetsplattform
Kampanjemedlemskap	Markedsføringsplattform
Støttestatus	Helpdesk
Produktkatalog	E-handelsplattform eller PIM

Hvis to systemer kan oppdatere det samme feltet, definer konfliktregler før lansering. Ellers vil brukere slutte å stole på den nye programvaren fordi poster ser ut til å endre seg uten forklaring.

Design integrasjoner som en del av implementeringen

Moderne programvare fungerer sjelden alene.

Implementeringsintensjon overlapper ofte med integrering og automatisering. Det matcher virkelige forretningsutrullinger. Et CRM trenger skjemaer, e-post, kalender, støtte, analyse og faktureringskontekst. En markedsføringsautomatiseringsplattform trenger e-handel, samtykke, produkt-, segment- og kampanjedata. Et prosjektledelsesverktøy kan trenge Slack, e-post, fillagring, skjemaer og rapportering.

Opprett et integrasjonskart:

Integrasjonsfelt	Eksempel
Kildesystem	Shopify
Destinasjonssystem	Brevo
Utløser	Ordre betalt
Data sendt	Kunde, produkt, ordreverdi, samtykke, rabattkode
Frekvens	Sanntid eller planlagt
Eier	E-handelsdrift
Feilhåndtering	Forsøk på nytt, varsling, kø eller manuell gjennomgang
Revisjonsmetode	Logg, dashbord eller stikkprøvekontroll

For hver integrasjon, definer:

1. Hva starter synkroniseringen.
2. Hvilke felt som flyttes.
3. Hvilke felt som aldri flyttes.
4. Hvilket system kan overskrive det andre.
5. Hvordan duplikater matches.
6. Hva som skjer når et API-kall feiler.
7. Hvem mottar feilvarslinger.
8. Hvordan teamet verifiserer at synkroniseringen fungerer.

Automatiseringsverktøy som Brevo Automations og Shopify Flow er avhengige av utløsere, betingelser og handlinger. Den modellen er nyttig for planlegging selv om du ikke bruker disse eksakte verktøyene. Alle implementeringer bør definere hvilken hendelse som starter en arbeidsflyt, hvilke betingelser som kontrollerer den og hvilken handling som skjer neste.

Gjennomfør sikkerhets- og tilgangsgjennomgang

Sikkerhet kan ikke vente til etter lansering.

NIST-stilig sikkerhetstenkning hører hjemme i implementeringsplanen fordi ny programvare endrer tilgang, dataflyter, leverandører, tillatelser og operasjonell risiko.

Gjennomgå disse punktene før piloten:

Sikkerhetsområde	Implementeringssjekk
Brukerroller	Brukere får minst tilgang som er nødvendig for arbeidet deres
Administratortilgang	Administratorroller er begrenset og gjennomgått
Autentisering	SSO, MFA, passordpolicy eller støtte for identitetsleverandør er tydelig
Dataklassifisering	Sensitive felt identifiseres før migrering
Revisjonslogger	Viktige endringer kan spores
Leverandørgjennomgang	Sikkerhet, personvern, databehandling og tilgjengelighetsdata gjennomgås
Tillatelser	Brukere kan ikke eksportere, slette eller endre poster utover sin rolle
Avslutning av arbeidsforhold	Tilgang kan fjernes raskt når noen slutter
Sikkerhetskopier	Kritiske data har en gjenopprettingsvei
Hendelsesprosess	Teamet vet hvem som håndterer sikkerhets- eller dataproblemer

Småbedrifter kan holde dette enkelt, men bør ikke hoppe over det. En enkel rollematrise er bedre enn å gi alle administratortilgang fordi lanseringen er hastet.

Pilottesting med ekte brukere

En pilot bør teste hele arbeidsflyten, ikke bare om folk kan logge inn.

Velg en pilotgruppe som representerer faktisk bruk:

Pilotrolle	Hvorfor inkludere dem
Avansert bruker	Finner grensetilfeller og arbeidsflytgap
Vanlig bruker	Viser om hverdagsoppgaver er tydelige
Skeptisk bruker	Avslører adopsjonshindringer tidlig
Leder	Sjekker rapportering og synlighet
Administrator eller driftseier	Tester konfigurasjon og støtteprosess

Gi piloten et tydelig omfang:

Pilotelementet	Eksempel
Varighet	To uker
Brukere	Fem salgsrepresentanter og én salgssjef
Arbeidsflyt	Ny innkommende ledruting og oppfølging
Data	Siste 90 dagers leads og live skjemainnsendinger
Suksessmåling	Raskere første respons og færre utildelte leads
Avslutningskriterier	Ingen kritiske dataproblemer, brukere fullfører oppgaver, rapportering er betrodd

Under piloten, spor:

1. Oppgaver fullført vellykket.
2. Oppgaver fullført med midlertidig løsning.
3. Oppgaver brukere ikke kunne fullføre.
4. Duplikate eller manglende poster.
5. Integrasjonsfeil.
6. Tillatelse problemer.
7. Opplæringsgap.
8. Støttespørsmål.
9. Rapporter som ikke stemmer med forventningene.
10. Bevegelse av forretningsmålinger.

Ikke avvis pilottilbakemeldinger som motstand. Noe motstand er dårlig vane, men noe av det er nyttig bevis på at arbeidsflyten, datamodellen eller opplæringsplanen ikke er klar.

Tren etter rolle, ikke etter funksjon

De fleste programvareopplæringer mislykkes fordi de går gjennom funksjoner i stedet for jobber.

Tren brukere på arbeidet de må utføre:

Rolle	Opplæringen bør dekke
Salgsrepresentant	Finn leads, oppdater stadium, logg aktivitet, opprett neste oppgave
Markedsføringsleder	Bygg segment, sjekk samtykke, start kampanje, les resultater
Støtteagent	Vis kundekontekst, oppdater billett, eskaler, lukk løkken
E-handeloperatør	Sjekk ordrehendelser, gjennomgå automatisering, fiks mislykket synkronisering
Leder	Les dashbord, sjekk adopsjon, coach teamet
Administrator	Administrer felt, roller, integrasjoner og støttekø

En praktisk opplæringsplan inkluderer:

1. Kort live gjennomgang for målarbeidsflyten.
2. Skriftlig sjekkliste for vanlige oppgaver.
3. Innspilt demo for folk som mister opplæring.
4. Kontortid i den første lanserings-uka.
5. En støttekanal for spørsmål og feil.
6. Rollespesifikke hurtigreferansedokumenter.
7. En prosess for å be om konfigurasjonsendringer.

Opplæring bør skje etter at piloten har fikset de store problemene. Opplæring for tidlig lærer folk en arbeidsflyt som kan endre seg. Opplæring for sent skaper en støttetopp i lanseringsuka.

Lanser med en stabiliseringsplan

Lanseringsdagen er ikke slutten på implementeringen. Det er starten på stabilisering.

Opprett en sjekkliste for lansering:

Lanseringspunkt	Klar?
Forretningseier godkjenner omfang	Ja eller nei
Pilotavslutningskriterier oppfylt	Ja eller nei
Datamigrering testet	Ja eller nei
Integrasjoner testet	Ja eller nei
Roller og tillatelser gjennomgått	Ja eller nei
Opplæring levert	Ja eller nei
Støttekanal åpen	Ja eller nei
Rapporteringsdashbord klart	Ja eller nei
Tilbakeføring eller manuell reserveplan dokumentert	Ja eller nei
Første 30 dager med metrikker definert	Ja eller nei

I de første to ukene, gjennomgå problemer daglig. I de neste 30 til 90 dagene, gjennomgå adopsjon og forretningsresultater ukentlig.

Spor implementeringshelse:

Metrikk	Hva det forteller deg
Aktive brukere	Om folk faktisk bruker verktøyet
Fullføring av nøkkeloppgaver	Om arbeidsflyten fungerer
Støttebilletter	Hvor brukere er blokkert
Datafeilfrekens	Om migrering og synkronisering er pålitelig
Integrasjonsfeil	Om tilkoblede systemer er stabile
Manuelle midlertidige løsninger	Hvor konfigurasjon er ufullstendig
Tid spart	Om utrullingen forbedrer driften
Inntekts- eller konverteringseffekt	Om forretningsmål har beveget seg
Brukertilfredshet	Om adopsjon sannsynligvis vil vedvare

Hvis adopsjon er lav, ikke anta umiddelbart at brukerne er skyld. Sjekk om verktøyet passer arbeidsflyten, om data er pålitelig, om ledere bruker rapportene og om brukere vet hvilken gammel prosess som er avviklet.

En 30-60-90 dagers plan for programvareimplementering

Bruk denne tidslinjen for moderate forretningsprogramvareutrullinger som CRM, markedsføringsautomatisering, kundestøtte, e-handelsautomatisering, prosjektledelse eller analyse.

Fase	Tidspunkt	Fokus	Resultat
Oppdagelse	Dag 1 til 10	Mål, arbeidsflyt, interessenter, data, risiko	Implementeringsnotat
Valg	Dag 11 til 25	Krav, demoer, poenggiving, budsjett	Verktøysbeslutning
Konfigurasjon	Dag 26 til 45	Felt, roller, arbeidsflyter, integrasjoner	Pilotklart system
Migreringtest	Dag 36 til 50	Prøveimport, duplikatgjennomgang, feltkartlegging	Migrasjonsplan
Pilot	Dag 46 til 65	Ekte brukere, ekte arbeid, støttetilbakemelding	Lanseringsbeslutning
Opplæring	Dag 60 til 75	Rollebaserte oppgaver og støtteprosess	Trent lanseringsgruppe
Lansering	Dag 76 til 90	Full utrulling, problemrespons, metrikksporing	Stabilisert prosess

Enkle verktøy kan gå raskere. Kjerneforretningssystemer kan trenge mer tid. Det viktige poenget er sekvensering: ikke tren brukere før arbeidsflyten er konfigurert, ikke lanser før data er testet, og ikke vurder ROI før adopsjon er stabilisert.

Vanlige feil ved programvareimplementering

Unngå disse problemene:

Feil	Bedre tilnærming
Kjøpe før kartlegging av arbeidsflyten	Dokumenter prosessen og målet først
La hvert team legge til krav	Skill ut må-ha fra hyggelig-å-ha
Importere urene data	Rens, dedupliser og kartlegg felt før migrering
Hoppe over integrasjoner	Behandle dataflyt som en del av lanseringsomfanget
Gi alle administratortilgang	Opprett roller før piloten
Trene etter funksjon	Tren etter jobb-som-skal-gjøres
Lansere til alle på en gang	Pilottesting først med mindre arbeidsflyten er lavrisiko
Holde den gamle prosessen i live for alltid	Sett en pensjonsdato for erstattede arbeidsflyter
Måle bare innlogginger	Spor oppgavegjennomføring og forretningsresultater
Behandle lansering som fullføring	Stabiliser i 30 til 90 dager

Den dyreste feilen er å late som om implementeringen er ferdig når verktøyet er konfigurert. Implementeringen er ferdig når forretningsprosessen fungerer, brukere adopterer den og den opprinnelige metrikken forbedres.

Hvor Tajo passer inn

Tajo er relevant når ny programvare avhenger av tilkoblede kunde- og handelsdata.

Vanlige eksempler:

Implementering	Tajos rolle
Brevo markedsføringsautomatisering	Hold kunde-, samtykke-, segment- og ordredata oppdatert
Shopify livssyklusarbeidsflyter	Synkroniser kunde- og ordrekontekst til meldinger og CRM-flyter
CRM-utrulling	Reduser duplikate kontakter og utdaterte livssyklusfelt
Lojalitets- eller retensjonsprogram	Hold kjøp, poeng og kundestatus alignert
Kampanjerapportering	Sørg for at segmenter og hendelser gjenspeiler nåværende e-handelsatferd
AI- eller automatiseringsarbeidsflyter	Gi automatiseringer pålitelig kontekst før de handler

Dette betyr noe fordi mange programvareutrullinger mislykkes av grunner som ser ut som adopsjonsproblemer, men som faktisk er dataproblemer. Hvis brukere ser utdaterte kunder, manglende ordre, duplikate kontakter, feil samtykke eller ødelagte segmenter, slutter de å stole på systemet.

Den beste implementeringsplanen behandler datasynkronisering, feltkartlegging, samtykke og arbeidsflytutløsere som kjernelanseringskrav.

Endelig sjekkliste

Før du markerer implementeringen som fullført, bekreft:

1. Programvaren er knyttet til et målbart forretningsmål.
2. Den nåværende arbeidsflyten er dokumentert.
3. Én utrullingsansvarlig er ansvarlig.
4. Krav er scoret mot arbeidsflyten.
5. Datamigrering er testet med prøveposter.
6. Integrasjoner har eiere, logger og feilhåndtering.
7. Roller og tillatelser er gjennomgått.
8. Pilotbrukere fullførte ekte arbeid vellykket.
9. Opplæring er rollespesifik.
10. Den gamle prosessen har en pensjoneringsplan.
11. Støttedekning eksisterer for lanseringsuken.
12. Adopsjon og forretningsmålinger spores i 30 til 90 dager.

Ny programvare forbedrer en bedrift bare når den endrer hvordan arbeid utføres. Start med arbeidsflyten, beskytt dataene, rull ut i kontrollerte faser og mål adopsjon etter lansering. Det er slik programvare blir et operativt fortrinn i stedet for et annet ubrukt verktøy.