Spørsmålet kommer nesten alltid i samme form: hva koster det å bytte medlemssystem? Og svaret som forventes, er ett tall. Vanskeligheten er at tallet som betyr mest for beslutningen, ikke er prisen på det nye systemet. Det er summen av arbeidet rundt det, fordelt over fem år.
For en norsk medlemsorganisasjon i mellomsjiktet, la oss si 5 000 til 50 000 medlemmer og 10 til 40 interne brukere, bør et systembytte som planleggingsantakelse settes av seks til tolv måneder fra beslutning til produksjonssetting. Basert på prosjekter vi har deltatt i innenfor det norske medlems- og organisasjonssegmentet ligger tjenestekostnaden i første år typisk på to til fire ganger årlig lisenskostnad, og fire poster driver den: datamigrering og datakvalitet, integrasjoner mot økonomi, betaling og nettsider, gjenoppbygging av rapporter, og opplæring. Over fem år er abonnementet normalt den minste posten, mens forvaltning og egne timer er de to som oftest mangler i regnestykket. To ting er verdt å si med én gang. Den største enkeltbesparelsen ligger sjelden i å forhandle prisen ned, men i å flytte i etapper i stedet for alt på én gang. Og å bli værende på systemet dere har er et fullt legitimt svar, som fortjener sitt eget regnestykke.
Hva består kostnaden ved å bytte medlemssystem av?
Seks poster utgjør nesten ethvert bytte av medlemssystem. Bare én av dem har en offentlig prisliste, og det er derfor den dominerer samtalen. De fire i midten er de som avgjør om to organisasjoner av samme størrelse ender med svært ulike prosjekter.
| Kostnadspost | Hva den dekker | Hva som flytter tallet |
|---|---|---|
| Abonnement eller lisens | Per bruker eller per medlem, avhengig av modell | Antall brukere, modulvalg, avtalelengde |
| Konfigurasjon og bygging | Prosesser, skjermbilder, roller, kontingentlogikk | Hvor langt dere avviker fra standarden |
| Datamigrering | Medlemmer, historikk, betalinger, dokumenter | Datakvalitet og hvor mange år dere tar med |
| Integrasjoner | Økonomi, betaling, nettsider, e-post, innlogging | Antall tilkoblede systemer, og hvor gamle de er |
| Rapporter og analyser | Styrerapportering, kontingent, medlemsutvikling | Hvor mange rapporter som faktisk har en eier |
| Opplæring og innføring | Administrasjon, økonomi, medlemsservice, tillitsvalgte | Antall roller, og om frivillige er brukere |
To organisasjoner med identisk brukertall kan ende med svært ulike prosjekter, og forskjellen sitter nesten utelukkende i data og integrasjoner. Det er den samme kostnadslogikken som vi går gjennom i artikkelen om hva en Dynamics 365-implementering faktisk koster, anvendt på et smalere prosjekt.
Kontingenten er posten som overrasker flest. Medlemskontingent er ikke én prosess, men flere: beregningsregler, kategorier og fritak, fakturering, lønnstrekk, purring, avstemming mot reskontro. Vi har skrevet om arkitekturen bak dette i artikkelen om kontingent og lønnstrekk. I et systembytte er kontingent normalt prosessen som trenger mest testing, fordi det er den der en feil er synlig for alle medlemmer samtidig.
To beslektede artikler står ved siden av denne. Når har medlemsorganisasjonen vokst ut av medlemssystemet? handler om behov, og ferdig medlemsløsning eller egen plattform? handler om arkitektur. Hvordan vi gjennomfører selve byttet, er beskrevet på siden vår om Dynamics 365 for medlemsorganisasjoner.
Vurderer dere å bytte medlemssystem? Vi kartlegger data, integrasjoner og kontingentprosesser og gir dere et konkret kostnadsbilde og en tidslinje for begge alternativene: bytte, eller bli og forbedre.
Hvor lang tid tar det å bytte medlemssystem?
Fasene overlapper i praksis, men rekkefølgen står seg. Varighetene under er planleggingsantakelser fra tilsvarende Dataverse-prosjekter i det norske markedet, ikke en garanti.
| Fase | Typisk varighet | Hva som avgjør |
|---|---|---|
| Kartlegging og beslutningsgrunnlag | 3 til 6 uker | Hvor godt dokumentert dagens prosesser er |
| Design av datamodell og prosess | 4 til 8 uker | Beslutningstakt, og om kontingentreglene er skrevet ned noe sted |
| Konfigurasjon og bygging | 8 til 16 uker | Antall prosesser som flyttes i første etappe |
| Datamigrering med prøvekjøringer | 6 til 12 uker, parallelt | Datakvalitet, og hvor mange års historikk dere beholder |
| Test og opplæring | 4 til 6 uker | Antall roller, og tilgang til egne fagpersoner |
| Produksjonssetting og stabilisering | 4 til 8 uker | Om første kontingentkjøring faller innenfor perioden |
En medlemsorganisasjon har faste vinduer i året der et bytte ikke bør skje. Kontingentkjøringen, årsmøtet, innmeldingssesongen og, for innsamlingsorganisasjoner, giversesongen. I praksis gir det to realistiske produksjonssettingsvinduer i året for de fleste. Å regne baklengs fra de vinduene er ofte det som faktisk avgjør om et prosjekt tar åtte måneder eller tolv.
Femårsbildet: hva totalkostnaden faktisk inneholder
En brukbar modell har to kolonner. Engangskostnader faller i år én. Løpende kostnader faller hvert år, også i år én.
Det er på den løpende siden sammenligningene som regel bryter sammen. Abonnement eller lisens er den synlige delen. Under ligger forvaltning og videreutvikling, lagring og kapasitet, integrasjonsvedlikehold, og opplæring av nye ansatte. Lagring fortjener en egen merknad: på Dataverse er kapasiteten rettighetsbasert på tvers av database-, fil- og logglagring, med mulighet for tilleggskapasitet når dere overskrider den. Tiår med medlemshistorikk og dokumentarkiv har derfor en løpende kostnad, og det er ett praktisk argument for å bestemme tidlig hvor mange år dere faktisk trenger å ta med.
Legg så til prisreguleringsklausulen. Flerårige avtaler har normalt en årlig indeksregulering, og over fem år får den betydning. Be om å se klausulen før dere sammenligner førsteårspriser mellom to leverandører, for en lavere startpris med brattere regulering kan være den dyreste av de to allerede i år fire.
Forvaltningsansvaret er en reell kostnad i begge modeller
En vanlig feil i slike beslutningsgrunnlag er å telle forvaltning som en kostnad i den ene modellen og som gratis i den andre. Den er ingen av delene.
I en ferdig domeneløsning ligger forvaltningen inne i abonnementet. Leverandøren oppgraderer, vedlikeholder og videreutvikler løsningen, og dere følger deres veikart. Det er en reell fordel: dere kjøper forutsigbarhet, og dere trenger ikke holde kompetansen selv. Avveiningen er at veikartet er deres, og at prioriteringer kan endre seg ved eierskifte.
På et fleksibelt fundament er forvaltningen deres, enten internt eller gjennom en partner. Dere setter veikartet, og dere betaler for det. Det er også en reell fordel, og en reell kostnad, og den bærer sin egen avhengighet: til et partnerforhold og til de personene som kjenner oppsettet deres. Vi går gjennom arkitekturforskjellene i sammenligningen av ferdig løsning og egen plattform.
For kostnadsmodellen er poenget enklere: sett forvaltning på begge sider av arket, på et realistisk nivå, så blir sammenligningen ærlig. Basert på prosjekter vi har deltatt i, ligger løpende forvaltning for en medlemsløsning typisk mellom 15 og 25 prosent av førsteårets prosjektkostnad per år, avhengig av hvor mye dere fortsetter å utvikle etter produksjonssetting. Det er tallet som oftest settes til null i et beslutningsgrunnlag, på begge sider.
"Den dyreste posten i et systembytte står sjelden i tilbudet. Det er timene egne folk bruker på å drifte to systemer samtidig mens migreringen pågår."
— Cartagena, basert på CRM- og Dynamics 365-leveranser til medlems-, interesse- og giverorganisasjoner i Norge
Hvorfor byttet blir dyrere enn budsjettert
I medlemsprosjekter står fem mønstre for det meste av avstanden mellom estimat og virkelighet. Ingen av dem er tekniske.
- Alt-skal-med-migreringen. Tjue års historikk flyttes fordi ingen turte å bestemme hva som kunne arkiveres. Migreringsarbeidet skalerer med volum og med antall unntak i de gamle dataene.
- Integrasjoner som telles som én. «Vi har en integrasjon mot økonomisystemet» viser seg ofte å være en nattlig filoverføring, en manuell avstemming og et regneark noen vedlikeholder. Tell koblinger, ikke systemer.
- Rapporter uten eier. En rapportliste viser seg nesten alltid å inneholde langt flere rapporter enn den har lesere. Å kartlegge hvilke som har en faktisk mottaker, krymper prosjektet, og selve kartleggingen tar en dag.
- Egen tid som ikke er budsjettert. Fagpersoner, økonomi og medlemsservice må være tilgjengelige gjennom design, test og første kontingentkjøring. Er ikke de timene planlagt, tas de fra ordinær drift, og prosjektet glir.
- Opplæring som kuttes sist i prosjektet og først i budsjettet. En medlemsorganisasjon har flere brukerroller enn en salgsorganisasjon, inkludert tillitsvalgte og frivillige som bruker systemet noen ganger i året. Det er de brukerne som genererer henvendelser hvis opplæringen er tynn. Vi går gjennom disiplinen i artikkelen om endringsledelse for CRM.
Ingenting av dette er særegent for medlemsorganisasjoner, og forskningen på kostnadsoverskridelser er verdt å kjenne til, selv om den dekker prosjekter langt større enn deres. I en studie fra 2012 av over 5 400 IT-prosjekter fant McKinsey og BT Centre for Major Programme Management ved Universitetet i Oxford at store IT-prosjekter i snitt gikk 45 prosent over budsjett og 7 prosent over tid, og leverte 56 prosent mindre verdi enn forutsatt. Studien definerte et stort prosjekt som ett med initialbudsjett over 15 millioner dollar, så størrelsesordenen kan ikke overføres til en medlemsorganisasjon. Mekanismene kan det, og de er de fem over. Panorama Consultings årlige ERP-undersøkelse, som bygger på egenrapporterte svar fra virksomheter, peker samme vei i mindre skala: budsjettoverskridelser er fortsatt utbredt, og ekstra teknologibehov oppgis som den hyppigste årsaken.
Koeksistens: slik sprer dere kostnaden og reduserer risikoen
Å erstatte alt på én dato er sjelden riktig form for en medlemsorganisasjon. Ikke fordi en etappevis tilnærming er billigere totalt, det er den som regel ikke, men fordi den endrer risikoprofilen og likviditetsbildet på en måte som betyr noe når årsbudsjettet er fast og styret vedtar det én gang i året.
Rekkefølgen betyr noe. Etabler datafundamentet først, slik at medlemsdata, organisasjonsstruktur og historikk ligger ett sted dere eier. La det eksisterende systemet fortsette å eie kontingent og betaling til det nye oppsettet er verifisert mot en reell kjøring, ikke mot testdata. Flytt deretter én prosess av gangen, med reskontrogrensen der den hører hjemme, slik vi beskriver i artikkelen om medlemsreskontro og ERP. Avvikling kommer sist.
Mønster: organisasjoner i sjiktet 10 000 til 30 000 medlemmer som flytter i etapper, bruker typisk tre til fem måneder lenger totalt enn de som forsøker én samlet overgang, men de fordeler kostnaden over to budsjettår og de får nesten aldri en kontingentkjøring på tverke. De vi ser slite, er de som slo sammen systembytte, ny kontingentmodell og ny selvbetjeningsportal til én leveranse, og deretter lot alle tre avhenge av samme produksjonssettingsdato.
Slik lager dere et beslutningsgrunnlag på fire uker
Fire uker er nok til å ta beslutningen, forutsatt at kartleggingen faktisk stiller de ubehagelige spørsmålene. En større forstudie endrer sjelden svaret; den flytter det bare lenger ut i året.
- Uke 1: inventar. Alle tilkoblede systemer, alle integrasjonspunkter, alle rapporter med navngitt mottaker, alle brukerroller inkludert tillitsvalgte og frivillige.
- Uke 2: datakvalitet. Duplikater, ufullstendige poster, hvor mange års historikk som faktisk brukes, og hvor kontingentreglene er dokumentert. Finnes de bare i hodet på én person, er det et funn i seg selv.
- Uke 3: prosess. Hvilke prosesser som faktisk skaper friksjon i dag, og hvilke av dem et nytt system ville løst. Dette er uken som oftest avdekker at problemet er rapportering, ikke registeret.
- Uke 4: to scenarier og en femårsmodell. Bytte, og bli og forbedre. Begge med engangskostnader, løpende kostnader, forvaltning og egne timer. Lander de to nær hverandre, er det som regel riktig å bli.
Be enhver leverandør om et estimat bygget på den kartleggingen, ikke på en generell prisliste. Og be om at estimatet splittes på de seks postene i den første tabellen. En leverandør som ikke kan bryte tallet ned på den måten, har ikke forstått miljøet deres godt nok til å prise det.
Ofte stilte spørsmål om kostnaden ved å bytte medlemssystem
Hva koster det å bytte medlemssystem?
Abonnementet er sjelden det som avgjør totalen. Kostnaden drives av fire ting: datamigrering og datakvalitet, antall integrasjoner som må reetableres, rapporter som må bygges opp igjen, og opplæring. Basert på prosjekter vi har deltatt i innenfor det norske medlems- og organisasjonssegmentet ligger tjenestekostnaden i første år typisk på to til fire ganger årlig lisenskostnad. Budsjettér i konsulentuker mot en konkret kartlegging av deres eget miljø, ikke mot en generell prisliste.
Hvor lang tid tar det å bytte medlemssystem?
Som planleggingsantakelse bør dere sette av seks til tolv måneder fra beslutning til produksjonssetting for en organisasjon med 5 000 til 50 000 medlemmer og 10 til 40 interne brukere. Enkle miljøer med få integrasjoner går raskere; organisasjoner med kontingentkjøringer, flere betalingskanaler og mange års historikk bør planlegge mot øvre del av spennet. Kalendertiden avgjøres sjelden av teknologien, men av hvor raskt beslutninger tas og hvor mye tid egne folk kan sette av.
Hva er den største skjulte kostnaden ved et systembytte?
Egen tid. I en overgangsperiode drifter organisasjonen to systemer parallelt, og administrasjon, økonomi og medlemsservice bærer den belastningen på toppen av ordinær drift. Denne kostnaden står nesten aldri i et tilbud, fordi den ikke er leverandørens kostnad. Erfaringsmessig er det den posten som oftest mangler i beslutningsgrunnlaget, og den som oftest forklarer hvorfor et prosjekt oppleves dyrere enn det så ut på papiret.
Er det billigere å beholde medlemssystemet vi har?
Ofte ja, og det er et legitimt svar. Hvis systemet dekker prosessene dere faktisk kjører, og friksjonen ligger i rapporteringen framfor i selve registeret, er et bytte en dyr måte å løse et mindre problem på. Den ærlige sammenligningen er ikke nytt system mot gammelt system, men femårskostnaden for begge alternativene, inkludert det dere ikke får gjort i dag. Å beholde systemet er et reelt alternativ som fortjener et ordentlig regnestykke, ikke et standardvalg dere lander på fordi alternativet ser vanskelig ut.
Hvordan regner vi totalkostnad over fem år?
Del modellen i to: engangskostnader i år én, og løpende kostnader hvert år. Engangs dekker kartlegging, design, konfigurasjon, datamigrering, integrasjoner, rapporter og opplæring. Løpende dekker abonnement eller lisens, forvaltning og videreutvikling, lagring og kapasitet, integrasjonsvedlikehold og opplæring av nye ansatte. Legg så til to linjer de fleste modeller utelater: egne timer, og prisreguleringsklausulen i avtalen. Flerårige avtaler har som regel en årlig indeksregulering, så be om å se den klausulen før dere sammenligner førsteårspriser.
Kan vi bytte uten å ta alt på én gang?
Ja, og for de fleste organisasjoner er det den minst risikable veien. Etabler datafundamentet først, la det eksisterende systemet fortsette å eie kontingent og betaling til det nye oppsettet er verifisert mot en reell kjøring, og flytt deretter én prosess av gangen. Koeksistens koster litt mer i overgangsperioden fordi dere drifter to systemer, men det fjerner den største enkeltrisikoen i et systembytte: at alt må virke samme dag. Vi anbefaler ikke å erstatte alt i ett steg.
Trenger dere egentlig å bytte, eller trenger dere et bedre fundament?
De fleste organisasjoner trenger ikke en stor forstudie. De trenger fire uker med ærlig kartlegging, en femårsmodell der forvaltning og egne timer er med, og to prissatte scenarier å legge fram for styret. Vi gjennomfører den kartleggingen for medlemsorganisasjoner, og vi sier tydelig fra når svaret er å beholde systemet dere har.