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.

2 Kommentarer
  1. Torbjorn Ryber
    Torbjorn Ryber says:

    Enkelt och elegant förklarat.

    Jag använder tillståndsgrafer i princip varenda jobb jag gör. Nu senast för att beskriva status för en dom som i mitt fall kan vara Inkommen, Överklagad, Laga Kraft eller Felmarkerad. Det blir väldigt tydligt vad som kan ske med en dom beroende på den status den befinner sig i. Liknar väldigt mycket den första bilden i artikeln.

    Mycket intressant att se nästa steg i utvecklingen i form av informationsmodellen över entiteter och händelser. Det hjälper mig som designer att samverka med utvecklarna. Min erfarenhet är att det för det allra mesta är utvecklarna själva som tar fram dessa så jag är nyfiken på om utvecklare vill sköta det själv eller uppskattar om jag skulle ta fram dem själv som input till deras arbete.

  2. Peter Tallungs
    Peter Tallungs says:

    Svar till Torbjörn Ryber.
    Vad roligt att du använder tillståndsdiagram. Men det är klart, du är ju ingenjör i botten.

    Det är ju fler saker som tillsammans definierar och förklarar det dynamiska beteendet hos ett objekt som till exempel en kund, ett ärende, en produkt eller som i ditt fall en dom:
    – Tillståndsdiagrammet ger vilka tillstånden är och vilka tillståndövergångar som kan finnas (som man kan se som Händelser)
    – ER-diagrammet över tillstånd och händelser ger vilka egenskaper tillstånd och händelser har som man vill hålla reda på. Bör innefatta namn, definitioner och andra regler. Samt ofta även möjliga orsakerna till händelser. Samt förstås hur man ska registrera vilka händelser som verkligen inträffat och när och med sin orsak.
    – Uppräkning av förekomsterna för möjliga tillstånd, händelser och orsaker med namn, eventuell förkortning och (viktigast) definition.

    Dessa saker bildar ju tillsammans en beskrivning av de begrepp som verksamheten behöver registrera och använda sig av.

    Jag ser detta som verksamhetsutveckling eftersom det är centrala företeelser och begrepp för att kunna förstå och hantera en verksamhet. Jag menar också att det är lika rätt att se det som systemutveckling, men bara om vi då förstår att systemutveckling inte är något annat än verksamhetsutveckling. Det ”system” man utvecklar kan aldrig vara isolerat till programvara utan är alltid en integrerad del av en verksamhet.

    Det vanliga är ju som du beskriver att systemutvecklare är tvungna att göra detta själva och att de sällan har en kultur och arbetssätt för att göra detta tillsammans med verksamhetskunniga och att etablera detta som en gemensam modell.

    Det blir inte bra. Det är orsaken till att centrala delen av verksamhetslogiken ligger dold, okänd, glömd, hoptrasslad och odokumenterad i kod och databaser idag. Så är det överallt och det är en tickande bomb.

    Men det kan vi ändra på. Mitt jobb som informationsarkitekt är att få verksamhetsexperter och systemutvecklare att ta steg mot att jobba ihop och utveckla it och verksamhet ihop som en helhet. Det är inte så svårt. Bara vi gör oss av med en del ingrodda föreställningar. Framförallt om att verksamhet är en sak och it en annan. Och vad det betyder i praktiken.

    Mitt svar till dig om huruvida utvecklare uppskattar om du gör detta:
    En bra fråga! Min erfarenhet är att jag först möts av en del skepsis från utvecklarna eftersom de är så vana med att såna som jag inte vet vad de talar om, lever i det blå, utan att de själva i slutändan ändå får göra detta själva för att de ska funka. Men snart blir de inte bara positiva utan till och med entusiastiska, och ivriga proponenter för arbetssättet. Framförallt för att jag inte ger dem en klar ”specifikation” utan modellen är lika mycket en fråga som ett påstående: ”Kan vi se det så här?”, ”Skulle det här fungera?”. De blir själva betraktade och behandlade som verksamhetskunniga som ger viktig input.

    Jag blir då mer av en metodcoach och kommunikatör än en som bestämmer över dem. Det är så jag skulle vilja förändra vår bransch och det är i den avsikten jag skriver den här artikelserien.

Lämna en kommentar

Want to join the discussion?
Dela med dig av dina synpunkter!

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *