Hallinta suunnitellaan orgiin

🌐 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 1/6 luvussa Tietojen laatu ja hallinta, Data Architect -kurssin luku 5. Jokainen moduuli on itsenäinen. Seuraava: Huonojen tietojen pitäminen ulkona

Kysymys, johon tämä moduuli vastaa: Mitä tietojen hallinta tarkoittaa arkkitehdille, ja kuka tekee mitä?

Kun ihmiset kuulevat sanan tietojen hallinta (data governance), he ajattelevat kokouksia: komiteoita, käytäntöjä, standardeja, asiakirjaa, joka selittää, kenen kuuluu tehdä mitäkin tiedoille. Kaikki se voi olla osa hallintaohjelmaa. Arkkitehtina minua kiinnostaa eri kysymys: missä käytäntö pannaan täytäntöön?

Jos käytännön mukaan vain taloushallinto saa muuttaa kenttää, mikä sen varmistaa? Jos sen mukaan ERP omistaa asiakkaan virallisen tietueen, mikä estää jotakuta Salesforcessa muuttamasta sitä? Jos sen mukaan tiimit näkevät vastaanottajan osoitteen vain omilla pysähdyksillään ja vain sinä päivänä, mikä oikeasti tekee siitä totta? Jos sen mukaan tämä säilytetään seitsemän vuotta, mikä arkistoi tai poistaa sen seitsemän vuoden jälkeen? Käytäntö ilman täytäntöönpanokohtaa on enimmäkseen toive. Tietojen hallinnasta tulee arkkitehtuuria, kun nämä päätökset rakennetaan järjestelmään.

Hallinta ei ole koskaan valmis

Sanon tämän heti alkuun: tietojen hallintaa ei saa koskaan valmiiksi. Olen nähnyt sen kulkevan aaltoina. Yritys kiinnittää tietojen laatuun todellista huomiota, ja asiat paranevat. Huomio siirtyy muualle, ja laatu lipsuu. Uusi integraatio otetaan käyttöön, liiketoimintayksikkö muuttaa prosessiaan, joku tuo tiedoston, yritys ostaa toisen yrityksen, agentti alkaa kirjoittaa tietueita, ja ongelma muuttuu taas. Tavoite ei ole myyttinen tila, jossa jokainen tietue on täydellinen ikuisesti. Tavoite on pitää tiedot riittävän luotettavina liiketoiminnalle ja pitää pahimmat huonot tiedot ulkona. Se on jatkuvaa työtä.

Kun Salesforce on enimmäkseen yksin, hallinta tarkoittaa tietojen siivoamista yhdessä paikassa. Kun se on yksi solmu luvun 4 järjestelmäkartassa, hallinta muuttuu vaikeammaksi, ja tarpeellisemmaksi. Nyt asiakas asuu Salesforcessa, ERP:ssä, tietovarastossa, kumppanien järjestelmissä ja Data 360:ssa. Kuka sen omistaa? Kuka saa muuttaa sitä? Mikä kopio on auktoritatiivinen, mitkä attribuutit saavat liikkua, kuinka kauan niitä säilytetään ja kuka vastaa, kun ne ovat väärin? Ne eivät ole konfiguraatiokysymyksiä. Ne ovat hallinnan kysymyksiä, joista tulee konfiguraatiota.

Tietueen omistaja ei ole tietojen omistaja

Aloita sanasta omistaja, koska Salesforce tekee siitä hämmentävän. Avaa tili (Account), niin näet omistajan (Owner): vaikkapa myyjän. Omistaako myyjä asiakastiedot? Ei välttämättä. Salesforcessa tietueen, jonka objektilla on omistaja, omistaa käyttäjä tai jono; omistaja saa täyden pääsyn, ja omistaja ohjaa kohdistamista ja jakamista roolihierarkian ja jakamissääntöjen kautta (Sharing and Record Access Features (opens in a new tab)). Se on tietueen omistajuutta: alustan mekanismi.

Tietojen omistaja on jotain muuta: henkilö tai toiminto, joka vastaa tiedoista liiketoiminnan omaisuutena. Taloushallinto voi omistaa asiakkaan viralliset tiedot, operatiivinen toiminta toimituksen tilan ja HR työntekijätiedot. Salesforce antaa jopa paikan kirjata sen: jokaisen kentän Data Owner -luokittelukentän (Data Classification Metadata Fields (opens in a new tab)).

Steve Truckingilla vähittäiskauppakumppanin (Retail Partner) tilin voi omistaa myyntijohtaja, joka hoitaa sitä kumppania. Mutta kumppanin juridista identiteettiä hallitsee taloushallinto, ja sen perustiedot ovat talouden ERP:ssä. Myynti, asiakaspalvelu, operatiivinen toiminta ja kumppaniportaali tarvitsevat kaikki tilin; mikään siitä ei tarkoita, että myyntijohtajan pitäisi muuttaa kumppanin juridista identiteettiä sen jälkeen, kun taloushallinto on vahvistanut sen. Olen nähnyt tiimien katsovan Owner-kenttää ja olettavan ratkaisseensa tietojen omistajuuden. Eivät ole. Tietueen kohdistaminen ei ole liiketoiminnan vastuuta.

Omistaja, vastuuhenkilö, ylläpitäjä

Kolme hallinnan roolia, kolme eri tehtävää.

Tietojen omistaja päättää käytännön. Omistaja vastaa siihen, mitä tiedot tarkoittavat, kuka saa luoda ja muuttaa niitä, kuinka tarkkoja niiden on oltava, kuinka kauan niitä säilytetään, kuka saa nähdä ne, mikä järjestelmä on auktoritatiivinen ja mitä tapahtuu, kun ne ovat väärin. Arkkitehdin ei pidä keksiä näitä vastauksia. Se on yksi vahvimmista kannoistani: omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön. Jos taloushallinto sanoo, että virallinen nimi voi muuttua vain ERP:n prosessin kautta, kun asiakas on aktiivinen, se on hallintapäätös. Sen tekeminen mekaanisesti todeksi on minun työni.

Tietojen vastuuhenkilö (data steward) pitää sen toiminnassa. Vastuuhenkilö on lähellä tietojen päivittäistä terveyttä: seuraa laatusignaaleja, tutkii kaksoiskappaleita, ratkaisee poikkeuksia, koordinoi korjauksia, ylläpitää määritelmiä ja huomaa prosessin, joka tuottaa jatkuvasti huonoja tietoja. Vastuuhenkilöllä on vielä kaksi tehtävää. Kun kaksi tiimiä on eri mieltä siitä, mitä kenttä tarkoittaa, kuka sen omistaa tai kuka saa nähdä sen, vastuuhenkilö vie kiistan omistajalle ja huolehtii, että päätös toteutuu. Ja vastuuhenkilö rakentaa datalukutaitoa: auttaa tietoja syöttäviä ja käyttäviä ihmisiä ymmärtämään, mitä tiedot tarkoittavat ja miksi säännöt ovat olemassa. Vastuuhenkilö tarvitsee muutakin kuin nimen kaaviossa. Hän tarvitsee aikaa, näkyvyyttä, prosessin ja valtuudet saada ongelmat korjatuiksi. Muuten ”tietojen vastuuhenkilöstä” tulee jonkun kahdeksas tehtävä, jota katsotaan kerran vuosineljänneksessä.

Ylläpitäjä (custodian) pyörittää järjestelmää. Ylläpitäjät, alustatiimit, tietoturvatiimit: kuka tahansa, joka käyttää tekniikkaa, joka tallentaa ja käsittelee tietoja. Omistaja sanoo, että vain nämä roolit saavat nähdä tiedot; ylläpitäjä käyttää kontrolleja, jotka tekevät siitä totta. Nimet ovat vähemmän tärkeitä kuin se, että jokainen vastuu on selvä, ja pienessä organisaatiossa yhdellä ihmisellä voi olla kaksi hattua.

Miten ohjelmaa pyöritetään

Hallintaohjelmilla on yleensä kolme muotoa. Keskitetty: yksi tiimi kirjoittaa käytännöt ja standardit kaikille tietoalueille. Se on johdonmukainen, ja siitä voi tulla pullonkaula, kaukana työtä tekevistä ihmisistä. Hajautettu (federoitu): jokainen alue, kuten talous, myynti tai operatiivinen toiminta, hallitsee omia tietojaan muutaman yhteisen säännön puitteissa. Se on lähellä työtä, ja määritelmät ajautuvat alueiden välillä erilleen. Hybridi: pieni keskustiimi omistaa standardit ja yhteiset määritelmät, ja alueiden omistajat ja vastuuhenkilöt hoitavat omat tietonsa. Useimmat näkemäni suuryritykset päätyvät jonnekin hybridin alueelle. Arkkitehdille muoto vastaa yhteen käytännön kysymykseen: kuka hyväksyy käytännön ennen kuin panen sen täytäntöön, ja missä yhteiset määritelmät ovat?

Koetieto. Tunne kolme tapaa pyörittää hallintaohjelmaa, keskitetty, federoitu (hajautettu) ja hybridi, ja mitä kukin tarkoittaa sille, kuka päättää käytännöt ja missä yhteiset määritelmät ovat.

Anna RACI:n ansaita paikkansa

RACI (kuka on Responsible eli toteuttaja, Accountable eli vastuussa, Consulted eli kuultava ja Informed eli tiedotettava) auttaa, mutta ei jättimäinen taulukko, joka on tehty, koska hallinta ”vaatii sellaisen”. Haluan sen vastaavan arkkitehtuurikysymyksiin, alkaen luvun 4 kolmesta (Luokkien takana olevat neljä kysymystä): missä tiedot luodaan, missä niitä muokataan ja missä niihin viitataan? Ne ovat usein eri järjestelmiä. Otetaan tuote: ERP luo sen, Salesforce viittaa siihen, portaali näyttää sen, tietovarasto analysoi sen. Nyt liiketoiminta muuttaa sitä, mitä ”aktiivinen tuote” tarkoittaa. Mistä muutos alkaa, kuka sen hyväksyy, miten se leviää ja mitkä kopiot ovat vain luku -tilassa? Jos et osaa vastata, sinulla ei vielä ole tietojen hallintaa. Sinulla on kopioita. Hyvä RACI paljastaa juuri sen epäselvyyden.

Hallinnan on muututtava mekaaniseksi

Liiketoiminta sanoo, että vain taloushallinto saa muuttaa asiakkaan virallista nimeä. En halua, että arkkitehtuurin vastaus on ”hoidetaan se koulutuksessa”. Koulutus auttaa; se ei ole täytäntöönpanoa. Ehkä se on kenttätason pääsy, vahvistussääntö, kenttä, johon vain integraatio kirjoittaa, tai hallittu prosessi suorien muokkausten sijaan. Mekanismi riippuu vaatimuksesta, mutta sellainen on oltava:

Hallinnan käytäntö	Omistaja päättää	Mahdollinen täytäntöönpanokohta
ERP omistaa asiakkaan juridisen identiteetin	Taloushallinto	Vain integraation kirjoittamat kentät, käyttöoikeudet, vahvistus
Vain tarvitsevat näkevät henkilötiedot	Tietosuoja, tietoturva	Jakaminen, käyttöoikeudet, kenttien pääsy
Asiakastunnisteet ovat yksilöllisiä	Liiketoiminnan omistaja	Yksilöllinen External ID, kaksoiskappalesäännöt
Hallittuja tietueita ei luoda käsin	Tietojen omistaja	Käyttöoikeudet, automaatio, integraatio
Arkaluonteisilla tiedoilla on määrätty säilytysaika	Tietosuoja, lakiasiat	Säilytys- tai poistoprosessi
Tärkeät muutokset on voitava todistaa	Compliance	Kenttähistoria, audit trail
Tietojen lähde pysyy tunnistettavana	Tietojen omistaja	Lähdekenttä, alkuperän metatiedot

Sanon tarkoituksella mahdollinen täytäntöönpanokohta. Tämä ei ole ominaisuuksien valintataulukko. Se on ajattelun järjestys: mikä on käytäntö, kuka sen omistaa ja mikä arkkitehtuurissa tekee siitä totta?

Click to enlarge

Omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön.

Älä luota hyvään käytökseen

”Älä koskaan muuta ERP:n asiakastunnusta.” Kaikki tietävät sen, kunnes joku muuttaa: vahingossa, tietojen latauksessa, automaation kautta, integraation kautta, agentin kautta. Jos sen muuttaminen vahingoittaisi yrityksen tietoja, ”älä kiltti” ei ole kontrolli. Rakenna kontrolli. Luota, mutta varmista. Ihmiset, integraatiot, automaatio ja tekoäly tekevät kaikki virheitä, joten arkkitehtuurin pitää olettaa, että ennemmin tai myöhemmin jokin yrittää sitä, minkä käytäntö kieltää. Mitä silloin tapahtuu?

Hallinta ylittää järjestelmien rajat

Takaisin järjestelmäkarttaan. ERP omistaa asiakkaan; Salesforcessa, tietovarastossa ja asiakastietoalustassa on kopiot; kumppani saa osan niistä. Mihin järjestelmään käytäntö pätee? Kaikkiin. Salesforce voi oikein estää virallisen nimen muutoksen, samalla kun integraatio antaa jonkin alavirran järjestelmän ylikirjoittaa sen. Salesforce voi poistaa henkilötietoja, joita tietovarastossa yhä on. Salesforcessa arkaluonteiseksi luokiteltu kenttä voi päätyä muualla luokittelemattomaan tekstikenttään. Hallinta ei voi pysähtyä orgin rajalle, koska tiedotkaan eivät pysähdy. Siksi luku 4 tuli ensin: järjestelmäkartta kertoo, kuinka pitkälle hallinnan on ulotuttava.

Hallitse riittävästi, älä kaikkea

Päinvastainen epäonnistuminen on aivan yhtä todellinen. Huomaamme, että hallinnalla on merkitystä, joten lukitsemme kaiken: kukaan ei voi luoda mitään, jokainen muutos vaatii hyväksynnän. Tiedot ovat hallittuja, eikä kukaan pysty tekemään työtään. Hallinta tarkoittaa tiedoille sopivaa kontrollia: tiukkaa joillekin, kevyttä toisille. Joitain tietueita voi luoda vapaasti, joihinkin tarvitaan hyväksyntä; joitain kenttiä voi muokata melkein kuka tahansa, joitain vain integraatio. Seuraava moduuli käsittelee juuri sitä käytännönläheisesti.

Ja koska hallinta ei ole koskaan valmis, täytäntöönpano tarvitsee palautetta. Lisääntyvätkö kaksoiskappaleet? Täyttyvätkö pakolliset kentät roskalla? Epäonnistuvatko integraatiot, keksivätkö käyttäjät kiertoteitä, kasvavatko poikkeukset, käyttävätkö vastuuhenkilöt koko päivän yhteen ongelmaan? Nämä signaalit kertovat, toimiiko suunnitelma, ja joskus sen, että kontrollia, tai käytäntöä, on muutettava.

Kokeen jälkeen: mitä tekoäly muuttaa. Tietojen hallinnalla on uusi kuluttaja: agentti. Tietojen omistaja päättää yhä, mitä saa käyttää ja mihin; arkkitehti tekee siitä yhä täytäntöönpantavaa. Muuttuvat nopeus ja mittakaava. Agentti lukee, yhdistelee ja käyttää hallittuja tietoja paljon ihmistä nopeammin, joten käytäntö, joka on olemassa vain asiakirjassa, suojaa vielä vähemmän.

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

• Kuka vastaa kustakin tärkeästä tietoalueesta, ja miten se eroaa tietueen omistajuudesta.
• Kuka on tietojen vastuuhenkilö ja kuka käyttää niitä ylläpitäjänä.
• Missä tärkeät tiedot luodaan, missä niitä muokataan, missä niihin viitataan ja missä niiden perustiedot hallitaan järjestelmäkartalla.
• Mikä täytäntöönpanokohta tekee kustakin tärkeästä käytännöstä mekaanisesti totta.
• Miten arkkitehtuuri näyttää, toimiiko hallinta vai alkaako se lipsua.

Kun kuulen hallintavaatimuksen, muunnan sen. ”ERP omistaa tämän.” ”Vain nämä ihmiset saavat nähdä tämän.” ”Meidän on voitava todistaa, kuka muutti tämän.” ”Säilytä tämä seitsemän vuotta.” Joka kerta: näytä minulle täytäntöönpanokohta. Arkkitehti ei päätä käytäntöä. Me suunnittelemme järjestelmän, joka panee sen täytäntöön. Siinä kohdassa hallinta lakkaa olemasta asiakirja ja muuttuu arkkitehtuuriksi.

Lue lisää

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).