In de praktijk worden veel BI oplossingen vaak gebouwd n.a.v. een concrete vraag waarop het liefst snel een antwoord moet komen. In interactie met de toekomstige gebruikers komt het rapport dan tot stand.  Tijdens het bouwen worden ad hoc de problemen opgelost die zich aandienen, bijvoorbeeld op het vlak van datakwaliteit. In het beste geval documenteert de BI specialist het hoe en het waarom van de ad hoc oplossingen. Vaak gebeurt dit ook niet.
Als een oplossing in nauwe samenwerking tussen de gebruiker en ontwikkelaar  tot stand komt, is de kans groot dat het eindresultaat voldoet in de behoefte van de gebruiker en heeft deze vertrouwen in de stuurinformatie die het oplevert.
De tijd schrijdt echter voort en mensen veranderen van functie binnen de organisatie of verlaten de organisatie voor een andere baan.  Gevolg is dan dat de BI oplossing nieuwe gebruikers krijgt. Deze gebruikers hebben geen  kennis over het ontstaan van het rapport en de keuzes die er gemaakt zijn. Als de BI oplossing dan niet of niet voldoende gedocumenteerd is, is de kans groot dat men de betekenis ervan niet meer goed kan duiden. Er komt dan een moment waarop men zich zal afvragen: welke conclusies kan ik wel, en welke kan ik niet uit het rapport trekken? Wanneer dit soort twijfel ontstaat bij de gebruiker,  loopt het leven van het BI oplossing op zijn einde. Het kan dan in onbruik raken of, erger nog: het wordt wel gebruikt maar fout geïnterpreteerd, zodat de verkeerde beslissingen worden genomen.
Het is dus van “levensbelang” voor een BI oplossing dat kennis over de herkomst van de cijfers behalve in de hoofden van zij de betrokken zijn bij de totstandkoming ervan goed geborgd wordt.
Te denken valt aan het vastleggen van de volgende punten:

• Een beschrijvingen van wat de aanleiding was om de BI oplossing te maken. Per onderdeel  (rapport, stuurgetal, …) een beschrijving van welke vragen er mee beantwoord kunnen worden.
• Definities van concepten:  Een zo precies mogelijke beschrijving op functioneel niveau van de concepten (entiteiten, relaties, kengetallen) die een rol spelen binnen de BI oplossing. Bijvoorbeeld: Een actuele klant is een persoon of instantie die binnen een periode van 2 jaar voorafgaand aan een peildatum tot aan de peildatum een factuur heeft ontvangen.
• Operationalisatie van de concepten:  Een zo precies mogelijke beschrijving  hoe de voor het concept data bij elkaar wordt gezocht binnen de bronsystemen, hoe deze wordt bewerkt of gefilterd.
• Historie: Hoe wordt omgesprongen met historische data?  Is het mogelijk eerder gemaakte rapportages exact te reproduceren of wordt data overschreven?
• Laadmomenten:  Wanneer is welke data in de operationele systemen beschikbaar in de BI oplossing?
• Onderhoudsmomenten definiëren: Het identificeren van situaties die impact hebben op de BI oplossing. Bijvoorbeeld: Als er nieuwe producten geïntroduceerd en in het kader van een BI rapportage is worden deze producten ingedeeld in klassen, dan moet deze klassenindeling worden bijgewerkt.

Ter afsluiting nog een tip: Documentatie is niemands hobby. Zeker als het achteraf nog moet gebeuren, is de verleiding groot om dit tot een minimum te beperken. Bedenk dat bepaalde schrijfactiviteiten al tijdens het ontwikkeltraject gestart kunnen worden.  Bijvoorbeeld het beschrijven van de aanleiding en de concepten. Dit kan ook zeer verhelderend werken in de communicatie met de toekomstige gebruiker…