Sammendrag
Mange ting i livet blir med rette møtt, men av de tingene som det er verdt å ha mer erfaring, er det de som oppstår fra feil som er gjort, fordi det oppnådde negative resultatet er kjent, årsakene til konteksten som påvirket feilen og prøv å ikke gjenta det så mye som mulig.
Denne listen over feil ved bygging av et datawarehouse-selskap er en av de første artiklene, som søker å generere et kunnskapsgrunnlag og erfaring fra erfaringer fra informasjonsteknologiprosjekter, i dette spesifikke tilfellet i utviklingsprosjekter for datawarehouse.
Denne listen ble opprettet for å tjene som et verktøy for alle menneskene som har en viss deltakelse i utviklingen av et datawarehouse og vil tillate å evaluere hvilken vei de går og mulighetene for endelig suksess, men de mest syntetiserte rådene som kan hentes fra det er å opprettholde et felles arbeid på deltakernivåer og organisasjonsområder, samt å jobbe på solide teoretisk-praktiske grunnlag for den involverte teknologien.
Målet med denne listen er å gi en kilde til konsultasjon av erfaringer, fra anvendelsen av denne teknologien i forskjellige selskaper, samt å gi teoretisk-praktisk grunnlag, som hviler på datavitenskapens domene og mer korrekt, av datawarehouse-teknologi, og som til syvende og sist skal føre til fremtidig suksess med bedriftens datawarehouse-prosjekt.
Nøkkelord: datawarehouse, datamart, datamining, bygging av et datahus for bedrifter, vanlige feil, administrering av et datawarehouse-prosjekt, risiko for å bygge et datawarehouse, utsiktene til datawarehouse, lønnsomhetsberegning for investering i et datahouse
Hovedsiden
1. Introduksjon
2. Liste over 10 vanligste feil ved bygging av et datawarehouse-selskap
3. Konklusjoner
4. Bibliografi
1. Introduksjon
I dag er teknologiområder i de fleste finansielle og kommersielle selskaper, som inntil nylig har viet mesteparten av sin innsats for å tilby transaksjonssystemer - som støttet byrden for de fleste aktiviteter i verdikjedene - De er fokusert på å oppnå en sammenhengende utnyttelse av lagrede data: historisk og transaksjonelt, virkeligheten rundt det, er den enorme størrelsen på data hentet fra den daglige driften av transaksjonssystemene, og problemet med å analysere og hente ut kunnskap fra alt dette. informasjon som forblir begravet i seg selv.
Det finnes en serie beregningsteknikker som gjør det mulig å transformere denne transaksjonsmessige, operasjonelle og daglige informasjonen til informasjon med forskjellige aggregeringsnivåer, oppsummert, nøyaktig og spesialisert etter emne, og som gjør det mulig å analysere dem, muliggjøre ledelsesmessige beslutninger, Denne teknologien kalles et datarepository eller Datawarehouse.
Basert på profesjonell praksis er imidlertid bygging av datawarehouse ikke immun mot problemer som hindrer suksess og oppnåelse av det endelige målet: støtte til ledelsesmessige beslutninger.
Denne artikkelen prøver å gå utover det teoretiske, og presentere problematiske problemer som forhindrer vellykket utvikling av et datawarehouse for bedrifter.
Derfor bør det spesifiseres at følgende liste - over de vanligste feilene i utviklingen av et datawarehouse-selskap - kommer frem fra utviklingen av denne teknologien i representative selskaper som tilhører den peruanske finans- og kommersielle sektoren.
Forutsatt at et prosjekt må tilfredsstille klienten ved å representere avkastningen på investeringen - vi vet at det ikke alltid er lett å estimere dette i datateknologiprosjekter, er imidlertid suksessen til et datawarehouse-utviklingsprosjekt direkte proporsjonal med verktøyet oppnådd fra analysen av informasjon om å ta de riktige beslutningene som selskapet drar fordel av, på dette tidspunktet: å vite at en beslutning som er tatt - basert på analyse av data gjennom datawarehouse - gir større inntekter og / eller sparing, er den mest Tilstrekkelig estimering, for dette må vi ta i betraktning hvor enkelt det er å skaffe rapporter så vel som fleksibiliteten i konfigurasjonen.Det vurderes - å generere læring fra beslutningene som tas hver gang - viktigheten av å lagre formen og informasjonen til aggregatene og rapportene som er brukt over tid, som en måte å demonstrere verdien av for selskapet.
Denne listen, med riktig bruk, vil gi rom for mer nøyaktig beslutningstaking fra prosjektledelse, eiere og klienter, og vite de mulige konsekvensene av en eller annen bestemt strategi eller tiltak og forhindre hyppige feil, og tillater kostnadsbesparelser, både i formulering, utvikling og gjennomføring av prosjektet.
2. Liste over 10 vanligste feil ved bygging av et datawarehouse-selskap
Første feil: Anta løsningen på problemene som kan oppstå som et rent teknisk spørsmål
Datawarehouse krever aktiv deltakelse fra ledelsesmessige beslutningstakere.
Andre feil: Ikke tildele et tilstrekkelig budsjett for hele prosjektet.
En tilstrekkelig tildeling av kapital og ressurser for å støtte og drifte den teknologiske plattformen og infrastrukturen som et datawarehouse-selskap krever, må være et av de første aspektene når man ser på det som et prosjekt.
Tredje feil: Mangel på engasjement fra toppledelsen.
Suksessen til bedriftens datawarehouse krever full støtte fra toppledelsen basert på sikkerheten og tilliten som gis til prosjektledelsen og dens utviklingsteam, for å la arbeidet være flytende i alle organisatoriske områder som er involvert i prosjektet.
Fjerde feil: Har ikke tilstrekkelig infrastruktur for å støtte den.
Bedriftsdatavarehuset krever en tilstrekkelig teknologisk så vel som organisatorisk infrastruktur. Systemarkitekturen til et datawarehouse spenner fra proprietære databaseserver, datatransformasjon og rengjøringsservere, front-end ledelsesbrukernoder som er arrangert i hele organisasjonen. Programvare krever server-, klient- og virksomhetssjikt-applikasjoner som fungerer effektivt i n-dimensjonale spørsmiljøer og parallell behandling.
Femte feil: Overflødige, ikke-transparente og udokumenterte databaser.
Status for transaksjonsdatabasene som informasjonen som vil bli transformert og lagret i datawarehouse er hentet fra, blir vanligvis ikke vurdert i de første tidsestimatene. Dette kan imidlertid representere betydelig forsinkelse, ideelt sett er det statene til enhetene som kontoer, klienter, gjeld, betalinger osv. lagres i historiske tabeller i betydelige tidsperioder i henhold til den gjennomsnittlige variasjonsfrekvensen (månedlig, annenhver uke, daglig) og i standardform, Imidlertid er denne informasjonen i praksis funnet som en del av tabeller som brukes til styringsrapporter, som allerede har gjennomgått en filtreringsprosess, og dermed mistet sammenhengen mellom historiske data og endringer i tilstandene over tid på nivået med alt Bedriften.
I noen tilfeller anbefales det å gjøre en uavhengig reengineering av databaser på et transaksjonsnivå, der endringer i statene til enhetene kan lagres på en ren måte som et tidligere trinn for å vurdere utvinning av dataene fra deres opprinnelse.
Sjette feil: Unnlatelse av å fremme et miljø med fullstendig samarbeid mellom DBAs og datawarehouse-teamet.
Når du starter et datawarehouse-prosjekt i et selskap, eksisterer generelt DBAs Database Administrators-området generelt, så det anbefales å opprette Datawarehouse-området på samme nivå som DBA-ene - og ikke under DBA-kontrollen. Mange DBA-er er ansvarlige for å opprettholde databasene for å støtte daglige transaksjoner. Å lage en alternativ plattform som er tilstrekkelig for utvikling av datawarehouse, ha tilgang til informasjonskildene til datawarehouse-domenet direkte og ikke som mellommenn til DBAene, er en av de viktige faktorene som bidrar til en raskere utvikling av prosjektet og at sikte på suksess.
7. feil: Unnlatelse av å bruke en kravspesifikasjonsmetodikk egnet for styring.
I kravspesifikasjonsaktivitetene fra ledelsesbrukere er det ikke ofte å bruke en metodikk som lar brukeren uttrykke kravene sine lett og klar for påfølgende tilbakemelding.
Det anbefales bruk av prototyping, så vel som utarbeidelse av funksjonelle spesifikasjonsdokumenter for krav fra styringsområder.
8. feil: Uvitenhet om verdikjeden, informasjonsflyt i forretningsaktiviteter.
Å identifisere aktivitetene som er kritiske suksessfaktorer, samt å observere flyt av aktiviteter med sentral kompetanse som lar produktene eller tjenestene som tilbys gi kunden verdi, er en kunnskapsoppgave for virksomheten som designerne av datawarehouse ikke må bestå omgå dette for å velge en prosjektutviklingsstrategi - basert på en generell modell for å utvikle datamart etter prosesser eller organisasjonsområder - som gjør det mulig å etablere prioriteringer i henhold til selskapets strategiske plan.
9. feil: Har ikke et integrasjonsperspektiv med andre relaterte teknologier.
En solid teoretisk base innen informasjonsteknologi, og et bredt spekter av eksisterende trender og løsninger, vil tillate utvikling av et datawarehouse med en visjon for fremtiden. I dette perspektivet er relaterte teknologier: OLAP som gjør det mulig å analysere historisk informasjon for å bestemme atferdsmønstre, på den annen side datamining som gjør det mulig å oppdage mønstre av atferd, men automatisk bruke modeller og algoritmer (beslutning trær, klynger, nettverksnervaler, uklar logikk, lineær regresjon, etc.), Noe lenger unna er implementeringen av et balansert målkort for bedrifter, der datawarehouse serverer informasjon fra indikatorene for historiske tidsperioder.
10. feil: Dårlig prosjektstyring og avslutning av prosjektutviklingsplanen.
Prosjektlederens kapasitet er eksponert i all den reelle dimensjonen, både innen teknisk og menneskelig trening og produktet av opplevelser i lignende prosjekter. Utviklingen av datawarehouse må være syklisk og i trinn, med aktivitetene analyse, design, utvikling, testing; repeterende milepæler, prøver å unngå repeterende arbeid.
3. Konklusjoner
Denne artikkelen er del av en serie artikler som forfatteren presenterer for informasjonsteknologi, spesielt i denne artikkelen, og gir en liste over 10 av de vanligste feilene som oppstår i utviklingen av prosjekter for å bygge et datawarehouse-selskap..
Det teoretiske grunnlaget som denne klassen av prosjekter bygger på, starter fra oppfatningen av flerdimensjonale informasjonsdatabaser (Ontology, Conceptual Data Model, Semantic Interpretation, Theory of Sets and Relations), hvorfra det forventes å få nøyaktig informasjon., nøyaktig og oppsummert for analyse og støtte for ledelsesmessige beslutninger.
Det praktiske grunnlaget ble oppnådd som et resultat av forfatterens deltakelse i forskjellige datawarehouse-prosjekter i viktige peruanske kommersielle og finansielle selskaper, hvis erfaring er impregnert i denne artikkelen, og blir presentert for leseren som et verktøy for konsultasjon og teoretisk-praktisk grunnlag., for fremtidig suksess i utviklingen av bedriftens datawarehouse.
4. Bibliografi
1. Bygge datavarehuset Forfatter WH Inmon Redaksjon John
Wiley & Sons, Inc. New York, NY, USA 1996
2. Datavarehusets livssyklusverktøysett: Ekspertmetoder for å designe, utvikle og distribuere datavarehusforfattere Ralph Kimball, Laura Reeves, Warren Thornthwaite, Margy Ross, Warren Thornwaite Redaksjon John Wiley & Sons, Inc. New York, NY, USA 1998
3. Genetisk algoritme for materialisert visningsvalg i data
Lageromgivelser Redaksjonell Springer Berlin / Heidelberg
1999
4. Datavarehusmodellering og kvalitetsspørsmål Forfatter: Panos Vassiliadis - Kunnskaps- og datagrunnlagssystemer Laboratorium for datavitenskap - Institutt for elektroteknikk og datateknikk - Nasjonalt teknisk universitet i Athen - Zographou 157 73, Athen, HELLAS phd.pdf
5. Vedlikehold av datavarehusvisninger ved bruk av standardisering
Forfattere: Mukesh Mohania, Kamal Karlapalem, Millist Vincent In D.
Ram, redaktør, Datahåndtering, side 32–50. Springer Verlag, 1997.
6. En metodikk for datawarehouse-design: konseptuell modellering Forfattere José María Cavero Universidad Rey Juan Carlos, Spania, Esperanza Marcos Universidad Rey Juan Carlos, Spania, Mario Piattini Universidad de Castilla-La Mancha, Spania, Adolfo Sánchez Cronos Ibérica, SA, Spania. Utgiver IRM Press Hershey, PA, USA 2002
7. En strategi for styring av datakvalitet i datavarehussystemer
1 / IQ01HelfertMaur.pdf
