--- title: "Van melding tot release: hoe lang een wijziging in je datawarehouse onderweg is" titleHtml: "Van melding tot release: hoe lang een wijziging in je datawarehouse onderweg is" description: "Een kleine wijziging in je datawarehouse duurt vaak maanden. Niet door het werk zelf, maar door het wachten ertussen. Hoe dat komt, en hoe het sneller kan." date: 2026-08-19 author: "Jeroen Buisman" heroImage: ../../../assets/blog/van-melding-tot-release-hoe-lang-een-wijziging-in-je-datawarehouse-onderweg-is.jpg relatedLinks: - label: "Hoe we werken" href: /hoe-we-werken/ - label: "Hoe een tijdelijke oplossing je nieuwe standaard wordt" href: /inzichten/hoe-een-tijdelijke-oplossing-je-nieuwe-standaard-wordt/ themas: - datawarehouse - bi-strategie tags: [] lang: nl draft: false --- Een afdeling is anders gaan werken en de rapportage klopt daardoor niet meer. Er is een nieuwe vraag waar het bestuur een antwoord op wil. Of er moet iets aangeleverd worden waarvoor een gegeven nodig is dat er nu niet in zit. En dat vraagt om een aanpassing in het datawarehouse. Een veld dat erbij moet, een definitie die niet meer klopt met hoe de afdeling werkt, een koppeling die anders moet. Op zichzelf geen ingewikkelde wijziging. Je meldt het bij je leverancier. En dan begint het. ## Hoe zo'n verzoek onderweg is Je maakt een ticket aan in het supportsysteem, en dan wacht je af. Met een beetje geluk kijkt er binnen een week iemand naar. Het antwoord is dan meestal dat het ter beoordeling naar de ontwikkelaars gaat. Een paar weken later komt het bericht dat het op de backlog staat. Dat klinkt als vooruitgang, ook al is er nog niets gebeurd. Daarna hangt het ervan af of je verzoek net voor een nieuwe sprint op die backlog kwam, en of het genoeg prioriteit heeft gekregen om meteen te worden meegenomen. Zo niet, dan wacht je op de sprint daarna. Of die daarna. En dan komt het bericht dat het in de volgende release zit. Er kunnen makkelijk maanden overheen gaan voordat de gevraagde aanpassing is doorgevoerd. Van die maanden gaat er weinig tijd naar de wijziging zelf. Het meeste is wachten tussen stappen: op de stapel, op een beoordeling, op een plek in de sprint, op een releasemoment. De optelsom is dat de doorlooptijd van een (relatief) kleine wijziging niet wordt bepaald door hoeveel werk het is, maar door hoe vaak de overleggen en de releases plaatsvinden. Eigenlijk wordt het bepaald door de bureaucratie er omheen. En haast helpt maar beperkt. Je kunt escaleren, en soms levert dat iets op, meestal tegen extra kosten. Maar een enkele klant krijgt een grote leverancier zelden zo ver dat de planning opzij gaat. In afwachting van de wijziging maak je zelf maar een work-around, of de gevraagde rapportage wacht gewoon. En je zit als BI-afdeling met een interne klant die het antwoord niet krijgt. ## Hoe het ook kan Als diezelfde vraag bij ons binnenkomt gaat het zo. We zien de vraag binnenkomen en beslissen snel, vaak dezelfde dag, of het iets is wat we gaan doorvoeren. Daarna bereiden we het werk voor: we beschrijven in overleg met de melder wat er moet gebeuren. Dat is een gesprek tussen twee mensen, zonder tussenlagen, en daardoor weten we ook waarom de vraag gesteld wordt. Zo'n gesprek zul je bij een grote leverancier zelden krijgen. Daar gaat je melding langs een supportmedewerker, een product owner en een scrum master, en wat de ontwikkelaar uiteindelijk voor zich heeft is de melding zoals die is opgeschreven. Vervolgens voeren we het uit, testen we de wijziging en of er niets anders is stukgegaan. En dan zorgen we dat het meegaat in de volgende uitlevering, of anders die daarna. En als het nodig is zorgen we dat de wijziging eerder beschikbaar is. Weken wachten op een beoordeling gebeurt niet. Wat overblijft is de tijd die het werk zelf kost, plus de tijd tot de eerstvolgende uitlevering. ## Waarom dat kan Dat komt doordat we met een klein team werken. Daardoor zit er weinig tussen de vraag en de uitvoering ervan. Er is geen bureaucratische laag die eerst moet beoordelen of iets in aanmerking komt, geen overleg waarin bepaald wordt of het verzoek in behandeling gaat, en geen tweede overleg waarin het wordt ingepland. Wie de vraag ziet, kan er iets over besluiten, en wie erover besluit kan er ook aan werken. Het verschil is de wachttijd, niet het werk. Het voorbereiden, het uitvoeren, het testen en het uitleveren gebeuren allemaal. Wat ertussenuit valt is de tijd waarin een verzoek op een stapel ligt, op een beoordeling wacht of op een plek in een sprint. Van die maanden doorlooptijd zit het meeste juist daarin. Daar komt bij dat het bij ons dezelfde mensen zijn die de omgeving kennen. Wie er nu aan werkt, werkte er vorig jaar ook aan. Er hoeft niemand ingewerkt te worden en er hoeft niemand uit te zoeken hoe het model in elkaar zit voordat er iets kan gebeuren. Dat scheelt tijd, en het scheelt fouten. ## Wat dat voor een BI-afdeling betekent Kortere doorlooptijden veranderen wat een BI-afdeling kan toezeggen. Een vraag die binnenkomt hoeft niet meer op een lijst voor volgend kwartaal, en een aanleiding die vandaag speelt kan ook vandaag opgepakt worden. Dat scheelt work-arounds, en het scheelt uitleggen waarom iets nog steeds niet klaar is. Wil je weten hoe dat er bij jullie uit zou zien? We lopen graag een keer door hoe wij werken, en waar dat voor jullie tot snellere resultaten zou leiden.