Org-strategia on järjestelmäkartan päätös

🌐 Saatavilla myös 28 kielellä

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

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 5/6 luvussa Yrityksen tietojen ymmärtäminen, Data Architect -kurssin luku 4. Jokainen moduuli on itsenäinen. Edellinen: Piirrä järjestelmäkartta · Seuraava: Steve Truckingin järjestelmäkartta

Kysymys, johon tämä moduuli vastaa: Yksi org vai monta, ja missä se toimii?

Kun opetan CTA-kandidaatteja, kerron heille, että skenaarion suurin päätös tehdään ensimmäisten viiden tai kymmenen minuutin aikana: kuinka monen Salesforce-orgin kanssa olemme tekemisissä? Yksi iso org? Alueelliset orgit Pohjois-Amerikalle, EMEA:lle ja APAC:lle? Erilliset orgit erillisille liiketoimintayksiköille? Erityinen org maalle, jolla on omat sääntönsä? Ja suoraan siihen sidottuna: missä nuo orgit toimivat?

Nämä eivät ole ylläpidon yksityiskohtia. Ne muuttavat sitä, missä tiedot asuvat, integraatioita, raportointia, identiteettiä ja sitä, miten ihmiset ympäri maailmaa tavoittavat järjestelmän. Siksi käsittelen org-strategiaa järjestelmäkartan päätöksenä, ja siksi teen sen ensin.

Aloita yhdestä orgista

Lähtökohtani on yksinkertainen: aloita yhdestä orgista. Ei siksi, että yksi org olisi aina oikein, vaan siksi, että tarvitsen syyn lisätä toinen. Yksi org antaa minulle yhden paikan jaetuille asiakastiedoille, yhden suojausmallin, yhden paikan käyttöönotoille, yhden joukon integraatioita ja yhden paikan raportoida. Ja yksi org voi silti tukea eri liiketoimintayksiköitä, maita, prosesseja, tietuetyyppejä, sovelluksia, jakamismalleja ja käyttökokemuksia.

En siis lisää orgia siksi, että Euroopassa tehdään asiat vähän eri tavalla, tai siksi, että divisioonalla on oma myyntiprosessinsa, tai siksi, etteivät liiketoimintayksiköt pidä toisistaan. Ne ovat vaatimuksia, eivät orgien rajoja. Kysymys on: mikä voima on tarpeeksi vahva oikeuttamaan toisen orgin?

Useilla orgeilla on hintansa

Jaa yksi org kolmeen (Pohjois-Amerikka, Eurooppa, Aasia ja Tyynenmeren alue), niin et ole piirtänyt kolmea siistiä laatikkoa; olet luonut uusia kysymyksiä. Missä globaali asiakas asuu? Entä jos se toimii kahdella alueella: kaksi kopiota, ja kumpi omistaa sen? Miten kukaan raportoi globaalisti? Integroituuko ERP kaikkiin kolmeen, saako tietovarasto kolme syötettä, yhdistyykö identiteetinhallinnan palvelu kaikkiin kolmeen? Otammeko samat toiminnot käyttöön kolme kertaa ja pidämme kolme tietomallia linjassa? Jos agentti tarvitsee globaalin näkymän asiakkaaseen, mitä orgia se kysyy?

Palaa moduulin 4 järjestelmäkarttaan. Yhdestä Salesforce-laatikosta tulee kolme, ja jokainen nuoli piirretään uudelleen. Useat orgit eivät ole väärin. Ne eivät ole koskaan ilmaisia.

Etsi todellisia rajoja

Mikä voi oikeuttaa toisen orgin? Rajat, jotka ovat tarpeeksi todellisia muovatakseen arkkitehtuuria: tietojen sijainti, sääntely, juridinen erottelu, aidosti erilaiset toimintamallit, yritysosto, jota ei ole vielä yhdistetty, alueellinen isännöintirajoite, hyvin erilainen hallintamalli, joskus mittakaava tai eristys. Luettelo ei ole täydellinen. Tarkoitus on erottaa toisistaan ”nämä ryhmät ovat erilaisia” ja ”nämä ryhmät tarvitsevat arkkitehtuurisen rajan”. Jälkimmäisen rima on paljon korkeammalla.

Maantiede ei automaattisesti ole org-strategia

”Toimimme 30 maassa, joten tarvitsemme 30 orgia.” Ei. Maantieteellä on merkitystä, kun se tuo mukanaan arkkitehtuurisen vaatimuksen. Yrityksellä voi olla käyttäjiä ympäri maailmaa yhdellä yhteisellä arkkitehtuurilla. En siis laske maita; kysyn, mitä niiden mukana tulee. Missä tietoja saa säilyttää? Missä niitä saa käsitellä? Onko henkilötietojen siirrolle rajojen yli rajoituksia? Sopimuksellisia lupauksia tietojen sijainnista? Tarvitseeko jokin alue eri Salesforce-palvelun tai isännän? ”Meillä on toimisto Saksassa” ei yksin riitä.

Isännöinti on osa piirrosta

Tässä nykyaikainen alusta tekee järjestelmäkartasta kiinnostavamman. Hyperforce pyörittää Salesforcea julkisen pilven infrastruktuurilla alueilla ympäri maailmaa ja antaa asiakkaille enemmän valinnanvaraa ja hallintaa siihen, missä heidän tietonsa sijaitsevat (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Joten kun nimeän laatikon ”Salesforce, Eurooppa”, sijainnilla voi olla merkitystä.

Mutta ole tarkka. Orgin sijainnin valitseminen ei ole lupaus siitä, että jokaisen palvelun jokainen tavu pysyy siellä. Salesforce kehottaa asiakkaita tutustumaan Hyperforcen luottamus- ja vaatimustenmukaisuusdokumentaatioon, mukaan lukien ostamiensa palvelujen lisäalihankkijat (sama lähde). Älä siis sano: ”olemme Hyperforcessa maassa X, joten kaikki pysyy maassa X.” Tiedä, mitä palveluja oikeasti käytät ja mitä vaatimusta olet täyttämässä. Ja huomaa, mitä valitset: alueen, et sen alla olevaa pilveä. Hyperforce toimii AWS:ssä, ja Google Cloudissa vuoden 2026 lopusta alkaen, ja Salesforce päättää, millä palveluntarjoajalla org on; asiakas, jolla on dokumentoitu sääntelyyn perustuva syy välttää jotain niistä, keskustelee asiakastiiminsä kanssa (sama lähde).

Älä leiki juristia

Tässä kohdassa arkkitehtienkin täytyy tuntea roolinsa. Jos joku sanoo: ”Euroopan tietosuojalaki vaatii erillisen orgin”, en hyväksy sitä sokeasti. En myöskään nimitä itseäni yrityksen juristiksi ja julista, ettei se vaadi. Kysyn: mitä tiettyä vaatimusta olemme täyttämässä? Missä tiedot säilytetään, missä niitä käsitellään, siirrot rajojen yli, kuka pääsee niihin tukitehtävissä, sopimus, sisäinen käytäntö? Sitten muunnan sen vaatimuksen arkkitehtuuriksi yhdessä tietosuojan, tietoturvan, vaatimustenmukaisuuden ja lakiasioiden kanssa. Älä keksi juridisia vaatimuksia äläkä sivuuta niitä. Käännä ne.

Kun Eurooppa saa oman orgin

Tässä on raja, jonka näen todellisissa skenaarioissa. Yrityksellä on vahva läsnäolo Yhdysvalloissa ja vahva läsnäolo Euroopassa: kaksi suurta asiakaskuntaa, kaksi myynti- ja palvelutoimintoa ja eurooppalainen tietosuojaohjelma, joka on rakennettu GDPR:n (tietosuoja-asetus) ympärille. GDPR ei sano: ”tarvitset erillisen Salesforce-orgin.” Se asettaa säännöt henkilötiedoille, myös sille, milloin niitä saa siirtää EU:n ulkopuolelle (GDPR, V luku (opens in a new tab)). Mutta tämä yritys päättää yhdessä tietosuoja- ja lakitiimiensä kanssa, että sen eurooppalaisten asiakkaiden henkilötietojen pitäisi asua Euroopassa isännöidyssä orgissa, jota pyörittää sen eurooppalainen tiimi ja jota hallitaan sen eurooppalaisen hallintamallin mukaan. Se on todellinen vaatimus, ja se on heidän, ei minun.

Nyt ”yksi iso globaali org” ei ole enää mieltymys. Järjestelmäkartassa on raja, Salesforce AMER ja Salesforce EMEA, ja minun täytyy piirtää se. Eikä toinen org ole koskaan vain yksi laatikko lisää.

Click to enlarge

Kaksi orgia, AMER ja EMEA. Meripihka on se, mitä toinen org tuo mukanaan: ei yksi laatikko lisää, vaan jokainen nuoli uudelleen.

Kävele nuolet uudelleen läpi

Kun orgeja on useampi kuin yksi, kävele järjestelmäkartta uudelleen läpi. Lähettääkö ERP tuotteet jokaiseen orgiin? Lähettääkö kukin tilaukset takaisin? Missä asiakkaiden perustietoja hallitaan, ja saavatko heidän tietonsa ylittää alueiden rajoja? Onko integraatiokerros globaali vai alueellinen? Mikä identiteetinhallinnan palvelu kirjaa sisään mitkä käyttäjät? Minne analyyttiset tiedot menevät?

Kolme paikkaa näyttää hinnan nopeimmin:

Raportointi. Toimitusjohtaja haluaa globaalin myyntiputken. Yhdessä orgissa se on Salesforce-raportti. Kolmessa se on yrityksen raportointiongelma: replikoidaanko, lähetetäänkö tietovarastoon, federoidaanko? Kuinka ajantasainen sen täytyy olla, ja määrittelevätkö orgit edes ”myyntiputken” samalla tavalla? Analytiikan paikka seuraa tietojen paikkaa, ja jos jaat operatiiviset tiedot tarkoituksella, sinun täytyy suunnitella, miten näkemys kootaan taas yhteen.

Perustiedot. Globaali asiakas ostaa Yhdysvalloissa, Saksassa ja Japanissa. Kolme orgia, joten luultavasti kolme tiliä. Mistä tiedät, että ne ovat sama yritys? Mikä on globaali tunniste, ja kuka sen omistaa? Jos yksi alue muuttaa osoitetta, pitäisikö muutoksen levitä? Mitkä attribuutit ovat globaaleja ja mitkä alueellisia? Org-strategia ei ratkaise identiteettiä; se muuttaa identiteettiongelmaa. Se on luku 6.

Integraatio. Yksi org: Salesforce, integraatiokerros, ERP. Kolme orgia: kolme yhteyttä integraatiokerrokseen, ehkä yksi niistä omalla isännällään ja yhteyksillään, osa virroista jaettuja, osa alueellisia, osa tiedoista saa ylittää rajan ja osa ei. Jopa verkko voi muuttua: jos yritys tarvitsee oman yksityisen yhteyden Hyperforceen (AWS:ssä Salesforce suosittelee AWS Direct Connectia; sama Hyperforce-FAQ), jokainen piirroksen org ja isäntä on yksi suunniteltava yhteys lisää. Se, missä org toimii, voi muuttaa sitä, miten muu yritys tavoittaa sen.

Yksi org vai monta on päätös, jonka teet nyt, alussa, järjestelmäkartassa. Se, miten orgit sitten jakavat tietoja (orgien välinen Salesforce Connect, integraatio niiden välillä, Data 360), on mekaniikkaa, ja luku 14, Yksi org vai monta? (coming soon), käsittelee sen.

Jos suunnittelet koko tietomallin ja integraatioarkkitehtuurin ja kuulet vasta sitten ”muuten, tämän pitää olla kolme orgia”, et ole tehnyt pientä säätöä. Olet muuttanut arkkitehtuuria. Siksi päätös tehdään ensin.

Älä jaa vain tehdäksesi laatikoista pienempiä

Iso org tuntuu monimutkaiselta: paljon yksiköitä, objekteja, käyttäjiä, integraatioita. Joku sanoo: ”Eikö olisi siistimpää, jos jokaisella olisi oma orginsa?” Piirroksesta voi tulla siistimpi. Yrityksestä ei välttämättä. Olet vaihtanut sisäisen monimutkaisuuden hajautettuun monimutkaisuuteen: synkronointi, päällekkäiset tiedot, orgien välinen identiteetti, globaali raportointi, useat julkaisuputket, monistetut integraatiot ja automaatiot sekä niiden kaikkien hallinta. Joskus se on silti oikea vaihtokauppa. Mutta erillinen ei ole sama kuin yksinkertainen.

Eikä yksi orgkaan ole ilmainen. Yhteinen hallinta korostuu, tiimit voivat vaikuttaa toisiinsa, suojausrajat vaativat huolellista suunnittelua, tietomallin täytyy palvella monia ryhmiä, julkaisut vaativat koordinointia, ja alueelliset säännöt voivat rajoittaa kaikkia. Kyse ei siis ole siitä, että ”Steve sanoo aina yksi org”. Lähtöoletukseni on yksi org; sitten etsin vaatimusta, joka on tarpeeksi vahva siirtämään minut siitä pois.

Tee päätös näkyväksi

Jos org-strategialla on merkitystä, älä piirrä geneeristä Salesforce-pilveä. Piirrä orgit ja nimeä ne (AMER, EMEA, mitä ne todellisuudessa ovatkin), merkitse kunkin taustalla oleva isännöinti- tai sijaintivaatimus ja kävele yhteydet läpi. Toisen arkkitehdin pitäisi nähdä, miksi kukin raja on olemassa. Jos en osaa selittää, miksi Salesforce-laatikoita on kolme, en ole saanut päätöstä valmiiksi.

Steve Truckingilla on yksi org Yhdysvalloissa, eikä mikään sen taustakuvauksessa vaadi toista. Mutta pidä tämä moduuli mielessä päättötyötä varten: yritysosto, jolla on oma orginsa, on juuri sellainen raja, joka koettelee näitä kysymyksiä.

Kokeen jälkeen: mitä tekoäly muuttaa. Agentti voi tehdä orgin rajasta käyttäjälle näkymättömän. Pinnan alla arkkitehtuurin täytyy silti päättää, mitä orgia tai järjestelmää agentti saa kysyä, mitkä tiedot saavat ylittää alueiden rajat ja mikä vastaus on auktoritatiivinen. Tekoäly voi piilottaa monimutkaisuuden käyttökokemuksesta; se ei poista hallintaa eikä rajaa.

Mitä arkkitehti tässä päättää

• Onko useammalle kuin yhdelle orgille aito arkkitehtuurinen syy, sen sijaan että erot ratkaistaisiin yhden orgin sisällä.
• Missä kukin org toimii, ja mikä tietojen sijaintiin, sääntelyyn, sopimukseen tai liiketoimintaan liittyvä vaatimus sijoittaa sen sinne.
• Mitkä tiedot saavat ylittää orgien ja alueiden rajat, missä perustiedot ovat auktoritatiivisia ja miten globaali identiteetti toimii.
• Miten integraatio, identiteetti, analytiikka ja raportointi muuttuvat, kun yhdestä Salesforce-laatikosta tulee useita.
• Onko erottamisen hyöty sen luoman hajautetun arkkitehtuurin arvoinen.

Kun luen skenaariota, etsin ensin tätä päätöstä: yksi org vai monta, isännöity missä ja minkä pakottamana? Vastaa niihin, niin muu järjestelmäkartta alkaa muotoutua.

Lue lisää

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), V luku (henkilötietojen siirrot kolmansiin maihin) (englanniksi, tarkistettu 2026-10-14).