Bij Performance Management, Data Warehousing, Business Intelligence of het starten met Big Data en Advanced analytics, het is belangrijk te beseffen dat ze allen niet-eindige reizen voorstellen. Het houdt daarbij niet op na de vrijgave van "een” kubus aan een aantal eind-gebruikers of tenminste het zou daar niet bij mogen blijven.
Indien u net gestart bent met BI of CPM dan zal u hoogstwaarschijnlijk bepaalde kubussen of rapporten afleveren aan een mogelijk niet volledig gedefinieerde groep van business gebruikers. Mogelijk zal u zelfs bepaalde documentatie of extra guidelines publiceren. Daarop komen er bepaalde vragen bij u terecht in verband met support of vragen rond de behoeftes voor een minieme uitbreiding van de bestaande oplossing die net gebouwd werd of misschien zelfs voor een compleet nieuwe kubus en bijgevolg begint het onderliggend data model stilletjesaan uit te deinen. Misschien moet u wel op zoek naar externe hulp. Mogelijk worden verschillende oplossingen gebouwd op het zelfde ogenblik. Maar hoe gaat u eigenlijk om met deze tsunami van nieuwe en veranderende noden, oplossingen en projecten? Zeker indien de teams die de oplossingen leveren bestaan uit een mix van interne & externe resources, waarbij die laatste groep mogelijk bestaat uit verschillende partijen aangevuld met individuele personen. Maar wat uiteindelijk telt is dat er een herhaalbare methode gebruikt wordt om BI op een succesvolle manier te implementeren; een CPM of BI methodologie, die duidelijk definieert wat er dient te gebeuren en hoe het dient te gebeuren op een consistente, gedocumenteerde en herhaalbare manier.
Maar hoe nu starten met uw methodologie in functie van definitie en implementatie?
Zet je alvast schrap om eerst en vooral kristisch te kijken naar de huidige manier van werken. Start door een gedetailleerde inventaris van zaken te maken die dienen te gebeuren wanneer u een BI of CPM oplossing wil creëren;
- Welke stappen neemt u en in welke volgorde?
- Welke deliverables levert u af?
- Welke rollen dienen er ingevuld te worden?
- Welke activiteiten worden uitgevoerd?
- Welke technologie wordt gebruikt en waarom?
- Welke standaarden werden gedefinieerd?
Gebaseerd op deze inventaris, is het belangrijk om te identificeren wat werkt en wat niet werkt en de redenen waarom.
- Wat ontbreekt er?
- Wie ontbreekt er in de lijst van stakeholders?
- Wat is de perceptie van de business gebruikers?
- Hoe worden deze betrokken?
- Hoe gebeurt de communicatie in functie van de voortgang van de lopende projecten?
- Hoe volgt u het gebruik van de oplossing op?
- Hoe worden de requirements verzameld, gebruikt en geverifieerd op het einde van het project?
Nadat we een correct zicht hebben op de "As Is” situatie, dienen we onze voorkeur "To Be” situatie te definiëren. Welk stadium willen we bereiken en wanneer? Op basis van deze twee situaties kunnen de deltas bepaald worden, waaruit finaal een realistische roadmap in haalbare delen gedistilleerd kan worden.
Wanneer we een methodologie definiëren is het belangrijk dat de rollen, activiteiten en deliverables op maat van BI, DW of PM gemaakt worden. Het is noodzakelijk te erkennen dat BI en CPM bijvoorbeeld oplossingen vereisen waarbij de eindproducten klaar zijn na 2 a 3 maanden wat op hun beurt resulteert in gelijkaardige iteraties. We dienen ons er ook van te vergewissen dat de gekozen methode de taken duidelijk opsplitst binnen haalbare fases, welke er als volgt zouden kunnen uitzien:
- Strategie & planning: scope van wat er dient gedefinieerd te worden, tegen wanneer, door wie?
- Analyse: definitie van de details van de oplossing die gebouwd dient te worden (conceptueel data model, rapport design ...)
- Design: design van de oplossing (logisch data model, bron-doel mappings ...)
- Bouw: het bouwen van de oplossing en het technisch testen er van
- Test: business testen en business acceptatie
- Oplevering: in productie brengen van de oplossing
- Opvolging: opvolgen van de uiteindelijke acceptatie en het gebruik ervan binnen de organisatie
Elk van de fases dient overeen te komen met een bijhorende mijlpaal. Natuurlijk zou u een gevestigde methodologie zoals element61’s elementary methodologie kunnen gebruiken. Maar vergewis u er van dat u uw methode altijd aan de organisatie en de specifieke situatie dient aan te passen.
Voor elk van de fases die gedefinieerd werden, dient een specifieke set van activiteiten en deliverables gedefinieerd te worden. Welke actviteiten dienen bijvoorbeeld uitgevoerd te worden in de design fase? Een RACI (Responsible, Accountable, must be Consulted, must be Informed) kan helpen in het beschrijven van de participatie van de verschillende rollen naar compleetheid toe bij het uitvoeren van de taken. Voor elke activiteit is het tevens noodzakelijk om een haalbaar tijdsbestek aan te geven. Al deze verschillende componenten moeten leiden tot een project plan dat weldoordacht is en klaar om uitgevoerd te worden.
Omwille van consistentie en om zich volledig te kunnen concentreren op de essentie is het advies om herbruikbare templates en bijhorende spelregels te definiëren. Hier dient een onderscheid gemaakt te worden tussen algemene project deliverables zoals bijvoorbeeld een "issue log” en een "risk log” en BI specifieke deliverables, zoals een data model. Een ander onderscheid zou kunnen zijn dat bepaalde deliverables binnen elke iteratie dienen opgeleverd te worden, waar andere deliverables slechts éénmalig opgeleverd dienen te worden zoals bijvoorbeeld "naming conventions”. Samen met het project plan, zullen deze deliverables en standaarden garanderen dat zowel interne als externe mensen die aan de oplossing werken, dezelfde aanpak zullen hanteren. Uiteindelijk is het essentieel dat twee verschillende project teams niet met bijvoorbeeld twee verschillende fout behandeling mechanismes voor de dag komen, die dan ook nog eens niet geïntegreerd kunnen worden.
Na het definiëren van de fases, deliverables, ownership etc. is het belangrijk om de juiste prioriteiten en accenten te leggen. Het is vanzelfsprekend dat u uw huidige manier van werken niet van vandaag op morgen kan veranderen. Het gaat uiteindelijk nog steeds over de oplevering van oplossingen voor business gebruikers en het gebruik van een weloverwogen methode is uiteindelijk geen doel op zich. Daarom is het belangrijk om een maturiteitsmodel te definiëren waarbinnen de "As Is” & "To Be” situaties kunnen gesitueerd worden aan beide zijden van het spectrum. Daartussen bevinden zich een aantal tussenliggende mijlpalen die afhankelijk zijn van een bepaalde tijdslijn. De eerste mijlpaal staat voor het bereiken van de meest belangrijke en / of dringende deliverables, templates of activiteiten. Hier is het belangrijk om duidelijk de niveau’s of mijlpalen die overbrugd dienen te worden, te begrijpen, daarnaast betekent dit eveneens dat een duidelijk begrip vereist is omtrent wat dit betekent in functie van de tijd benodigd om die niveau’s of mijlpalen te bereiken, alsook de betrokken personen, veranderingen aan processen, technologie, kosten & voordelen.
Bij de aanvang van uw trip doorheen PM, DW of BI land, is het een best practice om een herhaalbare methode op te stellen met alle noodzakelijke ingrediënten voor succes.
Dit kan alleen bereikt worden door alle issues op de juiste manier aan te pakken en te vertrouwen op een u eigengemaakte en goed-gedefinieerde methodologie.
element61 kan u helpen bij het definiëren en implementeren van de juiste aanpak, startend van het werk dat reeds gebeurd is met het bouwen van onze eigen BI, CPM & DW methodologie elementary.
Contacteer ons voor meer informatie rond de creatie van een BI methdologie!