Org-strategi er en landskabsbeslutning

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 5 af 6 i kapitlet Forstå virksomhedens data, kapitel 4 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Tegn systemlandskabet · Næste: Steve Truckings landskab

Spørgsmålet, dette modul besvarer: Én org eller mange, og hvor kører den?

Når jeg underviser CTA-kandidater, fortæller jeg dem, at den største beslutning i et scenarie kommer i de første fem eller ti minutter: hvor mange Salesforce-org’er har vi med at gøre? Én stor org? Regionale org’er for Nordamerika, EMEA og APAC? Separate org’er for separate forretningsenheder? En særlig org til et land med sine egne regler? Og direkte knyttet til det: hvor kører de org’er?

Det er ikke admin-detaljer. De ændrer, hvor dataene bor, integrationerne, rapporteringen, identiteten, og hvordan folk rundt om i verden når systemet. Derfor behandler jeg org-strategi som en landskabsbeslutning, og derfor træffer jeg den først.

Start med én org

Min udgangsposition er enkel: start med én org. Ikke fordi én org altid er rigtigt, men fordi jeg skal have en grund til at tilføje en til. Én org giver mig ét sted til fælles kundedata, én sikkerhedsmodel, ét sted at deploye til, ét sæt integrationer, ét sted at rapportere fra. Og én org kan stadig understøtte forskellige forretningsenheder, lande, processer, posttyper, apps, delingsmodeller og oplevelser.

Så jeg tilføjer ikke en org, fordi Europa gør tingene lidt anderledes, eller en division har sin egen salgsproces, eller forretningsenhederne ikke kan lide hinanden. Det er krav, ikke org-grænser. Spørgsmålet er: hvilken kraft er stærk nok til at retfærdiggøre en org til?

Flere org’er har en pris

Del én org op i tre (Nordamerika, Europa, Asien-Stillehavet), og du har ikke tegnet tre pæne kasser; du har skabt nye spørgsmål. Hvor bor en global kunde? Hvad hvis den opererer i to regioner: to kopier, og hvilken ejer den? Hvordan rapporterer nogen globalt? Integrerer ERP’et med alle tre, får datavarehuset tre feeds, forbinder identitetsudbyderen sig til alle tre? Deployer vi den samme funktionalitet tre gange og holder tre datamodeller i takt? Hvis en agent har brug for et globalt billede af en kunde, hvilken org spørger den så?

Gå tilbage til landskabet fra modul 4. Én Salesforce-kasse bliver til tre, og hver pil skal tegnes om. Flere org’er er ikke forkert. Det er aldrig gratis.

Kig efter reelle grænser

Hvad kan retfærdiggøre en org til? Grænser, der er reelle nok til at forme arkitekturen: krav om dataopbevaringssted, regulering, juridisk adskillelse, reelt forskellige driftsmodeller, et opkøb, der ikke er integreret endnu, en regional hostingbegrænsning, meget forskellig styring, nogle gange skala eller isolation. Listen er ikke komplet. Pointen er at kunne skelne »disse grupper er forskellige« fra »disse grupper har brug for en arkitektonisk grænse«. Den anden bar ligger meget højere.

Geografi er ikke automatisk en org-strategi

»Vi opererer i 30 lande, så vi skal have 30 org’er.« Nej. Geografi betyder noget, når den bringer et arkitektonisk krav med sig. En virksomhed kan have brugere over hele verden på én fælles arkitektur. Så jeg tæller ikke lande; jeg spørger, hvad der følger med dem. Hvor må dataene opbevares? Hvor må de behandles? Er der grænser for at flytte persondata på tværs af landegrænser? Kontraktlige løfter om dataopbevaringssted? Har en region brug for en anden Salesforce-tjeneste eller -host? »Der er et kontor i Tyskland« er ikke nok i sig selv.

Hosting er en del af tegningen

Her gør den moderne platform landskabet mere interessant. Hyperforce kører Salesforce på offentlig cloudinfrastruktur i regioner over hele verden og giver kunderne flere valg og mere kontrol over, hvor deres data opbevares (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Så når jeg skriver »Salesforce, Europa« på en kasse, kan den placering betyde noget.

Men vær præcis. At vælge, hvor en org bor, er ikke et løfte om, at hver eneste byte fra hver eneste tjeneste bliver der. Salesforce beder kunderne gennemgå trust- og compliance-dokumentationen for Hyperforce, herunder de ekstra underdatabehandlere for de tjenester, de køber (samme kilde). Så sig ikke »vi er på Hyperforce i land X, så alt bliver i land X«. Vid, hvilke tjenester du faktisk bruger, og hvilket krav du opfylder. Og læg mærke til, hvad du vælger: regionen, ikke clouden nedenunder. Hyperforce kører på AWS, med Google Cloud fra slutningen af 2026, og Salesforce bestemmer, hvilken udbyder en org står på; en kunde med en dokumenteret regulatorisk grund til at undgå én af dem taler med sit account team (samme kilde).

Spil ikke jurist

Det er også her, arkitekter skal kende deres rolle. Hvis nogen siger: »Europæisk privatlivslovgivning kræver en separat org«, accepterer jeg det ikke blindt. Jeg udnævner heller ikke mig selv til virksomhedens jurist og erklærer, at den ikke gør. Jeg spørger: hvilket konkret krav er det, vi opfylder? Hvor data opbevares, hvor de behandles, overførsel på tværs af grænser, hvem der kan tilgå dem i forbindelse med support, en kontrakt, en intern politik? Så arbejder jeg sammen med privacy, sikkerhed, compliance og jura om at gøre det krav til arkitektur. Opfind ikke juridiske krav, og ignorer dem ikke. Oversæt dem.

Når Europa får sin egen org

Her er en grænse, jeg ser i rigtige scenarier. En virksomhed har en stor tilstedeværelse i USA og en stor tilstedeværelse i Europa: to store kundebaser, to salgs- og serviceorganisationer og et europæisk privatlivsprogram bygget op omkring GDPR. GDPR siger ikke »du skal have en separat Salesforce-org«. Den fastsætter regler for persondata, herunder hvornår de må overføres ud af EU (GDPR, kapitel V (opens in a new tab)). Men denne virksomhed beslutter sammen med sine privacy- og juristteams, at dens europæiske kunders persondata skal bo i en org, der er hostet i Europa, drives af dens europæiske team og er underlagt dens europæiske styring. Det er et reelt krav, og det er deres, ikke mit.

Nu er »én stor global org« ikke længere en præference. Der er en grænse på landskabet, Salesforce AMER og Salesforce EMEA, og den skal jeg tegne. Og den anden org er aldrig bare én kasse mere.

Click to enlarge

To org’er, AMER og EMEA. Det ravfarvede er det, den anden org tilføjer: ikke én kasse mere, men hver pil igen.

Gå pilene igennem igen

Med mere end én org skal du gå landskabet igennem igen. Sender ERP’et produkter til hver org? Sender hver af dem ordrer tilbage? Hvor mastres kunderne, og må deres data krydse regioner? Er integrationslaget globalt eller regionalt? Hvilken identitetsudbyder logger hvilke brugere ind? Hvor går de analytiske data hen?

Tre steder viser prisen hurtigst:

Rapportering. Den administrerende direktør vil have en global pipeline. I én org er det en Salesforce-rapport. I tre er det et rapporteringsproblem for hele virksomheden: replikere, sende til datavarehuset, føderere? Hvor aktuelt skal det være, og definerer org’erne overhovedet »pipeline« på samme måde? Hvor analysen bor, følger af, hvor dataene bor, og hvis du med vilje deler de operationelle data op, skal du designe, hvordan indsigten samles igen.

Masterdata. En global kunde køber i USA, Tyskland og Japan. Tre org’er, så sandsynligvis tre konti. Hvordan ved du, at det er den samme virksomhed? Hvad er den globale identifikator, og hvem ejer den? Hvis én region ændrer adressen, skal ændringen så spredes? Hvilke attributter er globale, og hvilke er regionale? Org-strategi løser ikke identitet; den ændrer identitetsproblemet. Det er kapitel 6.

Integration. Én org: Salesforce, integrationslaget, ERP’et. Tre org’er: tre forbindelser ind i integrationslaget, måske én med sin egen host og forbindelse, nogle flows fælles, nogle regionale, nogle data, der må krydse, og nogle, der ikke må. Selv netværket kan ændre sig: hvis virksomheden har brug for en dedikeret privat forbindelse ind i Hyperforce (på AWS anbefaler Salesforce AWS Direct Connect; samme Hyperforce-FAQ), er hver org og host på tegningen endnu en forbindelse, der skal planlægges. Hvor en org kører, kan ændre, hvordan resten af virksomheden når den.

Én org eller mange er en beslutning, du træffer nu, i starten, på landskabet. Hvordan org’erne derefter deler data (Salesforce Connect på tværs af org’er, integration mellem dem, Data 360), er mekanikken, og kapitel 14, Én org eller mange? (coming soon), dækker den.

Hvis du designer hele datamodellen og integrationsarkitekturen og først derefter hører »nå ja, det her skal i øvrigt være tre org’er«, har du ikke lavet en lille justering. Du har ændret arkitekturen. Derfor kommer beslutningen først.

Del ikke op bare for at gøre kasserne mindre

En stor org føles kompliceret: mange enheder, objekter, brugere, integrationer. Nogen siger: »Ville det ikke være pænere, hvis alle havde deres egen org?« Tegningen bliver måske pænere. Virksomheden gør det måske ikke. Du har byttet intern kompleksitet for distribueret kompleksitet: synkronisering, dubletdata, identitet på tværs af org’er, global rapportering, flere release-pipelines, duplikerede integrationer og automatiseringer og styring af det hele. Nogle gange er det stadig den rigtige byttehandel. Men adskilt er ikke det samme som enkelt.

Og én org er heller ikke gratis. Fælles styring betyder mere, teams kan påvirke hinanden, sikkerhedsgrænser kræver omhyggeligt design, datamodellen skal tjene mange grupper, releases skal koordineres, og regionale regler kan begrænse alle. Så det er ikke »Steve siger altid én org«. Min udgangsholdning er én org; så leder jeg efter det krav, der er stærkt nok til at flytte mig væk fra den.

Gør beslutningen synlig

Hvis org-strategi betyder noget, så tegn ikke en generisk Salesforce-sky. Tegn org’erne, og sæt navn på dem (AMER, EMEA, hvad der nu er virkeligt), notér kravet om hosting eller dataopbevaringssted bag hver af dem, og gå forbindelserne igennem. En anden arkitekt skal kunne se, hvorfor hver grænse findes. Hvis jeg ikke kan forklare, hvorfor der er tre Salesforce-kasser, er jeg ikke færdig med beslutningen.

Steve Trucking kører én org i USA, og intet i virksomhedens brief kræver en til. Men husk dette modul til afslutningsprojektet: et opkøb, der kommer med sin egen org, er præcis den slags grænse, der sætter de spørgsmål på prøve.

Ud over eksamen: hvad AI ændrer. En agent kan gøre en org-grænse usynlig for brugeren. Nedenunder skal arkitekturen stadig afgøre, hvilken org eller hvilket system agenten må spørge, hvilke data der må krydse regioner, og hvilket svar der er autoritativt. AI kan skjule kompleksiteten i oplevelsen; den fjerner ikke styringen eller grænsen.

Hvad en arkitekt beslutter her

• Om der er en reel arkitektonisk grund til mere end én org, i stedet for at løse forskellene inden for én.
• Hvor hver org kører, og hvilket krav om dataopbevaringssted, regulering, kontrakt eller forretning der placerer den der.
• Hvilke data der må krydse org- og regionsgrænser, hvor masterdata er autoritative, og hvordan global identitet fungerer.
• Hvordan integration, identitet, analyse og rapportering ændrer sig, når én Salesforce-kasse bliver til flere.
• Om gevinsten ved adskillelse er den distribuerede arkitektur værd, som den skaber.

Når jeg læser et scenarie, leder jeg efter denne beslutning først: én org eller mange, hostet hvor, og tvunget af hvad? Svar på det, og resten af landskabet begynder at tage form.

Læs mere

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), kapitel V (overførsel af personoplysninger til tredjelande) (kontrolleret 2026-10-14).