Yrityksen tietojen lajit

🌐 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 Yrityksen tietojen ymmärtäminen, Data Architect -kurssin luku 4. Jokainen moduuli on itsenäinen. Edellinen: Salesforce on yksi järjestelmä monien joukossa · Seuraava: Salesforcea ympäröivät järjestelmät

Kysymys, johon tämä moduuli vastaa: Millaisia tietoja yrityksellä on, ja miksi ne kuuluvat eri paikkoihin?

Asiakastietue. Luettelo maista. Tilaus. Kentän määritys. Viiden vuoden myyntisummat. Neljä miljoonaa toimituskuvaa. Ne ovat kaikki tietoja, mutta arkkitehtuurin kannalta ne eivät ole sama asia. Ne muuttuvat eri tavalla, kasvavat eri tavalla, niitä käytetään eri tavalla ja niiden omistajat ovat eri ihmisiä, eikä niiden pitäisi automaattisesti asua samassa paikassa. Joten kun joku sanoo ”tarvitsemme nämä tiedot Salesforceen”, seuraava kysymykseni on: minkä lajin tietoja ne ovat? Vastaus alkaa kertoa, mitä niille pitää tehdä.

Aloita lajista, älä objektista

Salesforce-ihmisinä käännämme vaatimukset rakenteiksi lähes heti: asiakas, tili; kuva, File; tila, valintaluettelo. Siitä on aikanaan hyötyä. Yrityksen tasolla haluan ensin tietää, minkä lajin tiedosta on kyse. Luokittelutapoja on monia (DAMAn tietämyskokonaisuus on vakiolähde), ja minusta kuusi lajia on hyödyllisiä: perustiedot, viitetiedot, tapahtumatiedot, metatiedot, analyyttiset tiedot ja rakenteettomat tiedot. Luokat eivät ole arkkitehtuuri. Ne ovat tapa kysyä parempia kysymyksiä.

Perustiedot: asiat, jotka liiketoiminta tuntee

Perustiedot (master data) kuvaavat pysyviä asioita, joiden ympärillä liiketoiminta pyörii: asiakkaat, tuotteet, hinnoittelu, työntekijät, toimittajat, sijainnit, omaisuuserät. Salesforcen myyntiorgissa ne ovat tilisi ja yhteyshenkilösi, tuotteesi ja hinnastosi. Steve Truckingissa vähittäiskauppakumppani (Retail Partner) on perustietoa. Keystone ei ole tapahtuma; se on organisaatio, johon Steve Truckingilla on jatkuva suhde. Myös yhdeksän jakelukeskusta ovat perustietoja.

Perustiedot elävät pidempään kuin niitä käyttävät tapahtumat: yhdellä vähittäiskauppakumppanilla voi olla miljoonia toimituksia. Siksi ensimmäinen kysymys niistä on aina kuka ne omistaa? Se ei välttämättä ole Salesforce. ERP voi omistaa tuotteet. Salesforce voi omistaa prospektit, kun taas ERP muuttuu auktoritatiiviseksi, kun niistä tulee asiakkaita. MDM-alusta voi omistaa asiakkaan yrityksen tason identiteetin, joka kootaan useista järjestelmistä. Luku 6, Perustiedot ja identiteetti, menee syvälle. Tunnista nyt muoto.

Viitetiedot: liiketoiminnan yhteinen sanasto

Viitetiedot ovat hallittua sanastoa, jolla luokitellaan muita tietoja: maakoodit, valuutat, tuoteluokat, syykoodit, tilat. Steve Truckingin toimitustilat (aikataulutettu, lastattu, jakelussa, saapumassa, toimitettu, asennettu, poikkeama, palautettu) ovat viitetietoja. Ne eivät ole toimituksia; ne ovat sanoja, joilla toimituksia kuvataan.

Ne näyttävät pieniltä ja harmittomilta, usein valintaluettelo, jossa on kahdeksan arvoa. Älä sekoita pientä merkityksettömään. Jos Salesforce sanoo Delivered, ERP sanoo Complete ja vähittäiskauppakumppani lähettää D, jonkun täytyy määritellä, mitä kukin tarkoittaa ja miten ne vastaavat toisiaan. Viitetiedoissa piilevät integraation oletukset.

Tapahtumatiedot: mitä tapahtui

Tapahtumatiedot kirjaavat toimintaa: tehty tilaus, suoritettu maksu, valmistunut toimitus, avattu tapaus. Samassa myyntiorgissa ne ovat tarjouksia ja tarjousrivejä, tilauksia ja tilausrivejä, maksuja: jokainen osoittaa takaisin asiakkaaseen ja tuotteeseen. Steve Truckingin miljoona toimitusta vuodessa ovat tapahtumatietoja, ja niin ovat niiden tilapäivityksetkin: noin kahdeksan toimitusta kohden, eli kahdeksan miljoonaa tilamuutosta vuodessa, yrityksessä, joka kasvaa 30 % vuodessa.

Se on täysin eri kasvukäyrä kuin perustiedoilla. Kolme vähittäiskauppakumppania ylhäällä; miljoonia rivejä alla. Tässä Steven ”nollien määrä” (Steve’s Number of Zeros) on tärkeä: et voi katsoa ketjua vähittäiskauppakumppani → toimitus → tila ja antaa jokaiselle laatikolle samaa painoa. Tapahtumatietojen kohdalla ajattelen heti volyymia, nopeutta, säilytystä, historiaa, arkistointia, integraatiota ja sitä, miten ihmisten oikeasti täytyy löytää ne. Osa 2 viettää siellä paljon aikaa.

Metatiedot: tietoa tiedoista

Olet työskennellyt metatietojen kanssa koko kurssin ajan: objektin määritys, kentän tyyppi, sen kuvaus, sen suhteet. Koko yrityksellä niitä on: tietovarastojen skeemat, integraatioiden vastaavuudet, tietoluettelot, API-sopimukset, ja jokaiselle kentälle omistaja, arkaluonteisuustaso, määritelmä, alkuperä ja säilytyssääntö. Arvot ovat tietoja; kuvaus siitä, mitä ne tarkoittavat, on metatietoa. Kuten luku 3 sanoi, Flag2__c ei kerro kenellekään mitään, ja sillä on entistä enemmän merkitystä nyt, kun tekoäly lukee metatietoja selvittääkseen, mitä tiedot tarkoittavat.

Analyyttiset tiedot: tietoja, jotka teimme muista tiedoista

”Mikä on täsmällisyysasteemme vähittäiskauppakumppaneittain viimeisten viiden vuoden ajalta?” ei ole tapahtuma. Se on analyyttinen kysymys, johon vastataan johtamalla uusia tietoja miljoonista toimituksista: täsmällisyysprosentti, vauriomäärä, liikevaihto kumppania kohden, asennusten laatu, tiimien trendit. Ja se on eri työ. Ajojärjestelijä, joka kysyy ”mikä on kuorma-auton 217 seuraava pysähdys?”, ei tarvitse käydä läpi viiden vuoden historiaa. Johto, joka vertaa viiden vuoden täsmällisyyttä alueittain, tarvitsee. Siksi analyyttiset tiedot asuvat yleensä tietovarastossa, lakehousessa tai analytiikka-alustalla, joka on rakennettu sitä työtä varten. Se, että Salesforce voi tallentaa jotain, ei tee operatiivisesta alustasta paikkaa, jossa sille ajetaan jokainen analyysi.

Rakenteettomat tiedot: mikä ei mahdu riveihin

Asiakirjat, PDF:t, kuvat, ääni, video, sähköpostit, litteroinnit, tietämysartikkelit. Steve Truckingissa toimituskuvat: noin neljä toimitusta kohden, asennuksissa enemmän, neljästä viiteen miljoonaa vuodessa. Kuva ei ole vain yksi kenttä lisää. Se on iso, se voi näyttää jonkun kodin sisältä, sillä on omat säilytyssääntönsä, ja sitä haetaan eri tavalla, jos ollenkaan.

Tämän lajin merkitys kasvaa joka vuosi, koska tekoäly voi nyt tehdä hyödyllisiä asioita tiedolla, joka ennen oli jäsennellyn mallin ulkopuolella. Litterointi on tietoa. PDF-käyttöohje on tietoa. Asennuskuva on tietoa. Se ei tarkoita, että se kuuluu Salesforcen coreen. Se tarkoittaa, että se kuuluu järjestelmäkarttaan.

Click to enlarge

Kuusi tyyppiä, neljä kysymystä kustakin. Vastaukset muuttuvat tyypistä toiseen, ja juuri se on tarkoitus.

Laji on vain puolet kysymyksestä: kuormitus

Ei riitä, että tiedämme, minkä lajin tietoja meillä on. Haluan tietää myös, mitä teemme niillä. Tässä on kolme kuormitusta, ja niiden sekoittaminen tuottaa huonoa arkkitehtuuria.

Operatiivinen: liiketoiminnan pyörittäminen. Ajojärjestelijä päivittää toimituksen, tiimi saa pysähdyksen valmiiksi, asiakaspalvelija avaa tapauksen. Paljon pieniä lukuja ja kirjoituksia: etsi tämä, päivitä tuo, näytä tämän päivän pysähdykset. Tämä on OLTP, online transaction processing, ja Salesforce on siinä erittäin hyvä; siellä ylläpitäjät ja kehittäjät elävät.

Analyyttinen: liiketoiminnan ymmärtäminen. Jokainen toimitus viiden vuoden ajalta kumppanin ja jakelukeskuksen mukaan ryhmiteltynä, vuosittain verrattuna ja talouden tietoihin yhdistettynä. Nyt käymme läpi ja koostamme. Tämä on OLAP, online analytical processing, ja sitä varten tietovarastot, lakehouset ja analytiikka-alustat on rakennettu. Yksinkertaisesti: org pyörittää liiketoimintaa; tietovarastot ja tietoaltaat analysoivat sitä. Klassinen virhe on laittaa tämä kuormitus operatiiviselle alustalle ja yllättyä, kun nollat kasvavat. Jos joku haluaa käydä toistuvasti läpi valtavia määriä historiaa, älä kohtele sitä ”vain yhtenä raporttina”. Kysy, onko se oikea alusta. Osa 2 palaa tähän luvussa Suunnittelu mittakaavaa varten (coming soon) (älä tee coresta tietovarastoasi), ja osa 3 näyttää, miten analyyttiset rakenteet rakennetaan, luvussa Relaatiotietokannan tuolla puolen (coming soon).

Suoratoisto: liikkeessä olevat tiedot. Tapahtumat, telemetria, tilamuutokset, anturilukemat. Steve Truckingin kuorma-autot lähettävät noin 200 000 GPS-lukemaa päivässä. Ajojärjestelijää kiinnostaa, missä kuorma-auto 217 on nyt. Tarvitseeko Salesforcen säilyttää jokaisen kuorma-auton jokainen minuutin välein otettu lukema? Ehkä ei. ”Missä se on nyt?” ja ”millaisia reittitehokkuuden trendejä oli viime neljänneksellä?” tulevat samasta lähteestä ja johtavat täysin erilaisiin tallennuspäätöksiin.

Kuinka nopeasti tietojen pitää liikkua?

Sitten viive. Kurssilla sanon sen näin: reaaliaikainen on sitä, että odotat ovella jonkun palaamista. Lähetät hänet asialle ja seisot siinä, koska et voi jatkaa ennen kuin hän palaa. Se on synkronista. Lähes reaaliaikainen on sitä, että katsot hänen lähtevän ja jatkat muiden töiden parissa; kun hän palaa vähän myöhemmin, hoidat asian. Se on asynkronista. Ja sitten on eräajo: kukaan ei lähde ovesta yksi kerrallaan. Tiedot odottavat ja liikkuvat joukkona aikataulun mukaan: tunneittain, muutaman tunnin välein tai päivittäin. On paljon tilanteita, joissa eräajo riittää, ja joitain, joissa ei. Sen tietäminen, kumpi on kumpi, on se työ. Nämä kolme eivät ole pelkkiä integraatiotermejä; ne ovat arkkitehtuurisia valintoja.

Otetaan tavallinen ERP-integraatio. ERP:ssä luodaan uusi tuote klo 11.00. Tarvitseeko myynnin todella pystyä myymään sitä kello 12:een mennessä? Olen nähnyt molemmat vastaukset. Jotkut asiakkaat haluavat sen mahdollisimman pian; toiset sanovat, ettei sinulta voi odottaa sen SKU:n myymistä, jos emme ole vielä toimittaneet sitä sinulle. Joten tuotteet siirtyvät yleensä päivittäin, joskus nopeammin. Asiakkaat vähintään päivittäin; olen nähnyt tunneittain ja äärimmäisissä tapauksissa lähes reaaliajassa. Tilaukset ovat eri asia: toimituksen täytyy alkaa, joten lähes reaaliaikaisesti. Myyjä sulkee kaupan ja jatkaa eteenpäin, ja tilaus päätyy ERP:hen sekunneissa tai minuutissa tai kahdessa. ”Yrityksen tiedoille” ei ole yhtä oikeaa viivettä. Kysy, mitä liiketoiminta oikeasti tarvitsee, äläkä tee kaikesta reaaliaikaista siksi, että se kuulostaa vaikuttavalta. Reaaliaikaisuudella on hintansa.

Luokkien takana olevat neljä kysymystä

Sinun ei tarvitse kulkea ympäriinsä julistamassa ”tämä on tapahtumatietoa!” Luokittelu on olemassa käynnistääkseen neljä kysymystä jokaisesta tärkeästä tietojoukosta:

• Kuka sen omistaa? Mikä järjestelmä on auktoritatiivinen? Jaan sen kolmeen: missä se luodaan, missä sitä muokataan ja missä siihen viitataan? Luku 6 menee näihin syvälle (Luotu, muokattu, viitattu ja kuinka nopeasti?).
• Kuinka nopeasti se muuttuu? Kerran vuodessa, päivittäin, kymmeniä tai satoja kertoja sekunnissa?
• Kuinka suureksi se kasvaa? Kymmenen tietuetta, kymmenentuhatta, kymmenen miljoonaa, kymmenen miljardia?
• Mikä on sen elinkaari? Elääkö se ikuisesti, arkistoidaanko se, täytyykö se poistaa, menettääkö se arvoaan ajan myötä?

Nuo neljä kertovat minulle paljon enemmän kuin ”voiko Salesforce tallentaa tämän?” Ja ne kokoavat yhteen sen, mitä olemme jo oppineet: omistajuuden, elinkaaren, nollien määrän ja sen, missä tiedot asuvat.

Yksi liiketoiminta tuottaa jokaista lajia

Steve Truckingissa vähittäiskauppakumppani on perustietoa; tilasanasto on viitetietoa; jokainen toimitus on tapahtumatietoa; sen kenttien määritykset ovat metatietoa; viiden vuoden täsmällisyyden tuloskortti on analyyttistä tietoa; asennuskuva on rakenteetonta tietoa; ja GPS-syöte on suoratoistoa. Kaikki se on ”Steve Truckingin tietoja”. Mikään siitä ei tarkoita, että se kuuluisi samaan tietokantaan. Siinä on muutos.

Kokeen jälkeen: mitä tekoäly muuttaa. Vastatakseen yhteen kysymykseen agentti voi tarvita jäsennellyn asiakastietueen, tuoreen tapahtuman, PDF-käyttöohjeen, asiakaspalvelun litteroinnin ja reaaliaikaista telemetriaa. Rakenteettomista ja suoratoistotiedoista tulee arkkitehtuurin täysivaltaisia osia silloinkin, kun ne eivät kuulu CRM-tietokantaan, ja arkkitehdin täytyy yhä tietää, kuka omistaa kunkin lähteen, kuinka ajantasainen se on ja pitäisikö agentin luottaa siihen.

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

• Minkä lajin tietoja kukin tärkeä tietojoukko on, ja kuka sen omistaa.
• Onko sen kuormitus operatiivinen, analyyttinen, suoratoisto vai sekoitus.
• Kuinka nopeasti se muuttuu, ja kuinka nopeasti muiden järjestelmien todella täytyy nähdä muutos.
• Miten volyymi ja elinkaari muovaavat sitä, missä se asuu ja kuinka kauan.
• Pitäisikö Salesforcen omistaa se, säilyttää siitä kopio, viitata siihen vai jättää se paikkaan, joka sopii kuormitukselle paremmin.

Kun joku ojentaa sinulle vaatimuksen, älä hyppää suoraan siihen, mikä objekti, mikä kenttä, mikä API. Kysy ensin, minkä lajin tietoa se on, kuka sen omistaa, kuinka nopeasti se muuttuu, kuinka suureksi se kasvaa, kuinka kauan se elää ja mitä yritämme sillä tehdä. Tili, toimitustapahtuma, viiden vuoden koonti ja valokuva voivat kaikki olla tärkeitä samalle liiketoiminnalle olematta sama arkkitehtuurinen ongelma.

Lue lisää

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2. painos (2017): tietoluokkien ja tiedonhallinnan vakiolähde (englanniksi).
• Steve Truckingin taustakuvaus, osio 4 (volyymit).