Klik voor meer informatie over auteur Wayne Yaddow.
Datawarehousing (DW) en business intelligence (BI) -projecten hebben hoge prioriteit voor veel organisaties die streven naar meer en betere datagestuurde beslissingen en acties in hun hele onderneming. Deze groepen willen hun gebruikersbestand voor gegevensdetectie, BI en analyse uitbreiden, zodat hun zakelijke gebruikers weloverwogen beslissingen kunnen nemen. Tegelijkertijd eisen gebruikers hoogwaardige en vaak complexe BI-rapporten.
Datawarehouse-projecten zijn zeer ingewikkeld en fundamenteel riskant. Onder hun vele taken moeten projectmanagers die het datawarehouse-team leiden, alle datakwaliteitsrisico’s identificeren. Een primair doel van dit proces is het documenteren van essentiële informatie met betrekking tot projectrisico’s.
Dit artikel richt zich op het vermijden van de volgende vier veelvoorkomende fouten die andere datawarehouse- en BI-projecten hebben ondervonden, om nieuwe functies en mogelijkheden met succes te plannen en te implementeren.
Kwaliteitsborging niet vroeg in het project introduceren
Tijdens de eerste fasen van datawarehouse / BI-projecten ligt de focus vaak op BI-vereisten en datagerelateerde behoeften voor het bouwen van de operationele datastore, het enterprise datawarehouse en applicatierapportage-infrastructuren. Op de een of andere manier wordt het belang van end-to-end DW-projecttests en datakwaliteit vaak over het hoofd gezien.
Er is altijd een waardering voor Data kwaliteit. Toch kan de overweldigende focus op datamodellering, dataverzameling en ETL-ontwerp ertoe leiden dat het team de focus op datakwaliteit verliest, naarmate de vereisten van het datawarehouse en het ontwerp vordert. Uiteindelijk zullen problemen zoals deze zich voordoen:
- “Doelgegevens zijn niet verenigbaar met bronnen. “
- “Dubbele gegevens zijn er in overvloed.”
- “Aggregaties en drilldowns in rapporten zijn niet correct.“
Uiteindelijk is het succes van een datawarehouse sterk afhankelijk van het vermogen om een reeks tests te plannen, ontwerpen en uitvoeren die vroege en voortdurende problemen blootleggen: problemen met inconsistenties van gegevens, gegevenskwaliteit, gegevensbeveiliging, het ETL-proces, prestaties, -stroomnauwkeurigheid en de ervaring van de eindgebruiker.
Veel datawarehouseteams discussiëren over wanneer ze moeten beginnen met testen terwijl ze nieuwe software ontwikkelen. Voor de meeste DW-projecten zou het testen van software moeten beginnen zodra het ontwerp en de vereisten zijn gebaseerd. Een vroege start van QA biedt verschillende voordelen die de algehele effectiviteit van softwaretests verbeteren. Q Een deelname aan het begin van een project maakt testers effectiever door hen in staat te stellen meer te weten te komen over het product en de bedrijfsregels die ze gaan testen. Ze zullen waarschijnlijk betere testplannen en testcases ontwerpen.
Tijdens de ontwerp- en requirementsfase kunnen testers samen met ontwikkelaars bepalen welke aspecten van een ontwerp testbaar zijn en welke gebieden een hoger risico hebben. Deze kennis helpt testfouten te voorkomen en testers beter uit te rusten om testcases te ontwerpen en defecten te identificeren.
Implementeren van een succesvol datawarehouse project is een uitdaging. Het vereist een afweging van vele factoren, zoals een sterke betrokkenheid van het bedrijf, grondige gegevensanalyse, een schaalbaar systeem, gegevensarchitectuur, een uitgebreid programma, gegevensbeheer, gegevens van hoge kwaliteit, gebruik van gevestigde normen en processen, uitstekende communicatie en projectbeheer .
Brongegevens niet adequaat profileren en valideren voordat ze in het datawarehouse worden geladen
Studies van analisten hebben consequent aangetoond dat meer dan 75% van de datawarehouse- en data-integratieprojectteams hun planning of budgetten hebben overschreden of anderszins te maken hebben gehad met projectfalen. Waarom het hoge uitvalpercentage?
Onvoldoende brongegevenskwaliteit is de hoofdoorzaak van storingen in een breed scala aan datawarehousing-projecten. Het vooraf profileren en valideren van alle brongegevens kan aanzienlijke voordelen opleveren.
De traditionele benadering van datawarehouse-projecten volgt deze basisstappen:
- Analyseer het bedrijf, de gebruiker en de technische vereisten van het project.
- Analyseer de beschikbare interne en externe databronnen.
- Identificeer en analyseer een reeks gegevensbronnen uit legacysystemen, operationele systemen en externe bronnen om hun relevantie voor de vereisten van de doeldatabase te bepalen.
Het is misschien dwaasheid om aan te nemen dat u uw brongegevens kent voordat u begint met het ontwerpen van uw beoogde datawarehouse. De belangrijkste zwakte van de traditionele data-integratiebenadering is dat deze ervan uitgaat dat de gegevens die nodig zijn voor een applicatie volledig beschikbaar zijn uit de databronnen. Grote bedrijven hebben miljoenen dollars uitgegeven aan data-integratieprojecten om later te vernemen dat de brongegevens het doelmodel niet ondersteunden.
Gegevensprofilering moet worden uitgevoerd voor elke gegevensbron: tabelanalyse, rij- en kolomanalyse, beoordelingen van primaire en externe sleutels en kruistabelanalyse implementeren. Profilering van brongegevens moet ook worden overwogen om minimum, maximum, gemiddelde, modus, percentielen en dubbele waarden te ontdekken – zelfs profilering van metagegevens zoals gegevenstypen, gegevenslengtes, null-waarden en tekenreekspatronen.
Onvoldoende aandacht schenken aan testautomatisering
Met de komst van DevOps voor datawarehousing brengen organisaties nieuwe applicaties sneller dan ooit uit – soms op aanvraag of meerdere keren per dag. Veel bedrijven gebruiken echter nog steeds handmatige ETL-testprocessen voor zeer zichtbare of klantgerichte applicaties. Dat vertaalt zich in een risico voor de klantloyaliteit, het merk, vertrouwelijke gegevens en erger. Zelfs met nieuwe automatiseringstools die op de markt komen, worden ETL- en dataprofileringstests vandaag nog steeds voornamelijk bereikt met handmatige tests.
Door ETL-tests te automatiseren, zijn frequente rook- en regressietests mogelijk zonder veel tussenkomst van de gebruiker. Geautomatiseerd testen van vertrouwde code na elke nieuwe database-build kan meetbare tijd en kosten besparen.
Een beslissing om geautomatiseerde tools voor datawarehouse-testen te implementeren, hangt af van een budget dat extra uitgaven ondersteunt om aan geavanceerde testvereisten te voldoen. Als het implementeren van door de leverancier geleverde testautomatisering te duur wordt geacht, is het essentieel om testtools te overwegen die intern zijn gebouwd en onderhouden, omdat ze waarschijnlijk een groter voordeel hebben dan helemaal geen testautomatisering.
Evalueer bij het ontwikkelen van scenario’s voor testautomatisering uw volledige set testscenario’s om de beste kandidaten voor automatisering te bepalen op basis van risico en waarde (ROI): welke soorten defecten zouden ertoe leiden dat u een integratie of implementatie stopzet? Welke soorten tests oefenen kritische kernfunctionaliteit uit? Welke tests hebben betrekking op toepassingsgebieden waarvan in het verleden bekend is dat ze niet slagen? Welke tests leveren informatie op die nog niet is gedekt door andere tests in de pijplijn?
Uiteindelijk bespaart testautomatisering tijd en geld, en wat nog belangrijker is, zakelijke gebruikers zullen de kwaliteit van BI-resultaten waarderen en de gegevens van de dataplatformoplossing accepteren als een “enkele versie van de waarheid”.
Implementeren van gebrekkige beheerscontroles voor projectwijzigingen
Verandering is constant in elk datawarehouse-project. Ongeacht de branche komt er uiteindelijk behoefte aan nieuwe eisen en andere veranderingen. Een streven naar voortdurende verbetering en nieuwe datawarehouse-vereisten leidt vaak tot een variatie in de projectomvang of -resultaten.
Verandermanagement is een essentieel onderdeel van het succes van datawarehouse-initiatieven, maar hoe vaak wordt uitgebreid verandermanagement geminimaliseerd? Volgens Forrester’s Q1 2014 Wereldwijd BI Maturity Surveyis meer dan de helft van de ondervraagden van mening dat hun processen voor het beheren van veranderingen op basis van nieuwe datawarehouse-gegevens en -functionaliteit niet goed ingeburgerd zijn en niet soepel functioneren.
Testers moeten verwijzen naar kritieke documenten die bij alle wijzigingen betrokken zijn – documentatie zoals zakelijke vereisten, ontwerp en technische specificaties, documenten voor het in kaart brengen van gegevens, ETL-taakstromen en meer. Het vermogen om deze documenten te identificeren en te koppelen aan het algehele veranderingsbeheerproces en om testplannen op te stellen, zijn essentieel voor effectieve kwaliteitsborging.
Veranderingen voor BI-initiatieven komen vaak uit meerdere bronnen, waaronder de verzoeken van bedrijfseigenaren of andere belanghebbenden en de gevolgen van wijzigingen in het bronsysteem. Het QA-team moet deelnemen aan de manier waarop wijzigingen worden geregistreerd, beheerd, geprioriteerd en bijgewerkt, en moet er vervolgens voor zorgen dat alle wijzigingen worden geverifieerd. Als uw organisatie al een tool voor het bijhouden van wijzigingen heeft, is het een goed idee om daar gebruik van te maken.
Datawarehouse- en BI / analyseprojecten hebben de neiging om geld te besteden aan technologie en implementatie, maar verandermanagement en post-go-live adoptieactiviteiten worden vaak ondergefinancierd – of zelfs helemaal over het hoofd gezien. Goed verandermanagement vergemakkelijkt de communicatie vanaf het begin en motiveert gebruikers om van weerstand naar acceptatie en zelfs opwinding over te gaan – waardoor de buy-in toeneemt en de succesvolle acceptatie van de nieuwe functionaliteit aanzienlijk wordt verbeterd
Patrick Meehan, onderzoeksdirecteur in De CIO-onderzoeksgroep van Gartner Group, stelt dat de meeste falende datawarehouse / BI- (en DM / A) -projecten vertraging oplopen of het budget overschrijden vanwege slechte communicatie over nieuwe en veranderende eisen tussen het management en de IT-teams.
Wanneer uw organisatie een datawarehouse-project uitrolt, wordt de kans op succes aanzienlijk vergroot wanneer verandermanagement een integraal onderdeel van het initiatief is.
Laatste gedachten
Fouten die hier worden beschreven, zijn gericht op het helpen van organisaties om QA-problemen te omzeilen die veel andere datawarehouse-projecten hebben ondervonden. De aangeboden tips zorgen voor tevredenheid terwijl datawarehouse-teams nieuwe functies en mogelijkheden plannen en implementeren. Deze beproefde aanbevelingen kunnen veel geld, tijd en personeel besparen en de resultaten van de datawarehouse-applicatie in ontwikkeling verbeteren.
