Gartner anslår at nærmere 70 til 80 prosent av nyinitierte Business Intelligence-prosjekter mislykkes . Dette skyldes utallige årsaker, fra dårlig verktøyvalg til mangel på kommunikasjon mellom IT og forretningsinteressenter. Etter å ha implementert BI-prosjekter på tvers av bransjer, håper jeg å dele erfaringene mine i dette blogginnlegget og fremheve viktige årsaker til at business intelligence-prosjekter mislykkes. Denne artikkelen vil presentere mottiltak mot feil basert på tre prinsipper som skal styre hvordan datalager bygges. Å følge disse datalagerkonseptene skal hjelpe deg som datalagerutvikler å navigere i utviklingsreisen og unngå de vanlige hullene eller til og med sinkholene til BI-implementeringer.

Business Intelligence Data Warehouse Implementation

Selv om kriteriene for et vellykket datainformasjonslager for forretningsinformasjon vil variere fra prosjekt til side, forventes og kreves visse minimumsnivåer i alle prosjekter. Her er en liste over hovedattributtene som vanligvis finnes i et vellykket datainformasjonslager:

• Verdi: Business intelligence-prosjekter kan strekke seg over mange måneder eller til og med år. Det er imidlertid viktig å vise fordelene med et datalager til dine forretningsinteressenter veldig tidlig i prosjektet for å sikre fortsatt finansiering og interesse. Ideelt sett bør interessenter få vist en meningsfull forretningsverdi ut av det nye systemet i løpet av de første tre ukene av et prosjekt.
• Selvbetjening BI: Dagene med å vente på IT for å oppfylle dataforespørsler eller utføre dataanalyser er over. Suksessen til ethvert BI-prosjekt måles nå av hvor godt det gir forretningsbrukerne muligheten til å hente ut verdi ut av systemet selv.
• Koste: BI-prosjekter har generelt relativt høye implementeringskostnader. For å motveie og kompensere for de høye startkostnadene, er det viktig å designe lager med lave vedlikeholdskostnader. Hvis klienten krever et fullverdig team av BI-utviklere for å sikre / diagnostisere datakvalitetsproblemer, gjøre rutinemessige endringer i datamodellene eller håndtere ETL-feil, vil systemet være kostbart å budsjettere og risikere å bli slått av etter en tid .
• Tilpasningsevne: Evnen til å tilpasse seg utviklingskrav i virksomheten er avgjørende. Det er viktig å huske på det utallige antall BI-verktøy som er tilgjengelig på markedet og tempoet de utvikler seg for å inkludere ekstra funksjonalitet og funksjoner. Sammen med det faktum at bedrifter kontinuerlig utvikler seg, vil kravene til lageret endres; tilpasningsevne krever at datalager er utformet for å muliggjøre bruk av alternative BI-verktøy som forskjellige back-end eller visualiseringsverktøy i fremtiden, og kan tilpasses til ofte uforutsette endringer i kravene.

Gjennom min erfaring med å bygge vellykkede løsninger, og kanskje enda viktigere, å være involvert i mislykkede prosjekter, har jeg kommet til at tre hovedprinsipper er avgjørende for å øke sannsynligheten for en vellykket implementering av business intelligence-system. Før vi dekker dem i detalj, kan vi imidlertid begynne med en viss sammenheng.

Hva er et datalager?

Før du går inn i forskjellige datalagerkonsepter, er det viktig å forstå hva et datalager faktisk er.

Datalager er ofte tenkt på som business intelligence-systemer opprettet for å hjelpe de daglige rapporteringsbehovene til en forretningsenhet. De har ikke de samme ytelseskravene i sanntid (i standardimplementeringer) som OLTP-datasystemer, og mens OLTP-systemer bare vil inneholde dataene som gjelder en liten delmengde av virksomheten, ser datalagerene ut til å omfatte alle data knyttet til virksomheten .

Datalagermodeller gir fordeler for en bedrift bare når lageret blir sett på som det sentrale knutepunktet for “all things data” og ikke bare et verktøy som driftsrapportene dine produseres gjennom. Alle operasjonelle systemer skal ha toveiskommunikasjon med datalageret for å mate data i og for å få tilbakemelding om hvordan du kan forbedre driftseffektiviteten. Enhver forretningsendring, som for eksempel en økning i priser eller reduksjon av tilbudet / varelageret, skal først prototypes og prognostiseres i datalagermiljøet ditt, slik at virksomheten din på en pålitelig måte kan forutsi og kvantifisere resultatet. I denne sammenheng, alle datavitenskap og dataanalyse funksjoner vil være sentrert rundt datalageret.

Det er mange komponenter i et datalager, og det er ikke bare en database:

• TIL database er et medium der du lagrer dataene dine.
• TIL datavarehus går utover det for å inkludere verktøy og komponenter som er nødvendige for å hente ut forretningsverdien ut av dataene dine, og kan inkludere komponenter som integrasjonsrørledninger, datakvalitetsrammer, visualiseringsverktøy og til og med maskinlæringsprogrammer.

Her er en mer visuell fremstilling av forskjellen mellom en database og en databaselagerstruktur. Databaser eller nye logiske datametalagre som Hive danner den sentrale stjernen til et datalagers stjernesystem, med alle andre komponenter som sine roterende planeter. Imidlertid, i motsetning til et stjernesystem, kan et datalager ha en eller flere databaser, og disse databasene skal kunne byttes ut med ny teknologi, som vi vil diskutere senere i artikkelen.

Prinsipp for første datalager: datakvalitet hersker

Datalager er bare nyttige og verdifulle i den grad dataene er klarert av forretningsinteressentene. For å sikre dette må det bygges rammer som automatisk fanger opp og korrigerer (der det er mulig) problemer med datakvaliteten. Datarensing bør være en del av dataintegrasjonsprosessen med regelmessige datatilsyn eller dataprofilering for å identifisere eventuelle dataproblemer. Mens disse proaktive tiltakene er implementert, må du også vurdere reaktive tiltak når dårlige data glir disse portene og rapporteres av brukeren.

For å sikre brukernes tillit til datalagersystemet, bør eventuelle dårlige data uthevet av forretningsbrukere undersøkes som en prioritet. For å hjelpe til med denne innsatsen, bør dataradio og datastyringsrammer bygges inn i plattformen for å sikre at eventuelle dataproblemer kan identifiseres og utbedres raskt av supportpersonalet. De fleste dataintegrasjonsplattformer integrerer en viss grad av datakvalitetsløsninger, for eksempel DQS i MS SQL Server eller IDQ i Informatica.

Dra nytte av disse innebygde plattformene hvis du bruker et kommersielt verktøy i dataintegrasjonsrørledningene dine, men i tillegg eller på annen måte, sørg for at du bygger ut mekanismene som vil hjelpe deg med å opprettholde kvaliteten på dataene dine. For eksempel mangler de fleste dataintegrasjonsverktøy god funksjonalitet for å spore datarynet. For å overvinne denne begrensningen, kan et tilpasset batchkontrollrammeverk bygges ved hjelp av en serie kontrolltabeller for å spore hver dataflyt som oppstår i systemet.

Det er veldig vanskelig å gjenvinne tilliten til dine forretningsinteressenter hvis de møter dårlig kvalitet på plattformen din, så investeringene i datakvalitetsrammer bør være vel verdt kostnaden.

Andre prinsipp for datalager: Vend trekanten

Denne figuren illustrerer delingen av innsatsen i implementering og bruk av de fleste datalagre.

Mest innsats investeres i å bygge og vedlikeholde lageret, mens verdien av å ha et lager for forretningsanalyse er en mye mindre del av innsatsen. Dette er en annen grunn til at business intelligence-prosjekter ofte mislykkes. Noen ganger tar det for lang tid i prosjektsyklusen å vise noen meningsfylt verdi for klienten, og når systemet endelig er på plass, krever det fortsatt mye IT-arbeid for å få noen forretningsverdier ut av det. Som vi sa innledningsvis, kan design og distribusjon av business intelligence-systemer være en kostbar og langvarig prosess. Derfor vil interessenter med rette forvente å raskt høste verdien av deres forretningsinformasjon og datalagringsarbeid. Hvis ingen merverdi blir til, eller hvis resultatene rett og slett er for sent til å være av reell verdi, er det ikke mye som hindrer dem i å trekke i støpselet.

Det andre prinsippet for utvikling av datalager er å snu trekanten som illustrert her.

Ditt valg av forretningsinformasjonsverktøy og rammene du setter på plass, må sørge for at en større del av innsatsen til lageret er å hente ut forretningsverdi enn å bygge og vedlikeholde den. Dette vil sikre høyt engasjement fra dine forretningsinteressenter fordi de umiddelbart vil se verdien av å investere i prosjektet. Enda viktigere, du gjør det mulig for virksomheten å være selvforsynt med utvinne verdi uten å ha så sterk avhengighet av IT.

Du kan følge dette prinsippet ved å følge trinnvise utviklingsmetoder når du lager lageret for å sikre at du leverer produksjonsfunksjonalitet så raskt som mulig. Etter Kimballs datamartsstrategi eller Linstedt's Data Vault Metodologier for datalagerdesign hjelper deg med å utvikle systemer som bygger trinnvis, mens du tar hensyn til endring jevnt. Bruk et semantisk lag i plattformen din, for eksempel en MS SSAS-kube eller til og med et Business Objects Universe, for å gi et lett forståelig forretningsgrensesnitt til dataene dine. Når det gjelder førstnevnte, vil du også tilby en enkel mekanisme for brukere å spørre om data fra Excel - fremdeles det mest populære dataanalyseverktøyet.

Inkluderer BI-verktøy som fremmer selvbetjenings-BI, for eksempel Borde eller PowerBI vil bare bidra til å forbedre brukerengasjementet, ettersom grensesnittet til spørringsdata nå er drastisk forenklet i motsetning til å skrive SQL.

Lagring av kildedata i en data lake før du fyller ut en database, vil det hjelpe å eksponere kildedataene for brukere veldig tidlig i ombordstigningsprosessen. I det minste vil nå avanserte brukere som forretningskvanter kunne fordøye kildedataene (gjennom råfilene) ved å koble sammen verktøy som Hive / Impala på toppen av filene. Dette vil bidra til å redusere tiden det tar for bedriften å analysere et nytt datapunkt fra uker til dager eller til og med timer.

Tredje databaselagerprinsipp: Plug and Play

Data er i ferd med å bli den digitale ekvivalenten med olje. De siste årene har vi sett en eksplosjon i antall verktøy som kan brukes som en del av en datalagerplattform og innovasjonsgraden. De ledende anklagene er de utallige visualiseringsverktøyene som er tilgjengelige akkurat nå, med avanserte alternativer for bakenden bak. Gitt dette miljøet og tilbøyeligheten til at forretningskrav stadig endrer seg, er det viktig å huske på at du trenger å bytte ut komponenter i teknologibakken eller til og med introdusere / fjerne andre med tiden, slik forretnings- og teknologiforandringer tilsier.

Basert på personlig erfaring, ville det være heldig hvis en plattform kunne vare i 12 måneder uten noen form for betydelig endring. En rimelig innsats er uunngåelig i disse situasjonene; det bør imidlertid alltid være mulig å endre teknologi eller design, og plattformen din bør være utformet for å imøtekomme dette eventuelle behovet. Hvis migreringskostnadene for et lager er for høye, kan virksomheten ganske enkelt bestemme at kostnaden ikke er berettiget, og forlate det du har bygget i stedet for å migrere den eksisterende løsningen til nye verktøy.

Å bygge et system som vil imøtekomme alle tenkelige fremtidige behov er umulig. Derfor er det nødvendig med en viss forståelse for at det du designer og bygger nå kan erstattes med tid når du bygger datalager. For dette formål vil jeg anbefale bruk av generiske verktøy og design der det er mulig, i stedet for å koble plattformen tett til verktøyene den kjører på. Selvfølgelig må dette gjøres etter nøye planlegging og vurdering, da kraften i mange verktøy, spesielt databaser, ligger i deres individualitet og i nært utfylling.

For eksempel forbedres ETL-ytelsen dramatisk når du bruker lagrede prosedyrer i en database for å opprette nye forretningsanalysedata i motsetning til å trekke ut og behandle data utenfor databasen ved hjelp av Python eller SSIS. Når det gjelder rapporteringslaget, vil visualiseringsverktøy tilby visse funksjoner som ikke er lett tilgjengelige i andre, for eksempel Power BI støtter tilpassede MDX-spørsmål, men Tableau gjør det ikke. Poenget mitt er ikke å ta til orde for opphør av lagrede prosedyrer eller unngåelse av SSAS-kuber eller tablett i systemene dine. Min intensjon er bare å fremme viktigheten av å være oppmerksom på å rettferdiggjøre beslutninger om å knytte plattformen din til verktøyene.

Et annet potensielt synkehull er i integreringslaget. Det er veldig enkelt å bruke et verktøy som SSIS for dataintegrering på grunn av dets feilsøkingsfunksjoner eller brukervennlighet med SQL Server-plattformen. Imidlertid vil migrering av hundrevis av SSIS-pakker til et annet verktøy bli et veldig kostbart prosjekt. I tilfeller der du for det meste gjør 'EL', må du bruke et generisk verktøy for å utføre behandlingen. Ved å bruke et programmeringsspråk som Python eller Java til å skrive en generisk laster for å laste opp iscenesettingslaget ditt, vil det bidra til å kutte ned på individuelle SSIS-pakker du ellers ville ha trengt. Denne tilnærmingen hjelper ikke bare med å redusere vedlikeholdskostnader og fremtidige migrasjonskostnader, men hjelper også med å automatisere flere aspekter av datainnbyggingsprosessen uten å måtte skrive nye individuelle pakker (knytte seg til prinsipp 2).

I alle disse tilfellene må du bestemme et praktisk kompromiss mellom de umiddelbare fordelene og de fremtidige migrasjonskostnadene for å sikre at lageret ikke blir skrotet fordi det ikke takler endring, eller fordi endringen ville ha nødvendig for mye tid, krefter eller investeringer.

Innpakning

Det er mange grunner til at et bestemt business intelligence-system kan mislykkes, og det er også noen vanlige tilsyn som kan føre til en eventuell feil. Det stadig skiftende teknologilandskapet, et begrenset budsjett for datasystemer på grunn av misforstått sekundærprioritet til operasjonelle systemer, og den store kompleksiteten og vanskeligheten med å jobbe med data, betyr at nøye vurdering av ikke bare umiddelbare mål, men også fremtidige planer må skje når du designer bygge komponentene til et datalager.

Grunnleggende om datalagring skissert i denne artikkelen er ment å hjelpe deg når du tar disse viktige hensynene. Å ta hensyn til disse prinsippene garanterer selvfølgelig ikke suksess, men de vil helt sikkert hjelpe deg med å unngå fiasko.

Forstå det grunnleggende

Hva gjør en datalagerutvikler?

Datalagerutviklere eller mer ofte referert til nå som dataingeniører er ansvarlige for den generelle utviklingen og vedlikeholdet av datalageret. Det ville være opp til dem å bestemme seg for teknologibakken samt eventuelle tilpassede rammer og prosesser og å gjøre data klare for forbrukerne.

Hva er et datalagereksempel?

Bruk av forskjellige teknologier betyr at de fleste datalager er veldig forskjellige fra hverandre. Et grunnleggende eksempel vil bestå av en SQL-serverdatabase, med SSIS som danner dataintegreringslaget, og Power BI og SSRS sitter på toppen av databasen for å oppfylle kravene til visualisering og rapportering.

Hvordan fungerer et datalager?

Et datalager er dannet av utallige verktøy og rammer som arbeider helhetlig sammen for å gjøre data klare for å få innsikt. I hjertet av et datalager er en database eller en logisk metalagring av data med et dataintegrasjonsrammeverk som utgjør ryggraden.

Hva er fordelene med et datalager?

Datalager gir mekanismen for en organisasjon til å lagre og modellere alle dataene fra forskjellige avdelinger i en sammenhengende struktur. Fra dette kan ulike forbrukere av bedriftens data serveres, både interne og eksterne. Et datalager er i stand til å være den eneste sannhetskilden.