I dette blogindlæg er vi beærede over at dele viden fra gæsteforfatter og analyseekspert, Mike Norris, om planlægning og faldgruber, der skal undgås for dit analytisk moderniseringsinitiativ.
Når man overvejer et analytisk moderniseringsinitiativ, er der flere spørgsmål at undersøge ... Tingene fungerer nu, så hvorfor gøre dette? Hvilket pres forventes? Hvad skal målet / målene være? Hvad skal man undgå? Hvordan skal en vellykket plan se ud?
Hvorfor modernisere Analytics?
I Business Analytics bliver innovation leveret til hidtil usete priser. Der er konstant pres for at udnytte “hvad der er nyt” og varmt. Hadoop, Data Lakes, Data Science Lab, Citizen Data Analyst, Selvbetjening for alle, indsigt i tankens hastighed ... osv. Lyder det bekendt? For mange ledere er dette en tid, hvor de står over for store beslutninger om investering. Mange starter nye veje og søger at levere mere kapacitet og kommer til kort. Andre forsøger moderniseringsvejen og kæmper for at holde engagement fra lederskab.
Mange af disse forsøg på at modernisere resulterer i tilføjelse af nye leverandører, teknologier, processer og analysetilbud. Denne form for modernisering giver en hurtigere indledende gevinst, men efterlader teknisk gæld og overhead, da den typisk ikke erstatter en eksisterende del af analysepuslespillet, men snarere overlapper dem. Disse typer af "moderniseringer" er mere et springskud, og ikke en jeg ville betragte som "modernisering."
Her er min definition af, hvad jeg mener, når jeg siger modernisering i en analytisk kontekst:
”Modernisering er forbedringen af de analyser, vi allerede har, eller tilføjelsen af funktionalitet eller kapacitet til de teknologier, der allerede er i brug. Modernisering foretages altid for at nå et forbedringsmål. Mål bør defineres via partnerskab mellem brugerfællesskabet og IT/analytics lederskab. ”
Disse mål kan være:
- Overfladisk - bedre sexet udseende indhold eller forbedret brugeroplevelse.
- Funktionel - forbedret ydeevne eller tilføjet funktionalitet og kapacitet
- Udvidelse - at give en integreret oplevelse eller tilføje yderligere projekter og arbejdsbyrder.
Gennem mine mere end 20 år i Business Analytics-rummet har jeg arbejdet med hundredvis af virksomheder og organisationer, der har hjulpet og rådgivet dem om installationer, opgraderinger, konfigurationer og strategiske planer og projekter. Det gør mig ofte ondt, når jeg engagerer mig sent, at være bærer af en portion virkelighed under moderniseringsprojekter. Så mange begynder uden en plan eller værre, med en plan og ingen validering af den plan. Langt de værste er dem, der var en kombination af IT- og Analytics-moderniseringer som et alt-i-ét massivt projekt.
Pres for at forvente og overvinde
- Alt skal være Cloud & SaaS - Cloud har mange fordele og er det oplagte valg for enhver netto ny strategi og investering. At flytte alt fra lokaler til cloud, fordi det er virksomhedens strategi kombineret med en "dato", er dårlig strategi og kommer fra dårlig ledelse, der opererer i et vakuum. Sørg for, at fordele og eventuelle virkninger forstås, før du tilmelder dig en dato.
- Single sourcing alt - Ja, der er virksomheder, der kan levere dig alt, hvad du har brug for. En enkelt kilde sælger kan sælge dig fordelene, men er de virkelige eller opfattes? Analyserummet har stort set været åbent og heterogent, hvilket giver dig mulighed for at gå bedst i racen, så tag sunde valg.
- Nyere produkter er bedre - Nyere lige bedre fungerer måske for biler, men ikke typisk med software, medmindre det er en tilbudsudvikling. Leverandører med mange års erfaring og historie i virkeligheden ser langsomt ud til at følge med, men det er med god grund. Disse leverandører har en tendens til at have et robust tilbud, som andre ikke kan matche, og det tilbud har meget mere levetid, når brugen af dem vokser. Ja, lidt forsinkelse, men det betyder ikke altid, at en udskiftning er nødvendig. I mange tilfælde kan der eksistere flere stykker, hvis skillelinjerne er klare.
- Skynder det gigantiske resultat - Desværre er den tildelte tid sjældent præcis, så det er godt at have milepæle og mindre planer med sejre defineret for at vise meningsfulde fremskridt og resultater.
- Det hele vil være meget hurtigere - Dette er et stort mål og en ambition, men ikke altid virkeligheden. At tilbyde arkitektur spiller en enorm faktor, ligesom hvor godt udført en hvilken som helst integration udføres og samlokalisering af omkringliggende afhængige og understøttende tjenester og funktioner.
- Modernisering af fremtidens beviser os - Som jeg sagde i åbningen, nyskabelserne flyver, så dette er et område, der vil fortsætte med at udvikle sig. Hold dig altid opdateret med, hvad du har, og sørg for, at opdateringer er planlagt. Efter eventuelle opdateringer evaluer nye funktioner og funktioner, der skal udnyttes eller gøres tilgængelige.
- Modernisering er bare "opgraderinger" og vil være let - Det moderniserer ikke opgraderer. Det betyder opgraderinger, opdateringer, udskiftninger og udnyttelse af nyere funktioner og muligheder. Opgrader først, og udnyt derefter ny funktion og kapacitet.
Udarbejdelse af en moderniseringsplan for Analytics
Inden jeg foretager nogen moderniseringsindsats, vil jeg foreslå at gøre et par ting, som jeg vil dele for at hjælpe med at forbedre succesraterne.
1. Bestem målene.
Du kan ikke have et mål som: "At levere en hurtig, problemfri kilde til smuk analyse, der muliggør let forbrug og oprettelse af indhold." Dette er et fantastisk mål for at få projektet godkendt, men det er et overordnet mål, der er fyldt med fare og undergang ... det er simpelthen for stort. Fokuser og skab mål for en enkelt teknologisk ændring ad gangen med et målt ønskeligt resultat. Modernisering i mange tilfælde skal gøres stykke for stykke og erfaring efter erfaring. Det betyder flere mindre projekter og mål.
Folk vil argumentere for, at dette betyder mere tid og generel indsats og måske for mange ændringer for brugerne. Efter min erfaring, ja, vil denne plan se længere ud, men afspejler mere den faktiske tid, det vil tage alligevel. Hvad angår hyppigheden af ændring af brugeroplevelsen, kan dette håndteres ved ikke at skubbe resultaterne til produktion, før du har et komplet sæt ændringer, der giver mening. Moderniseringsplanerne "gør det hele på en gang" har jeg set køre 12-18 måneder længere end forventet, hvilket er meget sværere at forklare. Værre er det pres, der lægges på teamet, der udfører planen, og den konstante negativitet, der kommer fra udfordringer undervejs. Disse fører også til store omdrejninger, hvilket resulterer i springkørsel.
Den største grund til at fokusere på mindre ændringer er, at hvis din analyse går i stykker undervejs, så er det meget hurtigere og lettere at fejlfinde og løse eventuelle problemer. Færre variabler betyder hurtigere problemløsning. Jeg ved, at det lyder enkelt, men jeg vil fortælle dig, at jeg har arbejdet med mere end et firma, der besluttede at gøre en monster -moderniseringsindsats, hvor:
- analyseplatform skulle opgraderes
- forespørgselsteknologi opdateret
- analyseplatform flyttet til skyen
- godkendelsesmetode byttede ud for en web Single Sign On -udbyder
- en databaseleverandør ændrede og flyttede fra en lokal ejet og drevet model til en SaaS-løsning
Når tingene ikke fungerede, brugte de masser af tid og kræfter på at afgøre, hvad der forårsagede problemet, før de kom til den faktiske løsning. I sidste ende løb disse "gør det hele på en gang" -projekter langt over tid og budget og gav blandede resultater på grund af delvise målopnåelser og negativiteten, der omgav projektet. Mange af disse blev bare "få det i gang så godt som muligt" -projekter til sidst.
2. Lav en plan pr. Mål.
Planen skal indeholde input fra ALLE interessenter for gennemsigtighed, fuldstændighed og nøjagtighed. Mit eksempel her ville være ændring af databaseteknologier. Nogle leverandører tilbyder kompatibilitet med andre leverandører, og det hjælper med salg, når de taler om tid til værdi. Hver databaseleverandør vil også forsøge at skubbe deres holdning til, at de klarer sig bedre end den etablerede. Problemet er, at disse udsagn ikke overlapper hinanden. Jeg har endnu ikke set en arbejdsbyrde flytte fra en databaseteknologi til en anden med at udnytte en leverandørs kompatibilitet og forbedre ydeevnen for eksisterende arbejdsbyrder.
Når du skifter databaseleverandører / -teknologier, får du næsten helt sikkert forskellige niveauer af SQL -kompatibilitet, eksponerede databasefunktioner og forskellige datatyper, som alle kan forårsage kaos på eksisterende applikationer, der sidder øverst. Pointen er, at planen skal valideres med de mennesker, der kan undersøge og bestemme den sandsynlige effekt af en så stor ændring. Eksperter skal engageres for at fjerne overraskelser senere.
3. Planlæg planerne.
Da alle målene er drillet, kan vi opleve, at nogle af dem kan løbe parallelt. Når vi bruger en analyseplatform, kan vi opleve, at forskellige grupper eller forretningsenheder bruger forskellige underliggende komponenter som f.eks. Databaser, der skal moderniseres, så disse kan køre parallelt.
4. Undersøg alle planerne analytisk og ryd op.
Dette er et så vigtigt skridt, og en mange udelader. Jeg beder dig om at bruge den analyse, du har mod din analyse. Dette er nøglen til ikke at spilde tid og ressourcer. Bestem, hvilke data der er døde, hvilket indhold i din analyseplatform ikke længere bruges eller er relevant. Vi har alle bygget analytiske projekter eller indhold til en engangsopgave, men de fleste af os er også sure til at slette det eller rydde op efter os selv. det er digital indhold, der ikke koster noget at bare lade være indtil det øjeblik, nogen skal vedligeholde, opgradere eller modernisere det.
Ville det chokere dig at finde ud af, at 80% af dit analytiske indhold er dødt, ikke brugt, er blevet erstattet af en ny version eller er blevet brudt i lang tid uden klager? Hvornår var sidste gang vi tjekkede?
Start ikke noget projekt, der kræver validering af analytisk indhold uden at gennemgå, hvad der skal valideres, og hvad der skal ryddes op eller skraldes. Hvis vi ikke har nogen analyser at bruge mod analyserne, så find ud af, hvordan du får nogle fremadrettet.
5. Evaluer, at moderniseringsprojektet og individuelle planer er helhedsorienterede.
Lad os gå tilbage til det dårlige mål, "At levere en hurtig, problemfri kilde til smuk analyse, der muliggør let forbrug og indholdsoprettelse", og nedbryde det fra et højt niveau. Der er sandsynligvis en infrastrukturændring til behandling af hukommelse og disk, en databaseopgradering eller ændring, et skifte til en moderne Single Sign On -udbyderteknologi som SAML eller OpenIDConnect og en opdatering eller opgradering af analyseplatformen. Det er alle gode ting og hjælper med at modernisere, men vi skal huske det slutbrugere er interessenter. Hvis disse brugere får det samme indhold, som de har været i årevis, men bare hurtigere, vil deres tilfredshedsniveau sandsynligvis være minimalt. Smukt indhold kan ikke bare være til nye projekter og skal leveres til vores største gruppe af forbrugere. Modernisering af det eksisterende indhold ses sjældent, men har største effekt på brugerne. Dette er især vigtigt for administratorer eller andre på teamet, der understøtter analyseplatformen. Ikke at holde slutbrugerne tilfredse med, at andre værktøjer bliver bragt ind for at gå rundt om, hvad teamet leverer, og slutresultaterne kan være katastrofale. Jeg vil dække dette emne i min næste blog om et par uger.
6. Sidste råd.
Tag backup ofte, og lav ikke et moderniseringsprojekt kun i produktionen. Brug kræfterne på at få et simuleret produktionsmiljø til store, vidtgående ændringer. Dette vil igen hjælpe med at minimere variabler og forskelle mellem, hvad der fungerer uden for og inden i produktionen.
Held og lykke på din egen moderniseringsrejse!
Har du spørgsmål til dit eget moderniseringsinitiativ? Kontakt os for at diskutere dine behov, og hvordan vi kan hjælpe!
