Modernisera din Analytics -upplevelse

by November 11, 2020BI/Analytics, Cognos Analytics, Tycka om, Uppgradera Cognos0 kommentarer

I det här blogginlägget är vi hedrade att dela med oss ​​av kunskapen från gästförfattare och analytiker, Mike Norris, om planering och fallgropar för att undvika ditt analytiska moderniseringsinitiativ.

När man överväger ett analytiskt moderniseringsinitiativ finns det flera frågor att utforska ... Saker och ting fungerar nu så varför göra detta? Vilket tryck förväntas? Vad ska målet / målen vara? Vad är saker att undvika? Hur ska en framgångsrik plan se ut?

Varför modernisera Analytics?

I Business Analytics levereras innovation till oöverträffade priser. Det finns ett konstant tryck för att utnyttja ”vad som är nytt” och hett. Hadoop, Data Lakes, Data Science Lab, Citizen Data Analyst, Self-service for all, insights on the speed speed ... etc. Låter bekant? För många ledare är detta en tid då de står inför stora beslut om investeringar. Många startar nya vägar för att leverera mer kapacitet och kommer till kort. Andra försöker modernisera vägen och kämpar för att hålla engagemang från ledarskapet.

Många av dessa försök att modernisera resulterar i tillägg av nya leverantörer, teknik, processer och analysutbud. Denna form av modernisering ger en snabbare inledande vinst men lämnar tekniska skulder och overhead eftersom den inte vanligtvis ersätter en befintlig del av analyspusslet utan överlappar dem. Dessa typer av "moderniseringar" är mer ett språng, och inte en jag skulle anse som "modernisering".

Här är min definition av vad jag menar när jag säger modernisering i ett analytiskt sammanhang:

”Modernisering är förbättringen av den analys vi redan har eller tillägget av funktionalitet eller kapacitet till den teknik som redan används. Modernisering görs alltid för att uppnå ett förbättringsmål. Mål bör definieras via partnerskap mellan användarsamhället och IT/analytics ledarskap. ”

Dessa mål kan vara:

  • Ytlig - bättre sexigare innehåll eller förbättrad användarupplevelse.
  • Funktionell - förbättrad prestanda eller ökad funktionalitet och kapacitet
  • Utöka - ge en inbäddad upplevelse eller lägga till ytterligare projekt och arbetsbelastningar.

Under mina tjugo år i Business Analytics har jag arbetat med hundratals företag och organisationer för att hjälpa och ge råd om installationer, uppgraderingar, konfigurationer och strategiska planer och projekt. Det gör ofta ont när jag engagerar mig sent, att bära en dos av verklighet under moderniseringsprojekt. Så många börjar utan en plan eller värre, med en plan och ingen validering av den planen. De överlägset värsta är de som var en kombination av IT- och Analytics-moderniseringar som ett allt-i-ett-massivt projekt.

Press att vänta och övervinna

  • Allt måste vara Cloud & SaaS - Cloud har många fördelar och är det självklara valet för varje ny ny strategi och investering. Att flytta allt från lokaler till moln eftersom det är företagets strategi i kombination med ett "datum" är dålig strategi och kommer från dåligt ledarskap som verkar i ett vakuum. Se till att fördelar och eventuella effekter är förstådda innan du registrerar dig till ett datum.
  • Singel köper allt - Ja, det finns företag som kan förse dig med allt du behöver. En leverantör av en enda källa kan sälja dig fördelarna men är de verkliga eller upplevda? Analysutrymmet har i stort sett varit öppet och heterogent vilket gör att du kan gå bäst i rasen, så gör bra val.
  • Nyare produkter är bättre - Nyare lika bättre kan fungera för bilar men vanligtvis inte med programvara om det inte är en erbjudandeutveckling. Leverantörer med många års erfarenhet och historia i verkliga världen verkar långsamma att hänga med, men det är av goda skäl. Dessa leverantörer tenderar att ha ett robust erbjudande som andra inte kan matcha, och det erbjudandet har mycket mer livstidsvärde när användningen av dem växer. Ja, en viss fördröjning men det betyder inte alltid att en ersättning behövs. I många fall kan flera bitar existera om skiljelinjerna är tydliga.
  • Skyndar på det gigantiska resultatet - Tyvärr är den tilldelade tiden sällan exakt så det är bra att ha milstolpar och mindre planer med segrar definierade för att visa meningsfulla framsteg och resultat.
  • Allt kommer att gå mycket snabbare - Det här är ett stort mål och en strävan men inte alltid verkligheten. Att erbjuda arkitektur spelar en enorm faktor, liksom hur välskött all integration görs och samlokalisering av omgivande beroende och stödjande tjänster och funktioner.
  • Modernisering nu framtid bevisar oss - Som jag sa i öppnaren flyger innovationerna så det här är ett område som kommer att fortsätta utvecklas. Håll dig alltid uppdaterad om vad du har och se till att uppdateringar planeras. Efter några uppdateringar utvärdera nya funktioner och funktioner som ska utnyttjas eller göras tillgängliga.
  • Modernisering är bara "uppgraderingar" och blir enkelt - Det moderniseras inte uppgraderas. Det innebär uppgraderingar, uppdateringar, utbyten och utnyttjande av nyare funktioner och funktioner. Uppgradera först och utnyttja sedan ny funktion och kapacitet.

Utarbetar en moderniseringsplan för Analytics

Innan jag gör några moderniseringsinsatser skulle jag föreslå att du gör några saker som jag kommer att dela för att förbättra framgångarna.

1. Bestäm målen.

Du kan inte ha ett mål som "Att tillhandahålla en snabb, sömlös källa till vacker analys som möjliggör enkel konsumtion och innehållsskapande." Detta är ett bra mål för att få projektet godkänt men är ett övergripande mål som är fullt av fara och undergång ... det är helt enkelt för stort. Fokusera och skapa mål för en enda teknikförändring i taget med ett uppmätt önskvärt resultat. Modernisering i många fall måste göras bit för bit och erfarenhet av erfarenhet. Det innebär fler mindre projekt och mål.

Folk kommer att hävda att detta innebär mer tid och övergripande ansträngning och kanske för många förändringar för användarna. Enligt min erfarenhet, ja, den här planen kommer att se längre ut men återspeglar mer den faktiska tid det kommer att ta ändå. När det gäller frekvensen av förändring av användarupplevelsen kan detta hanteras genom att inte skjuta resultaten till produktion förrän du har en komplett uppsättning ändringar som är vettiga. Moderniseringsplanerna ”gör allt på en gång” har jag sett köra 12-18 månader längre än förväntat, vilket är mycket svårare att förklara. Värre är trycket som läggs på laget som genomför planen och den konstanta negativiteten som kommer från utmaningar längs vägen. Dessa leder också till stora svängningar som resulterar i språng.

Den största anledningen till att fokusera på mindre förändringar är att om din analys går sönder under vägen är det mycket snabbare och lättare att felsöka och lösa eventuella problem. Färre variabler betyder snabbare problemlösning. Jag vet att det här låter enkelt, men jag kommer att berätta att jag har arbetat med mer än ett företag som bestämde sig för att göra en monstermoderniseringsinsats där:

  • analysplattform skulle uppgraderas
  • förfrågan teknik uppdaterad
  • analysplattform flyttade till molnet
  • autentiseringsmetod bytte ut för en webbleverantör för enkel inloggning
  • en databasleverantör ändrade och flyttade från en lokal ägs och drivs modell till en SaaS-lösning

När saker inte fungerade spenderade de massor av tid och ansträngning på att avgöra vad som orsakade problemet innan de kom till den faktiska lösningen. I slutändan sprang dessa ”gör allt på en gång” -projekt långt över tid och budget och gav blandade resultat på grund av delmålsuppnåelser och negativiteten som omgav projektet. Många av dessa blev bara "få igång så bra som möjligt" -projekt i slutet.

2. Skapa en plan per mål.

Planen måste inkludera input från ALLA intressenter för transparens, fullständighet och noggrannhet. Mitt exempel här skulle vara förändring av databasteknik. Vissa leverantörer erbjuder kompatibilitet med andra leverantörer och det hjälper till med försäljning när de pratar om tid att värdera. Varje databasleverantör kommer också att försöka driva sin position att de presterar bättre än den sittande. Frågan är att dessa uttalanden inte överlappar varandra. Jag har ännu inte sett en arbetsbelastning flytta från en databasteknik till en annan med att utnyttja leverantörens kompatibilitet och förbättra prestanda för befintliga arbetsbelastningar.

När du byter databasleverantörer / -teknologier får du nästan säkert olika nivåer av SQL -kompatibilitet, exponerade databasfunktioner och olika datatyper, som alla kan skapa förödelse för befintliga applikationer som sitter högst upp. Poängen är att planen måste valideras med de människor som kan undersöka och bestämma den troliga effekten av en så stor förändring. Experter måste anlitas för att eliminera överraskningar senare.

3. Planera planerna.

Eftersom alla mål är retade kan vi upptäcka att några av dem kan köras parallellt. När vi använder en analysplattform kan vi upptäcka att olika grupper eller affärsenheter använder olika underliggande komponenter som databaser som ska moderniseras, så att dessa kan köras parallellt.

4. Undersök alla planer analytiskt och städa upp.

Detta är ett så viktigt steg och en som många utelämnar. Jag uppmanar dig att använda den analys du har mot din analys. Detta är nyckeln till att inte slösa tid och resurser. Bestäm vilken data som är död, vilket innehåll i din analysplattform som inte längre används eller är relevant. Vi har alla byggt analytiska projekt eller innehåll för en engångsuppgift men de flesta av oss är också sugna på att ta bort det eller städa efter oss själva. Det är digital innehåll som inte kostar något att bara lämna till det ögonblick någon måste underhålla, uppgradera eller modernisera det.

Skulle det chocka dig att få reda på att 80% av ditt analytiska innehåll är dött, inte används, har ersatts av en ny version eller har brutits länge utan klagomål? När var sista gången vi kollade?

Starta inte något projekt som kräver validering av analytiskt innehåll utan att granska vad som måste valideras och vad som behöver städas eller skräpas. Om vi ​​inte har någon analys att använda mot analysen, ta reda på hur vi kan få lite framåt.

5. Utvärdera att moderniseringsprojektet och individuella planer är holistiskt slutförda.

Låt oss gå tillbaka till det dåliga målet, ”Att tillhandahålla en snabb, sömlös källa till vacker analys som möjliggör enkel konsumtion och innehållsskapande”, och bryta ner den från en hög nivå. Det finns troligtvis en infrastrukturändring för bearbetning av minne och disk, en databasuppgradering eller ändring, en övergång till en modern Single Sign On -leverantörsteknik som SAML eller OpenIDConnect, och en uppdatering eller uppgradering av analysplattformen. Det här är alla bra saker och hjälper till att modernisera, men vi måste komma ihåg det slutanvändare är intressenter. Om användarna får samma innehåll som de har gjort i flera år men bara snabbare, kommer deras tillfredsställelse sannolikt att vara minimal. Vackert innehåll kan inte bara vara för nya projekt och ska levereras till vår största konsumentgrupp. Modernisering av befintligt innehåll ses sällan men har största påverkan på användarna. Detta är särskilt viktigt för administratörer eller någon annan i teamet som stöder analysplattformen. Att inte hålla slutanvändarna glada resultat i att andra verktyg tas in för att gå runt vad teamet levererar med slutresultaten möjligen katastrofala. Jag kommer att täcka detta ämne i min nästa blogg om några veckor.

6. Sista rådet.

Ta säkerhetskopior ofta och gör inte bara ett moderniseringsprojekt i produktionen. Lägg ner ansträngningarna på att få en simulerad produktionsmiljö för stora, omfattande förändringar. Detta kommer igen att bidra till att minimera variabler och skillnader mellan vad som fungerar utanför och inuti produktionen.

Lycka till på din egen moderniseringsresa!

Har du frågor om ditt eget moderniseringsinitiativ? Kontakta oss för att diskutera dina behov och hur vi kan hjälpa!