En dashboard som uppdateras ofta kan vara värdefull för den som behöver agera under arbetsdagen. För ett månatligt resultatmöte kan samma lösning bli en onödig kostnad. Börja med hur snabbt beslutet behöver fattas och undersök sedan hur färsk data faktiskt går att få.
Realtidsanalys innebär att analysera data med så liten fördröjning att resultatet går att använda i det pågående förloppet. Det kräver en fungerande kedja från händelsen i källsystemet till den siffra användaren ser. En animerad graf eller tät omladdning säger i sig lite om den kedjan.
Vilket beslut blir sämre av att vänta?
Fråga vem som ska agera, vad personen kan ändra och hur länge informationen är användbar. En bemanningsansvarig som fördelar dagens inkommande samtal kan behöva uppdaterade köuppgifter. En ekonomiansvarig som följer föregående månads marginal behöver framför allt ett avstämt och jämförbart underlag.
Det hjälper att formulera behovet konkret: om väntetiden stiger under dagen ska en ansvarig kunna se utvecklingen och bedöma bemanningen. Då går det att diskutera hur stor fördröjning som kan accepteras. Ett allmänt önskemål om att allt ska vara i realtid ger betydligt sämre vägledning för lösningen.
Daglig uppdatering, nära realtid eller realtid?
Olika nyckeltal kan behöva olika uppdateringstakt i samma BI-lösning. Det går exempelvis att följa dagens orderläge tätare och bokföringsutfall efter en nattlig uppdatering. Visa period och aktualitet för varje del så att läsaren förstår skillnaden.
Begreppen används olika mellan leverantörer. Bestäm därför en mätbar accepterad fördröjning för ert användningsfall. Tabellen visar exempel att diskutera, inte tekniska garantier för ett visst system.
| Upplägg | Möjligt användningsfall | Fråga att ställa |
|---|---|---|
| Schemalagd sammanställning | Budgetuppföljning och veckorapport | När är underlaget klart och när läses det? |
| Nära realtid | Dagens bokningar, order eller samtalsvolym | Kan vi agera med en viss fördröjning? |
| Realtid med låg fördröjning | Operativ övervakning med omedelbart åtgärdsbehov | Vilken fördröjning och tillgänglighet behöver flödet klara? |
Mät tiden från händelse till färdig siffra
Tänk er att en bokning registreras klockan 10.00, blir tillgänglig i en export 10.15 och hämtas till analysen 10.20. En dashboard som läses in 10.21 visar då en händelse med 21 minuters fördröjning. Att sidan laddar om varje minut förändrar inte när exporten blir tillgänglig.
Dokumentera när händelsen inträffade, när källan gjorde den tillgänglig, när hämtningen lyckades och när analysen blev färdig. Dessa tidpunkter svarar på olika frågor. En lyckad hämtning kan dessutom innehålla gammal data om leverantörens underliggande export inte har uppdaterats.
Bestäm hur försenade händelser, rättelser och dubbletter ska hanteras. Dagens siffra kan vara preliminär och senare behöva ändras. En relevant statusmarkering och en avstämning mot källsystemet hjälper användaren att förstå vad som går att lita på just nu.
- Visa vilken period ett mått avser och när dess underlag senast uppdaterades.
- Skilj på noll registrerade händelser och en källa som slutat leverera.
- Ange när en fördröjning ska ge en varning och vem som tar emot den.
Tätare uppdatering påverkar hela lösningen
Möjligheterna beror på källsystemets API, exporter, eventstöd och tillåtna anropsvolym. Det behövs också utrymme för bearbetning och analys. Fler användare och fler diagram kan öka belastningen när varje vy frågar efter färska värden.
För Power BI beskriver Microsoft att automatisk siduppdatering beror på anslutningstyp och kapacitetsinställningar. Ett valt uppdateringsintervall behöver därför kontrolleras i den publicerade miljön. Utred även källans svarstid och belastning när ni väljer upplägg.
Be om en bedömning av både första leverans och löpande drift. Ett enklare alternativ kan vara att hämta förändringar med ett överenskommet intervall och skicka en signal när ett tröskelvärde passeras. Det kan räcka för arbetsuppgiften utan att varje historisk rapport behöver uppdateras lika ofta.
Ett bättre underlag till er BI-konsult
Beskriv den operativa frågan innan ni väljer teknik. Ta med ett exempel på dagens vy, vilka system som innehåller uppgifterna och vem som ansvarar för åtkomsten. Ett avgränsat test med verklig data kan sedan visa både uppnådd fördröjning och kostnaden för att hålla den nivån.
PVBC kan hjälpa er att utreda datatillgången och bygga en dashboard med uppdateringstakt, kontroller och status som passar användningen. Vi börjar med ett konkret mått och den person som behöver agera på det. Därefter går det att bedöma vad som är värt att bygga vidare på.
- Beslut: vad ska en ansvarig kunna ändra under dagen?
- Aktualitet: hur gammalt får underlaget vara när beslutet fattas?
- Källor: när blir relevanta händelser faktiskt tillgängliga?
- Drift: vad ska hända vid försening, fel eller utebliven data?
- Utvärdering: hur kontrollerar vi fördröjning, beräkningar och användbarhet?
Vanliga frågor
Kan alla våra system kopplas till realtidsanalys?
Det behöver utredas per källa. Ett system kan erbjuda löpande händelser, ett annat ett API med begränsad anropsvolym och ett tredje en daglig export. Åtkomst, villkor och när uppgifterna blir tillgängliga avgör vilken aktualitet som går att uppnå.
Är nära realtid tillräckligt för försäljningsuppföljning?
Det kan det vara. Utgå från vad säljledningen ska göra med informationen och hur snabbt affärsstatus uppdateras i CRM-systemet. För ett veckomöte kan en daglig uppdatering räcka; för dagens bemanning eller orderhantering kan ni behöva tätare underlag.
Hur ser vi om dashboardens siffror är aktuella?
Visa aktualitet per källa eller mått, med period, senaste lyckade uppdatering och tydlig status vid försening. Kontrollera också källans egen uppdateringstid. En tidsstämpel för när webbsidan öppnades säger bara när sidan laddades.