Hierarkiat ja kaksisuuntaiset tiedot

🌐 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 Perustiedot ja identiteetti, Data Architect -kurssin luku 6. Jokainen moduuli on itsenäinen. Edellinen: Kartta ei ole päätös · Seuraava: Tarkistuspiste 1: Steve Trucking

Kysymys, johon tämä moduuli vastaa: Miten hallitset tietoja, joita ylläpitää useampi kuin yksi järjestelmä?

Helppo arkkitehtuuri: ERP omistaa asiakkaan, Salesforce saa kopion, valmis. Todelliset yritykset eivät ole niin siistejä. ERP omistaa virallisen asiakkaan ja Salesforce myyntisuhteen; yksi divisioona elää SAP:ssa, ostettu toisessa ERP:ssä; prospektit ovat olemassa vain Salesforcessa. Sitten joku haluaa Salesforcen käyttäjien päivittävän ERP:n hallitsemaa kenttää, ja nuolet alkavat osoittaa molempiin suuntiin. Kuten sanon tätä opettaessani: ”Vaikeimpia ovat kaksisuuntaiset.” Ei siksi, että tietojen lähettäminen molempiin suuntiin olisi teknisesti vaikeaa, vaan siksi, että kun molemmat järjestelmät osallistuvat muutokseen, auktoriteetin suhteen on oltava äärimmäisen tarkka.

Kaksisuuntaiset tiedot eivät tarkoita kahta masteria

ERP omistaa laskutusosoitteen, joka kopioidaan Salesforceen. Myyjä kuulee asiakkaalta, että se on muuttunut, ja liiketoiminta haluaa hänen päivittävän sen poistumatta Salesforcesta. Järkevää. Nyt tiedot virtaavat ERP → Salesforce ja Salesforce → ERP. Omistaako Salesforce nyt laskutusosoitteen yhdessä ERP:n kanssa? Ei. Integraation suunta ei ratkaise auktoriteettia. Myyjä ei muuta Salesforcen kopiota. Arkkitehtuurisesti hän pyytää muuttamaan auktoritatiivista arvoa. Et muuta ERP:n kenttää; pyydät muuttamaan sitä. Salesforce on käyttöliittymä; ERP on yhä master.

Se muuttaa suunnittelua. Jos Salesforce omistaisi kentän, tallenna ja valmis. Jos ERP omistaa sen, ”tallenna” tarkoittaa, että Salesforce lähettää ehdotetun osoitteen, ERP vahvistaa ja hyväksyy sen, päivittää masterinsa ja lähettää auktoritatiivisen arvon takaisin. Vasta silloin hallittu arvo on muuttunut: pyyntö → vahvistus → hyväksyntä → julkaisu, ei ”päivitetään molemmat järjestelmät ja toivotaan, että ne pysyvät synkronissa”.

Click to enlarge

Kaksisuuntainen integraatio ei luo kaksisuuntaista auktoriteettia.

Kun master sanoo ei

ERP hylkää muutoksen: asiakas on passiivinen, osoite rikkoo ERP:n sääntöä, käyttäjä ei saa muuttaa virallisia osoitteita, ERP on alhaalla tai joku muu muutti asiakasta sillä välin. Jos Salesforce näytti jo uuden osoitteen, meillä on nyt kaksi totuutta, ja moduuli 1 kertoi jo, kumpi voittaa: ERP:n. Siksi arkkitehtuuri tarvitsee tilan pyydetty, ei vielä hyväksytty: erillisen ehdotetun arvon, ”odottava muutos” -lipun tai vahvistuksen odottamisen ennen näyttämistä. Mekanismi riippuu käyttötapauksesta. Sääntö ei: älä koskaan anna hylätyn pyynnön muuttua kilpailevaksi totuudeksi.

Silmukat ja törmäykset

Tässä klassikko. ERP päivittää Salesforcea; Salesforcen integraatio näkee muutoksen ja lähettää sen ERP:hen; ERP näkee päivityksen ja lähettää sen takaisin. Olet rakentanut hyvin kalliin silmukan. Hyvä kaksisuuntainen suunnittelu tietää, mistä muutos alkoi, onko master hyväksynyt sen ja onko kyseessä uusi liiketoiminnan muutos vai vain kaiku jo käsitellystä: lähdetunnisteet, aikaleimat, integraation metatiedot, idempotentti käsittely. Integraatioluku menee syvälle. Perustietojen periaate on yksinkertainen: tiedä, oletko aloittamassa muutosta vai heijastamassa sitä.

Sitten törmäykset. Tapasit yhden luvussa 5: myyjä pyytää nimeä Steve’s Plumbing LLC, kun joku kirjoittaa ERP:hen Steve’s Plumbing L.L.C. (Suojaa hallittu tietue). Tässä toinen. Salesforce ehdottaa osoitetta Pääkatu 125; lähes samalla hetkellä ERP:n käyttäjä muuttaa sen numeroon 130. Kumpi voittaa? Yleispätevää teknistä vastausta ei ole. Ehkä ERP voittaa aina, koska se omistaa kentän; ehkä Salesforcen pyyntö menee tarkistusjonoon; ehkä myöhemmin hyväksytty muutos voittaa; ehkä ERP hylkää jokaisen päivityksen, jonka lähtöarvo on muuttunut. Se on rinnakkaisuutta, mutta sen alla on auktoriteettipäätös, eikä mikään integraatiomalli pelasta sinua, jos kukaan ei päättänyt, kuka saa tehdä auktoritatiivisen muutoksen.

Ja yksittäinen kenttä on helppo tapaus. Osoite on katu, kaupunki ja postinumero. Salesforce lähettää uuden kadun, kun ERP on juuri muuttanut kaupungin. Päästätkö kadun läpi yksinään? Vai käsitteletkö osoitetta yhtenä transaktiona, jolloin kentät menevät kaikki yhdessä tai ei mikään niistä, ja hylkäät koko muutoksen? Päätä ennen ensimmäistä törmäystä, mitkä kentät kulkevat ryhmänä, älä sen jälkeen.

Aina kun näen kaksisuuntaisen integraation, kysyn: mitä tapahtuu, kun molemmat puolet muuttavat samoja tietoja? Jos vastaus on ”niin tuskin käy”, emme ole valmiita. Kumpi voittaa, hylkäämmekö, jonotammeko, vertaammeko versioita, tarkistammeko? Pitäisikö kentän ylipäätään olla muokattavissa molemmissa paikoissa? Joskus paras kaksisuuntainen suunnitelma poistaa yhden suunnan tietyltä attribuutilta: Salesforce saa pyytää; vain ERP julkaisee hyväksytyn arvon. Tiedot liikkuvat yhä molempiin suuntiin, mutta vain yksi järjestelmä hallitsee kenttää. Se ero on kaikki kaikessa.

Hierarkiatkin ovat perustietoja

Myös suhteet voivat olla perustietoja. Globaali emoyhtiö, jolla on Pohjois-Amerikan ja Euroopan alueet, ja kullakin maakohtaiset tytäryhtiöt: hierarkia itsessään kantaa merkitystä. Kuka on emo? Mikä tytäryhtiö kuuluu minkäkin oikeushenkilön alle? Mitkä tilit kootaan globaalin asiakkaan alle? Se ohjaa raportointia, myyntialueita, hinnoittelua, sopimuksia, luottoriskiä, palvelua, tietojen käyttöoikeuksia ja analytiikkaa. Hierarkia voi olla yhtä tärkeä kuin sen sisältämät tietueet, ja se tarvitsee saman hallinnan. (Koe mainitsee hierarkioiden hallinnan; se unohtuu helposti.)

Salesforcessa tilihierarkiat rakennetaan Parent Account -kentällä (päätili). Lightningin hierarkianäkymä näyttää enintään 2 000 tiliä, ja vain ne, jotka käyttäjä saa nähdä; henkilötilejä ei tueta hierarkiassa; ja Account Site (tilin toimipaikka) erottaa yrityksen sijainnit toisistaan (Considerations for Using Account Hierarchy (opens in a new tab)). Mutta Parent Account -kenttä ei vastaa arkkitehtuurikysymykseen: kuka omistaa hierarkian?

Koetieto. Tunne tilihierarkian perusteet: se rakennetaan Parent Account -kentällä; Lightning-näkymä näyttää enintään 2 000 tiliä, vain ne, jotka käyttäjä näkee; henkilötilejä ei tueta; ja Account Site erottaa yrityksen sijainnit toisistaan.

Yksi hierarkia, useita mastereita

Kokemukseni mukaan hierarkioilla on jaettu hallinta. Pohjois-Amerikan yksiköt tulevat SAP:sta, Euroopan yksiköt toisesta ERP:stä, uudet prospektit rakennetaan Salesforcessa, eikä ostettua tytäryhtiötä ole vielä migroitu. Kuka omistaa hierarkian? Se riippuu haarasta. Kukin ERP hallitsee omaa haaraansa; Salesforce hallitsee prospektien suhteita, kunnes ne konvertoidaan. Se on oikeutettu arkkitehtuuri, kunhan kaikki tietävät, missä rajat kulkevat. Päätä haara kerrallaan.

Click to enlarge

Hierarkian auktoriteetin voi määrätä haara kerrallaan.

Älä siis anna Parent Account -kentän kätkeä auktoriteettia. Käyttäjä vaihtaa tytäryhtiön emoa Salesforcessa. Teknisesti triviaalia. Arkkitehtuurisesti: muuttiko hän juuri yrityksen juridista rakennetta? Jos ERP hallitsee sitä haaraa, tuskin, joten Salesforcen pitäisi estää se tai muuttaa se muutospyynnöksi. Tai ehkä Salesforce ylläpitää oikeutetusti kaupallista hierarkiaa, kun taas ERP ylläpitää juridista. Silloin niiden ei ehkä pitäisi olla sama suhde lainkaan.

Yrityksellä voi olla useita päteviä hierarkioita: juridinen, laskutus, myynti, palvelu, maantieteellinen. Globaali emo allekirjoittaa sopimuksen, alueet saavat palvelua itsenäisesti, laskutus kulkee yhteisen talousyksikön kautta, myynti johtaa alueittain. Mikä on oikea hierarkia? Kaikki; ne vastaavat eri kysymyksiin. Virhe on olettaa, että niitä täytyy olla yksi. Jokaisella suhteen lajilla pitäisi olla selvä auktoriteetti: moduulin 1 attribuuttiperiaate sovellettuna suhteisiin.

Eikä jokainen vanhempi–lapsi-suhde ole perustietoa. Päivän toimitusten ryhmittely yhdelle reitille on suhde, mutta se on tapahtumatietoa, operatiivinen tapahtuma. Asiakashierarkia kuvaa pysyvää liiketoimintasuhdetta. Molemmat näyttävät mallissa vanhempi–lapsi-suhteelta; niillä ei ole yhteistä elinkaarta. Kysy, mitä suhde tarkoittaa ja kuinka kauan se merkitys kestää.

Yksi asiakas, kaksi ERP:tä

Kun opetan tätä, kysyn salilta: kuka on työskennellyt asiakkaan kanssa, jolla on yksi Salesforce ja useampi kuin yksi ERP? Käsiä nousee joka kerta. Kysy miksi, ja käy ilmi, että ERP:t on jaettu alueittain (yksi Pohjois-Amerikalle, yksi Euroopalle), toiminnoittain (putkiliike ostaa sähköliikkeen, ja kumpikin pitää oman ERP:nsä) tai vain historiallisista syistä: liiketoiminta ostettiin, eikä kukaan ole vielä migroinut sitä.

Otetaan asiakkaaksi Steve’s Plumbing. Se tekee liiketoimintaa Pohjois-Amerikassa, joten Pohjois-Amerikan ERP:ssä on sille asiakastietue. Sitten se avaa toimiston Müncheniin, ja Euroopan ERP luo sille oman asiakastietueensa omalla asiakasnumerollaan. Sama yritys, kaksi tietuetta, kaksi ID:tä. Miten esitän sen yhdessä Salesforce-orgissa? Olen nähnyt kolme tapaa.

Tilihierarkia. Steve’s Plumbing on emo, ja Steve’s Plumbing North America ja Steve’s Plumbing Europe ovat lapsitilejä, kukin lapsi edustaa yhden ERP:n tietuetta. Koukku: lapset eivät oikeastaan enää ole Steve’s Plumbing. Ne ovat Steve’s Plumbing tekemässä liiketoimintaa jollakin alueella, ja kuten juuri näimme, hierarkia kantaa merkitystä.

Vertaistilit. Kaksi tiliä rinnakkain, kummassakin kenttä, joka kertoo, mihin ERP:hen se kuuluu: yrityskoodi, alue. Mitään ei ole piilotettu. Hinta näkyy raportoinnissa: nähdäksesi Steve’s Plumbingin koko maailmassa tarvitset jotain, joka kertoo, että nämä kaksi tiliä ovat sama yritys.

Yksi tili, jolla on lapsi kutakin ERP:tä kohden. Yksi Steve’s Plumbing ja lapsiobjekti, jossa on tietue kutakin ERP:tä kohden ja siinä sen ERP:n asiakas-ID. Kaksi ERP:tä tai kymmenen. Myyjät näkevät yhden asiakkaan ja tekevät yhden tilauksen; kulissien takana flow’t päättävät, mihin ERP:hen kukin rivi menee: sähkötyöt sähköpuolen ERP:hen, putkityöt putkipuolen ERP:hen. Mutta nyt sinun on päätettävä, mikä ERP on ensisijainen yhteisten arvojen, kuten nimen ja osoitteen, osalta, ja mitä tapahtuu, kun asiakas on olemassa yhdessä ERP:ssä mutta ei toisessa.

Click to enlarge

Yksi asiakas, kaksi ERP:tä: kolme tapaa esittää se Salesforcessa.

Kysy, miten ERP:t pidetään synkronissa

Joten mikä niistä? Ensin: kuinka paljon ERP-rakenteesta myyjien pitäisi nähdä? Jos he ovat aina tienneet, että Pohjois-Amerikka ja Eurooppa ovat erillisiä liiketoimintoja, koska he kirjautuvat jompaankumpaan ERP:hen, älä piilota sitä heiltä. Vie se rakenne Salesforceen vertaistileinä. Jos liiketoiminta haluaa myynnin eteen yhden Steve’s Plumbingin, kyseessä on yksi tili, jolla on lapsi kutakin ERP:tä kohden.

Sitten kysymys, joka oikeasti ratkaisee asian, eikä sitä ratkaista Salesforcessa. Kysyn asiakkaalta: miten pidätte nuo kaksi tietuetta synkronissa ERP-järjestelmienne välillä? En tarkoita asioita, jotka ovat paikallisia kullekin ERP:lle, kuten saldoa; se on tapahtumatietoa. Tarkoitan perustietoja: virallista nimeä, osoitteita. Jos heillä on tiimi, joka pitää kaksi ERP:tä synkronissa, voimme tuoda ne yhteen yhdeksi tiliksi. Jos he eivät pysty pitämään niitä synkronissa omissa ERP-järjestelmissään, miten he voivat odottaa meidän pitävän ne synkronissa Salesforcessa? Silloin ratkaisu on vertaistilit tai hierarkia.

Muista, mikä ERP on. Ne ovat valtavia järjestelmiä, joiden käyttöönotto kestää vuosia, ja niillä on oma tapansa hallita perustietoja. Salesforce ei tule ohjaamaan niitä. Me emme pääse hallitsemaan ERP-järjestelmiä. Me pääsemme hallitsemaan sitä, miten esitämme ne Salesforcessa.

MDM keskellä

Jotkut asiakkaat ovat ratkaisseet tämän jo ennen kuin tulemme paikalle. Suuri yritys, monta vuotta liiketoimintaa, useita ERP:tä: he törmäsivät tähän ongelmaan kauan ennen Salesforcea ja laittoivat keskelle erillisen MDM-tuotteen välittämään ERP-järjestelmien välillä. Se on moduulin 2 rinnakkaiselo tai keskitetty MDM. Nyt Salesforce ei kytkeydy jokaiseen ERP:hen. Se osoittaa yhteen paikkaan, MDM-keskukseen, ja saa asiakkaasta yhden esityksen. Älä kuitenkaan odota kohtaavasi sellaista usein. Ne ovat itsessään isoja toteutuksia; kaikkina vuosinani olen työskennellyt sellaisen kanssa vain kaksi tai kolme kertaa. Ja keskuksenkin kanssa saatat yhä tarvita sitä lapsiobjektia, jotta jokainen tilaus tietää, mihin ERP:hen se on menossa.

Click to enlarge

MDM keskellä: Salesforce osoittaa yhteen paikkaan.

Steve Trucking: kenen hierarkia?

Vähittäiskauppakumppanilla on oma rakenteensa: konsernin emoyhtiö, alueelliset divisioonat, jakelukeskukset, myymälät. Omistaako Steve Trucking sen hierarkian? Ei; kumppani on oman organisaationsa auktoriteetti. Mutta Steve Trucking voi tarvita oman kaupallisen näkymänsä samoihin sijainteihin sopimuksia, asiakkuudenhallintaa, palvelua ja raportointia varten, ehkä lapsitilin kullekin jakelukeskukselle kumppanin alle. Kaksi oikeutettua hierarkiaa, kaksi auktoriteettia. Nimeä ne, äläkä teeskentele, että yksi puu edustaa jokaista suhdetta.

Tee rajat näkyviksi

Aina kun auktoriteetti on jaettu, haluan rajan näkyviin: kenttien nimeäminen, tietueiden metatiedot, lähdejärjestelmien tunnisteet, käyttöoikeudet, integraatioiden käyttäytyminen, dokumentaatio. En halua kehittäjän lukevan viittä integraatiota löytääkseen, että ”nämä Parent Account -arvot tulevat SAP:sta, paitsi prospektit, paitsi Eurooppa”. Se ei ole ylläpidettävä auktoriteettimalli. Jos hierarkialla on jaettu hallinta, dokumentoi jako. Jos auktoriteetti muuttuu konversiossa, dokumentoi muutos. Jos Salesforce voi pyytää muutosta mutta ei tehdä sitä, tee se ilmeiseksi käyttökokemuksessa.

Salesforcessa se alkaa yhdestä kentästä. Tarvitaan kenttä, joka kertoo selvästi, että tämä on perustietoa: ERP:n avain tai ”on perustietoa” -lippu. Ohjaa kenttien muokattavuutta sillä kentällä, ei tietuetyypillä; Dynamic Formsin ansiosta et enää tarvitse tietuetyyppiä näyttääksesi ERP:n kentät vain luku -tilassa (luku 5, Oma tietuetyyppi kullekin virralle). Voit sallia tietueiden luomisen masterin ulkopuolella, mutta pidä silmällä muokkauksia.

Kokeen jälkeen: mitä tekoäly muuttaa. Asiakas sanoo agentille: ”vaihda laskutusosoitteemme osoitteeseen Pääkatu 125.” Kenttä on Salesforcessa ihan siinä. Pitäisikö agentin päivittää se? Ei, jos ERP omistaa sen. Agentti tarvitsee kirjoitusauktoriteetin, ei pelkkää pääsyä kenttään: sen toiminnon pitäisi koodata hyväksytty polku, lähettää muutospyyntö ja sanoa ”olen lähettänyt muutoksen käsiteltäväksi”, eikä väittää virheellisesti ”olen päivittänyt laskutusosoitteesi”.

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

• Muuttaako Salesforcessa tehty muokkaus auktoritatiivisia tietoja vai pyytääkö se muutosta järjestelmältä, joka omistaa ne.
• Miten kaksisuuntaiset virrat erottavat alkuperäiset muutokset kaiuista ja käsittelevät hylkäykset, törmäykset, viiveen ja virheet.
• Kuka omistaa kunkin hierarkian, tarvittaessa haara kerrallaan.
• Useassa ERP:ssä olevalle asiakkaalle: hierarkia, vertaistilit vai yksi tili, jolla on lapsi kutakin ERP:tä kohden, sen mukaan, kuinka hyvin asiakas pitää ERP-järjestelmänsä synkronissa.
• Ovatko kilpailevat hierarkiat oikeasti eri oikeutettuja suhteita: juridinen, laskutus, myynti, palvelu.
• Miten auktoriteetin rajat ja hyväksytyt kirjoituspolut tehdään näkyviksi käyttäjille, integraatioille, kehittäjille ja agenteille.

Jaettu auktoriteetti ei ole ongelma. Epäselvä auktoriteetti on. Useat ERP:t voivat hallita eri haaroja, Salesforce voi hallita joitakin attribuutteja ja pyytää muutoksia toisiin, ja useat hierarkiat voivat kuvata yhtä yritystä. Kaikki se toimii, kunhan osaat kunkin tärkeän attribuutin ja suhteen kohdalla sanoa, kuka sen omistaa, kuka saa muuttaa sitä, missä auktoritatiivinen muutos tehdään ja mitä tapahtuu, kun järjestelmät ovat eri mieltä. Jos et osaa, uusi kaksisuuntainen nuoli kaaviossa ei korjaa sitä.

Lue lisää

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).