Når en norsk medlemsorganisasjon vurderer nye systemer i dag, svarer flere leverandører med de samme to ordene: Dynamics 365. Det svaret skjuler et viktig valg, for Dynamics 365 for medlemsorganisasjoner leveres i to ganske forskjellige modeller.
Den første er en vertikal basisløsning: en ferdig domeneløsning leverandøren har bygget oppå plattformen og forvalter som ett produkt for mange kunder. Den andre er egen plattform: Dynamics 365 og Dataverse der medlemsmodellen designes rundt deres organisasjon, ofte med utgangspunkt i en referansemodell implementeringspartneren har med seg. Begge er legitime. Men de er forskjellige kjøp, og forskjellen blir først synlig den dagen behovene deres avviker fra standarden.
Det korte svaret: en vertikal basisløsning gir dere raskere start og innebygget bransjekunnskap, i bytte mot at leverandøren eier datamodellen og produktveikartet. Egen plattform gir dere eierskap til modellen og frihet til å integrere og bygge videre, i bytte mot flere beslutninger i starten og et reelt forvaltningsansvar. Hva som er riktig, avhenger av hvor standard organisasjonen deres faktisk er.
Hva er en vertikal basisløsning?
En vertikal basisløsning er en ferdig domeneløsning bygget på Dynamics 365 for én bransje. For medlemsorganisasjoner betyr det at leverandøren allerede har modellert medlemskap, kontingent, lokallag, verv, arrangementer og selvbetjening, og leverer dette som ett produkt som konfigureres per kunde. I det norske markedet er Mysoft Dynamics 365 det tydeligste eksempelet på modellen, og flere konsulentmiljøer tilbyr egne pakkede medlemsløsninger.
Verdien er reell. I leverandørens designvalg ligger mange års bransjeerfaring, oppstarten går raskere fordi de fleste beslutningene allerede er tatt, og produktet forvaltes sentralt slik at oppgraderinger kommer til alle. For en organisasjon der prosessene passer standarden, er dette effektivt og forutsigbart. Det er en ferdig domeneløsning, bygget av folk som kan domenet godt.
Motstykket er like reelt: datamodellen, grensene for tilpasning og veikartet tilhører leverandørens produktorganisasjon. Dere påvirker dem som én kunde blant mange.
Vurderer dere medlemsløsninger akkurat nå? Vi går gjennom arkitekturen bak tilbudene dere har på bordet: eierskap til datamodell, integrasjonspunkter og exit-betingelser. Én arbeidsøkt, før dere signerer.
Hva betyr det å bygge på egen plattform?
Plattformtilnærmingen bruker det samme Microsoft-fundamentet, men medlemsmodellen bor i deres eget miljø: Dynamics 365-applikasjoner på Dataverse, Microsofts felles datatjeneste, med Power Platform for applikasjoner og automatisering, og Power BI og Microsoft Fabric for innsikt. Datamodellen designes rundt hvordan organisasjonen deres jobber, og alt dere bygger på den, er deres.
I praksis starter få organisasjoner med blanke ark. Implementeringspartnere har med seg referansemodeller for medlemsdomenet, slik at medlemskap, kontingentstrukturer og samtykker ikke må finnes opp på nytt. Forskjellen fra en basisløsning er at referansemodellen er et utgangspunkt dere overtar eierskapet til, ikke et produkt dere abonnerer på. Dette er tilnærmingen vi beskriver grundigere i artikkelen om medlemsdata som plattform.
Vær nøktern på kostnadssiden: eierskap betyr ansvar. Noen må eie modellen, styre endringer og forvalte miljøet over tid, enten internt eller gjennom en partneravtale. Det forvaltningsansvaret er en reell plattformkostnad, og organisasjoner som ikke kan bemanne det, bør vekte det tungt i valget.
Fem arkitekturspørsmål som skiller modellene
Funksjonslister nærmer seg hverandre over tid; arkitektur gjør det ikke. Når dere sammenligner tilbud, legg funksjonssammenligningen til side en time og still disse fem spørsmålene i stedet.
| Spørsmål | Vertikal basisløsning | Egen plattform |
|---|---|---|
| Hvem eier datamodellen? | Leverandøren. Dere får konfigurasjonsmuligheter innenfor produktets rammer. | Dere. Referansemodellen blir deres og utvikles med organisasjonen. |
| Hvor fritt kan dere integrere? | Gjennom produktets integrasjonspunkter. Nye integrasjoner går ofte via leverandøren. | Direkte mot Dataverse med standardverktøy, i egen takt og med den partneren dere velger. |
| Kan dere bygge videre med Fabric, Power BI og Copilot? | Ofte, men på leverandørens premisser: det avhenger av hvilke tabeller som er dokumentert og støttet. | Ja, rett på egen modell. Innsikt og AI jobber på data dere kontrollerer betydningen av. |
| Hva koster en exit? | Dataene kommer ut, men modellen må bygges opp igjen. Planlegg for et reelt migreringsprosjekt. | Partnerbytte er billig; modellen og historikken er deres. Å forlate selve plattformen er fortsatt et reelt prosjekt. |
| Hvem bestemmer veikartet? | Leverandørens produktorganisasjon, og i siste instans dens eiere. | Microsoft for fundamentet; dere for egen modell og egne applikasjoner. |
Det første spørsmålet betyr mest. Data går sjelden tapt i et systembytte; mening gjør det. Vi har tidligere skrevet om hvorfor CRM ikke er et masterregister og om forskjellen på å eie data og å eie systemet. Det samme skillet avgjør hvor dyrt det er å ombestemme seg senere.
"Dere kjøper ikke funksjonslisten. Dere kjøper retten til å endre den. Forskjellen mellom modellene viser seg først den dagen behovet avviker fra standarden."
Cartagena, basert på Dynamics 365- og medlemsplattformprosjekter for organisasjoner fra noen tusen til over hundre tusen medlemmer
Hvem bestemmer veikartet når leverandøren skifter eier?
Veikart-spørsmålet har blitt mer aktuelt fordi det nordiske markedet konsoliderer. Et konkret eksempel: Mysoft, en av de mest etablerte norske leverandørene av en medlems-basisløsning på Dynamics 365, ble kjøpt av svenske Multisoft i 2025, og i mars 2026 kjøpte SEB Private Equity majoriteten i Multisoft Group. To eierskifter på under ett år er ikke kritikk av selskapene; det er et normalt trekk i et marked som konsoliderer, og nye eiere har ofte med seg investeringskapasitet.
Men det illustrerer arkitekturpoenget. I en basisløsning er veikartet en produktbeslutning som tas av leverandøren, og leverandørens prioriteringer settes av eierne. Når eierkjeden endres, blir ikke deres innflytelse over veikartet større. Ingenting av dette er unikt for én leverandør; det samme gjelder enhver pakket løsning, på enhver plattform.
På egen plattform er eksponeringen strukturert annerledes. Fundamentet følger Microsofts veikart, som er offentlig og forutsigbart i utgivelsesrytmen. Medlemsmodellen, integrasjonene og applikasjonene er deres, og en implementeringspartner kan byttes ut uten at plattformen byttes. Leverandørrisikoen forsvinner ikke, men den flytter seg fra produktlaget til partnerlaget, der et bytte er langt billigere.
Når er en ferdig basisløsning riktig valg?
En ærlig sammenligning må svare skikkelig på dette spørsmålet, for hos mange organisasjoner er basisløsningen det riktige svaret. Mønsteret vi ser: organisasjonens prosesser ligger tett på bransjestandarden, medlemskapet er den dominerende relasjonen, kontingenten kjører i velkjente modeller, og det finnes lite intern kapasitet eller vilje til å eie en plattform. I den situasjonen leverer en ferdig domeneløsning raskere og med lavere risiko enn et plattformprosjekt, og leverandørens løpende produktforvaltning er en tjeneste dere ellers måtte organisert selv.
Velger dere denne veien, gjør det med åpne øyne: få datamodellen dokumentert, få eksportformatet demonstrert, og få betingelsene for egne integrasjoner inn i avtalen. En god basisløsningsleverandør svarer på alle tre uten å nøle.
Når er egen plattform riktig valg?
Plattformveien forsvarer kostnaden når organisasjonens virkelighet ikke lenger passer i ett produkts domenemodell. Typiske signaler: flere inntektsstrømmer enn kontingent, relasjoner som går utover selve medlemskapet, kurs, sertifiseringer eller politisk påvirkningsarbeid med egne prosesser, integrasjonsbehov mot egne økonomi- og fagsystemer, og en ambisjon om å bruke innsikt og AI på egne data. Dette er situasjonen vi beskrev fra den andre siden i artikkelen om å vokse ut av medlemssystemet.
Mønster: en situasjon som går igjen i prosjekter vi har deltatt i: en organisasjon med noen titusen medlemmer kjører en basisløsning som dekker medlemsregisteret godt. Så kommer behovene produktet ikke ble bygget for: en sertifiseringsordning, en ny inntektsstrøm, dypere rapportering til styret. Hvert avvik blir en endringsforespørsel som prises og prioriteres av leverandøren. Ingen av dem er urimelige; det er summen av dem som utløser arkitekturvurderingen.
Merk at dette ikke er et argument for å bytte alt på en gang. Overgangsmønstrene vi anbefaler er gradvise: koeksistens, der dagens løsning forblir fasit for deler av domenet mens plattformen overtar andre. Aldri riv og erstatt.
Slik gjennomfører dere vurderingen i praksis
Fire steg gir dere en beslutning som tåler ettersyn. Først: kartlegg prosessene som avviker fra bransjestandarden; de avgjør hvor mye en basisløsning må bøyes. Deretter: be hver tilbyder vise datamodellen og de dokumenterte integrasjonspunktene, ikke demoen. Så: pris exiten inn i totalkostnaden: hva ville det kostet å forlate denne løsningen i år fem? Til slutt: still veikart-spørsmålet skriftlig: hvilke forpliktelser tar leverandøren på funksjonaliteten dere er avhengige av?
På kostnadssiden gjelder samme disiplin som i ethvert Dynamics 365-prosjekt: tjenester overstiger normalt lisenser, og den ærlige sammenligningen gjøres over fem år, ikke over første faktura. Mekanikken har vi dekket i artikkelen om implementeringskostnad for Dynamics 365.
Ofte stilte spørsmål om basisløsning mot plattform
Hva er en vertikal basisløsning på Dynamics 365?
En vertikal basisløsning er en ferdig domeneløsning som en leverandør har bygget på Dynamics 365 for en bestemt bransje, for eksempel medlemsorganisasjoner. Leverandøren har ferdigmodellert medlemskap, kontingent, verv og selvbetjening, og forvalter løsningen som ett produkt for mange kunder. Dere kjøper raskere oppstart og innebygget bransjekunnskap, mot at leverandøren eier datamodellen og produktveikartet.
Er en ferdig medlemsløsning billigere enn en egen plattform?
I starten som regel ja: oppstartskostnaden er lavere fordi designvalgene allerede er tatt. Over tid avhenger svaret av hvor godt standarden passer. Tilpasninger utenfor produktets rammer, integrasjoner leverandøren må prise særskilt, og en eventuell exit kan flytte totalkostnaden. En egen plattform koster mer i etablering og krever forvaltning, men gir mer kontroll over hvor pengene går. Regn på fem år, ikke på år én.
Hvem eier dataene i en vertikal basisløsning?
Dataene er juridisk sett deres, og en seriøs leverandør leverer dem ut ved avtaleslutt. Det avgjørende spørsmålet er hvem som eier datamodellen: strukturen som gir dataene mening. Får dere en rå eksport av tabeller bygget for leverandørens produkt, må modellen bygges opp igjen i neste løsning. Be om å få se datamodellen og eksportformatet før dere signerer, ikke etter.
Kan vi bruke Power BI, Fabric eller Copilot oppå en basisløsning?
Ofte ja, siden løsningen ligger i Dataverse, men i praksis avhenger det av hvor åpen leverandørens modell er og hva avtalen tillater. Rapportering mot skjulte eller udokumenterte tabeller blir fort skjør når produktet oppdateres. På egen plattform er datamodellen deres, og Power BI, Microsoft Fabric og Copilot kobles på uten mellomledd. Spør leverandøren konkret: hvilke tabeller er dokumentert og støttet for egen analyse?
Hva koster det å bytte fra en basisløsning senere?
Exit-kostnaden består av mer enn ny lisens: dataeksport og datavask, ny modellering av historikk, reetablering av integrasjoner og opplæring. Basert på prosjekter vi har deltatt i er det vanlig at exit fra en ferdig domeneløsning koster i samme størrelsesorden som den opprinnelige innføringen. Kostnaden er reell uansett modell, men den er lavere når dere selv eier datamodellen. Regn den inn i beslutningen fra start.
Hva betyr det for oss at leverandøren skifter eier?
Ikke nødvendigvis noe dramatisk: produktet forsvinner sjelden over natten, og nye eiere investerer ofte i videreutvikling. Men prioriteringene i veikartet kan endre seg, og i en basisløsning er veikartet leverandørens beslutning. Still to spørsmål: hvilke forpliktelser har leverandøren på funksjonalitet dere er avhengige av, og hva er deres plan B hvis produktretningen endres? På egen plattform er eksponeringen mindre fordi modellen og tilpasningene er deres.
Hvilken modell passer deres organisasjon?
Svaret kommer sjelden fra en funksjonssammenligning. Vi gjennomfører en fokusert arkitekturgjennomgang av alternativene dere vurderer: eierskap til datamodell, integrasjonsfrihet, exit-kostnad og veikart-eksponering, oppsummert i et grunnlag styret kan ta beslutning på. Bygget på erfaring fra leveranser av medlemsplattformer på Dynamics 365 og Dataverse.