Modellmönster: Observationer

Föregående artikel, ”Modellmönster: Mätningar”, handlade om att registrera mätningar av olika slag. ”Mätningar” är ett namn vi använder för kvantitativa observationer, det vill säga observationer vars resultat kan uttryckas som ett mätvärde. Denna artikel breddar temat till att omfatta alla typer av observationer. Ty kvalitativa observationer blir viktigare i samma takt som kvantitativa.

Exemplen nedan är från sjukvården där man ju gör en stor mängd observationer. Men samma mönster är tillämpliga på alla sammanhang där man registrerar observationer av olika slag.

Mönster 1: Observationer

Precis som det finns många kvantitativa utsagor vi kan göra om en patient finns det också kvalitativa utsagor. Som blodgrupp, kön och om patienten har diabetes eller inte. Vi kan se dessa som Kategoriobservationer eftersom resultatet av observationen, det Observerade värdet, alltid representerar en kategori av något slag, till exempel alla med blodgrupp A, alla kvinnor eller alla som inte har diabetes.

Vi kan utöka mönstret från föregående artikeln, ”Modellmönster: Mätningar”, till att omfatta även sådana observationer.
Kön blir ett Kategorifenomen samt Man, Kvinna, och eventuellt andra kön, blir Observerbara värden. Blodgrupp blir ett annat kategorifenomen med de observerbara värdena A, B, AB och 0. Diabetes blir en tredje typ av kategorifenomen med de observerbara värdena Positiv och Negativ.

Om diagrammets layout

Innan vi går till nästa mönster vill jag ta upp detta med layouten i diagrammet ovan. Till höger har vi regler för observationer, det vill säga vilka fenomen som kan observeras, hur de är indelade i två typer samt vilka värden och måttenheter som gäller för varje fenomen. Till vänster har vi de observationer som gjorts. När något ändras till höger, till exempel att man inför underblodgrupperna A1 och A2 i vad som går att registrera, innebär det att verksamheten konfigureras. När något ändras till vänster, det vill säga att en observation görs, opereras verksamheten.

Jag har i flera av de tidigare artiklarna om modellmönster, till exempel den föregående artikeln ”Modellmönster: Mätningar”, skrivit om hur värdefullt det är att dela in ett modelldiagram (eller mer vanligt, en del av ett diagram, ett särskilt ämnesområde) på detta sätt. Det här är ett annat bra exempel.

Men vi har en dimension till hos modellen ovan som avspeglas i diagrammet. Entiteterna bildar två horisontella rader i diagrammet, en för observationer av kategorifenomen och en för kvantitativa fenomen. Vi ser således två dimensioner i den här delen av verksamheten och avspeglar det i diagrammet.

Spegla verksamheten i diagrammens struktur

Jag tycker att det är intressant hur vi kan strukturerar våra diagram för att avspegla de mönster vi vill se i verksamheten. Vi kan hitta mönster i den mentala strukturen hos de företeelser som verksamheten hanterar som vi på så sätt kan representera och kommunicera. Det är egentligen det enda sätt vi kan få grepp om och hantera det komplicerade maskineri en verksamhet faktiskt är. Jag har inte sett den aspekten av vårt arbete som informationsmodellerare beskrivet eller diskuterat någonstans. Det har varit och är fortfarande, märkligt nog, ignorerat i hela branschen trots att det är en så central aspekt av vårt yrkeskunnande. Hitta och förmedla användbara mönster är väl allt vi gör ungefär. Desto mer angeläget att vi inom vår yrkesgrupp tar upp och diskuterar och tillsammans utvecklar hur vi kan rita och strukturera våra diagram. Jag tror att det har en stor betydelse för hur bra våra modeller blir och är därmed en viktig faktor för hur vi lyckas som individer, team och profession.

Jag kommer att komma in lite djupare på detta ämne i kommande artiklar vilka mer direkt kommer att handla om hur vi kan gestalta våra modeller.

Mönster 2: Indikationer

Vissa fenomen indikerar andra fenomen. Exempel: Viktminskning indikerar Diabetes. Vi kan utöka regelplanet i modellen med sådan kunskap.

Mönster 3: Observationsmetod

När man registrerar en observation kan det vara mer än resultatet som är viktigt. Man vill gärna veta vilken observationsmetod som användes, då det kan förklara ett märkligt resultat eller användas för att bedöma noggrannheten i observationen. Vi lägger därför till observationsmetod i diagrammet.

Mönster 4: Tid för observationen och Tid för registreringen

En observation har en tid för när den gjordes och en tid för när den registrerades. Tiden för observationen kan vara en Tidpunkt eller en Tidsperiod. Tiden för registreringen kan dock bara vara en tidpunkt.

Det gäller de flesta händelser, att de har separata tider för när de inträffade och när de registrerades.

Jag kommer att komma in på detta med temporala mönster i en kommande artikel.  

Mönster 5: Ogiltig observation

Vi kan inte komma ifrån att vissa observationer förklaras ogiltiga genom att en eller flera nya observationer motsäger den första.

Vi kanske har regler som säger att registreringen av en observation aldrig får raderas. Då får vi i stället klassa om observationen som ogiltig och länka den till den eller de nya observationer som motiverar detta.

Var kommer dessa mönster från?

Även denna artikel, precis som den föregående om mätningar, har jag inspirerats från vad jag hittat i Martin Fowlers bok ”Analysis Patterns” från 1997. Boken är, som jag tidigare nämnt, en dold skatt, lite av en apokryfisk skrift, vad gäller modellmönster. Som härmed återupptäcks hoppas jag.

/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: Mätningar

I de flesta organisationer görs mätningar av olika slag. I stort sett alla verksamheter blir mer och mer datadrivna, vilket innebär att en mängd olika typer av kvantitativa data samlas in och hanteras. Denna artikel tar upp några användbara mönster för att registrera mätningar. Exemplen är tagna från sjukvården, men mönstren är tillämpliga på alla slags verksamheter.   

/Peter Tallungs, IRM, 2021-10-14

Mönster 1: Specifika attribut per mätvärde

Det vanligaste sättet att registrera ett mätvärde i ett informationssystem är att registrera ett numeriskt värde i ett fält avsett för ett visst mätvärde.

Ett problem är att det vanligen inte anges vilken måttenhet som avses. Det har lett till fatala misstag många gånger.

Ett sätt att åtgärda detta är att alltid baka in namnet på måttenheten i attributnamnet. Det är ett enkelt och effektivt sätt att öka datakvaliteten och minska risken för missförstånd. Ändå är det sällan så görs. Kanske det ännu finns en kvardröjande uppfattning om att attributnamn måste vara korta. Men det var länge sedan vi hade den tekniska begränsningen i våra informationssystem.

Mönster 2: Entitet för mätvärde

I till exempel medicinska sammanhang vill man av säkerhetsskäl kunna registrera en mätning exakt som den gjordes, utan att behöva räkna om måttenhet. Då blir det användbart att introducera en särskild entitet för Mätvärde där vi ser måttenhet, värde och tecken som en sammanhållen enhet.

Monetära belopp kan hanteras på samma sätt. På det sättet kan man hantera flera valutor samtidigt.

Mönster 3: Omräkningsfaktor

Om vi som i föregående mönster har måttenheter som är explicit angivna i modellen så kan vi automatiskt omvandla ett mätvärde från en enhet till en annan, om vi har en Omräkningsfaktor. En sådan kan hantera de flesta omräkningar, dock inte alla. Till exempel Celsius till Fahrenheit kräver en formel. Dagar, månader och år konverterar inte heller så lätt till varandra, utan kräver lite mer avancerad omräkning.

Detta mönster är vanligt för automatisk omräkning av monetära belopp i olika valutor. Vanligen vill man hålla reda på valutakurser över tiden vilket gör att de behöver datumstämplas.

Mönster 4: Mätning

På ett sjukhus måste man kunna registrera många olika slags mätningar för samma patient. Då kan man inte ha ett attribut per möjlig mätning. Det skulle bli hundratals attribut, där de flesta förblir oanvända för en och samma patient.

En lösning är att betrakta alla saker som kan mätas (längd, vikt, blodsockernivå mm) som Typ av fenomen samt införa Mätning, en entitet för själva mätningen som görs. Vi kan då också lägga på attribut på mätningen, så som vem som gjorde den, när den gjordes och var. 

Det är värdefullt att dela in den del av modellen som är för mätningar i ett operativt plan och ett regelplan enligt ovan. Det operativa planet registrerar de mätningar som görs dagligen. Regelplanet representerar reglerna om vad som kan mätas och uppdateras endast då dessa ändras.


Man kan också ha en lista av tillämpliga måttenheter för varje fenomen, för användarna att välja från.

Kvantitativa och kvalitativa observationer

”Mätningar” är ett namn vi använder för kvantitativa observationer, det vill säga observationer vars resultat uttrycks som kvantitet eller antal av något slag. Nästa artikel breddar temat till att omfatta även kategoriobservationer, det vill säga observationer vars resultat uttrycks som tillhörande en kategori av något slag.

/Peter Tallungs, IRM

Vintergatan – en karta och en metod för att accelerera innovation och förändring

Vintergatan är en metod och en karta som gör det lätt att navigera en verksamhet från strategi till reellt genomförande i en ständigt föränderlig värld. Den knyter samman andra arkitekturmodeller så att den blir lättöverskådlig för hela verksamheten oavsett bransch. Med dess hjälp går det att synkronisera en mängd skilda resurser i en viss önskad riktning.

Hela idéen för Vintergatan uppstod genom ett starkt behov av att få verksamheter att holistiskt bli mer organiserade och effektiva. Metoden har utvecklats av kon- sultföretaget IRM i samarbete med ett trettiotal andra företag. Visionen var att verksamheter ska snabbt kunna svara på och bryta ner komplexa frågor som kan uppstå i verksamheten. Vintergatan är en karta över en verksamhet som visar vad verksamheten gör i vilken ordning. Vilka IT system man använder då man utför detta arbete, vilken information som skapas var och som behöver förmedlas till andra, samt hur man interagerar med sina kunder och partners. Allt i en och samma bild.

För fem år sedan började Cecilia Nordén, som arbetat med affärsstrategier och verksamhetsarkitektur sedan 1997, på IRM och anser att modellen är oerhört kraftfull. Även Thomas Larsson som är ny verksamhetsarkitekt på IRM har sett vad modellen kan göra för kunderna.

Visuellt starka analyser ger bättre beslutsunderlag

– Att ha en karta över verksamheten är intressant. Men riktigt spännande blir det då vi börjar använda kartan som grund för att göra analyser. På kartan kan vi visualisera frågor som: vilka projekt som pågår var, var vi har problem idag, vad vi lägger våra pengar på, önskemål från kunder eller var ny teknologi skulle ge störst nytta. Genom att visualisera dessa typer av frågeställningar på ett och samma sätt kan vi jämföra dessa på ett liknande sätt och upptäcka fler saker som behöver hanteras.

Innovation handlar mindre om idén i sig och mer om tiden det tar att omsätta den till något som når ut till kunderna så fort som möjligt, med en effektiv process på insidan. Vintergatan är ett ovärderligt verktyg för att föra rätt diskussioner om hur detta ska gå att realisera samt göra ”reality check” på vad som är möjligt eller inte, berättar Cecilia.

En gemensam bild som alla kan relatera till

–Vi skapar en gemensam bild, en verksamhetskarta som alla enkelt kan arbeta med. Vi använder liknelsen med en karta eftersom det är lätt för en organisation att relatera till på ett pedagogiskt sätt. Många verksamheter använder ibland svåra termer och då blir det oåtkomligt för många. Det var det som attraherade mig att börja jobba på IRM med Vintergatan. Jag kunde verkligen applicera och förklara metoden för mina kunder oavsett vilka utmaningar de stod inför, berättar Thomas.

Framtidvisioner

–Visionen för IRM är att växa starkt inom Vintergatan. Vi ser att det finns ett skriande behov hos verksamheter efter en gemensam bild av hur deras verksamhet fungerar idag. Många har tagit till sig vikten av gemensamma visioner och mål. Men om alla börjar den resan på helt olika platser, pga sin egen syn på hur verksamheten fungerar idag, så blir effekten att alla rusar iväg på sin egen väg och vi får svårt att tillsammans nå uppsatta mål, förklarar Cecilia. Thomas fortsätter:

–Jag har en önskan om att vi inte ska dela upp allting i så hårda block som vi gör idag. Ta exempel som IT- arkitekter, UX specialister, kundresor och så vidare. Idag känns det som att det är olika discipliner som cirkulerar omkring. Min vision är att vi slutar med det och kommer överens om åtminstone ett sätt att se på verksamheten tillsammans. Det är min ödmjuka syn.

Etablera Vintergatan i din organisation

Med utgångspunkt från Vintergatan etablerar vi tillsammans ett nytt sätt att arbeta med er verksamhetsarkitektur, för att uppnå samsyn, skapa bättre beslutsunderlag, öka förändringstakten och kundvärdet. Vi utvecklar former för att förstå och använda nya mönster kring förmågor och produkter/tjänster samt de olika tidsperspektiven.

Läs mer om Vintergatan

Har du frågor om Vintergatan? Tveka inte att kontakta oss.

Cecilia Nordén, verksamhetsarkitekt och författare till boken Vintergatan – din verksamhetskarta
Thomas Larsson, verksamhetsarkitekt och författare till boken Lat men effektiv

Modellmönster: Planering

De flesta organisationer behöver planera sin verksamhet samt följa upp planerna. Till detta har de diverse informationssystem. I detta sammanhang finns det lite mer att tänka på än man kanske till förstone tror.

I denna artikel tar jag avstamp i det enklaste och vanligaste mönstret, Planerad – Pågående – Genomförd, och förklarar varför det inte alltid fungerar så bra. Jag ger i de senare mönstren i artikeln ett alternativt sätt att se på planer.

nster 1: Uppgift

Beståndsdelarna i en plan är de uppgifter som vi människor planerar och genomför. En uppgift kan definieras som en avgränsad enhet av arbete som man planerat att göra, gör just nu eller har gjort. En uppgift kan ha ett antal egenskaper baserat på vem, vad, var och när.

Mönster 2: Planerad – Pågående – Genomförd

När vi gör planer och när vi övervakar planer behöver vi ta hänsyn till de tillstånd en uppgift kan ha. Det är vanligt att man har tillstånden Planerad, Pågående och Genomförd, eller motsvarande.

Det här är ett enkelt och mycket vanligt mönster, som kan verka naturligt och självklart. Men Martin Fowler argumenterar i sin bok ”Analysis Patterns” för att mönstret egentligen inte är särskilt realistisk, det vill säga att den är en teoretisk modell som rimmar dåligt med hur vi gör i verkligheten.

Låt oss titta närmare på svagheterna med detta mönster.

Planering kan sägas bestå av tidsplanering och resursplanering. Dessa kan ske i vilken ordning som helst. Men många uppgifter sätts igång utan formella beslut. De har då varken tids- eller resursplanerats. Vi kan ju förstås alltid hävda att de planeras precis i det ögonblick de startas, men det blir då mer en teoretisk styrmodell än en korrekt bild av verkligheten. Ett annat problem med detta enkla mönster är att det inte tar höjd för att många aktiviteter sätts igång innan man har alla resurser som kommer att behövas. Man planerar att anskaffa det som behövs under vägen.

Hur ska vi då göra? Jo, antingen kan vi söka ett mönster som bättre avspeglar verkligheten. Eller så kan vi använda detta enkla linjära mönster. Men då bör vi i alla fall känna till och närmare förstå dess svagheter. I annat fall får vi svårt att hantera svagheterna när de ger sig till känna.

Mönster 3: Föreslagen uppgift och Implementerad uppgift

Ett helt annat sätt att se på uppgifter, ett sätt som enligt min mening stämmer bättre med verkligheten, är att de finns som två olika företeelser, Föreslagen uppgift och Implementerad uppgift.

En föreslagen uppgift finns bara i en plan som ett förslag. Där kan den resurs- och tidsplaneras i godtycklig ordning. Uppgiften har ingen verklig existens. Först om och när den påbörjas får den en verklig existens, den är då implementerad, det vill säga att uppgiften pågår eller är redan genomförd. Vi bör då se den implementerade uppgiften som en helt egen företeelse, och inte som en föreslagen uppgift som ändrat tillstånd.

Det gör att vi kan registrera skillnader mellan plan och genomförande. Skillnad i tid sker nästan utan undantag, men egentligen kan precis alla egenskaper ändras från plan till genomförande. För att få flexibilitet bör länken mellan föreslagen och implementerad uppgift vara icke-obligatorisk.

Planering är viktigt, men planen är bara en hypotes som snabbt kan bli överspelad. När verkligheten träffar våra planer blir ibland även de bästa planerna lagda på hyllan, och många andra saker händer utan att vara planerade.

En allmän reflektion är följande: Det som vi i förstone ser som två olika tillstånd hos en och samma företeelse, kan ibland förstås bättre som om vi ser det som separata företeelser med olika identiteter och egenskaper.

Frågorna man kritiskt bör ställa sig är följande:

  1. Följer tillstånden regelmässigt på varandra, inte bara i vår ideala föreställningsvärld utan även i verkligheten?
  2. Förblir de väsentliga egenskaperna desamma före och efter tillståndsövergången?
  3. Är det sällsynt att en företeelse i första tillståndet splittras i flera företeelser i andra tillståndet (som att en planerad uppgift implementeras som flera uppgifter), eller tvärtom, att flera företeelser i första tillståndet slås samman till en enda företeelse i andra tillståndet (som att flera planerade uppgifter genomförs som en uppgift)?

Mönster 4: Genomförd uppgift och Annullerad uppgift

Så här långt har vi undersökt hur uppgifter föreslås och hur de påbörjas, men ännu inte om de genomförs.

Ett problem är att vi i många sammanhang inte kan säga med säkerhet om en uppgift var en framgång eller ett misslyckande. Det är ofta endast en subjektiv bedömning, och kan kanske göras först långt i efterhand.

Därför tar vi i detta mönster bara med två möjliga utgångar: avslut eller nedläggning, det vill säga vi får Genomförd uppgift och Annullerad uppgift. Observera att faktat att en uppgift är genomförd inte säger något om resultatet, det vill säga om den lyckades eller misslyckades.

Besltet om att annullera en uppgift kan komma antingen före eller efter att den påbörjats. Att annullera en föreslagen uppgift är detsamma som att besluta att inte påbörja.


Mönster 5: Suspension

Vi kan pausa en uppgift med avsikt att fortsätta den senare. Tisperioden för suspensionen kan ha en öppen sluttid, vi vet inte hur länge en pågående paus kommer att vara.

Om supensionens sluttiden är passerad är den inte längre suspenderad utan aktiv. En uppgift är suspenderad om den har en för ögonblicket gällande Suspension.

Både föreslagna och implementerade uppgifter kan vara suspenderade. Att suspendera en föreslagen uppgift är samma som att senarelägga starten.


Mönster 6: Plan

En Plan är i sin enklaste form en samling uppgifter länkade i någon slags sekvens. Sekvensen uttrycker vanligen någon form av beroende, att en uppgift inte kan påbörjas förrän en annan är slutförd.


Mönster 7: Interagerar planer

I många situationer samverkar eller interagerar flera planer med varandra. En och samma uppgift ingår i flera planer. Ett beroende mellan två uppgifter gäller endast inom en viss plan.

Var kommer dess mönster ifrån?

Dessa mönster härstammar från Martin Fowlers bok ”Analysis Patterns”. Som jag tidigare har skrivit är det en orättvist bortglömd skatt, som jag gärna vill lyfta fram.

/Peter Tallungs, IRM

Modellmönster: Ekonomisk redovisning – del 2: Posteringsregler

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”.

I den föregående artikeln, Ekonomisk redovisning – del 1: Konto och transaktioner, gick jag igenom sex mönster för konton och posteringar. I denna artikel presenterar jag sju mönster på hur man kan automatisera posteringar med hjälp av regler.

/Peter Tallungs, IRM, 2021-09-30

Mönster 1: Posteringsregel med faktor

Låt oss ta som exempel att varje gång pengar kommer in på ditt inkomstkonto lägger du 30 procent av beloppet på ditt skattekonto (som är ett minneskonto). Du kan då ha en Posteringsregel som gör detta automatiskt.

En posteringsregel är en regel som bevakar ett visst konto. När regeln upptäcker en postering till kontot så skapar regeln en annan postering till ett förutbestämt annat konto. Det konto som bevakas kallas Triggerkonto. Den händelse som ska trigga åtgärden, det vill säga i detta fall en postering till triggerkontot kallas Triggerhändelse. Det andra kontot som ska ta emot posteringen kallas Målkonto.

Om beloppet som ska posteras till målkontot är, som i detta fall, en procentsats av beloppet i triggerhändelsen, räcker det med att regeln uttrycks som en faktor.

Mönster 2: Posteringsregel med särskild beräkningsmetod


Om vi behöver mer flexibla regler för att beräkna vad som ska hända behöver varje regel ha sin egen beräkningsmetod.

Reversering av posteringar

Om vi har gjort en felaktig postering kan vi vanligen inte bara radera den, för den kan ha lett till en utförd betalning eller en skickad faktura. Vi får i stället ta bort effekterna av den felaktiga posteringen genom att göra en ny omvänd postering, det vill säga en identisk postering fast med omvänt tecken. Därför måste varje posteringsregel kunna beordras att göra en postering som är omvänd.

Automatiserade kontosystem

I en del kontosystem är samtliga transaktioner genererade av posteringsregler. Då har man särskilda inkonton där man registrerar initiala posteringar från världen utanför. Alla andra posteringar sker automatiskt genom triggning av posteringsregler. Därmed automatiseras en stor del av kontohanteringen. Då är transaktioner inte lika nödvändiga för att spåra vad som hänt, men det kan ändå vara bra att ha registrerade transaktioner. Det förenklar hanteringen av reglerna.

När ska posteringsreglerna exekveras?

Det finns olika tänkbara modeller som man kan tillämpa i ett kontosystem för när, var och hur posteringsregler exekveras i programkod. Varje modell har sina styrkor och svagheter.

Det kan ske direkt när händelsen inträffar (vilket kallas Eager Firing inom programmerarvärlden), vid bestämda tillfällen eller först när någon efterfrågar kontoställningen (vilket kallas Backward Chained Firing). Varje modell har styrkor och svagheter. Det handlar mest om prestanda, det vill säga den tid det tar att exekvera reglerna, samt om när vi vill hantera fel. Eager Firing låter oss få felen tidigt. De andra modellerna ger oss större valfrihet när vi vill hantera felen, men till priset av större komplexitet.

Mönster 3: En posteringsregel för en grupp av konton

Det är vanligare att en posteringsregel gäller för en grupp av konton än för ett enstaka konto. Vi kan hantera det på två sätt.

  1. Genom att införa ett regelplan i modellen med kontotyper till vilka vi kan knyta posteringsreglerna.
  2. Genom att lägga posteringsregeln på ett summakonto. Då aktiveras regeln när en postering görs till ett underkonto (eller till kontot självt om det kan ta emot posteringar.) Regelns målkonto kan också vara ett summakonto, men tolkningen av regeln kommer i så fall att skapa postering till lämpligt underkonto.

Mönster 4: Posteringsregler med separata metoder

Man kan behöva ha separata metoder för att beräkna belopp, bestämma målkonto med mera. Då kan man ha fördefinierade metoder för olika ändamål. En regel blir då sammansatt av ett antal fördefinierade metoder.

Mönster 5: Konteringspraxis


Om vi har många olika konton som sitter ihop i ett nätverk av posteringsregler blir det hela oöverskådligt.

Vi behöver ett sätt att bryta ner nätverket av regler i lagom stora bitar. Till exempel kan varje typ av kund ha en särskild faktureringsprocess, och därmed ett nätverk av konton och posteringsregler som skiljer sig lite grand från en annan typ av kund.

Ett särskilt nätverk av konton och posteringsregler är en Konteringspraxis. Konceptuellt är en konteringspraxis helt enkelt en specifik uppsättning konteringsregler.

Mönster 6: Orsak till en postering

Det är ofta viktigt att kunna spåra varför en viss postering har gjorts och varför den har den form den har. Till exempel om en kund ringer och frågar om en viss post på en faktura, så behöver vi kunna se vilka posteringar som ledde fram till posten och vilken regel som skapade transaktionen.

Detta mönster låter varje transaktion minnas vilken post,,,,eringsregel som skapade den och vilka posteringar som var argument till transaktionen.

Mönster 7: Konton för lagerhantering

Kontomodellen passar bra för lagerhantering.

Vi kan skapa ett ”tillgångskonto” för varje lagersaldo (Ett Lagersaldo är att ett visst antal av en viss vara finns på ett visst lager). När vi flyttar en vara från ett lager till ett annat skapar vi en Lagertransaktion. Vi kan också hantera kundordar som ”posteringar till utgiftskonton” och leverantörsordrar som ”posteringar till inkomstkonton”. Vi kan också ha ”summakonton” för alla varor av samma varugrupp i ett lager och för en viss lagervara totalt i alla lager, eller för orderstocken. 

Varifrån kommer dessa mönster?

Många mönster i denna artikel och den förra utgår från vad jag hittat i Martin Fowlers bok Analysis Patterns från 1997. Boken är en dold skatt vad gäller modellmönster för informationsmodellering. Martin Fowler skrev boken för programmerare, vilket jag tror är orsaken till att den är så gott som okänd bland informationsmodellerare. Fast den är inte särskilt känd bland programmerare heller. Hans modellmönster förtjänar att lyftas fram och komma till nytta. Jag vill på detta sätt bidra till detta.

Vilka är dina erfarenheter? Har du arbetat med något av dessa mönster eller liknande? Kanske har du andra mönster att dela med dig av?

/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: 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.

Layouten har stor betydelse

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