Org-strategi er en landskapsbeslutning

🌐 Finnes også på 28 språk

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 5 av 6 i kapitlet Forstå virksomhetens data, kapittel 4 i kurset Data Architect. Hver modul står på egne ben. Forrige: Tegn systemlandskapet · Neste: Steve Truckings landskap

Spørsmålet denne modulen besvarer: Én org eller mange, og hvor kjører den?

Når jeg underviser CTA-kandidater, sier jeg til dem at den største beslutningen i et scenario kommer i løpet av de første fem eller ti minuttene: hvor mange Salesforce-orger har vi med å gjøre? Én stor org? Regionale orger for Nord-Amerika, EMEA og APAC? Separate orger for separate forretningsenheter? En egen org for et land med egne regler? Og rett knyttet til det: hvor kjører de orgene?

Dette er ikke admin-detaljer. De endrer hvor dataene bor, integrasjonene, rapporteringen, identiteten og hvordan folk rundt om i verden når systemet. Derfor behandler jeg org-strategi som en landskapsbeslutning, og derfor tar jeg den først.

Start med én org

Utgangspunktet mitt er enkelt: start med én org. Ikke fordi én org alltid er riktig, men fordi jeg trenger en grunn til å legge til en til. Én org gir meg ett sted for delte kundedata, én sikkerhetsmodell, ett sted å deploye til, ett sett med integrasjoner, ett sted å rapportere fra. Og én org kan fortsatt støtte forskjellige forretningsenheter, land, prosesser, posttyper, apper, delingsmodeller og opplevelser.

Så jeg legger ikke til en org fordi Europa gjør ting litt annerledes, eller fordi en divisjon har sin egen salgsprosess, eller fordi forretningsenhetene ikke liker hverandre. Det er krav, ikke org-grenser. Spørsmålet er: hvilken kraft er sterk nok til å rettferdiggjøre en org til?

Flere orger har en kostnad

Del én org i tre (Nord-Amerika, Europa, Asia-Stillehavet), og du har ikke tegnet tre ryddige bokser; du har skapt nye spørsmål. Hvor bor en global kunde? Hva om den opererer i to regioner: to kopier, og hvilken eier den? Hvordan rapporterer noen globalt? Integrerer ERP-et med alle tre, får datavarehuset tre strømmer, kobler identitetsleverandøren seg til alle tre? Deployer vi den samme funksjonaliteten tre ganger og holder tre datamodeller i takt? Hvis en agent trenger et globalt bilde av en kunde, hvilken org spør den?

Gå tilbake til landskapet fra modul 4. Én Salesforce-boks blir tre, og hver pil må tegnes på nytt. Flere orger er ikke feil. Det er aldri gratis.

Se etter ekte grenser

Hva kan rettferdiggjøre en org til? Grenser som er ekte nok til å forme arkitekturen: krav til datalagringssted, regulering, juridisk atskillelse, virkelig forskjellige driftsmodeller, et oppkjøp som ikke er integrert ennå, en regional begrensning på hosting, svært forskjellig styring, noen ganger skala eller isolasjon. Listen er ikke komplett. Poenget er å skille «disse gruppene er forskjellige» fra «disse gruppene trenger en arkitektonisk grense». Den andre terskelen er mye høyere.

Geografi er ikke automatisk en org-strategi

«Vi opererer i 30 land, så vi trenger 30 orger.» Nei. Geografi betyr noe når den fører med seg et arkitektonisk krav. Et selskap kan ha brukere over hele verden på én felles arkitektur. Så jeg teller ikke land; jeg spør hva som følger med dem. Hvor får dataene lagres? Hvor får de behandles? Finnes det begrensninger på å flytte personopplysninger over grenser? Kontraktsfestede løfter om datalagringssted? Trenger en region en annen Salesforce-tjeneste eller et annet driftssted? «Vi har et kontor i Tyskland» er ikke nok alene.

Driften er en del av tegningen

Her gjør den moderne plattformen landskapet mer interessant. Hyperforce kjører Salesforce på infrastruktur i den offentlige skyen i regioner rundt om i verden, og gir kundene flere valg og mer kontroll over hvor dataene deres ligger (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Så når jeg merker en boks «Salesforce, Europa», kan den plasseringen bety noe.

Men vær presis. Å velge hvor en org bor, er ikke et løfte om at hver byte fra hver tjeneste blir der. Salesforce ber kundene gå gjennom dokumentasjonen om tillit og compliance for Hyperforce, inkludert de ekstra underleverandørene (sub-processors) for tjenestene de kjøper (samme kilde). Så ikke si «vi er på Hyperforce i land X, så alt blir i land X». Vit hvilke tjenester du faktisk bruker, og hvilket krav du oppfyller. Og legg merke til hva du velger: regionen, ikke skyen under den. Hyperforce kjører på AWS, med Google Cloud fra slutten av 2026, og Salesforce bestemmer hvilken leverandør en org ligger hos; en kunde med en dokumentert regulatorisk grunn til å unngå én av dem, tar det opp med kundeteamet sitt (samme kilde).

Ikke spill advokat

Det er også her arkitekter må kjenne rollen sin. Hvis noen sier «europeisk personvernlovgivning krever en separat org», godtar jeg det ikke blindt. Jeg utnevner heller ikke meg selv til selskapets advokat og erklærer at den ikke gjør det. Jeg spør: hvilket konkret krav er det vi oppfyller? Hvor data lagres, hvor de behandles, overføring over landegrenser, hvem som kan få tilgang for brukerstøtte, en kontrakt, intern policy? Så jobber jeg med personvern, sikkerhet, compliance og juridisk avdeling for å gjøre det kravet om til arkitektur. Ikke dikt opp juridiske krav, og ikke overse dem. Oversett dem.

Når Europa får sin egen org

Her er en grense jeg ser i ekte scenarioer. Et selskap har en stor tilstedeværelse i USA og en stor tilstedeværelse i Europa: to store kundebaser, to salgs- og serviceavdelinger, og et europeisk personvernprogram bygget rundt GDPR (personvernforordningen). GDPR sier ikke «du trenger en separat Salesforce-org». Den setter regler for personopplysninger, blant annet for når de kan overføres ut av EU (GDPR, kapittel V (opens in a new tab)). Men dette selskapet bestemmer, sammen med personvern- og juridiske team, at personopplysningene om de europeiske kundene skal bo i en org som driftes i Europa, drives av det europeiske teamet og styres av den europeiske styringen. Det er et ekte krav, og det er deres, ikke mitt.

Nå er ikke «én stor global org» lenger en preferanse. Det finnes en grense på landskapet, Salesforce AMER og Salesforce EMEA, og jeg må tegne den. Og org nummer to er aldri bare én boks til.

Click to enlarge

To orger, AMER og EMEA. Ravfargen er det org nummer to legger til: ikke én boks til, men hver pil på nytt.

Gå gjennom pilene igjen

Med mer enn én org går du gjennom landskapet på nytt. Sender ERP-et produkter til hver org? Sender hver av dem ordrer tilbake? Hvor håndteres kundene som masterdata, og får dataene deres krysse regioner? Er integrasjonslaget globalt eller regionalt? Hvilken identitetsleverandør logger inn hvilke brukere? Hvor går de analytiske dataene?

Tre steder viser kostnaden raskest:

Rapportering. Konsernsjefen vil ha en global pipeline. I én org er det en rapport i Salesforce. I tre er det et rapporteringsproblem for hele virksomheten: replikere, sende til datavarehuset, føderere? Hvor oppdatert må det være, og definerer orgene i det hele tatt «pipeline» på samme måte? Hvor analysen bor, følger av hvor dataene bor, og hvis du deler de operative dataene med vilje, må du designe hvordan innsikten kommer sammen igjen.

Masterdata. En global kunde kjøper i USA, Tyskland og Japan. Tre orger, så sannsynligvis tre kontoer. Hvordan vet du at det er samme selskap? Hva er den globale identifikatoren, og hvem eier den? Hvis én region endrer adressen, skal endringen spres? Hvilke attributter er globale og hvilke regionale? Org-strategi løser ikke identitet; den endrer identitetsproblemet. Det er kapittel 6.

Integrasjon. Én org: Salesforce, integrasjonslaget, ERP-et. Tre orger: tre forbindelser inn i integrasjonslaget, kanskje én med eget driftssted og egen tilkobling, noen flyter delt, noen regionale, noen data tillatt på tvers og noen ikke. Til og med nettverket kan endre seg: hvis virksomheten trenger dedikert privat tilkobling inn i Hyperforce (på AWS anbefaler Salesforce AWS Direct Connect; samme Hyperforce-FAQ), er hver org og hvert driftssted på tegningen enda en forbindelse å planlegge. Hvor en org kjører, kan endre hvordan resten av virksomheten når den.

Én org eller mange er en beslutning du tar nå, i starten, på landskapet. Hvordan orgene så deler data (Salesforce Connect på tvers av orger, integrasjon mellom dem, Data 360) er mekanikken, og kapittel 14, Én org eller mange? (coming soon), dekker den.

Hvis du designer hele datamodellen og integrasjonsarkitekturen og først da hører «forresten, dette må være tre orger», har du ikke gjort en liten justering. Du har endret arkitekturen. Derfor kommer beslutningen først.

Ikke del bare for å gjøre boksene mindre

En stor org føles komplisert: mange enheter, objekter, brukere, integrasjoner. Noen sier: «Ville det ikke vært ryddigere om alle hadde sin egen org?» Tegningen blir kanskje ryddigere. Virksomheten blir det kanskje ikke. Du har byttet intern kompleksitet mot distribuert kompleksitet: synkronisering, dupliserte data, identitet på tvers av orger, global rapportering, flere release-pipelines, dupliserte integrasjoner og automatisering, og styring av alt sammen. Noen ganger er det likevel riktig bytte. Men separat er ikke det samme som enkelt.

Og én org er heller ikke gratis. Felles styring betyr mer, team kan påvirke hverandre, sikkerhetsgrenser må designes nøye, datamodellen må tjene mange grupper, releaser må koordineres, og regionale regler kan begrense alle. Så det er ikke «Steve sier alltid én org». Mitt utgangspunkt er én org; så ser jeg etter kravet som er sterkt nok til å flytte meg fra den.

Gjør beslutningen synlig

Hvis org-strategien betyr noe, ikke tegn en generisk Salesforce-sky. Tegn orgene og merk dem (AMER, EMEA, det som faktisk gjelder), noter kravet om hosting eller datalagringssted bak hver av dem, og gå gjennom forbindelsene. En annen arkitekt skal kunne se hvorfor hver grense finnes. Kan jeg ikke forklare hvorfor det er tre Salesforce-bokser, er jeg ikke ferdig med beslutningen.

Steve Trucking kjører én org, i USA, og ingenting i briefen krever en til. Men ha denne modulen i bakhodet til avslutningsprosjektet: et oppkjøp som kommer med sin egen org, er akkurat den typen grense som setter disse spørsmålene på prøve.

Utover eksamen: hva KI endrer. En agent kan gjøre en org-grense usynlig for brukeren. Under overflaten må arkitekturen fortsatt bestemme hvilken org eller hvilket system agenten får spørre, hvilke data som får krysse regioner, og hvilket svar som er autoritativt. KI kan skjule kompleksiteten i opplevelsen; den fjerner ikke styringen eller grensen.

Hva en arkitekt bestemmer her

• Om det finnes en reell arkitektonisk grunn til mer enn én org, i stedet for å løse forskjellene inni én.
• Hvor hver org kjører, og hvilket krav om datalagringssted, regulering, kontrakt eller forretning som plasserer den der.
• Hvilke data som får krysse org- og regiongrenser, hvor masterdataene er autoritative, og hvordan global identitet fungerer.
• Hvordan integrasjon, identitet, analyse og rapportering endrer seg når én Salesforce-boks blir flere.
• Om gevinsten ved atskillelse er verdt den distribuerte arkitekturen den skaper.

Når jeg leser et scenario, ser jeg etter denne beslutningen først: én org eller mange, driftet hvor, og tvunget frem av hva? Svar på det, så begynner resten av landskapet å ta form.

Les mer

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab), på engelsk, kontrollert 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), kapittel V (overføring av personopplysninger til tredjeland), på engelsk, kontrollert 2026-10-14.