top of page
  • Skribentens bildPatrik Hallén

Så undviker du att drunkna i havet av information/data

Uppdaterat: 4 mars

Alla företag och organisationer har i samband med införandet av GDPR tvingats kartlägga och klassificera information och processer i en omfattning som de tidigare inte varit i närheten av. Inte sällan har arbetet initierats av juristavdelningen, hamnat i knät på HR som har klart mest av personinformation, för att slutligen bli IT-avdelningens nöt att knäcka - ”Ni kan ju ändå mest om vilken data vi har i våra system”.


Så undviker du att drunkna i havet av information/data

Från min roll som rådgivare i metodfrågor har jag med stigande förvåning sett hur man startat stora kartläggningsprojekt utan att ens fundera på skillnaden mellan information och data. 


Här är min enklaste definition:

Information är ett uttryck för vad vill komma ihåg. Data är hur vi har realiserat detta genom att lagra det på ett visst sätt.

Detta bygger givetvis på standards så jag vill inte ta åt mig äran för att ha gjort uppdelningen, men formuleringen är min egen.


För att knyta an till GDPR så är således personinformation ett uttryck för vad vi vill komma ihåg om en person, och persondata beskriver hur vi har realiserat detta genom att lagra det på ett visst sätt (databas, epost, post-it-lapp, personalliggare etc).


Men det finns en tredje storhet där man talar om Information och Data, nämligen själva föremålet. I fallet med GDPR så är det själva personen, den fysiska förekomsten med dess inneboende egenskaper och kvaliteter.


Vad säger standard?


Inom verksamhetsarkitektur har olika skolor vuxit fram, där en del inte skiljer på det medan andra gör det. Vi på aRway har i det här fallet valt att följa Professor Scheers forskning och SAP:s tillämpning av det. Denna backas även upp av forskning från t ex Global University Alliance.


Uppdelningen är enkel:

  • Business Object

  • Information Object

  • Data Object

Engelska är universalspråket inom Enterprise Architecture men de översätts rakt av till svenska: Verksamhetsobjekt, Informationsobjekt och Dataobjekt.


Det som är svårt är att förstå exakt vad det innebär. Jag ska göra ett försök att beskriva det utifrån ett exempel med en Loka-flaska.


Exempel: Tillverkning av en Loka-flaska


Vad är en Loka-flaska, egentligen?

Vid första anblicken av en Loka-flaska ser de flesta en miljövänlig* behållare som innehåller kolsyrat vatten.  Men om man frågar en marknadsförare så är den en produkt som släcker törst och som finns i flera olika förpackningsstorlekar.

Flaska med Loka Päron

Samma fråga ställd till en logistikchef ger svaret att den specifika flaskan tillverkades i en batch ett visst datum och levererades via ett distributionscenter till en lokal dagligvaruhandlare. En titt i systemet som utformar etiketten visar att det finns attribut som ska fyllas i för att etiketten ska vara fullständig: ”Bäst-före-datum”, ”Ingrediens - Salt” och en länk till en grafisk databas som lagrar bilder och logotyper. Detta visar att Loka-flaskan betyder olika saker  för olika intressenter:


Olika intressenter har olika behov

Tillverkningsprocessen formligen sprutar ut flaskor med exakt rätt mängd och med etiketten placerat på exakt rätt ställe. För en verksamhetsarkitekt beskrivs detta som ett verksamhetsobjekt.


För att följa lagar och regler måste vi spara på oss en mängd information om en Loka-flaska: Tillverkningsinformation, Innehållsinformation, Logistikinformation och Försäljningsinformation. För en verksamhetsarkitekt beskrivs detta som ett informationsobjekt.


För att kunna hantera all denna information har vi infört ett antal IT-system, några säkerligen standard och en del egenutvecklade. Gemensamt för dessa är att de strukturerar informationen i relationsdatabaser som utformats med exakta specifikationer om vad ett attribut ska heta och vilken datatyp (datum, heltal, text) som kan lagras. För att effektivt överföra data från databasen skapas en samling av data som är relevanta för mottagaren. Data ska t ex överföras till en laserskrivare som etsar fast datum och batchnummer på flaskan. För en verksamhetsarkitekt beskrivs detta som ett dataobjekt.


Sammanfattning

  • Verksamhetsobjekt - ett verkligt ting

  • Informationsobjekt - information om ett verkligt ting

  • Dataobjekt - realiseringen av information om ett verkligt ting

Metaobjekt I32 Verksamhetsobjekt, I31 Informationsobjekt och D41 Dataobjekt

Slutsatser

För att kunna gå från en idé till realisering för att kunna sätta upp en effektiv tillverkning med data som överförs mellan IT-system och maskiner har det visat sig vara nödvändigt att skilja på Information och Data.


Detta gäller även om anledningen till kartläggningen är GDPR eller robotisering.

Om du tycker att GDPR-arbetet gått trögt och verkat alltför komplext så kanske detta är en av anledningarna - ni har missat att dela på vad som är information och vad som ära data?


Behöver ni hjälp att komma igång med modellering av information och data?

Vi kan hjälpa er komma igång med hjälp av utbildningar och workshops.



bottom of page