Wat is datawarehouse-automatisering?

Wat wordt er precies geautomatiseerd?

Het repetitieve deel van datawarehousing: data ophalen, wegschrijven, historie bijhouden, fouten afhandelen en alles documenteren. Dat werk is voor elke tabel vrijwel hetzelfde, en precies daarom leent het zich voor generatie uit metadata. Wat níét wordt geautomatiseerd is het denkwerk: welke cijfers de organisatie nodig heeft en wat een begrip als 'omzet' of 'actieve klant' betekent.

Wanneer loont het, en wanneer niet?

Automatisering loont zodra het aantal bronnen en tabellen groter is dan wat één persoon met de hand kan bijhouden, of zodra de organisatie op de cijfers moet kunnen vertrouwen. In de praktijk ligt dat punt rond drie bronnen: vanaf daar kost het onderhoud van losse koppelingen meer dan het bouwen ervan.

Het loont niet als je één bron hebt en een handvol rapporten. Dan is een directe koppeling vanuit Power BI goedkoper en snel genoeg. Het loont ook niet als je datawarehouse vooral bestaat uit unieke, complexe berekeningen: die blijf je zelf schrijven, met of zonder tool.

• Wel: drie of meer bronnen, of één bron met veel tabellen en mutaties
• Wel: je wilt kunnen terugkijken naar de stand op een eerdere datum
• Wel: meerdere rapportbouwers moeten van dezelfde cijfers uitgaan
• Wel: het BI-team is meer tijd kwijt aan koppelingen dan aan analyses
• Wel: een ERP-migratie komt eraan en de rapportage moet doorlopen
• Niet: één bron, enkele rapporten, geen behoefte aan historie

Welke soorten tools zijn er?

De markt valt in vijf groepen uiteen. Ze lossen verschillende problemen op; de meeste verwarring ontstaat doordat ze allemaal 'data-integratie' of 'ETL' worden genoemd. Een vergelijking op onderdelen van Yres, TimeXtender, AnalyticsCreator en zelf bouwen vind je op de vergelijkingspagina, onderaan bij 'Verder lezen'.

Zelf bouwen of een tool gebruiken?

De licentie van een tool is zelden de grootste kostenpost; de uren van engineers zijn dat wel. Zelf bouwen met Azure Data Factory en dbt of SQL kost geen licentie en geeft volledige vrijheid. Daar staat tegenover dat elke bron, elke historietabel en elke herstelprocedure engineeringtijd kost, bij de bouw en daarna bij elke wijziging van een bron-API.

Reken daarom met de totale kosten over een paar jaar: bouwuren, beheeruren, de kosten van stilstand als de ene persoon die het begrijpt vertrekt, en de Azure-kosten. Voor technisch sterke teams met weinig bronnen kan zelf bouwen de beste keuze zijn. Voor organisaties zonder eigen dataplatformteam is het dat zelden.

Let bij een tool op wat er overblijft als je stopt. Sommige tools draaien je datawarehouse op een eigen uitvoeringslaag die moet blijven lopen; andere zetten gewone onderdelen in je eigen cloudomgeving neer die je na vertrek zelfstandig kunt voortzetten. Vraag het de leverancier letterlijk: wat krijg ik mee als ik opzeg, en blijft het laden dan doorlopen?

Waar let je op bij het kiezen?

Begin bij je bronnen en je mensen, niet bij de lijst met functies. Een tool die jouw ERP niet goed ontsluit, of die een specialist vraagt die je niet hebt, lost niets op.

• Bronnen: is er een eigen koppeling voor jouw ERP, of moet je die zelf samenstellen via een generieke REST-koppeling?
• Waar staat de data: in je eigen cloudomgeving of bij de leverancier?
• Doelplatform: past het bij wat je al hebt (Azure SQL, Fabric, Snowflake)?
• Modelleren: wil je dat de tool het datamodel voor je genereert, of bouw je het liever zelf op een laag met volledige historie?
• Herkomst van cijfers: op object- of op kolomniveau?
• Prijs: vast en vooraf bekend, of op aanvraag en afhankelijk van volume?
• Afhankelijkheid: wat blijft er werken als je het contract opzegt?
• Kennis: kan je huidige team ermee werken, of is er een gecertificeerde partner nodig?

Waar past Yres in dit beeld?

Yres is een datawarehouse-automatiseringsplatform voor Microsoft Azure, gemaakt door Plainwater in Nederland. Het genereert Azure Data Factory-pipelines uit metadata en laadt de data in een Azure SQL-database in de eigen Azure-omgeving van de klant, met volledige historie. Wat Yres oplevert zijn gewone Azure-onderdelen in jouw abonnement. Je data en je historie staan daar en blijven van jou. Stop je met Yres, dan draait je omgeving gewoon door en kunnen je eigen data engineers erop doorontwikkelen.

Yres kiest bewust voor één vaste, beproefde manier van laden en historie bewaren. Het heeft eigen koppelingen voor AFAS en Exact Online (officiële partner van beide), ontsluit SAP via OData, en sluit elk ander systeem aan via REST of OData. De prijs is vast en openbaar.

Wat Yres bewust niet doet, is het datamodel voor je genereren. Modelleren hangt sterk af van je eigen wensen en ervaring, en verandert mee met wat je rapportagetools vragen. Yres levert daarom de laag met volledige historie; het model daarop, of dat nu Kimball, Data Vault of iets eigens is, bouw je zelf met views en procedures die via changes mee naar productie gaan. Je verliest dus geen vrijheid, maar je krijgt er geen gereedschap voor. Verder genereert Yres geen semantisch model voor Power BI, is de herkomst van cijfers inzichtelijk op objectniveau en niet op kolomniveau, en richt het zich op Azure SQL als doelplatform; Microsoft Fabric als doelplatform staat gepland voor eind 2027. Is dat voor jou doorslaggevend, dan past een breder pakket beter.

Veelgestelde vragen