Fra forretningsbegrep til kolonne
Et forretningsbegrep skal defineres én gang og kobles til kolonnene som bruker det. Slik skriver du begrepet, kobler det og håndterer endringer.
Ta nettbutikken fra artikkelen om felles datamodell. Ledelsen spør hvor mange aktive kunder butikken har, og får tre forskjellige tall fra markedsavdelingen, kundeservice og økonomi. Hvorfor det skjer, og hvorfor en felles modell løser det, står i den artikkelen. Her handler det om hvordan: hva som skal skrives ned om «aktiv kunde», hvordan definisjonen kobles til tabellene, og hva som skjer den dagen noen vil endre den.
Hva et godt begrep inneholder
Et forretningsbegrep er mer enn et ord med en forklaring. For at det skal kunne brukes av både forretningen, utviklerne og analytikerne, trenger det fem deler.
Det finnes etablerte retningslinjer for hvordan definisjoner bør skrives. Standarden ISO/IEC 11179-4 sier blant annet at en definisjon skal si hva begrepet er, ikke bare hva det ikke er, og anbefaler at den er presis og entydig, ikke sirkulær, og at beslektede definisjoner bruker de samme begrepene og den samme strukturen. Rådene under bygger på de samme prinsippene.
Navn. Navnet er det folk sier i møter og skriver i rapporter, ikke det kolonnen heter i databasen. «Aktiv kunde», ikke er_aktiv eller active_flg. Velg ett navn og hold deg til det. Har begrepet synonymer som er i bruk, skriv dem ned, slik at folk som søker etter «kjøpende kunde» finner det samme begrepet.
Definisjon. Definisjonen skal være så presis at to personer som leser den, teller det samme. «En kunde som handler hos oss» er ikke nok. En bedre definisjon er: «En kunde som har betalt for minst én ordre de siste tolv månedene, regnet fra dagens dato. Ordrer som er returnert i sin helhet, telles ikke.» Den sier hva som telles, over hvilken periode, og hvordan et vanlig grensetilfelle håndteres.
Eier. Eieren er den som bestemmer hva begrepet betyr, og den som svarer når noen er i tvil. For «aktiv kunde» kan det være økonomi, fordi det er økonomi som rapporterer tallet videre. Eieren bør være en rolle eller et team, ikke bare en person, slik at begrepet ikke står uten eier når noen bytter jobb.
Eksempler. Eksempler gjør definisjonen konkret. En kunde som betalte for en ordre for tre måneder siden, er aktiv. En kunde som bare har opprettet en konto og meldt seg på nyhetsbrevet, er ikke aktiv. En kunde som kjøpte én vare for elleve måneder siden og returnerte den, er heller ikke aktiv. Det er ofte i eksemplene uenighetene kommer frem, fordi det er lettere å være uenig om et konkret tilfelle enn om en abstrakt setning.
Hva begrepet ikke er. Skriv ned de nærliggende begrepene som lett blandes sammen med dette. «Aktiv kunde» er ikke det samme som «registrert kunde», som teller alle med en konto. Det er heller ikke det samme som «kontaktbar kunde», som teller dem som har samtykket til markedsføring. Når markedsavdelingen trenger sitt tall, får de sitt eget begrep med sitt eget navn, i stedet for å låne et navn som betyr noe annet.
Et begrep med disse fem delene kan leses av en ny analytiker uten at noen må forklare det muntlig. Det kan også leses av en AI-assistent som skal skrive en spørring, av samme grunn.
Ett begrep, mange kolonner
Når begrepet er skrevet ned, er neste steg å finne ut hvor det brukes. Det er sjelden bare én kolonne. I nettbutikken kan «aktiv kunde» dukke opp som et flagg i kundetabellen i sølvlaget, som et filter i salgsrapporten og som en egen kolonne i kundedimensjonen i gullaget. Kolonnene kan hete forskjellige ting: er_aktiv i én tabell, aktiv_kunde i en annen.
Det samme gjelder begreper som «ordre» og «produkt». ordre_id finnes i ordretabellen, i ordrelinjetabellen, i returtabellen og i faktatabellen for salg. Alle viser til det samme begrepet, selv om tabellene er bygget av forskjellige team.
Koblingen går derfor fra begrepet til kolonnene, ikke omvendt. Begrepet har én definisjon, og hver kolonne som representerer det, peker til den. Da kan dere svare på to spørsmål som ellers er vanskelige: hvilke kolonner betyr «aktiv kunde», og hva betyr denne kolonnen?
En vanlig feil er å kopiere definisjonen inn i beskrivelsen av hver kolonne. Det virker ryddig den dagen det gjøres. Etter et år finnes det seks versjoner av definisjonen, med små forskjeller, og ingen vet hvilken som gjelder. Kolonnebeskrivelsen bør heller vise til begrepet og bare si det som er spesielt for akkurat denne kolonnen, for eksempel at flagget beregnes hver natt, eller at tabellen bare inneholder kunder fra den norske butikken.
En god kolonnebeskrivelse er derfor kort, men kan leses for seg selv: «Sann hvis kunden er aktiv. Beregnes ved nattlig lasting.» Koblingen til begrepet ligger ved siden av beskrivelsen, ikke som en henvisning i teksten. Slik står definisjonen ett sted, og kolonnen arver den.
Slik ser koblingen ut i en datakontrakt
Hvis dere beskriver tabellene som datakontrakter, kan koblingen skrives rett inn i kontrakten. Open Data Contract Standard har to felt for dette på hver kolonne: businessName for begrepets navn, og authoritativeDefinitions for en lenke til definisjonen.
apiVersion: v3.2.0
kind: DataContract
id: kunde
version: 1.0.0
status: active
schema:
- name: kunde
properties:
- name: er_aktiv
businessName: Aktiv kunde
logicalType: boolean
required: true
description: Sann hvis kunden er aktiv. Beregnes ved nattlig lasting.
authoritativeDefinitions:
- type: businessDefinition
url: https://ordbok.example.no/begreper/aktiv-kunde
description: Definisjonen, eid av økonomi
Kolonnen heter er_aktiv i databasen, men businessName sier hvilket begrep den representerer. Lenken i authoritativeDefinitions peker til stedet der definisjonen faktisk står, slik at den som leser kontrakten, kan slå den opp. Typen businessDefinition er en av typene standarden anbefaler for lenker til en forretningsordbok. Beskrivelsen gjentar ikke definisjonen, den sier bare det som gjelder for denne kolonnen.
Når en definisjon endres
Definisjoner endres. Økonomi kan bestemme at en aktiv kunde skal regnes over seks måneder i stedet for tolv, eller at ordrer som er delvis returnert heller ikke skal telle. Endringen er liten i teksten, men tallet i hver rapport som bruker begrepet, endres også. Derfor trenger endringen en fast fremgangsmåte.
Eieren bestemmer. Hvem som helst kan foreslå en endring, men det er eieren som avgjør den. Det hindrer at et team endrer definisjonen for å få sin egen rapport til å stemme, uten at de andre vet om det.
Finn det som bruker begrepet. Før endringen tas i bruk, må dere vite hvilke kolonner og rapporter som er koblet til begrepet. Det er her koblingen fra forrige avsnitt gjør jobben. Uten den må noen lete gjennom tabeller og rapporter etter alt som kan tenkes å bety «aktiv kunde», og noe blir glemt.
Si fra til konsumentene. De som eier rapportene og tabellene som bruker begrepet, må få vite hva som endres, hvorfor, og fra når. Er endringen stor nok til at tallene ikke lenger kan sammenlignes med fjorårets, må det også sies tydelig, slik at ingen tror kundene forsvant over natten.
Behold historikken. Den gamle definisjonen skal ikke slettes. Noen vil spørre hvorfor tallet for aktive kunder falt i mars, og svaret er at definisjonen ble endret. Det svaret finnes bare hvis det er skrevet ned når endringen skjedde, hva som ble endret, og hvem som bestemte det. Ligger begrepene i versjonskontroll sammen med datamodellen, får dere historikken uten ekstra arbeid.
Hvor dere kan begynne
Dere trenger ikke en komplett ordbok før dere begynner. Velg de begrepene som ofte skaper uenighet, i nettbutikken kanskje «aktiv kunde», «ordre» og «omsetning». Skriv navn, definisjon, eier, eksempler og hva begrepet ikke er. Finn kolonnene som bruker dem, og bytt ut de kopierte definisjonene med en henvisning til begrepet.
Neste gang noen spør hvor mange aktive kunder butikken har, finnes det ett svar, én definisjon å vise til, og én eier som kan forklare den. Vil du se hvordan begrepene henger sammen med resten av modellen, kan du lese videre om dimensjonsmodellering i praksis, eller se hvordan en forretningsordbok kan holde orden på begrepene.