Inlägg

Modellmönster: Ekonomisk redovisning – del 1: Konto och transaktioner

En viktig del av informationshanteringen i en verksamhet handlar om att följa hur pengar rör sig genom verksamheten och hur pengar intjänas och spenderas. I två artiklar går jag igenom mönster för ekonomisk redovisning. De mönster som jag tar upp har egentligen en bredare tillämpning än vad artikelrubriken säger. Överallt där man behöver hålla reda på tillgångar i olika poster som till exempel lagerhantering är det användbart att tänka i ”konton”, ”posteringar” och ”transaktioner”.

Mönster 1: Konto och Postering

Den grundläggande idén bakom ekonomisk redovisning är att man har olika högar med pengar för olika syften, och att vi registrerar hur pengar flyttas mellan högarna. Vi kallar en sådan hög för Konto.

Det behöver inte handla om pengar. Vilka resurser som helst kan hanteras, och hanteras i olika verksamheter, på samma sätt, som till exempel lagervaror eller poäng av olika slag.

I de flesta sammanhang vill vi inte bara hålla reda på hur mycket det finns på kontot utan även varje förändring som påverkat innehållet.

Ett konto håller saker av värde – pengar eller gods.

Pengar, eller gods, kan endast läggas till eller tas bort genom att göra en Postering. Posteringarna utgör tillsammans en historik av alla förändringar på kontot. Beloppets tecken (plus eller minus) anger om posteringen är en debitering eller kreditering (insättning eller uttag).

Saldo, hur mycket det finns på kontot vid ett givet tillfälle, är en nettoeffekt av samtliga posteringar på kontot fram till den valda tidpunkten. Regeln innebär att saldot beräknas varje gång den efterfrågas. Det hindrar inte att föregående saldo lagras internt från gång till gång för att snabba upp beräkningen.

Med detta mönster kan man också se hur saldot har ändrats under en tidsperiod. Ett Kontoutdrag är en lista på samtliga posteringar som gjorts under en tidsperiod.

Lägg märke till att man vanligen håller reda på två tidpunkter för en postering. Den tidpunkten då posteringen gäller, samt tidpunkten då posteringen registrerades.

Det är ofta så att vi behöver veta både tidpunkten för en händelse i verkligheten och tidpunkten för vår kunskap om denna händelse.

Mönster 2: Transaktion

En kontoändring innebär vanligen att ett belopp flyttas från ett konto till ett annat. Det räcker oftast inte med att registrera att beloppet har kommit eller gått utan vi måste också hålla reda på varifrån och varthän.

En Transaktion länkar explicit ihop ett uttag från ett konto med en insättning på ett annat. Att två posteringar hör samman på detta sätt visar på en viktig bokföringsprincip. Pengar, eller gods, uppstår aldrig ur intet och de försvinner aldrig, de bara flyttas runt mellan olika konton.

I bokföringssystem strävar vi efter att få kontona balanserade, det vill säga att få saldo lika med noll vid en viss tidpunkt i affärscykeln (bokslutet).

Med hjälp av explicita transaktioner bygger vi in denna kontroll i själva strukturen. Det gör det lättare att hitta läckor i systemet.

Märk att jag satt en tvåa vid relationen från Transaktion till Postering, detta för att markera att en transaktion måste omfatta precis två posteringar, varken mer eller mindre. Fast man kan egentligen mycket väl tänka sig transaktioner som omfattar ett godtyckligt antal uttag och insättningar, fast alltid minst två, bara summan blir noll. I själva verket är den tvåvärda transaktionen endast ett specialfall av den flervärda.

Mönster 3: Transaktion utan explicita posteringar

I kontosystem med endast tvåvärda transaktioner behöver man egentligen inte en särskild entitet för posteringar, utan kan förenkla modellen enligt följande.


Mönster 4: Summakonto och detaljkonton

I kontosystem är det ofta användbart att gruppera konton till summakonton. Om jag till exempel har separata konton för olika utgifter så vill jag kanske gruppera vissa som personliga utgifter och andra som affärsutgifter.

Posteringar kan då endast göras mot detaljkonton. Ett summakonto har ändå transaktioner genom sina underkonton. Summakonton kan i sin tur grupperas i mer övergripande summakonton.

Mönster 5: Gruppering av konton utan
explicita summakonton

Det är vanligt att dela upp konton i två typer; summakonton och detaljkonton, men egentligen är det inte nödvändigt. I detta mönster kan alla konton ha underkonton.

Mönster 6: Minneskonto

Ibland behöver man reservera pengar för ett visst ändamål, till exempel skatt. Då kan man ha ett konto där man löpande registrerar hur mycket man reserverar, ett så kallat Minneskonto. Då vet jag hur mycket av de pengar jag har som jag verkligen kan disponera.

Observera att när jag reserverar pengar på ett minneskonto så flyttas inte pengar. Det är bara en notering om hur mycket jag är skyldig. På så sätt innehåller ett minneskonto pengar fast inte ”riktiga” pengar. Det innebär att dubbel bokföring inte är nödvändig, det vill säga att en postering till minneskontot inte behöver speglas av en postering från ett annat konto. Det går att öka skulden i skattekontot utan att minska tillgångarna någon annanstans.

Det finns två sätt att hantera detta:

  1. Skapa ett motkonto. På detta sätt blir principen om dubbel bokföring genomgående för alla konton.
  2. Undanta minneskonto från regeln om att en transaktion alltid ska balansera. Tvärtom måste det då finnas en regel som säger att transaktioner mot minneskonton inte får balansera. I annat fall läcker verkliga pengar till minneskontot!

Fortsättning i nästa artikel

I nästa artikel tar jag upp hur man kan styra posteringar med hjälp av posteringsregler. 

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 30 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Produkt – del 2: Produktlivscykel och Leverantörsprodukt

En produkt har en livscykel. Den kan vara under utveckling, den kan vara öppen (att den finns tillgänglig) och den kan vara avslutad. Den kan också vara tillfälligt stängd, det vill säga suspenderad. Om vi ska kunna följa produkters beteende behöver vi veta vilka produkter vi har vid varje givet tillfälle. Därför behöver vi definiera en produktlivscykel. Den liknar i allt väsentligt den kundlivscykel jag beskrivit i tidigare artiklar.

Vi kan behöva hantera flera olika identiteter för samma produkt, till exempel då det gäller leverantörskedjor. Det beskrivs i mönstret Leverantörsprodukt.

Mönster 1: Produktlivscykel

En produkt har en livscykel. Det är viktigt att veta vilket tillstånd en produkt är i, då det bestämmer vad det går att göra med produkten i fråga. Man kan till exempel inte leverera en produkt som är under utveckling eller avvecklad. Ofta behöver man också registrera när livscykelhändelser inträffar för att kunna mäta och jämföra, till exempel hur länge produkter lever och hur många produkter som utvecklas men aldrig lanseras.

Det här är ett första försök till en livscykel för produkter i en verksamhet som både utvecklar och tillhandahåller produkter.

Vi inför ett supertillstånd

Det som utmärker ett tillstånd är att det bestämmer objektets beteende, det vill säga vad det går att göra med objektet. Att produkten är öppen innebär vanligen att man kan skapa produktindivider av den, det vill säga tillverka, tillhandahålla eller sälja exemplar av produkten (eller tjänsten).

Man inser då kanske att de andra två tillstånden har en viktig sak gemensamt. I båda fallen kan man inte skapa produktindivider. Ifall man ser detta som en grundläggande skillnad mellan produkterna i produktkatalogen, huruvida man kan tillhandahålla produkten till kunder eller ej, kan man tänka sig att man låter livscykeln avspegla detta tydligare.

Vi kan då bygga livscykeln kring två huvudsakliga tillstånd Öppen och Stängd, där stängd har olika undertillstånd, det vill säga specialfall. Det är egentligen samma modell, fast nu att vi har generaliserat tillstånden Under utveckling och Avslutad till att bli specialfall av tillståndet stängd.

Vi inför ett nytt subtillstånd

Låt oss säga att vi sedan kommer på att vi också behöver hålla reda på om produkten är tillfälligt avstängd eller inte. Det är ju ett subtillstånd, det vill säga ett specialfall av stängd. Då får vi följande modell.

Observera att livscykeln inte säger något om eventuella produktindivider. En produktindivid, det vill säga ett exemplar av en produkt, har sin egen livscykel.

Produktens livscykel säger inte ens något om det finns produktindivider eller inte. Både öppna och stängda produkter kan ha produktindivider, utom produkter under utveckling som ju rimligen inte kan ha någon produktindivid, såtillvida det inte är vidareutveckling.

Allt som jag här beskrivit om produktlivscykel är tillämpligt på livscykel för kunder, avtal med mera. Till exempel kan även kunder och avtal vara tillfälligt stängda. Denna bredd är typisk för mönster. Även om jag beskriver mönster för saker som kunder eller produkter har de nästan alltid en mycket bredare tillämpning. 

Mönster 2: Leverantörsprodukt

Om man är återförsäljare av produkter från olika leverantörer har man olika produktidentiteter att hålla reda på. Dels har vi vår egen produktkatalog, dels har vi de olika leverantörernas produktkataloger. Vi behöver vidare veta hur en produkt hos oss motsvarar en viss produkt hos en leverantör. En och samma produkt hos oss kan ha olika produktidentiteter hos olika leverantörer. Det är fallet där det är ett företag som specificerar produkterna men som använder sig av olika leverantörer vilka levererar enligt beställning.

Vi behöver då matcha ihop leverantörens produkt med den egna produkten i ett många-till-många-förhållande. Det kan kanske ändras över tid vilken underleverantör vi använder oss av för en viss produkt. Därför kan vi behöva sätta start- och slutdatum för matchningen.

Det är säkert ännu vanligare för komponenter, att ett företag bygger produkter av komponenter som de specificerar och låter olika underleverantörer tillverka och leverera till sig. Mönstret kan då tillämpas på komponenter i stället för produkter.

Kanske du har idéer om hur man kan tänka annorlunda, eller synpunkter på modellerna jag visar? Dela gärna med dig av dina tankar.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 23 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Produkt – del 1: Produktstrukturer

De flesta verksamheter erbjuder sina kunder produkter eller tjänster av något slag. Runt produkter och tjänster finns det många företeelser som behöver modelleras, definieras och benämnas. Ämnesområdet Produkt är i en del verksamheter så centralt att det finns informationsmodellerare som kallar sig för produktmodellerare. Jag går i denna, och följande, artikel igenom några centrala begrepp och mönster inom produktområdet.

Produkt eller tjänst?

Termen ”produkt” kan stå för olika saker. Det gemensamma är att det är något som en verksamhet kan tillhandahålla till sina kunder. I den ursprungliga betydelsen är det något materiellt, till skillnad från tjänst som är den immateriella motsvarigheten. Men det har blivit vanligt att man benämner även tjänster som produkter. Och eftersom de mönster jag kommer presenterar här fungerar lika bra för materiella som immateriella produkter så gör jag här ingen skillnad.

Verksamheter har ofta problem med sin produktflora

Jag upplever att man i många verksamheter har problem med en oöverskådlig produktflora och svårt att ens komma igång med att bringa ordning. Man har ofta stupat redan på tröskeln, redan när man försökt bestämma vad en ”produkt” är. Kanske har man ett par tusen saker registrerade som man säljer, men frågan blir då: Är det verkligen produkter? En del varor man erbjuder är kanske paketeringar av flera olika produkter. Och andra företeelser man hanterar är kanske bara komponenter som man sätter ihop produkter av. Många produkter är så lika varandra så man kanske borde se dem som varianter av en och samma produkt. Och några är små förbättringar av tidigare produkter, så man kanske borde se dem som versioner av en och samma produkt. Hur kan man bestämma vad som är vad, och hur ska man hålla reda på det?

Det brukar bli många åsikter, och jag har upplevt att många verksamheter inte har kunnat reda ut detta. Man har helt enkelt gett upp alla försök att bringa ordning i produktfloran, med resultatet att det blivit svårt att analysera och följa produkters beteenden över tid.

Men det är egentligen inte så svårt. Vi bör bara vässa våra analysverktyg en smula och gå metodiskt tillväga, begrepp för begrepp. Där har vi informationsarkitekter en viktig uppgift att fylla.

Om begreppet ”produkt”

Ett fruktbart sätt att se på begreppet produkt är att det är någonting man kan erbjuda kunder som en enhet.

”Kan erbjuda” är viktigt för det är en produkt, även om det är något man ännu inte har erbjudit någon kund. Eller av olika omständigheter aldrig kommer att erbjuda en kund.

Jag vill inte skriva ”sälja” för jag tycker inte att det är någon egentlig skillnad i avseendet om eller hur vi får ersättning för det vi erbjuder. En produkt kan vara helt gratis, det är likafullt en produkt.

”Som en enhet” är viktigt, ty mycket av det vi kan erbjuda kan vi inte erbjuda i sig självt utan bara som en komponent av något annat. Om jag säljer bilar så erbjuder jag kanske röd lack. Men inte som en självständig enhet. Du kan inte köpa röd lack av mig utan att den sitter på en bil. Du kan bara få röd lack som en komponent till bilen du köper. Men jag vill ju kanske ändå kunna följa upp hur röd lack säljer.

Det betyder inte att jag alltid måste sälja en produkt som en egen enhet. Jag kan paketera flera produkter så att de tillsammans blir en paketering. Du kanske kan köpa ett paket av mig med en isskrapa plus rattmuff. Det avgörande för om det är en produkt är att jag kan erbjuda den för sig själv.

Men ”produkt” är långt ifrån det enda begreppet vi behöver definiera. Låt oss gå vidare. Det har för övrigt ingen betydelse om man benämner produkt för ”artikel” eller ”vara”. Frågeställningarna och lösningarna blir precis desamma.

Mönster 1: Produktindivid

Vi behöver begreppsmässigt skilja de individuella exemplaren av en produkt från det som vi i förra stycket kallade för produkt. Ett namn som förekommer är ”produktindivid”, ”produktförekomst”, ”produktinstans” eller ”produktexemplar”.

Det kan finnas noll, en eller flera produktindivider av en och samma produkt. En produktindivid är alltid en individ av en viss produkt och har ett existentiellt beroende till denna, som jag uttrycker med en romb i änden på relationslinjen. Det uttrycker att produktindividen inte kan existera oberoende av sin produkt och att den heller aldrig kan ändras så den blir en individ av en annan produkt.

Produkt ligger i ett regelplan i förhållande till produktindivid, vilket betyder att när vi lägger upp en ny produkt kan det i detta sammanhang ses som en konfigurering av verksamheten. Vi bestämmer vad vi kan erbjuda. Det har inte hänt något operativt bara för att vi lägger upp en ny produkt, vi har inte producerat något, det betyder bara att vi bestämt att det finns ett visst erbjudande. Det är inte förrän det skapas ett exemplar av den produkten, en produktindivid, som det händer något operativt, som någon form av produktion har skett.

Resonemanget är precis lika för tjänster, det vill säga immateriella produkter. Ett försäkringsbolag erbjuder dig en hemförsäkring (produkt). Du tecknar en sådan, och avtalet får ett försäkringsnummer (en produktindivid). Den enda skillnaden är att en immateriell produkt (tjänst) uppstår genom någon form av performativ (utförande) akt.

Mönster 2: Produkttyp

Man delar vanligen in produkter efter olika kriterier i produkttyper, produktgrupper etcetera. Jag har inte tagit med det i diagrammet. Om vi fokuserar på själva produktadministrationen som en verksamhetsförmåga kommer man kanske vilja se entiteten produkt som tillhörande ett operativt plan. När man definierar en ny produkt innebär det just i detta sammanhang en operativ handling. Hur man delar in sin produktkatalog i produkttyper och produktgrupper innebär med det perspektivet att man konfigurerar verksamheten i fråga.

Med detta vill jag bara visa att vad man ser som operativt är inget absolut utan beror på sammanhanget. Att något sådant kan hända vid ett perspektivskifte kan kännas flyktigt och osäkert för en del. Men jag anser att det är viktigt att veta att olika kontext ger olika perspektiv och att vilken kontext man har kan därmed vara avgörande för modellen.   

Observera att jag här har valt att Produkt inte har ett existentiellt beroende till Produkttyp (det vill säga ingen romb i änden). Jag ser produkttyp som något som vanligen är en ganska flyktig indelning av produkter. Man kan ju ofta ändra typningen av produkter, det vill säga hur man delar in produkter i olika produkttyper, utan att det därför blir nya produkter. Man kan förstås hävda motsatsen för sin specifika verksamhet, men jag tror det är ovanligt. Det här är en bedömning jag gör, och det kan variera från verksamhet till verksamhet. Den kritiska frågan är: Kan en produkt ändra produkttyp och ändå ses som samma produkt. Om svaret är ja: ingen romb, om svaret är nej: romb.

Mönster 3: Produktvariant

En produkt kan finnas i flera varianter. Det kan vara olika färger eller andra smärre skillnader, men att man ändå vill se det som en och samma produkt. Vad som är olika produkter och vad som är flera varianter av samma produkt är ett val man gör i verksamheten.

Jag har varit med om att någon i en verksamhet har sagt att de egentligen har bara en produkt, men vi levererar den i många varianter, medan någon annan vill se det som att man har väldigt många produkter. Man behöver komma fram till hur man vill se det och vilka egenskaper som ska skilja för att man ska betrakta två artiklar som varianter av samma produkt. Det har mycket med marknadsföring och försäljning att göra, det vill säga hur man vill presentera varorna för kunderna.

Det finns alltid minst en variant av varje produkt. En produktindivid blir alltid en förekomst av en specifik produktvariant.

Mönster 4: Produktvarianttyp

Det finns ofta ett behov av att kategorisera även produktvarianterna. Om man säljer till exempel hushållsapparater kan det vara färger eller elanslutning. Det finns 14 olika standarder för elkontakter världen över. I vissa verksamheter har varje produkttyp sina egna varianttyper, i andra kan de vara gemensamma tvärs över hela produktkatalogen.

Mönster 5: Produktversion

Produkter förändras över tid. Man behöver hålla reda på vilken version en produktindivid är av. Inte bara produkter har versioner utan även produktvarianter. På så sätt får vi två parallella stråk i vår produktstruktur. En som är mer beständig över tid, och en annan som fångar hur en och samma produkt utvecklas över tiden.

Men hur bestämmer man när en viss vara ska ses som en ny produkt eller en ny version av en befintlig produkt? frågar sig den skarpsinnige. En riktlinje brukar vara att om ändringen är så pass framträdande att kunden uppfattar det som en ny produkt ska det vara en ny produkt annars är det en endast en ny version av den befintliga. Ett klädföretag jag jobbade för sa så här: ”Om en söm inte visar sig hålla i längden åtgärdar vi det. Då blir det en ny version. Kunden märker inte detta vid köpet, men vi vill veta vilken version en viss produktindivid är av när vi får klagomål. Om det visar sig att en ficka sitter fel placerad på en skjorta, och vi åtgärdar det, då blir det en ny produkt för kunden ser skillnaden.”

Mönster 6: Produktkomponent

Ofta utvecklar man komponenter som man kan använda för att bygga ihop olika produkter. En komponent kan definitionsmässigt inte säljas separat som en egen enhet, i så fall skulle den vara en produkt i sin egen rätt. Komponenter används inte bara i materiella produkter. Försäkringsbolag och finansiella verksamheter har ofta ett antal produktkomponenter vilka används till olika produkter.

Observera hur jag namnger och definierar den entitet som utgör många-till-många-relationen ”Produktkomponent i produktvariant”. Jag tycker att det är viktigt att vara strikt med att namnet, och definitionen avser en förekomst av entiteten. Det gör det lättare att förstå vad entiteten representerar. Man ser annars ofta att entiteten kallas Produktkonfiguration, men jag tycker att man bör vara konsekvent med att namnet på en entitet alltid ska vara namnet på en förekomst av entiteten. En förekomst av den entiteten är inte en fullständig konfiguration av en produkt utan endast en detalj av konfigurationen, nämligen just faktumet att en viss komponent används i en viss produktvariant.

Produktkomponenter har i likhet med produkter och produktvarianter sina typer, varianter och individer. Kanske behöver man också hålla reda på vilken version av en produktkomponent som ingår i en viss version av en produktvariant, och även vilken komponentindivid som ingår i vilken produktindivid.

Jag har i diagrammet tagit med följande:

  • Produktkonfigureringar på typnivå, det vill säga vilka typer av produktkomponenter som kan förekomma i vilka typer av produktvarianter.
  • Produktkonfigureringar på variantnivå, det vill säga vilka produktkomponenter som kan förekommer i vilka produkter.
  • Produktkonfigureringar på versionsnivå, det vill säga vilka versioner av komponenter som används i vilka versioner av produkter.
  • Produktkonfigureringar på individnivå, det vill säga vilket specifikt exemplar av en komponent som förekommer i vilket specifikt produktexemplar.

Lägg märke till den layout jag givit diagrammet, med entiteter i kolumner och rader. Själva strukturen och hur entiteterna är placerade i förhållande till varandra har stor betydelse då det skapar ordning och reda i begreppen och tankegången. Skillnaden mot om man placerar rutorna utan någon speciell tanke är helt avgörande för begripligheten.

Jag planerar att i senare artiklar ta upp sådant som gestaltning av modeller, hur man kan rita (och skriva) sina modeller på ett tydligare sätt så att de blir mer användbara.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 9 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Kundlivscykel – del 2: Livscykelhändelser

Detta är andra delen av två om en kundlivscykel, där vi tittar närmare på hur vi kan hantera de händelser som innebär att kunden byter status.

Mönster 1: Livscykelhändelser för kund

För att analysera och förstå rörelser i kundstocken behöver vi tydligt definiera och namnge vilka händelser som kan inträffa i en kunds livscykel och som innebär att en kund byter status, till exempel övergår från prospekt till aktuell kund. Man kan mena olika saker med händelser. Här har jag valt att bara se själva övergången, från ett tillstånd till ett annat, som en händelse. Det vill säga att jag här inte inkluderar den bakomliggande orsaken som orsakade tillståndsförändringen. Det gör modellen renare och tydligare och därmed mer användbar för analyser. Den bakomliggande händelsen som är orsaken till tillståndsövergången hanteras i nästa mönster i artikeln.

Jag har försökt att rita in varje möjlig tillståndsövergång, och därmed livscykelhändelse, som en pil i diagrammet här till höger och ge händelsen ett tydligt namn. Jag tror att det finns många andra förslag.

Pilen längst ner i diagrammet innebär att vi någon gång rensar ut minnet av den avslutade kunden. Det är ju också en händelse, men inte en händelse som har med kundrelationen i sig att göra utan bara med informationshanteringen som avbildar händelsen i verkligheten. Därför har den händelsen inte något namn och finns då inte heller registrerad någonstans, eftersom informationen om kunden då är borttagen.  

Nu kan vi skapa en entitet, kallad Livscykelhändelse, som har de sju möjliga händelserna i diagrammet ovan som förekomster.

Därefter kan vi skapa en entitet, kallad Kunds inträffade livscykelhändelse, för att registrera de kundhändelser som inträffar för kunden.

Observera att de två högra entiteterna i diagrammet tillhör ett regelplan. De definierar reglerna som finns, det vill säga vilka kundstatusar och livscykelhändelser som kan förekomma. När något händer i regelplanet, till exempel att en ny kundstatus läggs till, konfigureras verksamheten, det vill säga att vi förändrar reglerna för vad som kan inträffa. När något händer i det operativa planet, till exempel att ett prospekt blir ny kund, så opererar verksamheten.  

Om rubriker i diagrammet: Jag brukar gruppera entiteter och sätta rubriker i diagram enligt ovan. Modellen blir tydligare om man på detta sätt separerar regelplanet från det operativa planet. Det blir då tydligt var man sätter regler och var saker och ting händer operativt.

Men märk att vad som är konfigurering och vad som är en operativ händelse beror på sammanhanget. I modellen i stort kan man mycket väl hävda att detta att ett prospekt blir till aktuell kund är en konfigurering. De verkliga operativa händelserna är med detta större perspektiv först när en kund köper något. Skillnaden mellan det lilla sammanhanget och det stora visar bara att världen är fraktal. Den distinktion som gjorts mellan de två planen är endast för just detta sammanhang. Om man zoomar ut till ett större sammanhang kan mycket väl en operativ händelse (en ny kund) skifta till att ses som en konfigurering.

Mönster 2: Händelseorsaker

Vi har hittills definierat en händelse som det faktum att en viss tillståndsövergång har skett, oberoende av orsaken. Särskilt då det gäller avveckling av en kund brukar det vara värdefullt att registrera orsaken. Orsaken kan till exempel vara något av följande:

  • Kunden har varit inaktiv under en lång period (som man bör bestämma längden på).
  • Kunden har upphört att existera (avliden, utflyttad från landet, avvecklat företag).
  • Kunden har sagt upp sig.
  • Kunden har misskött sig, till exempel inte reglerat sina skulder till oss.
  • Kunden är misstänkt för brottslig verksamhet, eller på andra sätt blivit ej önskvärd.

Men även orsakerna till att man vinner prospekt eller att en kund skapas utan att tidigare varit prospekt är intressant att studera, för att förstå hur vi vinner kunder över huvud taget. Man kan förstås se och hantera allt detta som olika händelser, men jag anser att modellen blir renare och lättare att förstå, hantera, förändra och använda i analyser om man separerar livscykelhändelsen, det vill säga själva tillståndsövergången från den bakomliggande händelsen, det vill säga orsaken till tillståndsövergången. Om vi lägger till livscykelhändelser och händelseorsaker till modellen får vi modellen nedan. Vi ser nu att övre delen av diagrammet handlar om nuläget, kunders aktuella status, och nedre delen om kundernas historik, det vill säga vilka händelser som inträffat och varför. Och som tidigare visar högra delen av modellen själva regelverket, vad som kan inträffa, och vänstra delen det som verkligen inträffat.     

Enkel uppföljning

Om vi kan registrera kundhändelser på detta vis, blir mycket av uppföljningen enkel.
Vi kan till exempel göra följande:

  • Veta exakt hur många (aktuella) kunder vi har just nu och vi varje givet tillfälle i historien.
  • Veta och analysera churn rate (kundomsättning), det vill säga hur många kunder som tillkommer och försvinner under varje tidsperiod, och orsakerna till detta (så långt vi har kunskapen).
  • Analysera hur länge vi behåller kunder.

Om vi som brukligt har delat in kunder efter geografi, segment och kategorier av olika slag kan vi analysera beteendet för olika grupper av kunder enligt ovan utefter olika grupptillhörighet. Det finns då ingen ände på de analyser som vi direkt kan göra.

Inte bara kunder har en livscykel

Dessa modellmönster är användbara inte bara för kunder utan för alla företeelser vars livscykel man vill kunna analysera. Särskilt vanligt är det för produkter. Men även produktindivider, avtal och konton har ofta livscykler man vill hålla reda på.

Inte bara livscykler utan även andra cykler

Jag brukar kalla de övergripande tillstånden och händelserna i en företeelses liv för livscykel, men det finns ofta andra parallella förlopp som är värda att följa. För kunder kan det ofta vara att vi vill veta om de är i skuld eller inte, och händelsen att de hamnar i skuld och händelsen att vi aviserar skulden och när de reglerar skulden. På så sätt kan vi mäta hur lång tid det går, i allmänhet, innan betalning sker och vilka kategorier av kunder som är särskilt sena med mera.

Möjligheterna är stora. Vi kan med enkla grepp få kontroll på det dynamiska flödet i våra verksamheter. Det enda som behövs är en tydlig och genomtänkt struktur för tillstånd, händelser och händelseorsaker.

Kommentera gärna. Berätta hur du använder livscykler, händelser och händelseorsaker för att få koll på flödet i din verksamhet.  

Vad vi nu kan göra

Om man skapar en gemensam modell på detta sätt, i till exempel ett gemensamt Data Warehouse, och låter de olika kundsystemen rapportera enligt detta så får man på ett ganska enkelt sätt helt nya möjligheter. Den stora fördelen med detta är att vi inte behöver bygga om alla källsystem innan vi kan få gemensamma begrepp. Översättningen från de lokala begreppen görs där det finns bäst förutsättningar, det vill säga i de team som hanterar respektive källsystem. Alltså en pushmodell där den gemensamma modellen blir det semantiska formatet i kontraktet de måste rapportera enligt.

Det är en stor skillnad mot hur det vanligtvis är, det vill säga att man har flera olika system med olika, och vanligen oklara definitioner, och ingen gemensam modell. Analytiker får sitta och försöka tolka och pussla ihop data från olika system. Beroende på vem som tar fram rapporten blir resultaten olika. Jag får ofta höra från ledningar: ”Om jag ber om en viss rapport blir resultatet olika beroende på vem som tar fram den, och alla svar är sanna, fast på olika sätt och oklart hur.” Osäkerheten och bristande jämförbarhet är således ett problem. Ett annat problem är tidsåtgången och arbetsbelastningen. I en bank tog det analytikerna hela månaden att ta fram månadsrapporten. De hade därmed inte någon tid alls att göra det de ville göra och var bra på, att analysera resultatet och dra lärdom. Efter att vi implementerade en gemensam modell enligt ovan kunde de ta fram månadsrapporten på några sekunder. Det är svårt att tänka sig något annat vi som informationsarkitekter kan göra som ger större förändring på lika enkelt sätt.

Som vanligt skulle jag uppskatta om du ville kommentera detta. Kanske du har idéer om hur man kan tänka annorlunda, eller synpunkter på modellerna jag visar.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 9 september. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Kundlivscykel – del 1: Kundstatus

Kunder kommer och kunder lämnar. En kund kanske börjar som prospekt, blir sedan en aktuell kund för att senare lämna av någon orsak. Kunder har alltså en livscykel, med tillstånd och händelser. Om vi skapar en modell för denna livscykel, med namngivna och definierade tillstånd och händelser, öppnar sig många möjligheter till att analysera rörelserna i kundstocken.

Hur det brukar se ut

Vanligen har man i ett kundsystem ett fält för status. Där kan det finnas en kod för om kunden är ett prospekt (det vill säga någon person eller organisation som man registrerat för att man aktivt vill bearbeta denne för att bli en kund) eller en riktig kund (det vill säga en som köper ens varor eller tjänster). Vanligen har man även en kod för om kunden är avslutad. Fast det är ofta oklart hur lång tid en kund ska avstå från att köpa något för att betraktas som avslutad. Vanligen har man olika uppsättningar av koder i olika system och ofta är inte tillstånden väldefinierade.

Det är också vanligt att man blandat in flera betydelser i samma fält. Till exempel kan man ha en kod för att kunden är avslutad på egen begäran och en annan kod för om kunden är avslutad för att den inte betalt sina skulder. Det vill säga att ett och samma fält har två betydelser, dels status (att kunden är avslutad) och dels orsaken till att kunden är avslutad. 

I avsaknad av en gemensam modell med gemensamma definierade begrepp så blir det besvärligt att göra analyser av rörelserna i kundstocken, eller att ens säga hur många kunder man egentligen har. Något som varit bland det första jag ofta fått höra i de verksamheter jag kommit till är just: ”Vi vet inte ens hur många kunder vi har!”.

Hur kan man göra?

Det första man behöver göra är att skapa en gemensam modell för kundlivscykeln. Sedan kan man mappa alla de lokala koderna i de olika kundsystemen mot denna. Eller egentligen är det ju tvärtom man gör. Man går igenom och analyserar de olika statuskoderna som finns i källsystemen och vilka kunder som har vilken kod och varför. Med den direkta kunskapen vi då får om verksamheten kan vi skapa en gemensam modell som blir det gemensamma språket för hela verksamheten. Sedan låter man de olika källsystemen rapportera status och händelser, till exempel till ett Data Warehouse, för sina kunder enligt denna modell. På så sätt får man möjlighet till gemensamma rapporter som kan jämföras med varandra. Och detta utan att man behöver ensa hela verksamheten i alla sina delar samtidigt. Med tiden kommer de olika delarna av verksamheten att gravitera mot det gemensamma synsättet, fast varje del i sin egen takt. Om det inte händer så har vi förmodligen de facto ett lokalt behov som inte tillgodoses av den gemensamma modellen. Vad bra då att vi inte tvingade på varje hörn av verksamheten den gemensamma modellen. Det är så vi på samma gång kan få ett gemensamt språk och ändå kan låta varje del ha sina egenheter anpassade för de lokala behoven. 

I diagrammet visas hur en informationsmodell för en kundlivscykel kan se ut.

I det följande kommenterar jag modellen, hur de olika begreppen är definierade, namngivna och gestaltade.

Om status, även kallat tillstånd: Först behöver vi diskutera detta med status. Vad innebär en status egentligen? Med status menar vi ett tillstånd ett objekt (en förekomst av något) kan befinna sig i. För att vara ett tillstånd ska det vara definierat av ett visst beteende, det vill säga att tillståndet bestämmer vad det går att göra med objektet. Ett exempel: En aktuell kund kan vi sälja något till, men ett prospekt måste vi kanske först göra till kund för att kunna sälja till. En aktuell kund kan vi avsluta, men en avslutad kund kan vi inte avsluta igen.

Vi bör inte kontaminera våra tillstånd med att definiera dessa utifrån händelsen eller orsaken som gjorde att objektet nådde det tillståndet. Ett exempel: En avslutad kund kan vara avslutad av många olika orsaker. Men beteendet, det vill säga vad man kan göra med en avslutad kund, är precis detsamma oavsett orsaken till att kunden är avslutad. Vi vill förmodligen hålla reda på orsaken till att en kund avslutats men det blir fel om vi skapar en specifik status för varje orsak. Jag visar i nästa artikel hur man kan hålla reda på orsaken.

Om begreppet Kund: I dagligt tal menar man med begreppet Kund någon som just idag är kund. Men jag menar att det blir mer praktiskt om vi utökar begreppet och även inkluderar prospekt och tidigare kunder. Vi behöver ju ett begrepp för den intressent som gör hela resan, från prospekt (en som är en kandidat till att bli kund i en nära framtid, via aktuell kund (en som är kund i egentlig mening just nu) till avslutad kund. Jag tycker att det är mest praktiskt att kalla alla dessa för kunder, även om det avviker från dagligt språkbruk. Ty det finns inget annat namn som är användbart vad jag förstår.

Om tillståndet ”Aktuell”: Ofta kallar man detta tillstånd för ”Aktiv”, men min erfarenhet är att det kan bli ett problem med det namnet i många verksamheter. En kund som vi har en aktuell kundrelation till kan ju vara mer eller mindre aktiv över tiden. I perioder handlar kunden ofta och i perioder är kunden frånvarande. Det vill man ofta följa. Till exempel kanske man vill ”väcka” kunder som inte varit aktiva på ett tag, genom en riktad kampanj.

Om kunden har uteblivit under lång tid vill vi förmodligen se det som att vi förlorat kunden. Men huruvida kunden just nu är aktiv eller inte är ändå inte samma sak som om vi ser kunden som aktuell. Därför föredrar jag termen ”aktuell”. (I brist på bättre får jag väl säga. Du kanske har ett bättre förslag?).

Om att skriva definitioner i entitetsrutorna: Jag gillar att skriva definitionen av en entitet i själva diagrammet under namnet. Det är ett enkelt sätt att öka chansen till att läsaren direkt förstår vad som företeelsen står för.

Om definitionen för entiteten Kundstatus: Observera att definitionen för Kundstatus är ”Status som en kund kan ha”. Det för att inte blanda ihop det med den status som en kund verkligen har, som ju betecknas av attributet Kundstatus i Kund och relationen från Kund till Kundstatus. En förekomst av entiteten Kundstatus är ju en status en kund kan ha, och säger inget om hur många, om ens någon, som har denna status.

Om redundans i modellen för attributet/relationen Kundstatus: Attributet Kundstatus hos Kund och relationen från Kund till entiteten kundstatus står ju båda för samma sak och är därmed redundanta. En del tycker att det är fel att i informationsmodellen ha med en och samma sak två gånger. Det har jag också tyckt en gång men har med tiden vägt över till att jag alltid tar med det attribut (eller i vissa fall de attribut) som manifesterar relationen. Jag har flera skäl till detta:

  1. Jag vill se även relationer som attribut, för det är de i all väsentlighet. Till exempel Kundstatus är en egenskap hos en kund, det vill säga ett attribut. Att värdeförrådet finns uppräknat i en annan entitet ändrar inte detta. När jag i text dokumenterar attribut och relationer finns det ingen skillnad. Alla relationer behöver definieras, beskrivas och dokumenteras på samma sätt som attribut som inte är relationer.
  2. Spårbarheten blir tydligare om man sedan ska realisera modellen, som till exempel en databas. För då blir det ju databaskolumner, och jag vill gärna att det ska finnas en så direkt koppling som möjligt mellan informationsmodellen och databasen.
  3. I informationsmodellen vill jag gärna markera vad som unikt identifierar en förekomst, eftersom det hjälper läsaren att förstå vad en entitet egentligen är. Då måste jag ha med de attribut som ingår i en kompositnyckel, även om de är nycklar till andra entiteter och sålunda manifesterar relationer.

Om att redovisa förekomsterna av till exempel Kundstatus: Det är inte bara entiteter, attribut och relationer som vi behöver namnge och definiera. Då det gäller attribut med ett antal definierade förekomster (som i exemplet Kundstatus) så behöver vi namnge och definiera varje förekomst. Det rör sig ju i stort sett alltid om centrala verksamhetsbegrepp som används i rapporter och analyser. Det är ett vanligt missförstånd att det räcker med att definiera och dokumentera entiteter, attribut och relationer. Men förekomster av detta slag är minst lika viktiga, men nästan alltid ignorerade. 

Det som behövs dokumenteras för varje förekomst är i regel en kod, eller ett kortnamn, ett namn och en definition. Det kan också behövas ett ordningsnummer för att visa förekomsterna i en logisk och återkommande sorteringsordning i en valbar ruta eller i en rapport. Vi kan även behöva giltigt från och med- samt till och med-datum, om vi kommer att behöva hantera förändringar.

Jag dokumenterar förekomsterna i textdelen av modellen, med tar vanligen med dem även i diagrammen. Det underlättar förståelsen av diagrammet avsevärt. Jag ser till att de rutor i diagrammet där förekomsterna listas skiljs ut tydligt från entitetsrutorna.

Om kod, för till exempel Kundstatus: Förr var det så att alla värden för en status (ett tillstånd) hade en kod. Det var så vanligt att den entitet som jag i modellen ovan kallar för Kundstatus, skulle många kallat för Kundstatuskod. Skälet till att man hade koder var att man behövde snåla med utrymmet i databaser och därmed behövde använda så få tecken som möjligt. Men idag finns inte just den begränsningen. Men det är ändå så att vi ofta behöver ett kort namn (vare sig man nu ser det som en kod eller ett kortnamn, gränsen är flytande) för saker och ting, speciellt då man ska visa saker i kolumner i en rapport eller dylikt. Så jag är kluven. I varje fall behöver vi någon form av kod eller kortnamn, kanske både och. Ibland ett maximalt kompakt (bara ett tecken), ett kort (tre eller fyra tecken) och ett fullt utskrivet namn.

Om tillståndsdiagram i informationsmodellen: Jag har alltid med tillståndsdiagram (Harel statechart eller state machine) i diagramdelen till min modell, som visat ovan. Men observera att tillståndsdiagrammet i det exemplet är ofullständigt. Kunder tar inte alltid den raka vägen. Somliga blir kunder utan att först vara prospekt. Somliga som är avslutade återkommer och så vidare. Jag kommer i nästa artikel komplettera tillståndsdiagrammet och även hantera händelser och händelseorsaker.

Till dess skulle det vara roligt att höra dina synpunkter och erfarenheter. Vad håller du med om och vad skulle du vilja göra annorlunda?

/Peter Tallungs, IRM 

Modellmönster: Ansvarsförhållanden mellan parter

I en verksamhet behöver man hantera olika typer av ansvarsförhållanden mellan parter. De man kanske först tänker på är de som uttrycks i organisationshierarkier, men det är bara ett av en mängd olika slag av ansvarsförhållanden. I denna artikel beskriver jag några användbara mönster för att hantera förhållanden där en part har ett ansvar gentemot en annan. Jag passar också på att ta upp hur man kan införa ett regelplan i sin modell. Det är ett effektivt sätt att göra sin informationsmodell tydligare.

Mönster 1: Organisationshierarki med explicita nivåer

Det här är ett vanligt och naturligt sätt att modellera organisationshierarkier, liksom hierarkier i övrigt. Varje typ av organisationsenhet har sin egen entitet. Det har sin stora fördel i att det känns naturligt, det vill säga överensstämmer med den bild vi har naturligt i huvudet. Men det har en begränsning. Om organisationsstrukturen ändras – om till exempel nivån med avdelningar tas bort för att platta till strukturen – måste vi bygga om modellen helt och hållet.

Mönstret ger alltså en tydlig och naturlig men inte speciellt flexibel modell.
Det räcker till i de fall vi inte behöver hantera historik, det vill säga hur organisationen förändras över tid.

Mönstret passar inte heller då vi behöver en mer generisk modell som ska användas för flera olika organisationer.

Mönster 2: Organisationshierarki med generaliserade organisationsenheter

Vi kan skapa en mer generell entitet som gäller för alla organisationsenheter oavsett typ. Vi kan sedan ha mer dynamiska regler för vilka subtyper som finns samt begränsningsregler för hur de kan relatera till varandra.

Detta mönster har möjligen en något större flexibilitet än föregående, det vill säga att det blir lite lättare att förändra organisationsstrukturen. Men vad vi nu vunnit i flexibilitet har vi förlorat i tydlighet.

Mönster 3: Flera organisationshierarkier

Ofta har man två eller flera parallella organisationshierarkier, det vill säga multipla rapportvägar. Det avbildar man på enklaste sätt genom att ha fler än en moder-dotter-relation.

(Subtyper och begränsningsregler har inte tagits med i diagrammet här).

Men om vi vill hantera egenskaper hos själva relationen, till exempel historik som vilken tidsperiod relationen gällde för, behöver vi lyfta själva relationen till att representeras av en egen entitet. Vilket tar oss till nästa mönster.

Mönster 4: Organisationshierarki med relationsobjekt

Vi kan göra själva relationen till en egen entitet. Då öppnas flera möjligheter:

  1. Nya typer av ansvarsrelationer kan lätt läggas till.
    Vi kan typa relationerna så att en organisationsenhet kan ingå i flera hierarkier samtidigt. Man kan till exempel ha en organisationshierarki baserad på produkt och en annan baserad på säljorganisation.

    Om vi endast har två hierarkier är detta knappt värt besväret, men för fler hierarkier än så är det användbart.
  2. Vi kan ge varje relation en tidsperiod då den gäller.
    På så sätt kan vi hantera förändringar över tid, till exempel att en enhet byter plats i strukturen.

    När man på detta sätt gör entitetstrukturen mera generell blir det viktigt att i text uttrycka de regler som begränsar vilka relationer som är möjliga. Observera att reglerna i detta fall läggs på själva relationen.

Vi kan använda detta som en metamodell vilken kan härbärgera alla möjliga ansvarsstrukturer mellan organisationsenheter.  

Mönster 5: Relationsobjekt för ansvarsförhållanden för olika typer av intressenter

Det förra mönstret (mönster 4) handlar om organisationsenheter där en organisationsenhet kan ha en relation till en annan organisationsenhet, enligt en viss regel för en viss tidsperiod.

Alltid när något gäller för organisationer eller organisationsenheter kan man fråga sig om detsamma inte kan gälla för andra typer av intressenter, som till exempel personer. I just detta fall kan man ställ sig frågan: ”Kan en person ha en relation till en organisationsenhet eller till en annan person, enligt viss regel, för en viss tidsperiod?”. Eller motsvarande fråga för organisationer som helhet.

Om vi byter supertypen Organisationsenhet mot Intressent kan vi täcka en vid uppsättning relationer mellan parter, till exempel ledningsrelationer, anställningar och kontrakt.

Vi har emellertid introducerat komplexitet genom att vi nu täcker en mycket större variation i relationer mellan parter än bara mor-dotter-förhållanden. Det krävs regler för att styra vilka parter som kan ingå i vilka relationer.

Det kan vi hantera genom att introducera något i modellen som kan kallas regelplan.

Mönster 6: Relationer styrda av ett regelplan

Vi kan dela upp vår modell i två delar.

  • Operativa planet registrerar de dagliga förhållandena (eller händelserna) i domänen. I detta fall vilka konkreta ansvarsförhållanden som finns i verksamheten
  • Regelplanet håller de regler som styr strukturen i det operativa planet. I detta fall vilka typer av parter det kan finnas och vilka typer av ansvarsförhållanden som kan finnas för varje kombination av två typer av parter.

På så sätt definierar varje förekomst i regelplanet en tillåten konfiguration av förekomster i operativa planet.

Exempel: Ett specifikt ansvarsförhållande (en länk mellan två specifika parter) kan endast skapas mellan parter enligt vad som är angivet i Typ av ansvarsförhållande.

Det är intressant att notera hur det operativa planet speglas i regelplanet. De två planen har liknande men inte identiska relationer. Det operativa planet registrerar de specifika parterna i ett visst ansvarsförhållande medan regelplanet definierar vilka typer av parter som är tillåtna för en viss typ av ansvarsförhållande. Detta är ett typiskt mönster: Flervärd mappning i regelplanet för att visa tillåtna typer för en envärd mappning i operativa planet.

Metadata utrycks nu inte längre bara av entitetsstrukturen utan även av förekomsterna i regelplanet. För att systemet (det vill säga informationssystemet i bred bemärkelse) ska fungera räcker det inte med att implementera modellens struktur (till exempel skapa de tabeller som behövs). Vi måste också instansiera objektförekomsterna i regelplanet. Det vill säga till exempel att populera de tabeller som beskriver vilka parter som kan finnas och vilka relationer varje kombination av dessa kan ingå i. Att instansiera regelplanet innebär att konfigurera systemet, det vill säga verksamheten.

Notera att mappningen från Part till Typ av part ersätter subtypning av Part. Att en mappning definierar en subtyp kallas ibland ”power type”.

När ska detta mönster användas? Vi kan inte undvika att hantera den inbyggda komplexitet som finns inom en domän. Vi kan bara fråga oss vilket mönster som enklast representerar den komplexitet vi behöver hantera. Se upp bara så att detta mönster inte blir ett catch-all för alla typer av relationer mellan två parter.

Om regelplan i modeller 

Det är fruktbart att tänka i begreppen regelplan och operativt plan när man modellerar och att hålla isär dessa grafiskt inom ett ämnesområde. Fast jag skriver aldrig ut termen ”regelplan” utan något i stil med ”Regler för kund” eller ”Produktregler” som rubrik för den delen av ämnesområdet.

Regelplan kan ibland också kallas typplan eftersom de oftast innehåller entiteter vars instanser definierar typer. Det är också ett metaplan rent definitionsmässigt, men jag tycker vi ska undvika namnet ”metaplan”, för begreppet ”meta” är ett alldeles för vitt begrepp, det vill säga att det kan betyda lite vad som helst och kan därmed förvirra mer än det tydliggör. Metadata är ju data om data och det rymmer allt möjligt.

Att skikta en modell – eller vanligare ett ämnesområde inom en modell – på detta sätt är ett mycket kraftfullt sätt att ordna sin domän. Det är inte speciellt känt, men jag hoppas att det härmed sprider sig.  

Var kommer dessa mönster från

Jag har hämtat dessa mönster från Martin Fowlers bok ”Analysis Patterns”, från 1997. Det är bok som inte många känner till, i det närmaste en apokryfisk skrift, som jag menar har ett stort värde. Speciellt vill jag nämna detta med regelplan, vilket jag en gång lärt mig från denna bok, och använt i tjugo år i mina modeller. Det är mer eller mindre nödvändigt för att hantera lite mer komplicerade verksamhetsdelar.

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 26 augusti. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Intressentroller

Företag och andra organisationer har relationer till olika intressenter. Dessa intressenter är personer och organisationer som har specifika roller i relation till den verksamhet du modellerar. Det kan vara kunder, leverantörer, anställda, interna enheter, kontaktpersoner, avtalsparter eller andra intressentroller. Vi behöver begrepp och strukturer för att hantera dessa relationer. Vilka strukturer som är mest lämpade beror på vilka relationer vi behöver hålla reda på och vad vi behöver hålla reda på för varje relation. Detta är en central uppgift i varje organisation och ett kunskapsområde där informationsmodellering är ett centralt verktyg. Jag beskriver i denna artikel ett antal modellmönster som har med intressenter att göra. 

Mönster 1: Generalisering med Intressent

När två entiteter har samma attribut eller relationer söker man instinktivt efter en generalisering.
Generaliseringen av Person och Organisation är ett klassiskt exempel på en namnlös företeelse, något som alla känner till och använder men som det saknas ett naturligt namn för. ”Part” (engelskans ”Party”) eller ”Intressent” (engelskans ”Stakeholder”) är de namn som oftast används för den generaliserade företeelsen.

Intressent är en generalisering (supertypen) av Person och Organisation.

Mönster 2: Intressentroll

Många verksamheter behöver hålla reda på olika typer av intressenter, inte bara kunder. Det är då naturligt att dela in dem efter vilken roll de spelar i förhållande till den verksamhet du modellerar. Leverantör, Kund eller Partner är bara några exempel bland flera. Det är vanligt att se dessa roller som specialiseringar av intressent.

Vad vi då har avbildat är egentligen inte intressenterna i sig utan endast intressenterna i den roll de spelar för oss. Supertypen står då för den generaliserade rollen ”Intressent”. Fördelen är att det är en enkel modell. Men nackdelen blir att vi då inte skiljer ut de egenskaper som intressenten har oberoende av den roll den spelar för oss i motsats till de egenskaper som handlar om relationen till vår verksamhet.

Ett exempel: Om en organisation är både kund och partner till oss så förekommer den två gånger, en gång som kund och en annan som partner. Egenskaper som organisationens namn, adress, typ av organisation med flera som inte har med den specifika rollen att göra blir då redundanta. Det behöver i och för sig inte vara ett problem, men vi bör vara medvetna om den förenkling vi gjort. I de fall vi har intressenter av olika slag och där en intressent ofta förekommer i flera roller så kan den förenklingen bli ett hinder. I så fall behöver vi använda mönster 3.

Mönster 3: Intressent i intressentroll

Om vi tydligare behöver skilja på å ena sidan uppgifter som hör till intressenten i sig, oberoende av vilken roll denne har till oss, och å andra sidan uppgifter som har med den specifika rollen att göra, då passar detta mönster.

Inget av dessa två sätt (mönster 2 och mönster 3) att se på sina intressenter är objektivt rätt eller fel. Båda sätten har styrkor och svagheter, så vilket man ska välja beror på sammanhanget.

En sak vi inte hanterat i detta mönster är det vanliga fallet att personer inte alltid kan förekomma i samma uppsättning av roller som organisationer. Om vi behöver tydliggöra detta i vår modell kan vi tillämpa mönster 4. 

Mönster 4: Organisation och person i intressentroller

Ofta kan både organisationer och personer vara intressenter. Men det kan skilja vilka roller de kan ha i förhållande till vår verksamhet.

Kontaktperson är en roll en person har hos en intressent utifrån den specifika roll intressenten har i förhållande till vår verksamhet. Om en viss organisation är både leverantör och kund till oss så har den organisationen vanligen olika kontaktpersoner, en som leverantör och en annan som kund.

Dock är det viktigt att vi inte blandar ihop dessa generella och varaktiga intressentroller med de specifika roller en intressent kan ha i ett visst sammanhang. Vilket tar oss till mönster 5. 

Mönster 5: Avtalsroller

En intressent har vanligen en roll i olika specifika sammanhang, till exempel i olika avtal.

Det är viktigt att skilja på den generella roll en intressent har i vår verksamhet och den specifika roll intressenten har i ett specifikt sammanhang, till exempel ett avtal. De har ofta samma namn men är olika saker. Jag kan vara kund till företaget och jag kan vara avtalsparten ”kund” i ett specifikt avtal.

Det här är ett mönster som täcker det mesta man kan behöva hantera beträffande intressenter i sina intressentroller.

Refaktorera till enklast möjliga – men inte enklare!

Varje mönster har styrkor och svagheter och kan därmed passa mer eller mindre bra i olika verksamheter och för olika syften. Därför behöver vi förstå de olika mönstren och när de passar det vi behöver hantera. Att välja ett mönster som tar höjd för precis allt är förmodligen lika fel som att välja det enklaste som inte ta höjd för något. Ty ett alltför komplicerat mönster innebär en onödig komplexitet som för med sig en hanteringskostnad som verksamheten behöver bära framgent. Vi bör tänka på Einsteins devis: ”Allt bör göras så enkelt som möjligt men inte enklare”. Vi ska alltså lyfta fram och tydliggöra den inneboende komplexitet som finns i en verksamhet men sträva efter att reducera all onödig och pålagd komplexitet.

Vi behöver använda vårt omdöme och vår erfarenhet. Vi ska inte välja ett mönster för att sedan låsa oss till det i fortsättningen. I stället behöver vi refaktorera (stegvis omstrukturera) våra modeller allt eftersom vi lär oss mer om vår domän. Jag refaktorerar till ett mer kompetent mönster när jag ser att modellen inte uttrycker det jag behöver uttrycka. Och jag refaktorerar till ett enklare mönster när jag märker att saker kan uttryckas enklare och ändå räcka till.

Vi kan växa som informationsmodellerare genom att utveckla den repertoar av mönster vi har och på djupet förstår. Vi gör det bäst genom att dela, diskutera och tillämpa olika mönster.

Jag vill försöka ange källor för de mönster jag presenterar men just mönstren i denna artikel är sånt allmängods att det känns hopplöst att spåra dem.

Kanske du som läser detta kan komplettera med varianter på samma tema? Hur ser ni i er verksamhet på de olika intressentrollerna? Hur fungerar det?

/Peter Tallungs, IRM 

Nästa artikel i serien publiceras torsdag 19 augusti. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Försvar för enkla verktyg – del 5: publicerings- och samarbetsverktyg

En arkitektfunktion behöver vara tillgänglig för en större krets intressenter. Vi behöver därmed någon form av media för att kommunicera effektivt. Vi behöver också virtuella whiteboards för modelleringssessioner. Samt något så otippat som en storformatskrivare.

Som arkitektfunktion i en organisation är vi som vilken verksamhet som helst. Vi behöver berätta att vi finns och vad vi kan bidra med (vår marknadsföring). Vi behöver nå de som behöver våra tjänster (våra kunder) och har nytta av våra modeller, analyser och beskrivningar (våra tjänster och produkter). Vi behöver leverera det de behöver på det sätt som passar dem (vår ”försäljning”). Våra kunder behöver kunna nå oss (vår kundtjänst) och vi behöver modellera tillsammans med våra kunder (co-creation).

Vi kan jobba inbäddat i utvecklingsteam, vi kan köra workshops, vi kan intervjua och forska själva. Men vid sidan av dessa nära och påtagliga samverkansformer behöver vi också vara tillgängliga för en större krets i den organisation vi jobbar. Vi behöver därmed någon form av media så vi kan nå ut bredare. Det här är en av de vanligen misskötta delarna av arkitektarbetet; att förstå att vi är en verksamhet, som vilken som helst, med många intressenter och att vi därmed behöver agera som en sådan.

Vi behöver en kommunikationskanal

Vi behöver därmed någon form av kanal för att kommunicera brett. Jag beskriver nedan hur vi har gjort i de sammanhang jag jobbat. Oftast finns det någon form av samarbetsplattform, kanske en wiki eller något annat, i organisationen där man kan publicera material och skapa olika former av dialogtjänster. Det ska kunna gå att göra följande:

  • Bygga en lämplig struktur
  • Publicera texter, så som meddelanden, annonser och artiklar
  • Publicera länkar till material som man kan ladda ner
  • Prenumerera på notifieringar
  • Kommentera saker och ting, och att diskutera i forum.

Vi behöver ett skyltfönster, ett bibliotek och en anslagstavla

På en samarbetsplattform, av något slag, kan vi bygga upp en webbplats som blir vårt skyltfönster, vårt öppna bibliotek med publicerade modeller och andra dokument samt vår anslagstavla. Där kan vi göra följande:

  • Publicera basinformation om vår funktion:
  • Vilken funktion vi är, till exempel Informationsarkitekt-teamet (IA-teamet)
  • Vilka personer vi är (foton, namn, beskrivning av roll)
  • Vad vi kan bidra med
  • Hur man når oss (telefon och mejladress).
  • Publicera material, till exempel befintliga modelldokument, både för att titta på och ladda ner för att skrivna ut och använda.
  • Publicera händelser. Berätta vad som hänt, till exempel att vi nu uppdaterat en modell i något avseende.
  • Ta emot och bemöta kommentarer,det vill säga få till en dialog.

Vi behöver skilja på arkivet i bakgrunden, vårt repository där vi förvarar och versionshanterar allt vårt material och det öppna tillgängliga biblioteket av publicerat material. I alla verksamheter som hanterar material finns det ett arkiv där allt material förvaras och ett allmänt rum där det som är publicerat finns tillgängligt för de som behöver.  

Vi behöver en redaktör

Som vilken mediekanal som helst så behöver vi en redaktör. Det fungerar inte tillfredsställande med delat ansvar. Det kan vara en person som på en del av sin arbetstid ser till att sköta både struktur och innehåll, kräva in och publicera material och notifiera prenumeranter.

Vi behöver virtuella whiteboard-verktyg

Vi är många som i dessa Coronatider kört modellerings-sessioner på distans med hjälp av virtuella whiteboard-verktyg som till exempel Miro, Mural och Lucidspark och upptäckt att det går utmärkt. Det är klart att inget slår den dialog vi kan få till runt en fysisk whiteboard, men dessa verktyg är ändå fullgoda ersättare och vi kommer förmodligen att även i framtiden komplettera fysiska sessioner med virtuella.  

Vi behöver en storformatskrivare

Modelldiagram behöver bära mycket kunskap samtidigt som de är översiktliga och detaljrika. De kommer inte till sin fulla rätt vare sig på skärm eller projektorduk. De behöver kunna skrivas ut i stort format. Därför förespråkar jag en storformatskrivare.

Det påståendet möts ofta med misstro och ibland till och med lite löje. Vi lever ju i digitalåldern. Inte behöver vi pappersutskrifter då? Men papper är i detta fall det rätta.

En storformatskrivare är en färgskrivare med papper på rulle som skriver ut upp till A0-format (ca 84x119cm). Den är en bläckstråleskrivare vilket gör den enkel, billig och lättskött. Den kostar ca 15 000 kronor. Den är inte större än den gamla synten hemma i gillestugan och kan lätt rullas undan när den inte behövs.

Man kan visserligen få utskrifter från en kopieringsbyrå på stan. Men det tar arbetstid och ledtid och kostar dessutom mycket mer. En egen skrivare betalar sig i ren kostnad efter färre än tio utskrifter. Men det är inte den stora vinsten. Om man inte kan skriva ut direkt så är det en hämsko på arbetet, det segar ner den interaktiva processen. Ty när man skrivit ut en modell man tror man är klar med så upptäcker man direkt, och nästan utan undantag, att man vill ändra något.

Papprets kraft

Det är något magiskt med det fysiska papperet och hur man interagerar med det. Sätt upp din modellutskrift bredvid kaffeautomaten så kommer medarbetare att bli intresserade. Min kollega lägger till och med dit en bunt post-it-lappar och tuschpennor och lockar kaffetörstiga att förbättra modellen. Så bryter man den onödiga respekten för modellen och bjuder in till nyfikenhet, diskussion och engagemang. Man visar att modellen är ett påstående, en hypotes som ska prövas; lika mycket en fråga som ett påstående. ”Vår nuvarande missuppfattning” brukar jag säga. Är det så här saker och ting hänger ihop? Och är det här det bästa sättet att gestalta det? Vi vill veta vad du ser!

Organisationer som har tillgång till storformatskrivare tapetserar väggar och korridorer med modeller, samlas runt dem och ritar. Ibland breder de ut papper på golvet för att tillsammans stega sig igenom sina processer. Storformatskrivaren blir populär i organisationen. Det ligger något fantastiskt i det. Om vi verkligen vill ha engagemang och medskapande så är detta, det mest otippade verktyget i verktygslådan, även det viktigaste.    

På IRMs kontor har vi sedan många år tillbaka en storformatskrivare. Mycket av vårt sätt att utveckla hur vi gestaltar olika typer av modeller som informationsmodeller och förmågekartor hade inte varit möjligt utan den. Ofta tar jag med en rulle med modelldiagram till den kund jag är hos för tillfället. De hamnar på kundens korridorväggar och väcker nyfikenhet och intresse för vad vi gör.

Slutord

Det här var den sista artikeln i den fem delar korta artikelserien ”Försvar för enkla verktyg”. Jag har argumenterat för att en uppsättning vanliga verktyg som i de flesta fall redan nu finns tillgängliga från ditt ”skrivbord” är ett bättre alternativ för oss informationsmodellerare än de mer specialiserade verktyg som finns på marknaden.

Observera att inget av argumenten har varit att det är en billig och tillgänglig verktygslåda, även om det är sant. Ty det är ett argument som bör väga lätt. I stället har jag på punkt efter punkt velat visa att de enkla verktygen är de bästa verktygen. Ja, ofta till och med de enda verktyg som duger utmärkt för det vi behöver för att få till en hållbar och varaktig nytta i en verksamhet. 

Jag har skrivit detta utifrån min roll som informationsarkitekt. Men jag menar att det gäller i lika hög grad för de andra arkitekt-, analytiker- och utvecklarrollerna i våra organisationer. Behovet att arbeta modelldrivet, kommunicera och samverka är precis detsamma.

Det skulle vara intressant med en dialog runt detta. Vilka verktyg använder du? Har du gjort andra val än jag?

/Peter Tallungs, IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 27 maj. Då handlar det om notationer för informationsmodellering. Vilka finns det och vad skiljer dem åt?
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Försvar för enkla verktyg – del 1

En serie i serien. Med denna artikel inviger vi en artikelserie på fem artiklar om informationsmodelleringsverktyg i artikelserien Informationsarkitektens tankar.

Informationsmodellering är ett hantverk. För en hantverkare är verktygen viktiga. Låt oss se över vår verktygslåda. I den här artikeln vill jag försvara de enkla modelleringsverktygen.

Det finns ett antal specialiserade modelleringsverktyg, för både informationsmodeller och andra modeller. De är egentligen hela verktygsplattformar tänkta att stödja modelleringsarbetet genom att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. De ger ofta även stöd för att bygga upp ett förråd för en organisations samtliga modeller, ett repository.

En annan väg att gå är att använda sig av en kombination av vanliga generella verktyg, såsom basala rit-, -skriv, dokumenthanterings- och samarbetsverktyg där man själv får bygga upp de strukturer man behöver. Det är en ”best of breed”- strategi, de vill säga att man strävar efter att använda det bästa verktyget man kan finna för varje enskild arbetsuppgift i modelleringsarbetet.

Jag och mina kollegor har hjälpt många team och organisationer att bygga upp verksamhets- och informationsarkitektur samt Data Management. Vi har därmed erfarenheter från många olika sammanhang och förutsättningar.

Mot denna bakgrund har jag kommit till att förorda det senare alternativet då en kombination av enkla verktyg inte bara är gångbart utan det enda verkligt framgångsrika jag känner till. Enkla verktyg är inte enkla i den meningen att de är simpla. Tvärtom! De ger den flexibilitet och uttrycksfullhet vi behöver för att göra ett bra jobb som informationsarkitekter.

Jag har upplevt att denna ståndpunkt är kontroversiell bland enterprise- och it-arkitekter. Jag vill därför i denna artikel, och fyra efterföljande, tydligt och noggrant argumentera för den vägen. Kanske kan jag få någon att bli mer öppen för det alternativet. Eller också blir jag avfärdad som Luddit. (Ludditer var de engelska teknikfientliga väveriarbetarna som bjöd våldsamt motstånd till de nya effektiva vävstolarna i början av 1800-talet.)

Den enkla verktygslådan

Här är listan på de typiska verktyg jag rekommenderar. Det finns förstås likvärdiga alternativ, men då av samma enkla slag.

  • Microsoft Visio: För att rita
  • Microsoft Word: För textdokument och för att integrera text och bild
  • Katalogstruktur på server, eller liknande: Som repository för modeller
  • Ändringshistorik i dokument samt rutin för att spara versioner i katalogstrukturen: För versionshantering
  • Wiki eller det samarbetsverktyg som används i den organisation jag jobbar: För att publicera modeller samt kommunicera ut vad som händer
  • Storformatskrivare: För utskrift av modeller
  • Whiteboard och digitala samarbetsverktyg: För modelleringssessioner.

Jag kommer i följande fyra artiklar motivera och beskriva hur man kan använda respektive verktyg i verktygslådan. I denna inledande artikel ger jag generella motiveringar för kombinationen av enkla verktyg i motsats till de specialiserade.

Motivering för enkla verktyg

Här följer ett antal motiveringar till att välja enkla verktyg.

Motivering 1: Enkla verktyg ger frihetsgrader och möjliggör den rikare och mer kraftfulla gestaltning som vi behöver

Våra modeller kan bli mycket bättre gestaltade än vad som är vanligt idag. Det gäller alla slags modeller. Om vi ska lyckas få en organisation att samlas kring modellerna och låta dem representera en gemensam förståelse måste de bli mycket mer överskådliga, tydliga och tillgängliga. Samtidigt behöver de ges ett rikare uttryck genom att kombinera olika slags kunskap. Det handlar om hur vi ritar. Det vill säga struktur, disposition, färger, gråskalor, linjetyper, typsnitt, symboler, samt hur vi integrerar text och bild. Vi behöver kombinera och integrera olika slags diagram med varandra samt med textuella beskrivningar.

Det sätt vi i branschen idag arbetar med våra modeller har en stor potential till förbättring. Det handlar också om hur vi hanterar våra modeller, och hur vi tillgängliggör dem. För att kunna göra allt detta på ett bra sätt behöver vi verktyg som ger frihetsgrader, som inte begränsar oss, låser in oss och hindrar oss i det vi behöver göra.

Motivering 2: Enkla verktyg främjar experimenterande och därmed utveckling av alla våra områden där modellering är en viktig del.

Som yrkesgrupp behöver vi utveckla informationsmodelleringsområdet. För det behöver vi verktyg som ger oss den friheten.

Jag vill jämföra med vad som hände inom systemutveckling kring millennieskiftet. Vid slutet av 90-talet var tron på specialiserade modelleringsverktyg stor. Rational Unified Process var den förhärskande utvecklingsmetoden och Rational Rose var det modelleringsverktyg som skulle stödja hela utvecklingsprocessen. De organisationer som var ambitiösa och anammade detta arbetssätt fick det svårt. Metoden framställdes och tolkades på ett sätt som gjorde den överlastad och rigid. Själva metoden och verktyget styrde tänkandet och arbetssättet i stället för att vara en verktygslåda. Det blev att man fokuserade på att betjäna verktyget och utvecklingsmetoden i stället för att koncentrera sig på vad användare och verksamhet behövde. Man blev på så sätt en operatör av ett verktyg utan egen agens och ansvar.  

I det sena 90-talet växte missnöjet hos utvecklare och utifrån några individer växte det fram en motrörelse. Några utvecklare, på lite olika ställen, började tänka på vad de själva verkligen behövde och vad som fungerade. De tog fram mer basala och hantverksmässiga arbetssätt som parprogrammering, test-first design, scrum-tavlor med mera. Det nya tänkesättet grodde och spred sig i utvecklarsamhället. Ett par år efter millenniumskiftet fick det etiketten agila rörelsen. Utvecklare byggde själva enkla verktyg för att stödja sitt arbete. Mest kända blev testverktyg för att automatisera tester samt så kallade refactoring-verktyg för att snabbt och enkelt göra ändringar i kod.

Jag menar att vi behöver en liknande rörelse bland oss informationsarkitekter. Det vi behöver är en ny vår för arkitektarbetet som ett hantverk, precis det som agila rörelsen var för systemutvecklare för två årtionden sedan. Vad gäller arbetssätt så har vi redan lärt av agila rörelsen och alla förstår nog nu att vi behöver smidiga och mer kommunikativa arbetssätt. Men då det gäller verktyg återstår att överge de stora tunga modelleringsverktygen och i likhet med systemutvecklarna gå till oss själva, och ställa oss frågan vad vi egentligen behöver. Tillbaka till hantverket, och vad som verkligen stödjer det.

Jag har sett organisationer där arkitekterna varit som slavar under avancerade verktyg. De har varit upptagna med att mata verktygsmonstret. Resten av organisationen har inte haft nytta av arkitekterna, som befunnit sig i en parallell värld utan kontakt med verksamhetsutvecklingen.

Och denna nya vår jag hoppas på har faktiskt redan grytt på en del ställen. Jag har sett organisationer där verksamhets- och informationsarkitekter till sist givit upp sina tunga arbetssätt och verktyg. De har lämnat sina slutna rum, klivit ner från elfenbenstornet och gått ut där verksamhetsutvecklingen sker, bland utvecklarna och i verksamheten. De har sett hur de kan stödja utvecklingsarbetet. De har då, för första gången, känt sig välkomnade av utvecklare och domänexperter. De modellerar fortfarande, men nu med enkla tekniker som tjänat syftet på ett helt annat sätt.

I de fall de trots allt behövt lite mer verktygsstöd har de, precis som utvecklarna, själva experimenterar och byggt de verktyg de behövt. Jag ska försöka ge exempel på sådana verktyg framöver.

Dessa egenbyggda verktyg kan sedan i likhet med vad som hänt inom utvecklarvärlden så småningom kommersialiseras och bli standard. Det är egentligen alltid så det sker då ett yrkesområde utvecklas på riktigt. Alltid utifrån professionen och hantverket. Aldrig från verktygsleverantörerna.

Motivering 3: Enkla verktyg sätter fokus på uppgiften

Att ta ansvar för något stort, till exempel en informationsarkitektur, kan vara skrämmande. Det är många saker man måste ta ställning till och kanske behöva försvara. Då är det lockande att gömma sig bakom ett ramverk, en industrimodell, en metod eller ett verktyg som synes ge objektiva svar. Det är att fly undan det ansvar vi har. Då blir jag en operatör av ett verktyg i stället för informations- eller verksamhetsarkitekt.

Vi behöver i stället fokusera på vad som behöver lösas i verksamheten och använda de verktyg som gör jobbet. Inte först välja verktyg för att sedan bara mata detta.

Motivering 4: Enkla verktyg minskar beroendet

Om man i en organisation har tagit in ett avancerat modelleringsverktyg så medföljer det ett antal metamodeller, vilka styr hur de modeller man tar fram måste se ut och relatera till varandra. Om man senare vill ändra detta kan det bli mycket dyrt och svårt. Verktygen är i själva verket ofta en hel plattform av verktyg som hänger samman. Man blir på flera sätt, på gott och ont, beroende av leverantören och dennes utveckling av plattformen.  

Vanliga argument för specialiserade verktyg

När man argumenterar för en enkel verktygslåda får man ofta mothugg. Här följer ett antal argument som man stöter på och hur jag vill bemöta dem. 

Argument 1: Specialiserade verktyg ger konsistens

Specialiserade verktyg har en metamodell som styr hur vi kan modellera. Det gör att vi alla ritar och beskriver på samma sätt vilket är viktigt. Om vi inte gör på samma sätt blir resultatet spretigt, återanvändningen svår och kvaliteten lidande. Det följer vanligen med metamodeller vi kan välja mellan och i de mer avancerade verktygen kan vi själva, eller med hjälp från konsulter, ta fram en egen metamodell som passar oss.

Mitt motargument: Sättet vi modellerar behöver utvecklas för att på allvar bli relevant för våra verksamheter. Vi behöver alltså se det som ett hantverk i utveckling. Då är experimenterandet viktigt, att vi söker oss fram och lär oss. Vi ska då inte standardisera arbetssätt, notationer, metamodeller med mera. Det skulle frysa all utveckling och fortsätta hålla oss fast på det stadium vi är idag. Däremot ska vi dela erfarenheter och inspireras av varandra. Men det är något helt annat.

Det finns alltid, inom alla områden en motsats mellan utveckling och standardisering. Vi ska standardisera det vi tycker att vi nått en mognad inom. Men bara där. Där vi behöver utveckling ska vi tvärtom befrämja att vi gör olika, inte bekämpa. Vi behöver tåla och bejaka spretigheten. Utveckling innebär experimenterande.

När vi har lärt oss vad som verkligen fungerar kommer saker och ting att mogna och vi kommer naturligt att gravitera mot något av en de facto-standard. Men att gå utvecklingen i förväg och bestämma en standard innan vi har nått den mognaden är fel. Det är att frysa all utveckling. Därför behöver vi frihetsgrader. Det betyder inte kaos, utan bara att vi i får vara beredda på varianter och förbättringar i små steg. Och även något vilt försök ibland! Det är så utveckling går till. Överallt och alltid.

Argument 2: Specialiserade verktyg ger struktur och ordning

Specialiserade verktyg styr hur och var vi spar, versionshanterar och publicerar modeller. De ger oss ett strukturerat repository. Det gör att resultatet inte bara blir högar av osorterade modeller på olika ställen med oklara syften och sammanhang.

Mitt motargument: Vi behöver alltid ett strukturerat repository. Vi vill inte ha oordning. Men det är mycket lätt att ordna det på ett enkelt sätt och på vilken lagringsyta som helst där man kan ha filkataloger av något slag, och något slag av enkel åtkomstkontroll och versionshantering.

Det är fel att tro att ett specialiserat repository krävs för ordning och reda. Ett specialiserat repository ger heller inte ordning och reda av sig självt. Vi behöver även då tänka igenom och komma överens om saker och ting. Den största faran med verktyg som styr oss är kanske just den tankefällan, att vi tror att vi inte behöver tänka själva. Vi har sett modellbibliotek som varit total kaos i verktygsbaserade repositories och jag tror faktiskt att vi sett fler välordnade bibliotek bland de som byggs mera manuellt. Jag är övertygad om att när jag behöver bygga något själv leds jag in på att tänka igenom och ta ansvar för vad som behövs.   

Argument 3: Specialiserade verktyg ökar produktiviteten

Verktyget hjälper mig. Jag kan återanvända delar av andra modeller när jag gör en ny, eller referera till befintliga. När jag vill göra en ändring av något som manifesterar sig på många ställen behöver jag bara ändra på ett ställe. När jag vill publicera en modell gör jag det automatiskt. Versionshanteringen är inbyggd vilket gör att den går lätt och smidigt. Jag behöver inte fundera så mycket på hur jag ska göra rent praktiskt med dessa hushållsbestyr så jag kan koncentrera mig på själva modellerandet.

Mitt motargument: Jo, verktyget hjälper dig förvisso med några enkla uppgifter. Men inte alls så mycket som man kan tro, och inte alls med det som är det väsentliga; hur du gör riktigt bra modeller och hur du når ut med dem. Tvärt om hindrar det dig. Så triviala uppgifter går kanske något snabbare – men till ett mycket högt pris.

Om vi definierar produktivitet som hur mycket nytta vi gör, hur bra vi når ut och hur vi hjälper människor och team att hantera sin komplexitet så vinner de enkla verktygen överlägset. 

Det finns ett talesätt som säger ”A fool with a tool is still a fool”. Det brukar motvilligt citeras av verktygssäljare när man pekar på misslyckade införanden av deras produkter. De vill betona att deras fina verktyg trots allt inte garanterar ett bra resultat, utan att det kan finnas dumma människor som inte begriper hur de ska användas. Det finns ett tillägg till talesättet som säger ”A fool with a tool makes a faster fool”. Det vill säga att om ett verktyg ökar produktiviteten utan att verktygsanvändaren gör ett bra jobb hamnar man snabbt i ett dåligt läge.

Argument 4: Specialiserade verktyg stödjer samarbete

Verktyget stödjer att flera kan jobba samtidigt med samma modell, kanske även från olika geografiska platser.

Mitt motargument: Jo, verktyget har funktioner för detta. Men det fungerar bättre med de generella samarbetsverktygen vi använder i övrigt i våra distansarbeten.

Konflikten mellan viss automatisk hantering och stöd för rik gestaltning

Jag menar att om vi använder de specialiserade verktyg som finns så får vi visserligen stöd för vissa enkla uppgifter.

Men vi väljer samtidigt bort möjligheten till att göra riktigt bra modeller.

Vi kan inte få både och. Åtminstone inte idag. Och inte förrän vi själva inom professionen bidrar till den utveckling som kanske kan ge oss sådana verktyg.

Och vi tenderar till att både övervärdera nyttan av den lilla automatisering vi kan få samt att undervärdera vikten av att göra riktigt bra modeller som når fram.

I själva verket är det så krasst att om vi inte når fram har vi inget som motiverar vår existens.

De ivrigaste proponenter för specialiserade verktyg jag mött har nästan i samma mening beklagat att de inte har gehör hos it- och verksamhetspersoner för vad de gör, utan blir ständigt kringrända av utvecklingsprojekten. Det kanske skvallrar om något?

Fortsättning följer

Jag är medveten om att den här posten väcker många frågor. ”Peter pratar mycket om att vi ska göra bättre modeller men inte hur det går till.” Det är ett stort område, men jag vill steg för steg i den här artikelserien ge mitt bidrag till det.

Vad är din erfarenhet? Vilka verktyg använder du? Handen på hjärtat, vad fungerar på riktigt?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 22 april. Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.

Data management – se hela kedjan

För att en organisation ska få nytta av sina data behöver en hel kedja av förutsättningar vara uppfyllda. Vi behöver se och förstå hela kedjan för att hitta och förstärka svaga länkar.

En organisations data är en tillgång. Om vi kan hantera den tillgången på ett bra sätt så ger den mångfalt tillbaka. Data kan inte bara stödja verksamheten operativt utan också användas analytiskt, det vill säga ge insikter och kunskap och därmed ligga till grund för beslut och handling. Men för att en datatillgång verkligen ska ge nytta måste den tas om hand, den måste förvaltas aktivt. Det är det vi kallar Data Management.

En modell i form av en kedja

Data Management är ett område med stor spännvidd och som inkluderar alla de åtgärder som behövs för att ta hand om en dataresurs för att maximera dess värde.
För att få överblick över området kan vi använda oss av en modell över en tänkt kedja av förutsättningar, från det att data registreras någonstans tills det att man får nytta av dessa data i organisationen. Modellen är en uppräkning av förutsättningar som tillsammans bildar en kedja, där varje förutsättning behöver uppfyllas. Jag har ofta visat denna modell i olika sammanhang för att visa vad Data Management kan omfatta. Modellen kan dock kännas en aning konstlad. Man har försökt pressa in lite för mycket, speciellt i slutet av kedjan. Som jag skrev i artikeln ”Data eller information” skapas sällan kunskap direkt ur data på ett linjärt sätt vilket modellen ger sken av. Kunskapsprocessen i en organisation är en växelverkan mellan flera olika handlingar och källor, där data visserligen är en viktig källa men ändå endast en av de inblandade faktorerna. Så vi ska ta modellen med en nypa salt. Men jag tycker ändå att modellen, trots sina begränsningar, har sin poäng i att den positionerar Data Management i förhållande till angränsande och överlappande discipliner. Modellen presenteras i det följande.

Kedjan av förutsättningar

Nyttan av data uppstår bara om en serie av förutsättningar är uppfyllda. Dessa förutsättningar bildar länkar i en kedja. Varje förutsättning blir meningsfull endast om alla föregående förutsättningar i kedjan är uppfyllda. Som bekant är det den svagaste länken i en kedja som avgör om den håller. Det spelar då ingen roll hur starka de andra länkarna är. Svagheten i en länk vägs inte upp av styrkan i de andra.

Kedjan av förutsättningar kan listas som nedan. För varje förutsättning ger vi exempel på faktorer som kan bidra till att den förutsättningen kan uppfyllas.

  1. Att rätt data finns
    Att det någonstans (innanför eller utanför organisationen) finns rätt data, det vill säga som handlar om rätt saker och är anpassade till situationen.
    Bidragande faktorer: Dataplanering, dataanalys, processutveckling, utveckling av applikationer för registrering, Business Intelligence, givare för insamling av data, givare för maskindata med flera.
  2. Att man känner till att dessa data finns och var de finns
    Det händer ofta att data finns men att de som behöver den inte vet om det. Då stoppar det redan här.
    Bidragande faktorer: Aktivt sökande av datakällor och datatjänster, datakataloger, Data Dictionary, utbildning, kommunikation, informationsmodeller/- kartor med flera.
  3. Att man kan nå och få fram dessa data
    Kan vara via maskinella eller manuella tekniker.
    Bidragande faktorer: Applikationer, intranät, internet, sökmotorer, SQL, Data Warehouse, API-er, datatjänster, presentationstekniker med flera.
  4. Att man kan förstå dessa data
    Det vill säga att man kan tolka dess innebörd och syfte med stöd av sina egna referensramar.
    Bidragande faktorer: Utbildning, erfarenhet, definitionsarbete, namngivning, modeller/kartor, metadata, dokumentation, informationsanalys med flera.
  5. Att man kan lita på informationen
    Att man kan lita på att den information man tagit till sig stämmer med verkliga förhållanden.
    Bidragande faktorer: Metadata, källhänvisningar, goda erfarenheter, datakvalitetsarbete, redundans med flera.
  6. Att man kan vidarebearbeta data
    Att man kan sortera, filtrera, kombinera, summera och sammanställa data och därmed bilda sig ytterligare sammanfattad/komplex information som blir mer användbar för att dra kunskaper ur.
    Bidragande faktorer: Data-analysverktyg och metoder, Data Science, rapportverktyg, aktivt arbete med framtagning och förvaltning av rapporter med flera.
  7. Att man kan dra korrekta slutsatser från informationen
    Från informationen man fått fram behöver man sedan kunna dra slutsatser som är relevanta i sammanhanget.
    Bidragande faktorer: Domänkunskap, erfarenhet, överblick, logisk förmåga, abstraktionsförmåga, konkretionsförmåga med flera.
  8. Att man kan besluta sig för ett handlingsalternativ
    Detta baserat på slutsatserna, intuition, beslutsstil och personliga faktorer.
    Bidragande faktorer: Beslutstil, beslutsförmåga, belöningssystem, rekrytering, organisationskultur, personlig utveckling med flera.
  9. Att man kan gå från beslut till handling
    Det vill säga verkställa och agera.
    Bidragande faktorer: Genomförandekraft, motivation, handlingsberedskap, inräkning och kultur för att agera med flera.

Se hela kedjan

Varje gång en nytta av dataförsörjningen har uppstått har varje länk i kedjan hållit. Om en enda länk i kedjan brister blir värdet noll. Det vill säga ingen nytta, endast kostnader. Helheten är därmed viktig. Inom Data Management behöver vi se hela kedjan, hitta de svaga länkarna och stärka dessa. Vi behöver därmed satsa brett på informationsteknik och verksamhet samt människa och teknik i samverkan.

Var kommer Data Management in?

Vi kan succesivt dela in kedjan i större sträckningar, vilka var och en kan ges en rubrik. Låt oss se var vi som jobbar med Data Management kommer in.

  • Länk 1-3: Utdata till användaren
    Det är det som it- funktionen i organisationer vanligen avgränsar sin uppgift till. Man ser vanligen inte det som sin uppgift att tala om vad data betyder eller vilken kvalitet de har.
  • Länk 1-5: Informationsförsörjning
    Det bör vara vår uppgift inom Data Management att lyfta organisation och arbetssätt till att omfatta hela informationsförsörjningen. Vi informationsarkitekter kan kanske göra störst nytta då det gäller att stärka länk fyra och fem så att hela informationsförsörjningen håller.
  • Länk 1-7: Informationsförsörjning och användning
    Det bör även ingå i informationsarkitektens uppgift att bidra till att analytiska användare har verktyg för att bearbeta de data de har tillgång till. Vi behöver av många skäl samarbeta nära med den typen av användare. Inte minst för att det ger insikter i hur vi kan bidra med att få mer data och i rätt form.
  • Länk 1-9: Hela kedjan till och med att nytta uppstår
    Hur användarna av data drar slutsatser, beslutar och agerar, på basis av data, kan vi inte direkt påverka. Dock behöver vi observera och arbeta tätt ihop med de som gör det. För det ger insikter om vad vi som arbetar med informationsarkitektur eller Data Management behöver bidra med.

Hur långt sträcker sig ditt intresse?

Hur långt sträcker sig ditt intresse och engagemang? Hur ser du på din eller ditt teams roll? Vilken länk är svagast i din organisation? Kan du göra något för att stärka den?
Dina erfarenheter och tankar är välkomna.

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 15 april. Då inleder vi en liten serie i serien. Den kommer handla om hantverket informationsmodellering.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.