Huonojen tietojen pitäminen ulkona

🌐 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 2/6 luvussa Tietojen laatu ja hallinta, Data Architect -kurssin luku 5. Jokainen moduuli on itsenäinen. Edellinen: Hallinta suunnitellaan orgiin · Seuraava: Tunne tietosi

Kysymys, johon tämä moduuli vastaa: Miten tiedot pidetään hyvinä, ja miten ne pysyvät sellaisina?

Huonoja tietoja voi käsitellä kahdella tavalla: pysäyttää ne ennen kuin ne pääsevät sisään tai siivota ne jälkikäteen. Teet kumpaakin. Mutta jos saan valita, estän mieluummin ongelman kuin rakennan organisaation siivoamaan sitä ikuisesti. Kaksoiskappaleet, virheelliset tunnisteet, puuttuvat tiedot, epästandardit arvot, käyttäjät, jotka muuttavat toisen järjestelmän omistamia kenttiä, integraatiot, jotka ylikirjoittavat hyviä tietoja huonoilla: kaikesta tulee jonkun siivousprojekti. Suunnittelukysymys on siis: mitkä huonot tiedot voin kohtuudella pitää ulkona alun perinkin? Ja ”kohtuudella” on tärkeä sana, koska vastaus ei ole lukita jokaista kenttää, kunnes järjestelmä on käyttökelvoton.

”Riittävän hyvä” on liiketoiminnan määritelmä

Ennen kuin estät huonoja tietoja, määrittele hyvä. Yhtä määritelmää ei ole. Hyvä voi tarkoittaa riittävän täydellistä prosessin pyörittämiseen, riittävän tarkkaa päätöksentekoon, riittävän ajantasaista kuormitukselle, riittävän johdonmukaista muiden järjestelmien kanssa yhdistettäväksi, riittävän yksilöllistä, jotta tiedämme, mitä asiakasta tarkoitamme, riittävän standardia automaatiolle, riittävän jäljitettävää, jotta tiedämme, mistä se tuli. Se riippuu tiedoista. Jos Steve Trucking laskuttaa vähittäiskauppakumppania (Retail Partner), kumppanin juridisen identiteetin on oltava oikein. Jos myyjä kirjoittaa muistiinpanoja tapaamisen jälkeen, kukaan ei tarvitse komiteaa hyväksymään jokaista lausetta. ”Riittävän hyvä” on liiketoiminnan määritelmä; arkkitehti tekee siitä mitattavan ja täytäntöönpantavan.

Estä kalliit virheet

Jokainen huono kenttä ei ansaitse samaa huomiota. Välitän eniten virheistä, joilla on seurauksia alavirtaan. Kaksoiskappaleena oleva asiakas tarkoittaa kahta myyntihistoriaa, kahta palveluhistoriaa, kahta yhteyshenkilöjoukkoa, kahta ulkoista tunnistetta, kahta integraatiota synkronoimassa samaa yritystä, kahta versiota tietovarastossa ja Data 360:ssa, ja lopulta agenttia päättämässä, kumpi asiakas on oikea. Se on paljon kalliimpaa kuin kirjoitusvirhe kuvauksessa. Älä siis aloita kysymyksestä ”miten validoimme jokaisen kentän?” Aloita kysymyksestä mitkä huonot tiedot aiheuttavat suurimman liiketoiminnallisen tai arkkitehtuurisen ongelman? ja laita vahvimmat kontrollit sinne.

Avoin vai lukittu?

Tilien luominen on klassinen esimerkki. Pitäisikö jokaisen myyjän voida luoda tili? Vastaukseni: se riippuu tietoja ympäröivästä hallinnasta. Useimmille pienille ja keskisuurille orgeille avoin luonti sopii. Myyjä tapaa prospektin, luo tilin ja ryhtyy töihin; sitä varten CRM on olemassa. Kaksoiskappalesäännöt, pakolliset tiedot ja vastuuhenkilöiden työ hoitavat laadun. En lisää raskasta hyväksyntäprosessia vain siksi, että hallinta kuulostaa vastuulliselta.

Muutetaan nyt järjestelmäkarttaa. Asiakkaan juridiset perustiedot hallitaan ERP:ssä, ne virtaavat Salesforceen ERP-tunnisteen kanssa, ja ERP on auktoritatiivinen. Nyt avoin luonti tarkoittaa kahta tapaa luoda sama hallittu kokonaisuus. Kun ERP ja myyjä luovat kumpikin saman yrityksen, kumpi voittaa, mitä tunnistetta integraatiot käyttävät, kummassa tietueessa historia on? Avoin luonti lakkaa olemasta käytettävyyskysymys ja muuttuu perustietokysymykseksi. Kun tilit hallitaan ERP:ssä tai synkronoidaan sen kanssa, lukitse luonti.

Mutta täydellinen lukitseminenkin epäonnistuu. Myyjä on tavannut prospektin, jota ei ole ERP:ssä, ja haluaa avata myyntimahdollisuuden, ja hallintamalli sanoo: ”ei tiliä sinulle”. Niinpä hän odottaa kolme päivää taloushallintoa, liittää myyntimahdollisuuden väärään tiliin tai pitää prospektin muistiinpanokentässä tai taulukossa. Suojelimme tietomallia ja vahingoitimme liiketoimintaa.

Keskitie: väliaikainen tietuetyyppi

Tässä on keskitie, josta pidän. Anna myynnin luoda tili tietyllä tietuetyypillä, prospekti- tai väliaikaisella tyypillä, ja hallitse sen muuntamista hallituksi tyypiksi. Myynti tallentaa yrityksen ja alkaa myydä. Tietue kertoo suoraan: ei vielä vahvistettu auktoritatiivisessa järjestelmässä. Sitten hallittu prosessi muuntaa sen: taloushallinto hyväksyy sen, tai integraatio lähettää sen ERP:hen, joka joko täsmää sen olemassa olevaan asiakkaaseen tai luo uuden ja lähettää takaisin auktoritatiivisen tunnisteen. Nyt tietue ylittää rajan, väliaikainen → hallittu, mikä on aivan eri asia kuin se, että kaksi järjestelmää luo kumpikin omasta mielestään perustietueen.

Tietuetyyppi on mekanismi, jota opetan. Mitä ikinä käytätkin, tee tila näkyväksi tiedoissa: mistä tietue tuli, onko se ylittänyt rajan, kuka saa nyt muuttaa sitä ja mikä tunniste sitoo sen auktoritatiiviseen järjestelmään. ERP:n asiakastunnus, joka syntyy vasta muuntamisen jälkeen, on kaikkein selvin merkki.

Oma tietuetyyppi kullekin virralle

Laita koko virta yhteen kuvaan, niin näet, miksi tämä toimii. Asiakkaat ja tuotteet tulevat sisään ERP:stä. Myyntimahdollisuudet ja niiden rivit menevät ulos ja muuttuvat ERP:n tilauksiksi. Entä tilit? Osa tulee sisään, osa menee ulos. Niinpä yleinen malli, jonka olen nähnyt toteutuksesta toiseen, on kaksi tietuetyyppiä tilillä (Account), yksi kumpaankin suuntaan. Sales-tili syntyy Salesforcessa: myyjät luovat sen, muokkaavat sitä, myyvät sille, ja kun siitä tulee asiakas, se lähetetään ERP:hen. ERP-tili (olen kutsunut sitä nimellä Customer tai vain SAP) syntyy ERP:ssä ja tulee sisään integraation kautta. Kukaan muu kuin integraatio ei luo sen tietuetyypin tietueita, ja sen perustietokentät (virallinen nimi, osoitteet, maksuehdot) ovat käyttäjille vain luku -tilassa. Tietuetyyppi kertoo, mihin suuntaan tietue virtaa, joten perustietojen hallinnan suunta näkyy suoraan tietueessa.

Click to enlarge

Oma tietuetyyppi kullekin virralle: Sales-tilit menevät ulos, ERP-tilit tulevat sisään.

Se ei poista vaikeaa tapausta. Myyjä muuntaa liidin yritykselle Steve’s Plumbing, mutta Steve’s Plumbing on jo olemassa ERP-tilinä, eikä kaksoiskappaletarkistus jostain syystä huomannut sitä. Nyt yhdistät tietueita, siirrät lapsitietueet uudelle vanhemmalle ja päätät, kumpi tietue säilyy (luku 6, moduuli 3).

Äläkä jumitu itse tietuetyyppiin. Yleensä vältän tietuetyyppejä, ellei niille ole vahvoja perusteita. Käytin niitä tässä, koska ennen Dynamic Formsia tietuetyyppi valitsi sivun asettelun, ja yksi asettelu näytti ERP-kentät vain luku -tilassa. Dynamic Formsissa näkyvyyssäännöt voivat näyttää ja piilottaa kenttiä kentän arvon perusteella, kenttä voi olla vain luku -tilassa tietyllä sivulla, ja Salesforce itse sanoo, että Dynamic Forms vähentää tarvittavien sivuasettelujen ja tietuetyyppien määrää (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). Mutta vain luku sivulla on vain luku sillä sivulla: API, tietojen lataus tai integraatio voi yhä kirjoittaa kenttään. Todellinen täytäntöönpano on kenttätason suojaus tai vahvistussääntö; käyttöliittymän validointi ei ole tietojen validointia (luku 3, moduuli 9). Tietuetyypit ansaitsevat yhä paikkansa, kun kaksi tililajia tarvitsee eri valintaluettelon arvot tai liiketoimintaprosessit. Tärkeää on, että jokin kenttä kertoo selvästi, mistä tietue tuli: itse ERP-avain, perustietolippu tai lähteen valintaluettelo. Ohjaa sitten muokattavuutta sillä kentällä.

Click to enlarge

Väliaikaisesta hallituksi: myynti alkaa myydä heti; vain auktoritatiivinen prosessi tekee tietueesta hallitun.

Suojaa hallittu tietue

Kun asiakas palaa ERP:stä, sen ERP-tunnus, virallinen nimi, verotunniste ja laskutustiedot ovat hallittuja attribuutteja. Pitäisikö myyjän muuttaa niitä? Ei, jos ERP omistaa ne. Se on moduulin 1 käytäntö, joka tarvitsee täytäntöönpanokohtansa: ERP-tunnus vain luku -tilassa, juridinen identiteetti hallittu, ja silti myyjä muokkaa yhä myyntialuetta, suhdemuistiinpanoja ja Salesforcen omia luokitteluja. Tavoite ei ole koskematon tili. Tavoite on selvä raja tietojen, jotka Salesforce omistaa, ja tietojen, joihin Salesforce viittaa, välillä. (Luvun 4 erp_-etuliite tekee rajan näkyväksi skeemassa.)

Lopputuloksena on golden record, joka on oikeastaan hybridi. ERP:n perustietokentät tulevat sisään: virallinen nimi, laskutus- ja toimitusosoitteet, maksuehdot. Sitten Salesforce lisää omat kenttänsä, jotka eivät koskaan palaa takaisin: myyntiluokitus, viimeisimmän tilauksen päivämäärä, käytännössä kaikki, mitä markkinointi käyttää. Sama tili, kahdenlaisia kenttiä, ja kummallakin lajilla on yksi lähde.

Vaikeimpia ovat kaksisuuntaiset virrat. Sanotaan, että myyjä tarvitsee ERP:n virallisen nimen muutoksen Steve’s Plumbingista muotoon Steve’s Plumbing LLC. Samojen viiden minuutin aikana joku ERP:ssä muuttaa sen muotoon Steve’s Plumbing L.L.C. Kenen muutos voittaa? Tässä on ajattelutapa: jos kenttä hallitaan ERP:ssä, et muuta kenttää, vaan pyydät sen muuttamista. Päätä, mitä tapahtuu, kun pyyntö törmää: ERP voittaa, pyyntö hylätään, jos arvo muuttui välissä, tai se odottaa ihmistä ratkaisemaan sen. Ja päätä, kulkevatko toisiinsa liittyvät kentät yhdessä yhtenä muutoksena vai yksi kerrallaan. Luku 6 vie törmäyksiä pidemmälle (Silmukat ja törmäykset).

Pysäytä kaksoiskappaleet ovella

Kaksoiskappaleet kertautuvat. Nappaa yksi ennen kuin se luodaan, niin se on pieni ongelma. Löydä se kaksi vuotta myöhemmin, kun molemmissa roikkuu myyntimahdollisuuksia, tapauksia, yhteyshenkilöitä, laskuja, integraatioita ja analytiikkaa, niin se on iso ongelma. Luvun 3 moduuli 7 kävi läpi mekanismit (vastaavuussäännöt, kaksoiskappalesäännöt, yksilölliset External ID:t), joten en opeta niitä uudelleen. Hallinnan kysymys on: missä meidän on estettävä kaksoiskappaleet, ja missä siedämme niitä ja ratkaisemme ne myöhemmin? Satunnainen markkinointiliidi kestää epäselvyyttä. ERP:n hallitsema asiakas, jolla on taloudellisia tapahtumia, ei kestä.

Standardoi se, mitä koneet lukevat

Vapaa teksti on ihmisille ihanaa ja kamalaa, kun järjestelmän pitää tulkita sitä. Laita Arizona, AZ, Ariz., Phoenix area ja Southwest kenttään, joka ohjaa reititystä, niin sinulla on laatuongelma. Jos arvo ohjaa automaatiota, integraatiota, raportointia, tietoturvaa, kohdistamista tai agentin toimintaa, mieti tarkkaan, kuinka standardi sen on oltava. Jokaisesta tekstikentästä ei tule valintaluetteloa, mutta erota tieto, jota ihmiset lukevat, tiedosta, jonka perusteella koneet päättävät. Jälkimmäinen ansaitsee vahvemman kontrollin.

Älä anna pakollisten kenttien luoda valetietoja

Päätämme, että kenttä on tärkeä, ja teemme siitä pakollisen. Käyttäjä ei tiedä vastausta, järjestelmä ei päästä jatkamaan, joten hän kirjoittaa N/A, Unknown, 999999 tai test@test.com. Kenttä on täytetty; tieto on roskaa. Ennen kuin vaadit jotain, kysy, tietääkö käyttäjä sen oikeasti siinä vaiheessa. Jos ei, vaadi sitä myöhemmin prosessissa, anna toisen järjestelmän toimittaa se, käytä väliaikaista tilaa tai tarjoa eksplisiittinen Tuntematon, kun tuntematon on oikeutettu vastaus. Vahvistussääntö voi panna käytännön täytäntöön. Se ei voi saada ketään tietämään sitä, mitä hän ei tiedä.

Jokainen tietojen raja tarvitsee laatupäätöksen

Ihmiset eivät ole huonojen tietojen ainoa lähde; integraatiot tuottavat niitä nopeammin. Vähittäiskauppakumppanin kuormaluettelo (manifest) saapuu muutaman sadan rivin kanssa. Kourallisessa on virheellinen postinumero, parissa mainitaan tuntematon jakelukeskus, kaksi toistaa saman tilausviitteen. Mitä tapahtuu? Hylätäänkö koko tiedosto? Hyväksytäänkö hyvät rivit ja palautetaan huonot? Ladataanko kaikki ja siivotaan myöhemmin? Eristetäänkö poikkeukset? Kenelle kerrotaan, ja miten kumppani saa tietää, mikä epäonnistui? Yleispätevää vastausta ei ole, mutta jokin vastaus on oltava. Luku 4 sanoi, että jokainen nuoli tarvitsee mekanismin. Lisää siihen: jokainen tietojen raja tarvitsee laatupäätöksen: mitä hyväksymme, hylkäämme tai eristämme, ja kuka omistaa poikkeuksen.

Click to enlarge

Jokainen tietojen raja tarvitsee laatupäätöksen.

Historialliset tiedot ovat eri asia

RouteDeskissä on kahdeksan vuoden historia Steve Truckingin toiminnasta, ja sen laatu vaihtelee jakelukeskuksittain. Pitäisikö meidän siivota kaikki kahdeksan vuotta tämän päivän tasolle ennen siirtoa? Tuskin automaattisesti. Mihin sitä käytetään: päivittäiseen toimintaan, viitteeksi, korvausvaatimuksiin, raportointiin, trendianalyysiin? Pitääkö kaiken olla Salesforcessa, vai voiko osa jäädä muualle? Migraatioluku menee syvälle. Hallinnan näkökulma: historia ei automaattisesti tarvitse samaa tasoa kuin aktiiviset tiedot. Jos teet sen perusteella päätöksiä, laadulla on väliä. Jos säilytät sitä viitteeksi, toinen taso voi riittää. Tunne tarkoitus ennen kuin käytät omaisuuden menneisyyden siivoamiseen.

Mittaa sitä, minkä perusteella joku toimii

Hallinta ei ole koskaan valmis, joten sinun on nähtävä, kun laatu lipsuu: kaksoiskappaleiden osuus kasvaa, eristettyjä tietueita on enemmän, integraatiot hylkäävät enemmän, paikkamerkkiarvot leviävät, ohituspyyntöjä tulee enemmän, raportit eivät enää täsmää. Mutta älä rakenna 150 mittaria ja jätä 143:a huomiotta. Steve Truckingilla se voisi olla toimitukset ilman kelvollista kumppaniviitettä, toimitukset ilman käyttökelpoista osoitetta, toistuvat tilausviitteet, hylätyt kumppaniviestit ja väliaikaiseen tilaan juuttuneet tilit. Vihreitä palloja täynnä oleva koontinäyttö ei tarkoita, että tiedot ovat hyviä. Mittaa sitä, minkä perusteella joku on valmis toimimaan.

Kokeen jälkeen: mitä tekoäly muuttaa. Huonoista tiedoista tulee yhä useammin huonoa toimintaa. Ihminen voi huomata, että puhelinnumero näyttää väärältä, ennen kuin soittaa siihen; agentti yksinkertaisesti käyttää arvoa, jonka se saa. Kaksoiskappaleasiakkaat, vanhentuneet tilat, keksityt pakolliset arvot ja väärät tunnisteet muuttuvat suoraan vääräksi viestiksi tai vääräksi päivitykseksi. Se nostaa ennaltaehkäisyn arvoa. Se ei poista vastuuhenkilöiden työn tarvetta.

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

• Mitkä laatuvirheet aiheuttavat niin paljon haittaa, että ennaltaehkäisevät kontrollit ovat perusteltuja.
• Luodaanko hallittuja tietueita vapaasti, vain auktoritatiivisessa järjestelmässä vai väliaikaisesta hallituksi -polun kautta.
• Mitkä attribuutit Salesforce omistaa ja mihin se vain viittaa.
• Mitä tapahtuu saapuville tiedoille, jotka eivät läpäise tarkistuksia (hyväksy, hylkää tai eristä), ja kuka omistaa poikkeuksen.
• Mitä laatusignaaleja mitataan, jotta vastuuhenkilöt näkevät lipsumisen.

Et koskaan estä jokaista huonoa tietuetta. Työ ei ole täydellisiä tietoja; se on sen estämistä, että vältettävissä olevista huonoista tiedoista tulee kalliita tietoja. Pysäytä kaksoiskappale ennen kuin sillä on kahden vuoden historia. Suojaa tunniste ennen kuin kymmenen integraatiota riippuu väärästä. Anna myynnin luoda prospekti, mutta älä esitä sitä hallituksi asiakkaaksi ennen kuin se on sitä. Ja kun jotain huonoa pääsee läpi, varmista, että joku voi nähdä sen, omistaa sen ja korjata sen.

Lue lisää

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) ja Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).