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. 

/Peter Tallungs, IRM, 2021-09-02

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 finnas 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