Data management

De data som en organisation äger är en värdefull resurs. Hur kan vi bygga en förmåga att ta hand om denna resurs?

Data är inte bara en bas i den dagliga operativa verksamheten, data används också för att monitorerna, analysera, styra och förbättra verksamheten. Ofta kan data ge innehåll till nya tjänster för kunder och andra intressenter. Det finns många exempel på datadrivna tjänster som skapar helt nya affärsmöjligheter.

Men precis som andra resurser behöver dataresursen tas om hand. För detta behöver vi ett strukturerat arbetssätt. Vi behöver ägarskap och förvaltningsansvar på olika ställen i organisationen. Tillika behöver vi en stödfunktion som stödjer och utvecklar arbetssättet.

Vi kan ju jämföra med hur vi gör med andra resurser. För personal har vi en personalavdelning. För ekonomiska värden har vi en ekonomiavdelning. För informationsteknik har vi en it-funktion. För varje slag av resurs har vi vanligen någon form av stödfunktion. Men var har vi den funktion som stödjer vårdandet och utvecklandet av organisationens data? Om den inte finns i vår organisation idag behöver vi på något sätt skapa den, vilket innebär att bygga kompetens, kultur och arbetssätt för data management.

Jo, men borde inte det vara it-avdelningens ansvar, kanske du invänder? Jovisst, det kan man tycka. Men det sker inte idag, i alla fall inte i de organisationer jag har insikt i. Ansvaret faller mellan stolarna. It-folket tycker att det är verksamhetens data och därmed verksamhetsfolkets ansvar. Verksamhetsfolket å sin sida har svårt att på egen hand verkligen ta hand om data på ett bra sätt.
Det är en resurs de har otillräcklig insikt i då den ligger dold för dem i databaser och flyttas runt och misshandlas i en spaghetti av integrationer.

Verksamheten har också sällan den kompetens som behövs för att hantera data. Det har visserligen inte alltid it-folket heller, annars skulle det inte se ut som det gör på många ställen idag. Men it-sidan har åtminstone de grundläggande förutsättningarna och verktygen för att ta itu med uppgiften om de bara ville ta det ansvaret.

I vilket fall som helst, var ansvaret än bör placeras, behöver vi få ett grepp om vad det innebär att ta hand om data. Först därefter kan vi bygga en förmåga för detta, med lämpliga kompetenser.

För övrigt är det hög tid att it-sidan inte ser sig som en servicebyrå till verksamheten. Man bör se sig som en lika tätt integrerad del av verksamheten som övriga stödfunktioner. Som till exempel ekonomi- eller personalavdelningarna. Men det är en annan frågeställning som vi får ta en annan gång.

Masterdata

Jag har tidigare skrivit om att det är lämpligt att skilja på masterdata, global referensdata och händelsedata, i artikeln ”Det är skillnad på data och data”. Vi vill förstås få koll på all data. Arbetssättet är ungefär lika för alla typer av data men det finns skäl att prioritera masterdata. Första skälet är att masterdata är grundläggande för övriga data. Har du inte koll på masterdata går det inte att få koll på övriga data. Har du koll på masterdata blir det relativt enkelt att få koll på resten.

Det andra skälet är att det är mer oklart var ansvaret för varje typ av masterdata ska ligga än för andra typer av data. Det är en delad resurs och är därmed utsatt för de krafter som inom ekonomi brukar kallas för ”tragedy of the commons”. Det vill säga att alla vill utnyttja det gemensamma men ingen vill ta ansvar för att vårda det.

Masterdata är vanligen kund- och produktdata, men kan också vara andra data.
Vi går i det följande igenom några masterdatadomäner.

Kunddata

Den centrala informationen om kunder är en typisk kategori av masterdata. Dit kan man räkna alla uppgifter om kunder (både privatkunder och organisationskunder) som namn, kontaktuppgifter, status med mera. Normalt omfattar det både befintliga och tidigare kunder. Ofta även prospekts, det vill säga personer eller organisationer som ännu inte är kunder men som man har valt ut som kandidater till att bli kunder.

Uppgifter om enskilda kontakttillfällen med en kund eller köptransaktioner klassas emellertid inte som masterdata eftersom det representerar händelser i tiden och därmed är händelsedata.

Alla verksamheter har eller borde ha en centraliserad hantering av kunddata. Ofta brukar det finnas i ett ERP-system eller CRM-system. Om kunddata finns spritt behöver vi ha mekanismer som håller ihop detta.

Något som vi brukar stöta på är att man saknar en tydlig livscykelmodell för kunder. När blir en kund en kund? Är det vid första köpet? Eller tidigare? När blir en kund en tidigare kund? Är en kund som inte handlat på tre år fortfarande kund? Om man inte har tydliga regler för detta går det inte att veta hur många kunder man har eller att räkna på det som kallas ”churn rate”, det vill säga kundbortfall. Sedan bör man ju också hålla reda på orsaken till att kunder slutar. Det kan vara vårt val, kundens val eller helt enkelt att kunden avlidit eller konkursat. 

De senaste årens lagstiftningar har också gjort att organisationer behöver ha bättre koll på kunduppgifter. Ett exempel är krav på skydd av personuppgifter (GDPR). Ett annat exempel är de krav finansorganisationer har på sig att ha noggrann kännedom om sina kunder för att kunna reagera på signaler om penningtvätt. 

Data om övriga intressenter

Nästan alla verksamheter behöver hålla reda på också andra intressenter än kunder. Det kan vara leverantörer, partners eller andra. Medarbetare i den egna organisationen och kontaktpersoner hos olika intressenter är också intressenter. Då behöver man bestämma sig för om man ska ha en så kallad intressentmodell (party model), det vill säga att man har entiteter som representerar alla organisationer och personer man behöver hålla reda på oavsett roll dessa har till ens verksamhet. Där finns de uppgifter som inte har med den specifika rollen att göra, som organisationsnummer och namn och typ av organisation.

Därutöver behöver man separata rollspecifika entiteter för varje roll i förhållande till vår verksamhet som intressenten har. En och samma organisation kan ju vara både kund och leverantör. En och samma person kan på samma gång vara kund, representant för ett kundföretag eller anställd hos oss. Dessa rollspecifika entiteter rymmer det som har att göra med just den specifika relationen.

En intressentmodell behöver man i de fall då det är viktigt att ha en direkt överblick över vilka roller en och samma part har i förhållande till oss. Det brukar vara fallet i sammanhang där man behöver ha direkt koll på dubbla roller hos sina intressenter, som fallet ofta är i finansiella verksamheter. För andra verksamheter är en intressentmodell ofta overkill.

Produkter

De flesta verksamheter har produkter eller tjänster av något slag som man erbjuder omvärlden. Ofta går tjänster under namnet produkter, och ur informationssynpunkt är det ingen större skillnad. Så även jag kallar här tjänster för produkter.

Ofta har man en hel flora av produkter och ofta har man oordning i namngivning, klassificering, livscykelhantering med mera. Ofta har man inte definierade begrepp för ”produkt”, ”produktvariant”, ”produktversion”, ”produktkomponent”, ”produktlivscykel”, ”produktgrupp”, ”produkttyp”, ”produktindivid”, ”produktstatus”, ”externt namn”, ”internt namn”, ”leverantörens produktnamn” med mera. Det här är viktigt att reda ut, liksom regler för namngivning.

Om man utvecklar en befintlig produkt är resultatet att betrakta som en ny produkt eller är det en ny variant av en den befintliga produkten? Vad är det som kännetecknar en produkt, till skillnad från en variant på en produkt? Och det här som vi säljer, är det en produkt som består av ett antal komponenter, eller är det en paketering av flera produkter? Allt detta måste redas ut och standardiseras om man ska få ordning på en produktflora.

Tillverkare och försäljare av fysiska produkter har ofta behov av omfattande data om sina produkter, baserat på olika branschspecifika regelverk. Det kan vara dokumentation av olika slag som materialdata, testdata med mera.

Data management öppnar för mer än management av data

Det är lätt att inse att det inte går att isolera uppgiften att ta hand om data från att fånga, formulera, dokumentera begrepp och terminologi liksom verksamhetslogik. Vanligen blir det även påkallat att driva arbetet att inte bara dokumentera utan även utforma och standardisera begrepp, benämningar och verksamhetslogik. Detta är något bra. En informationsmodell och arbetet med den är, om det görs på ett bra sätt, en utmärkt plattform för det.

Roadmap för data management

Hur kan man då ta sig an jobbet att bygga upp data management i en organisation? Så här brukar vi gå till väga i de sammanhang jag jobbat i:

1. Kartlägg verksamhets- och systemlandskapet

Vi skapar en gemensam karta av vilka funktioner verksamheten består av och hur de samverkar med varandra och med omgivningen. Vi ritar in applikationer och hur de är integrerade så att vi får en karta som visar hur applikationer och dataströmmar är djupt integrerade delar av verksamheten. Vi gör detta genom en serie mindre arbetsmöten med verksamhets- och it-specialister. Kartan behöver vi för att förankra och ge kontext till alla övriga dialoger och modeller.

Det här är ett arbete som brukar gå förvånansvärt fort. På ett medelstort företag tar det kanske två till tre arbetsveckor att få fram en karta som är tillräcklig för att gå vidare med. Men naturligtvis kommer den att fortsätta förfinas under resans gång.

Resultatet brukar bli att verksamhet och it för första gången ser en ritning över hur verksamheten hänger ihop i alla sina delar, och får en gemensam spelplan för den dialog som behövs för all gemensam utveckling av it och verksamhet. Vilket är grundläggande, inte bara för data management, utan för all verksamhets- och it-utveckling.

2. Kartlägg datastrukturerna

Vi gör en eller flera detaljerade informationsmodeller för att förstå vilka företeelser som hanteras, deras egenskaper och hur de representeras i data.

Det här är inget annat än informationsmodellering, fast mer detaljerat och noggrant än vad som är vanligt. Arbetet går vanligen fort om man har tillgång till material och kunskap från it-kunniga. Säg att det tar återigen i storleksordningen två till tre arbetsveckor att få fram en tillräckligt säker modell för att kunna gå vidare. Arbetet kan göras delvis parallellt med steg 1 ovan. Modellen kommer naturligtvis att uppdateras efter hand ju mer vi lär oss. Arbetssättet består i koncentrerade mindre möten med kunniga personer, kombinerat med egen genomgång av databas- och filbeskrivningar.

Modellerna ger oss en tänkt bild, en hypotes, om hur det ser ut men ännu har vi egentligen inte studerat verkligheten närmare, det vill säga data i sig. När vi verkligen dyker ner i data upptäcker vi saker som gör att vi får ändra i modellerna.

3. Prioritera datadomän

Vi väljer ut en viss datadomän att fokusera på. Normalt är det en masterdatadomän, vanligen kund- eller produktdata. Ofta är kriteriet det som känns mest akut, men egentligen borde man kanske också väga in var man enklast kan få tidig nytta. Normalt är det redan bestämt eftersom själva orsaken till att vi blev inkallade berodde på ett visst problem man känt av. Men det händer ändå ganska ofta att vi ser att det finns ett mer akut behov eller en mer grundläggande datadomän, så att vi gärna vill styra om ordningen.

4. Kartlägg data

Vi går metodiskt igenom all data för den utvalda domänen i de centrala databaserna, samt hur de hanteras i integrationer. Resultatet blir en rapport över hur tillståndet är för datadomänen.

Detta moment kan ta längre tid. Det är ett ganska mekaniskt, rakt och enkelt arbete, men det tar tid att verkligen traska igenom stora datamängder ur alla möjliga aspekter. Men låt mig säga att det tar i storleksordningen fem arbetsveckor. Arbetssättet är en genomgång av data i databaser med enkla verktyg som SQL eller liknande.

5. Kartlägg produktion och användning av data

Vi kartlägger hur och var data skapas, hur de transporteras, och hur det används. Ofta får vi gå vidare till externa leverantörer av data, ibland leverantörens leverantör. Likaså får vi ofta söka upp externa konsumenter av data. Vi får en bild av vilka behov som finns, hur de tillgodoses, vilka verkliga brister som finns i praktiken och hur dessa uppstår. Vi intervjuar då de som känner till integrationerna och de som har kunskap om de olika applikationerna och hur de används. Det kan ta från ett par arbetsveckor beroende på hur stort ekosystemet visar sig vara.

Det är först nu vi har en tillräckligt tydlig problembild för att veta vad som behövs göras. Tills nu har det handlat om kunskapsinsamling.

6. Planera åtgärder

Nu har vi en klar bild av var och hur problemen känns av och var de uppstår. Då är det lämpligt att sätta samman en åtgärdsplan. Av nödvändighet är den endast preliminär. Ju längre vi kommer i arbetet desto tydligare blir det vad vi behöver göra.

7. Bygg organisation och arbetssätt och sätt igång

Vi bygger en rudimentär organisation för data management av den aktuella datadomänen och sätter igång med de åtgärder som prioriterats. Det handlar om en rad åtgärder, från rent tekniska till förändrade beteenden i verksamheten. Både engångsåtgärder för att åtgärda brister och nya rutiner för att förebygga nya brister.

Det här arbetet tar egentligen aldrig slut utan fortsätter som ett lågintensivt arbete för alltid. En datadomän behöver alltid vårdas mer eller mindre kontinuerligt. Så det här är mer en första enkel och prövande uppstart av en förmåga i organisationen.

När vi har fått rull på den första datadomänen sätter vi igång med nästa. Nu har jag beskrivit arbetet övergripande men mycket mer finns förstås att säga om varje steg. Jag planerar att beskriva varje steg mer i detalj, i olika artiklar, framöver.

Men viktigt att påpeka redan nu är att inget av arbetet handlar i grunden om teknik. Tvärtom vad många system- och konsultleverantörer påstår finns det inga speciella systemplattformar som gör jobbet och det är sällan andra verktyg än de enklaste är till hjälp. Det säljs speciella masterdatasystem, men enligt vår erfarenhet skymmer de uppgiften i stället för att hjälpa.

Och tvärt om en vanlig uppfattning behöver inte en masterdata-satsning vara stor, dyr och konsultintensiv. I själva verket motverkar det syftet. Det handlar om ett uthålligt lågintensivt agilt arbete, en mognadsprocess, en resa där vi tillsammans utforskar våra data och vår gemensamma förståelse för vad de representerar och steg för steg bygger ett sätt att bättre ta hand om data. 

Invändning 1: Bör man inte ta fram problembilden först?

Jag tror att man kan invända följande: Bör man inte först och främst ta reda på vad problemen är, innan man sätter igång? Mitt svar blir att det är sällan de i organisationen har en tydlig överblick över sin dataresurs. Olika personer upplever problem i olika situationer men de är inte på det klara med hur orsakssambanden ser ut. Det krävs en kartläggning. Och det är vad vi gör i steg 1 till 5. Det är först när vi vet hur saker hänger ihop som vi lite mer utförligt kan intervjua olika nyckelpersoner och representanter för användare. Det är först då vi kan ställa rätt frågor, förstå svaren, samt sätta samman och presentera en tydlig gemensam problembild. Och det är faktiskt sällan som den första beskrivningen är speciellt intressant.

Det är som att gå till läkaren. Jag har ett symptom jag söker för. Läkaren börjar med att skicka mig till blodprov, sedan röntgen av lungor och hjärta, ultraljud av levern och så vidare. Vid återbesöket får jag veta att jag har begynnande diabetes, högt blodtryck och dåliga levervärden. Läkaren sätter utifrån dessa resultat samman en åtgärdsplan i dialog med mig.

Det jag sökte för var endast ett symptom, den ytliga signalen på att allt inte var bra. Den verkliga problembilden behövde vi komma fram till tillsammans. Läkaren ställde inte direkt en diagnos utifrån mitt symptom, utan skapade sig först en helhetsbild genom de olika testerna för att kunna ge rätt hjälp. Det är alltså inte så att hon bara frågar om det jag söker för och fixar det.

På samma sätt är det med en dataresurs. En stor del av arbetet handlar om att ta reda på hur saker och ting hänger ihop, vad de olika aktörerna behöver och har respektive inte har idag, och hur de olika orsakskedjorna hänger ihop. Att åtgärda handlar sedan om ett uthålligt arbete.

Invändning 2: Bör man inte bygga organisation först?

Vi behöver bygga en central stödfunktion och vi behöver bygga roller och arbetssätt i olika delar av organisationen. Ska vi inte börja med det och först därefter sätta igång? Det är en vanlig uppfattning, men min erfarenhet är att det inte fungerar. Kultur, arbetssätt och roller behöver mogna fram. Det behöver få ta tid. Det är en dålig idé att stressa fram detta. Det som fungerar är att börja med enklast möjliga process och organisation och låta det hela växa fram efter hand. Den kände dataspecialisten Bob Seiner kallar den hållningen för ”Non-invasive Data Management”. Och visst borde egentligen all verksamhetsutveckling vara icke-invasiv! Det vill säga att coacha individer och team så att arbetssätt får mogna fram på individerna och teamens egna villkor.

Invändning 3: Varför smådutta? Vi behöver en större transformation, och det genast!

Jag tycker att vid det här laget borde vi ha lärt oss att stora projekt är en dålig idé. Många små steg betyder inte att verksamhetsutvecklingen går långsammare. Det gör att förändringen över huvud taget fungerar och att förändringen går precis så fort som är möjligt. Vilket ofta är överraskande snabbt. Och att det blir bra.

Vi ser fram mot din syn på data management. Kommentera gärna!

/Peter Tallungs, IRM 

Det är skillnad på data och data

När vi ska bygga upp Data Management i en verksamhet, det vill säga verksamhetens förmåga att vårda och utveckla sin dataresurs, behöver vi en grundläggande indelning av data i kategorier. Ty olika kategorier av data behöver lite olika ansatser.

Det är praktiskt att dela in data i olika kategorier. Man stöter också på många olika indelningssätt i litteraturen. Varje sätt har sina styrkor och svagheter och passar därmed sina speciella syften.

Säg att vi ska bygga upp någon form av Data Management, det vill säga förmågan att vårda och utveckla vår organisations data som en värdefull resurs. Då finns det en grundläggande och praktisk indelning som jag tror är allmänt accepterad och som visat sig användbar tvärs över alla verksamheter.

Det är en grov indelning av verksamhetsdata i tre kategorier som skiljer sig åt beträffande vilka typiska problemställningar respektive kategori är förknippad med då det kommer till att ta hand om dataresursen. Därmed behöver varje kategori av data hanteras på lite olika sätt och med olika prioritet. Det som i grunden skiljer kategorierna i det avseendet är vilken livscykel verksamhetobjekten (som data i fråga representerar) har, i vilken mån data i den kategorin refereras eller uppdateras från olika funktioner i verksamheten samt i vilken grad dessa data har ett naturligt ägarskap.

De tre kategorierna är masterdata, globala referensdata och händelsedata. Dessa kommer jag nu gå igenom och ge exempel på.

Masterdata

Masterdata är vanligen kund- och produktdata, men kan också vara andra data. Det är data som uppfyller följande kriterier:

  1. Representerar centrala verksamhetsobjekt som har en livscykel över tid.
    Exempel: En och samma kund finns i vår verksamhet över en längre tid och kan ändra adress, status och till och med namn och andra uppgifter under sin livstid som kund och ändå ha kvar samma identitet. Ett annat exempel: En och samma produkt lever över en längre tid trots att den kan ändra status och andra egenskaper under sin livstid.
    Observera att det här inte handlar om hur länge man behöver spara data över tid, utan bara om hur länge verksamhetsobjektet har en aktualitet. 
  2. Refereras av många andra dataobjekt, särskilt händelseobjekt, och bildar därmed en bas för övriga data.
    Exempel: Kunder refereras av offerter och transaktioner, produkter likaså. Man kan säga att de verksamhetsobjekt som representeras av masterdata är centrala för verksamheten i det att de är mer eller mindre beständiga och refereras från många håll. Data som representerar dessa fungerar därmed som en slags bas och ankare i dataresursen. 
  3. Saknar ofta naturligt ägarskap. Många behöver kund- och produktdata men det är oklart vem som ska vara ansvarig för dessa. Masterdata är i likhet med gemensamma tillgångar i övrigt utsatt för det ekonomisk-sociala fenomen som kallas ”tragedy of the commons”: Hur en gemensam resurs riskerar att misshushållas, då ingen känner ansvar.
  4. Uppdateras ofta från olika verksamhetsfunktioner. Till exempel kan både sälj och marknad registrera nya kunder. Ofta har man ännu helt separat hantering av olika säljkanaler vilket betyder att online-kunder läggs upp helt separat. Eller så har man slagit ihop två verksamheter med överlappande kundregister. Adresser behöver kanske uppdateras både från offentliga källor och av kunden själv, via kundtjänst eller självbetjäning. Allt detta skapar typiska masterdataproblem som vi behöver hantera.

Globala referensdata

Referensdata är data som är till för att vara värdeförråd för egenskaper hos andra dataobjekt, det vill säga uppräkningar av giltiga värden. Det kan till exempel vara listan med Sveriges postnummer, alla produkttyper vi har, SNI-koder (Svensk Näringslivsindelning), länder i världen etcetera.

Kanske känns referensdata bäst igen som ”koder”, men en kod är egentligen endast ett av attributen för en förekomst av referensdata.

Vi inkluderar här inte lokala referensdata, till exempel de olika kundstatuskoder som finns ifall de endast används som värdeförråd för attributet kundstatus för kund. Skälet är att lokal referensdata har en naturlig hemvist. Ansvaret för vilka kundstatuskoder som finns hänger naturligt samman med ansvaret för kunddata. Det ingår i beskrivning av attributet kundstatus.

Referensdata har likt masterdata en livscykel. En statuskod kan till exempel ändra namn, börja vara giltig vid en tidpunkt eller upphöra vid en annan.

Globala referensdata har ofta inte ett naturligt ägarskap. Postnummer har visserligen en naturlig källa, Sveriges postnummerregister, men man behöver ändå se till att någon tar ansvaret för att tillhandahålla, tillgängliggöra och uppdatera listan internt i organisationen.

Referensdata representerar inte några egentliga verksamhetsobjekt i kontext av den aktuella verksamheten, utan varje entitet representerar bara en lista av giltiga värden för en viss egenskap hos ett eller flera verksamhetsobjekt.

Speciellt för referensdata är att de har en typisk uppsättning attribut som gäller för de flesta fall. Oftast ser man bara kod och namn, men en bruttolista över möjliga attribut borde kanske se ut enligt nedan. Detta gäller för alla referensdata, både globala och lokala.

Attribut för referensdata – bruttolista

AttributBeskrivning
KodKod eller id. Kan också fungera som kortnamn.
NamnFullständigt namn.
KortnamnEtt kortare namn för användning i de fall hela namnet inte får plats i något sammanhang, som till exempel i en valbar lista i ett användargränssnitt eller i en kolumnrubrik i en rapport.
DefinitionDefinition av värdet. Viktigt, men glöms ofta bort. Bör finnas med i informationsmodellen, och också vara tillgänglig i användargränssnitt.
BeskrivningBeskrivning utöver definition, i de fall det behövs.
NoteringEventuella noteringar i övrigt.
SorteringsordningEn siffra som anger i vilken ordning värdet ska listas, i en valbar lista eller dylikt, för det fall att sorteringsordningen inte ska vara alfabetisk. Glöms ofta bort, men behövs för att värdena ska listas i en naturlig ordning och på samma sätt överallt där de visas.
Gäller från och med – datumFör de fall att listan med giltiga värden ändras.
Gäller till och med – datumFör de fall att listan med giltiga värden ändras.

Händelsedata

Data som inte är masterdata eller referensdata avser vanligen något som är en händelse i tiden, som en transaktion av något slag, till exempel ett köp eller en order. Hit kan man också hänföra sådant som en offert eller faktura. De har kanske en viss giltighet över tid, men ändrar aldrig någon egenskap utöver status.

Händelsedata har därmed till skillnad mot masterdata och referensdata ingen längre livscykel. De är att betrakta som ett snapshot i tiden och kan därmed aldrig ändras, utöver möjligen sin status. Dessutom hör händelser tydligt hemma i speciella verksamhetsfunktioner, då de inträffar i ett speciellt sammanhang. Därmed är de inte på samma sätt en delad resurs som masterdata och globala referensdata. Sist men inte minst viktigt, om du har fått ordning på masterdata och globala referensdata har du en fast grund att stå på. Allt detta talar för att händelsedata blir smidigare att hantera.

Viktigt att veta är att det som i en verksamhet har kort livslängd och därmed kan klassas som händelsedata kan i en annan verksamhet ha en beständighet och därmed behöva klassas som masterdata. Ett exempel kan vara avtal. I en verksamhet kan ett avtal gälla för endast en leverans och därmed snabbt vara överspelat. I en annan verksamhet löper avtal över lång tid och används för många leveranser. I det första fallet är det händelsedata, och i det andra fallet masterdata.

Jämförelse mellan kategorierna av data

Vi kan nu jämföra de tre kategorierna av data beträffande de faktorer som bör påverkar i vilken ordning vi bör adressera att ta hand om dataresursen. De fyra faktorer som jag kan se redovisas i tabellen nedan.

Vilka faktorer som påverkar prioriteringen för Data management för en datatyp

PåverkansfaktorMasterdataGlobal referensdataHändelsedata
Lever över tidJaJaNej
Refereras från många ställenJaJaNej
Saknar ofta naturligt sällskapJaJaNej
Uppdateras ofta från flera ställenJaNejNej

Syftet med indelningen

Varför är det bra att dela in data på detta vis? Jo, om vi verkligen ska ta hand om våra datamängder så ställer de här kategorierna olika krav på oss som verksamhetsförmåga. Masterdata och global referensdata utgör grunden och själva förankringen för all data. Det vill säga all övriga data är beroende av masterdata och global referensdata. Därför behöver vi först få ordning just där. Har vi gjort det så faller det övriga på plats ganska naturligt. Att däremot börja med händelsedata när vi har en skakig grund i till exempel kund- och produktdata är ogörligt.    

Jag brukar jämföra det med strategin för att röja hemma i villan. Om man först skapar ordning i förvaringsutrymmena, det vill säga på vinden, i källaren och i garaget, så blir det mycket lättare att ordna upp i resten av huset. Tvärt om är ingen bra idé.

Masterdata kommer som sagt först i prioritet, tillsammans med global referensdata. Händelsedata kommer naturligt senare i prioritet.

Detta är förstås en förenkling. Det kan finnas annat som gör att man behöver prioritera annorlunda. Men då blir det kanske till ett pris. Utan en fast grund är det svårt att göra någonting bra.

Data management

Vi bör givetvis ta hand om all data. De olika kategorierna av data har mer gemensamt än som skiljer i detta avseende. Men masterdata har ändå en nyckelroll i detta arbete. Därför brukar man se masterdatahantering som ett eget område. Globala referensdata har i viss mån liknande problem men är vanligen lättare att komma till rätta med.

Vi ska i nästa artikel titta på vad Data Management handlar om.

Till dess, vad anser du om indelningen som jag beskriver här? Har du en annan syn? Eller bättre beskrivning av respektive kategori?

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 4 mars. Peter Tallungs tittar närmare på vad Data management handlar om och ställer frågan: Hur kan vi bygga en förmåga att ta hand om den resurs som vårt data är?  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Informationsmodellen som domänmodell

En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar. Det vill säga allt det som verksamheten behöver hålla koll på, med andra ord verksamhetens domän.

Varje gång jag säger att informationsmodellen beskriver information så skorrar det lite falskt i mig. För jag tycker inte att det är helt rätt beskrivet, eller i varje fall inte speciellt klargörande.
Ja faktiskt till och med missledande, på sätt och vis. För då utelämnar vi det viktigaste. Låt mig förklara.

Det är sant att en informationsmodell beskriver strukturen hos informationen i något sammanhang. (Eller ofta snarare hur den bör vara.) Det kan vara data i en databas, i en fil, i en applikation eller en tjänst. Men det kan också vara den konceptuella strukturen av den information som delas av en verksamhet eller en verksamhetsfunktion.

Så långt är allt väl. Lätt att förstå och prata om. Men sedan kommer det som komplicerar, men som också gör det hela mer intressant. Mycket mer intressant i min mening.

Data i sig representerar i sin tur något som finns där ute i verkligheten. Varje entitet i en informationsmodell representerar en klass av företeelser som verksamheten behöver hålla reda på förekomster av. Det kan vara kunder, produkter, produkttyper, ordrar med mera.

Den dubbla rollen

Alltså, informationsmodellen avbildar både strukturen hos data i sig och utgör samtidigt en modell av domänen det vill säga de företeelser som verksamheten behöver hantera.

Informationsmodellen är följaktligen lika mycket en domänmodell som en modell över informationen som behövs för att hantera domänen.

En domänmodell beskriver verksamhetens ”värld”, de företeelser som behöver hanteras av verksamheten, beskrivna och benämnda på ett sätt som passar verksamhetens sammanhang och syfte. Den vill uttrycka den gemensamma förståelsen av det som hanteras och utgöra det gemensamma språket. Det är svårt att överdriva betydelsen för en organisation av att utveckla och vårda den förståelsen och det språket.

Det här är något som sällan kommer upp på bordet, men som jag menar är väsentligt för att förstå vad vi egentligen håller på med när vi modellerar.

Informationsmodellens största potential

Det är just där, som domänmodell, informationsmodellens största potential ligger menar jag, och samtidigt den hittills mest underutvecklade. Vi har, om vi blir skickliga i vårt värv, en förmåga att beskriva, hantera och utveckla hela verksamhetslogiken på ett sätt som annars inte är möjligt.

Jag har sett hur informationsmodellen enkelt och naturligt kan fylla en central och viktig roll i en verksamhet. En informationsmodell kan bli en gemensam karta över det som verksamheten hanterar, en domänmodell. Den kan bli bäraren av de gemensamma begrepp och det gemensamma språk som vi behöver. Jag har till och med sett att den kan bli bäraren av hela den grundläggande verksamhetslogiken. Och inte bara det, den kan även bli plattformen för utforskandet och utvecklandet av verksamhetslogiken och språket. Och det med överraskande enkla medel.

Informationsmodellering kan därmed fylla en mycket mer central roll i analys och utveckling av en verksamhet och dess informationssystem än den gör idag. Inte bara vad gäller analys och utveckling. Vi har ju i alla sammanhang behov av att arbeta för en gemensam förståelse, krispiga begrepp och ett gemensamt språk.

Fast i så fall behöver vi tänka om och tänka nytt. Vi behöver öppna upp beskrivningstekniken till en helt annan kraftfullhet. En huvudtanke med denna artikelserie är att föreslå hur vi kan få till detta.

Vad säger ”information” egentligen?

Nu till något helt annat. Ett annat sätt som namnet ”informationsmodell” skorrar lite falskt för mig har med förledet ”information” att göra. Ett måhända mindre problem, men ändå irriterande.

Om jag säger till min granne att jag jobbar med informationen på ett företag så skulle hon anta att jag är informatör eller skribent av något slag. Och kanske skulle jag sedan försöka förtydliga genom att fortsätta med att jag arbetar med en modell över informationen. Då skulle hon nog, om hon inte ryckte på axlarna och gav upp, göra sig en bild av att jag på något sätt ser över hur företaget ska informera externa eller interna intressenter. Eller kanske ser hon framför sig hur jag tar fram en modell för omvärldsbevakning. Så låt oss vara överens om att ”information” inte är en tillräckligt specifik benämning på det vi modellerar.

I själva verket beskriver en informationsmodell inte strukturen på information i största allmänhet utan endast strukturen och meningen hos den information som behöver listas i en verksamhet. Det vill säga den data som beskriver klasser av företeelser som har förekomster av något slag. Förekomster av saker som verksamheten behöver hantera och därmed behöver lista på något sätt. Till exempel kunder, ordrar, produkter, anställda, postnummer och tusen andra saker.

Och egentligen aldrig det som man i första hand tänker på som företagets information som företagets historia, affärsplan, årsredovisning, ägarförhållande, affärsidé, verksamhetsbeskrivning, kundvärde, marknad, kreditvärdighet med mera.

Kanske det skulle vara tydligare att prata om ”datamodell” som amerikanarna gör?

Så vad blir mitt förslag på namn på de modeller vi gör? Tja, traditionen gör väl att vi får fortsätta att säga ”informationsmodell”, fast det inte är speciellt förklarande och måhända tar emot lite grand. Och vi kan väl tillstå att ”datamodell” är en synonym. Och vara medvetna om att vi i själva verket modellerar en domän i sig utöver informationen och språket om domänen. Även om vi kanske ännu inte är mogna för att kalla det för domänmodell?

Vad tycker du? Kan du se informationsmodellens roll som domänmodell?  

/Peter Tallungs, IRM

Prenumerera på artikelserien om informationsarkitektur

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 25 februari. Det handlar då om skillnaden mellan data och data.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Informationsarkitekter: De två kulturerna

En roll med namnet informationsarkitekt har uppstått två gånger i historien i två olika sammanhang och med olika tyngdpunkt. Det kan skapa förvirring. Men det kan också vara en möjlighet.

Informationsarkitekten – sprungen ur databasadminstratörens roll

Den första gången någon kallades ”informationsarkitekt” var på mitten av 1970-talet, men professionen växte först fram på allvar ur databasadministratörernas värld på 1980-talet. I början handlade det om att designa databaser. Rollen utvecklades så småningom till att handla om det större perspektivet, att bringa ordning i en verksamhets data och information tvärs över olika källor, verksamhetsfunktioner, databaser, applikationssystem, integrationer, tjänster, rapporter med mera.

Tack vare den nära kopplingen som en verksamhets data har till begreppen och språket i en verksamhet så växte det fram så småningom på sina håll ett ansvar för begrepp och språk. Men fortfarande handlar det oftast om en nära koppling till informationstekniska system, och vanligen med ett mycket brett fokus över många enskilda tillämpningar, databaser, integrationer, rapporter. Ibland är uppgiften att skapa en gemensam grund tvärs över flera verksamheter.

Det är i det skrået jag och mina kollegor på IRM arbetar. Det finns ingen särskild utbildning för detta, men det finns branschorganisationer som DAMA (Data Management Association International) med konferenser och på webbplatser som TDAN (The Data Administrators Newsletter) finns ett rikt material att ta del av.

Informationsarkitekten – sprungen ur webbdesignerns roll

Den andra rollen med samma namn uppstod ett par decennier senare.  Boken ”Information Architecture for the World Wide Web” av Louis Rosenfeld med flera som kom 1998 brukar nämnas som startpunkt. Boken brukar kallas för ”Isbjörnsboken” med anledning av förlaget O’Reillys gimmick med djur på omslaget. Den manifesterade informationsarkitektens roll som en utbrytning ur webbdesignernas skrå. Författarna skrev om hur man skulle strukturera information på en webbplats. Rollen har sedan breddats till att handla om hur man strukturerar information för en viss tillämpning, vilken som helst, inte bara webbsidor.

För denna roll finns det idag flera utbildningar på svenska och utländska universitet. När man googlar på ”Informationsarkitekt” eller liknande får man nästan bara träff på rollen eller kunskapsområdet i denna nyare betydelse.

Två skilda skrån

Vi behöver för den fortsatta diskussionen kunna skilja dessa två rörelser åt. Det finns de som har börjat kalla vårt äldre område för Enterprise Information Architecture” vilket jag tycker är klargörande. Ty vårt arbete är ju inte begränsat till en specifik tillämpning utan spänner över en hel verksamhet, eller i alla fall stora delar av en verksamhet. En svensk översättning av termen kunde vara ”Verksamhetsinformationsarkitektur” om det inte vore så långt och tungvrickande. Den andra nyare inriktningen skulle kanske kunna heta Service Information Architecture” eftersom den handlar om hur information presenteras inom en enskild tjänst, till exempel en webbapplikation, en webbsida, en elektronisk tjänst, en broschyr eller liknande. Men som sagt, det är endast min egen tanke.

Det finns förstås ingen motsättning mellan dessa roller. Det finns beröringspunkter, men också skillnader i tyngdpunkt. Det märkliga är att det här är två olika kulturer som sällan möts. Vi inom dessa två områden borde interagera mera, men i stort sett har det fortsatt som två olika yrkesgrupper utan vidare kännedom om varandra.

Vad skiljer oss åt?

Det finns mycket som är gemensamt mellan rollerna eftersom det i båda fallen handlar om information och data.

Den stora skillnaden ligger i den yngre rollens fokus på hur man som användare brukar någon form av interaktiv tjänst. Rollen har ju sitt ursprung inom interaktionsdesign. Detta avspeglas i utbildningsinnehållet som har fokus på olika typer av användargränssnitt som kurser i webbutveckling och interaktionsdesign.

Detta saknas nästan helt och hållet i den äldre rollen som jag och mina kollegor är en del av. Den fokuserar på struktur, mening och egenskaper hos data och information i sig, gemensamt över alla tillämpningar, liksom över hela datadistributionen vilket naturligtvis ändå är en nödvändig grund för användbarheten för alla tillämpningar av data. Man kan säga att vi är ”presentationsagnostiker”. Det vi tar fram måste fungera för en hel verksamhet (eller ibland flera samverkande verksamheter eller hela branscher) tvärs över alla enskilda kommunikationskanaler och sammanhang.

Jag har också förstått att eftersom informationsarkitekter av den yngre rollen ligger så nära interaktionsdesigners i sitt arbete har de haft och har kanske fortfarande svårt att urskilja sig från de senare och motivera sin existens i den världen.

Kan vi närma oss varandra?

Om jag fick önska något skulle det vara att vi informationsarkitekter, oavsett inriktning kunde jobba närmare varandra och lära av varandra. Jag är säker på att vi av den äldre skaran skulle behöva bli bättre på informationsdesign och att de av den nya skaran skulle må bra av att lyfta blicken från enskilda tillämpningar till det större sammanhanget.

Men första steget måste då bli att vi känner till varandras existens. Det är med förhoppningen att bidra till den kännedomen jag skriver detta.

Vad säger du? Vad gör vi åt detta?

/Peter Tallungs IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 18 februari. Det handlar då om informationsmodellen som domänmodell. En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Informationsarkitektur – ”To make sense of any mess”

Ett försök att ringa in vad det handlar om.

Jag och mina kollegor är informationsarkitekter. Vi tar uppdrag där man vill ha hjälp med att få koll på verksamhetens data och dess struktur. Det här är ett försök att ringa in vad det handlar om.

När efterfrågas en informationsarkitekt?

De flesta organisationer hamnar förr eller senare i ett läge där man inte har så bra koll på sina datamängder som man behöver. Problemen kommer smygande och accelererar. Tyvärr sker tillvänjning parallellt, och det är svårt att få till kraft att ta tag i saken. Det är svårt att motivera ledningen att satsa på något så föga hajpat, något som i bästa fall ger ett resultat som ser ut som status quo. Att bara städa upp i det befintliga när det finns nya spännande tekniker och affärsmöjligheter.

Man har dragit på sig något som kan liknas vid en teknisk skuld, men som borde kallas verksamhetsskuld. Hur stor en verksamhetskuld är kan bedömas av frekvensen av ”What the F—k” som hörs närhelst man behöver rota i kökkenmöddingen av begrepp och data. 

Vanligen är det något annat som triggar till handling, så att man kallar in oss, något som känns som trängande eller attraktivt. Här är några typiska triggers:

Man:

  • behöver byta ut sitt centrala affärssystem (ERP-program)
  • vill införa ett säljstödsystem (CRM-införande)
  • vill bygga upp en integrationsplattform och ett integrationsteam för att lättare integrera interna och externa funktioner, processer och system (Integrationsprogram)
  • vill bygga datatjänster som externa parter kan använda
  • vill lägga en ny grund för dataanalys och rapportering (Business Intelligence-program)
  • vill lägga en grund för analys av ostrukturerade datamängder (Data Science-/Maskininlärning-/AI-/IoT-projekt)
  • har nya krav på rapportering till myndigheter (Compliance-projekt)
  • behöver få kontroll över sina kunddata (Masterdata-projekt, Kunddata)
  • behöver strukturera sin produktportfölj för bättre ordning (Product Lifecycle Management-projekt).

Det dessa initiativ har gemensamt är att de ställer krav på att man har kontroll på vilka data man har, hur data hanteras och vad data representerar. Det är då vi efterfrågas. Fast inte alltid från början i ett sådant projekt utan först en bit in, när man börjat köra fast. Man vill gärna tro att projektet bara handlar om teknik, men har nu upptäckt att grundproblemet är att man inte har koll på sina datamängder, begrepp och språk.

Det är just den typen av problem vi går igång på. Den amerikanska informationsarkitekten Abby Covert är den som sagt det bäst, det vi gör: Det handlar om att ”make sense of any mess”: ”att göra en röra begriplig”.

Vad gör jag som informationsarkitekt?

Arbetet brukar följa några vanliga spår:

  • Kartlägga vilka data som hanteras, eller behöver hanteras, i en verksamhet, vad de representerar för företeelser som verksamheten behöver hålla reda på, liksom företeelsernas egenskaper och relationer.
  • Kartlägga hur centrala datamängder skapas, fångas, lagras, distribueras, hanteras och används, idag.
  • Ge förslag på vad man behöver göra och på vilket sätt, för att hantera data och komma tillrätta med brister.
  • Etablera ett tydligt och effektivt gemensamt språk för de företeelser som representeras av data, inklusive företeelsernas egenskaper och verksamhetsregler.

Samtidigt ligger som en underström i arbetet det som vi vill se som den egentliga uppgiften:

  • Skapa gemensam förståelse för hur man kan ta hand om sina data och sina begrepp och att få till arbetssätt och organisation för att kontinuerligt vårda och utveckla detta.

Kultur och arbetssätt behöver få mogna fram så att organisationen i fortsättningen själv ska kunna hantera kunskapen om sina data, sina begrepp och sitt språk på ett hållbart sätt. Vi vill alltid vara ”spelande tränare” till individer, team och hela organisationen. Vi utvecklar kultur och arbetssätt, inte genom att bara prata utan genom att själva dela vardagen med medarbetarna. Vi kan praktiskt visa hur, inspirera och stödja.

Vad bör en informationsarkitekt kunna?

En informationsarkitekt kan ses som en specialiserad verksamhetsarkitekt, en som har inriktning mot data, information, språk och begrepp. Som sådan behöver jag röra mig tvärs över verksamhet och it. Jag behöver tillgång till databaser och filer, då det är där data finns. Jag behöver intervjua it-folk, för det är de som vet var data skapas, lagras, transporteras och transformeras. Jag behöver tala med och förstå verksamhetsfolk, särskilt de i praktiska operativa och analytiska funktioner, för det är de som använder och skapar data.

Därmed behöver jag vara bekväm med att gräva i datastrukturer i databaser och filer. Jag behöver vara analytisk och envis, hitta samband åt olika håll, knyta ihop delar med varandra och till helheter. Jag behöver tycka att det är roligt att skapa krispiga definitioner och korrekta namn på saker och ting. Men samtidigt behöver jag lyssna och kunna kommunicera pedagogiskt, både brett och djupt. Allt detta målar upp bilden av en nörd, en kommunikativ nörd.

Jag drivs av det där lilla pirret när man börjar ana hur saker hänger ihop. Det som får mig att gräva vidare. Till aha-upplevelsen när det plötsligt faller på plats. Bara för att strax därpå se att det öppnar upp för nya frågeställningar!

Vilka är informationsarkitektens verktyg?

I likhet med övriga arkitekter arbetar vi med modeller. Modeller är arkitekters viktigaste verktyg. Modeller är – rätt använda – kraftfulla sociala tanke- och kommunikationsverktyg. De kopplar ihop våra hjärnor, alla vi som deltar i arbetet, och hjälper oss att skapa gemensam förståelse, gemensamt språk och kan också bli den gemensamma arbetsplattform vi behöver för vårt kontinuerliga arbete. 

Den vanligaste typen av modell för en verksamhetsarkitekt är informationsmodellen. Den bär vår framväxande gemensamma förståelse för vilka data som finns och vad de betyder, samt språket för allt detta.

Utöver informationsmodellen, till och med före denna, brukar jag ta fram en funktions-/applikationskarta. Den visar vilka operativa delar verksamhetens är uppbyggd av samt hur de samverkar som ett ekosystem med varandra och med omgivningen. Den visar också hur systemportföljen är en djupt integrerad del i verksamhetens funktioner. Kartan kan jag sedan använda för att kartlägga hur data strömmar genom verksamhetens delar och it-system.
Kartan ger översikt och sammanhang. Därmed förankrar den alla övriga modeller och dialoger i sin relevanta kontext.

I övrigt behöver vi bygga upp ett bibliotek för dessa dokument samt en plattform för att publicera och kommunicera resultat och underrättelser till alla berörda parter.

Hur stort är arbetet med informationsarkitektur?

Det här är ett arbete som mår bäst av att drivas agilt. En eller ett par personer är drivande och involverar de som behövs efter hand. Den första nyttan kommer snabbt, men det är viktigt att få till en kontinuitet. Det handlar om att med tiden få organisationen rustad för att kunna ta hand om sina data, sina begrepp och sitt språk. Det är något som inte kan forceras utan bör få tid att mogna fram. Och man blir aldrig klar. Det finns alltid nya frågor att ta sig an. Med framgång kommer hunger efter mer.  

Vad ger en informationsarkitektur?

Informationsarkitekturen ger en grund för hela organisationens hantering och utnyttjande av data, inte minst då det gäller utveckling av nya sätt att använda data. Om man verkligen tänker efter vad det betyder att ha koll på sina data och ha tydliga begrepp, så inser man hur viktigt det är.

Det första värdet av arbetet är att all utveckling, vare sig i projekt eller löpande, där data är en väsentlig del går lättare, snabbare och med mindre risk.

Låt mig ge ett exempel. På en bank fick vi så småningom ordning på hanteringen av data och alla tusentals begrepp. Då gav vi oss på att försöka uppskatta den kostnads- och tidsbesparing som detta gav, vad beträffande den ständigt pågående verksamhets- och systemutvecklingen, som var en stor del av den totala budgeten.

Som en grund tog vi först reda på hur många mantimmar per år som användes för utvecklingsarbete, vare sig det var under arbetsformen projekt eller förvaltning, eller det var tid som hamnade på verksamhet eller it. Sedan intervjuade vi verksamhets- och it-utvecklare av olika slag och resonerade oss fram på följande sätt: Första frågan var hur stor del av all utvecklingstid som omfattade funktioner där förståelsen av data var en central del av problematiken. Svaret vi kom fram till blev en uppskattning på 60 procent. Nästa fråga blev följande: Hur mycket tid spar du i ett sådant arbete om vi har koll på data och begrepp? Uppskattningen blev 60 procent av tiden, tvärs över alla faser i arbetet, från analys och krav till implementation, test och förvaltning, liksom tvärs över alla involverade roller.

Det kan tyckas mycket, men alla som varit inblandade i utvecklingsprojekt i en dataintensiv verksamhet vet hur stor del av arbetet som handlar om att försöka förstå vad saker och ting egentligen betyder och hur man ska hantera det. För att inte tala om de överraskningar som kommer sent i projektet då man inser att man har pratat förbi varandra.

Det innebär att den totala tids- och kostnadsbesparingen för utveckling, i den koncernen skulle bli 60 procent x 60 procent, vilket blir runt 36 procent. Vi multiplicerade den siffran med hela den årliga utvecklingskostnaden och fick fram en uppskattad årlig besparing på runt 70 miljoner kronor. Den summan vågade vi nästan inte visa för ledningen för att inte misstänkas för att vara orealistiska.

Men alla inblandade såg det som helt rimligt. Och man såg också att denna besparing egentligen bara var den lilla effekten. Det finns en större effekt av att kunna ta hand om sina data, och att ha ett väldefinierat språk för sina analyser och rapporter. Det visade sig att risken för försenade eller misslyckade projekt minskade dramatiskt. Vi kunde komma ut med datadrivna tjänster snabbare och smidigare. Vi kunde nu göra saker som inte tidigare var möjliga. Vi kunde använda data till nya tjänster och produkter. Det är svårt att överskatta vad det betyder.

Än idag, tio år senare, är de begrepp, språk, förståelse och arbetssätt vi tillsammans byggde upp, en självklar kärna i företagets it- och verksamhetsutveckling.

Jag har svårt att tänka mig någon annan satsning som ger mer tillbaka per spenderad krona och med större säkerhet.

Det förutsätter förstås att man vet hur man gör. Hur man kan bygga ett effektivt och förståndigt arbetssätt. Hur man kan skapa engagemang och driva arbetet på ett hållbart sätt.

Om detta vill jag skriva.

Vad tycker du? Har du en annan syn på området Informationsarkitektur? Vill du att vi tar upp något specifikt inom området? Kommentera gärna! Vi ser fram mot en dialog

/Peter Tallungs IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 11 februari. Det handlar då om rollen informationsarkitekt. En roll med namnet informationsarkitekt har uppstått två gånger i historien i två olika sammanhang och med olika tyngdpunkt. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.