I dette blogginnlegget er vi beæret over å dele kunnskapen fra gjesteforfatter og analyseekspert, Mike Norris, om planlegging og fallgruver som du bør unngå for ditt analytisk moderniseringsinitiativ.
Når du vurderer et analytisk moderniseringsinitiativ, er det flere spørsmål å utforske ... Ting fungerer nå, så hvorfor gjøre dette? Hvilket press forventes? Hva skal målet (e) være? Hva er ting å unngå? Hvordan skal en vellykket plan se ut?
Hvorfor modernisere Analytics?
I Business Analytics blir innovasjon levert til enestående priser. Det er konstant press for å utnytte “det som er nytt” og varmt. Hadoop, Data Lakes, Data Science Lab, Citizen Data Analyst, Selvbetjening for alle, innsikt i tankens hastighet ... etc. Høres kjent ut? For mange ledere er dette en tid da de står overfor store beslutninger om investeringer. Mange starter nye veier og ønsker å levere mer evne og kommer til kort. Andre prøver moderniseringsveien og sliter med å holde engasjement fra ledelse.
Mange av disse forsøkene på å modernisere resulterer i tillegg av nye leverandører, teknologier, prosesser og analysetilbud. Denne formen for modernisering gir en raskere innledende seier, men etterlater teknisk gjeld og overhead, da den vanligvis ikke erstatter en eksisterende del av analysepuslespillet, men heller overlapper dem. Denne typen "moderniseringer" er mer et sprang, og ikke en jeg vil betrakte som "modernisering".
Her er min definisjon av hva jeg mener når jeg sier modernisering i en analytisk kontekst:
"Modernisering er forbedringen av analysene vi allerede har eller tillegg av funksjonalitet eller evne til teknologiene som allerede er i bruk. Modernisering gjøres alltid for å oppnå et forbedringsmål. Mål bør defineres gjennom partnerskap mellom brukermiljøet og IT/analytics -ledelsen. ”
Disse målene kan være:
- Overfladisk - bedre sexigere innhold eller forbedret brukeropplevelse.
- funksjonell - forbedret ytelse eller ekstra funksjonalitet og evne
- utvide - gi en innebygd opplevelse eller legge til flere prosjekter og arbeidsmengder.
Gjennom mine 20 pluss-år i Business Analytics-området har jeg jobbet med hundrevis av selskaper og organisasjoner som har hjulpet og gitt råd om installasjoner, oppgraderinger, konfigurasjoner og strategiske planer og prosjekter. Det gjør ofte vondt når jeg engasjerer meg sent, å være bærer av en dose virkelighet under moderniseringsprosjekter. Så mange begynner uten en plan eller verre, med en plan og ingen validering av den planen. De desidert verste er de som var en kombinasjon av IT- og Analytics-moderniseringer som et alt-i-ett-massivt prosjekt.
Press for å forvente og overvinne
- Alt må være Cloud & SaaS - Cloud har mange fordeler og er det åpenbare valget for enhver netto ny strategi og investering. Å flytte alt fra lokaler til sky fordi det er selskapets strategi kombinert med en "etter dato" er dårlig strategi og kommer fra dårlig ledelse som opererer i et vakuum. Sørg for at fordeler og eventuelle konsekvenser er forstått før du registrerer deg på en dato.
- Single sourcing alt - Ja, det er selskaper som kan gi deg alt du trenger. En enkeltkildeleverandør kan selge deg fordelene, men er de virkelige eller oppfattes? Analyserommet har stort sett vært åpent og heterogent, slik at du kan gå best i rasen, så ta gode valg.
- Nyere produkter er bedre - Nyere like bedre kan fungere for biler, men vanligvis ikke med programvare, med mindre det er en evolusjon. Leverandører med mange års erfaring og historie i virkeligheten virker trege til å følge med, men dette er med god grunn. Disse leverandørene har en tendens til å ha et robust tilbud som andre ikke kan matche, og det tilbudet har mye mer levetid når bruken av dem vokser. Ja, noe forsinkelse, men det indikerer ikke alltid at en erstatning er nødvendig. I mange tilfeller kan det eksistere flere stykker hvis skillelinjene er klare.
- Ruser det gigantiske utfallet - Dessverre er den tildelte tiden sjelden nøyaktig, så det er godt å ha milepæler og mindre planer med seire definert for å vise meningsfylte fremskritt og utfall.
- Det hele vil gå mye raskere - Dette er et stort mål og ambisjon, men ikke alltid virkelighet. Å tilby arkitektur spiller en enorm faktor, det samme gjør hvor godt utført en hvilken som helst integrasjon er gjort og samlokalisering av omkringliggende avhengige og støttende tjenester og funksjoner.
- Å modernisere nå fremtidige bevis på oss - Som jeg sa i åpningen, innovasjonene flyr, så dette er et område som vil fortsette å utvikle seg. Hold deg alltid oppdatert på det du har, og sørg for at oppdateringer er planlagt. Etter oppdateringer, evaluer nye funksjoner og funksjonalitet som skal utnyttes eller gjøres tilgjengelig.
- Modernisering er bare "oppgraderinger" og blir enkelt - Det moderniserer ikke oppgraderer. Det betyr oppgraderinger, oppdateringer, erstatninger og utnyttelse av nyere funksjon og muligheter. Oppgrader først, og utnytt deretter ny funksjon og mulighet.
Utarbeider en moderniseringsplan for Analytics
Før jeg gjør noen moderniseringstiltak, vil jeg foreslå å gjøre et par ting som jeg vil dele for å forbedre suksessraten.
1. Bestem målene.
Du kan ikke ha et mål som "Å gi en rask, sømløs kilde til vakker analyse som gjør det enkelt å konsumere og lage innhold." Dette er et godt mål for å få prosjektet godkjent, men er et overordnet mål som er full av fare og undergang ... det er rett og slett for stort. Fokuser og lag mål for en enkelt teknologisk endring om gangen med et målt ønskelig utfall. Modernisering i mange tilfeller må gjøres stykke for stykke og erfaring etter erfaring. Dette betyr flere mindre prosjekter og mål.
Folk vil hevde at dette betyr mer tid og generell innsats og kanskje for mange endringer for brukerne. Etter min erfaring, ja, denne planen vil se lengre ut, men reflekterer mer den faktiske tiden det vil ta uansett. Når det gjelder hyppigheten av endringer i brukeropplevelsen, kan dette håndteres ved ikke å skyve resultatene til produksjon før du har et komplett sett med endringer som gir mening. Moderniseringsplanene "gjør alt på en gang" har jeg sett kjøre 12-18 måneder lenger enn forventet, noe som er mye vanskeligere å forklare. Verre er presset på laget som utfører planen og den konstante negativiteten som kommer fra utfordringer underveis. Disse fører også til store svingninger som resulterer i sprangbevegelser.
Den største grunnen til å fokusere på mindre endringer er at hvis analysen din bryter underveis, er det mye raskere og enklere å feilsøke og løse eventuelle problemer. Færre variabler betyr raskere problemløsning. Jeg vet at dette høres enkelt ut, men jeg skal fortelle deg at jeg har jobbet med mer enn ett selskap som bestemte seg for å gjøre et monster -moderniseringsarbeid der:
- analyseplattformen skulle oppgraderes
- spørreteknologi oppdatert
- analyseplattform flyttet til skyen
- godkjenningsmetode byttet ut for en Internett -påloggingsleverandør
- en databaseleverandør endret og flyttet fra en lokal eid og drevet modell til en SaaS-løsning
Når ting ikke fungerte, brukte de tonnevis med tid og krefter på å finne ut hva som forårsaket problemet før de kom til den faktiske løsningen. Til slutt løp disse "gjør alt på en gang" -prosjektene langt over tid og budsjett og ga blandede resultater på grunn av delvise måloppnåelser og negativiteten som omringet prosjektet. Mange av disse ble bare "få det i gang så godt som mulig" prosjekter til slutt.
2. Lag en plan per mål.
Planen må inneholde innspill fra ALLE interessenter for åpenhet, fullstendighet og nøyaktighet. Mitt eksempel her vil være endring av databaseteknologier. Noen leverandører tilbyr kompatibilitet med andre leverandører, og dette hjelper med salg når de snakker om tid til verdi. Hver databaseleverandør vil også prøve å presse sin posisjon om at de utfører bedre enn den sittende. Problemet er at disse utsagnene ikke overlapper hverandre. Jeg har ennå ikke sett en arbeidsbelastning gå fra en databaseteknologi til en annen med å utnytte leverandørens kompatibilitet og forbedre ytelsen til eksisterende arbeidsmengder.
Når du endrer databaseleverandører / -teknologier, får du nesten helt sikkert forskjellige nivåer av SQL -kompatibilitet, eksponerte databasefunksjoner og forskjellige datatyper, som alle kan skape ødeleggelse for eksisterende applikasjoner som sitter på toppen. Poenget er at planen må valideres med mennesker som kan undersøke og bestemme den sannsynlige effekten av en så stor endring. Eksperter må engasjeres for å eliminere overraskelser senere.
3. Planlegg planene.
Ettersom alle målene er plaget ut, kan vi oppdage at noen av dem kan løpe parallelt. Når vi bruker en analyseplattform, kan vi oppdage at forskjellige grupper eller forretningsenheter bruker forskjellige underliggende komponenter som databaser som skal moderniseres, slik at disse kan kjøre parallelt.
4. Undersøk alle planene analytisk og rydde opp.
Dette er et så viktig skritt og mange utelater. Jeg ber deg om å bruke den analysen du har mot analysen din. Dette er nøkkelen til å ikke kaste bort tid og ressurser. Bestem hvilke data som er døde, hvilket innhold i analyseplattformen din som ikke lenger brukes eller er relevant. Vi har alle bygget analytiske prosjekter eller innhold for en engangsoppgave, men de fleste av oss suger også til å slette det eller rydde opp etter oss selv. Det er digital innhold som ikke koster noe å bare la være til det øyeblikket noen må vedlikeholde, oppgradere eller modernisere det.
Ville det sjokkere deg å finne ut at 80% av ditt analytiske innhold er dødt, ikke brukt, har blitt erstattet av en ny versjon eller har blitt brutt i lang tid uten klager? Når var siste gang vi sjekket?
Ikke start noe prosjekt som krever validering av analytisk innhold uten å gå gjennom hva som må valideres og hva som må ryddes opp eller søppel. Hvis vi ikke har noen analyser å bruke mot analysen, kan du finne ut hvordan du kan få noen fremover.
5. Vurder at moderniseringsprosjektet og individuelle planer er helhetlig gjennomført.
La oss gå tilbake til det dårlige målet, "Å gi en rask, sømløs kilde til vakker analyse som muliggjør enkelt forbruk og innholdsskaping," og bryte den ned fra et høyt nivå. Det er sannsynligvis en infrastrukturendring for behandling av minne og disk, en databaseoppgradering eller endring, et skifte til en moderne Single Sign On -leverandørteknologi som SAML eller OpenIDConnect, og en oppdatering eller oppgradering av analyseplattformen. Dette er alle gode ting og bidrar til å modernisere, men vi må huske det sluttbrukere er interessenter. Hvis brukerne får det samme innholdet som de har gjort i mange år, men bare raskere, vil tilfredshetsnivået sannsynligvis være minimalt. Vakkert innhold kan ikke bare være for nye prosjekter og bør leveres til vår største gruppe av forbrukere. Modernisering av eksisterende innhold blir sjelden sett på, men har største innvirkning på brukerne. Dette er spesielt viktig for administratorer eller noen andre på teamet som støtter analyseplattformen. Ikke å holde sluttbrukerne lykkelige med at andre verktøy blir hentet inn for å gå rundt det teamet leverer, og sluttresultatene kan være katastrofale. Jeg dekker dette emnet i min neste blogg om noen uker.
6. Siste råd.
Ta sikkerhetskopier ofte, og ikke gjør et moderniseringsprosjekt bare i produksjon. Bruk krefter på å ha et simulert produksjonsmiljø for store, omfattende endringer. Dette igjen vil bidra til å minimere variabler og forskjeller mellom det som fungerer utenfor og inne i produksjonen.
Lykke til på din egen moderniseringsreise!
Har du spørsmål om ditt eget moderniseringsinitiativ? Kontakt for å diskutere dine behov og hvordan vi kan hjelpe!
