Qlik Support & Beheer: de complete gids (2026)

Een klant belde met een noodgeval. De persoon die al jaren alle Qlik-ontwikkeling en het beheer van hun omgeving had gedaan, was vertrokken. Vrij kort na zijn vertrek begonnen dingen stuk te gaan. Dashboards kwamen niet meer overeen met de verwachting. Rapportages waren incompleet. Kritieke informatie ontbrak.

We gingen kijken. Wat we aantroffen was een omgeving zonder ook maar één regel documentatie. Tientallen apps, waarvan sommige vrijwel identieke kopieën waren met net kleine verschillen. Niemand wist meer waarom die er waren of welke de juiste was. Geen architectuurbeschrijving, geen versiebeheer. Jaar op jaar waren zaken rechtstreeks in productie aangepast, pleisters op pleisters, totdat de structuur die er misschien ooit was volledig verdwenen was. De omgeving draaide, maar het hing aan een zijden draadje.

Dit is het scenario dat veel organisaties vrezen maar zelden actief voorkomen: de afhankelijkheid van één persoon, en de kwetsbaarheid die pas zichtbaar wordt als die persoon weg is.

Ik zie dit patroon al bijna twintig jaar terugkomen in Qlik-omgevingen. In deze gids leg ik uit hoe goed Qlik-beheer eruitziet, wat er mis gaat zonder structureel onderhoud, hoe proactief werken verschilt van reactief fixen, en wanneer je beter een partner inschakelt dan het zelf probeert.

Kort samengevat: Qlik-omgevingen groeien vanzelf. Beheersbaarheid niet. Zonder structureel onderhoud groeit technische schuld stiller dan je denkt, totdat een vertrek, een migratie of een release het blootlegt. Proactief beheer houdt je omgeving bruikbaar en zorgt dat elke wijziging hanteerbaar blijft in plaats van steeds zwaarder wordt.

Inhoudsopgave

• Wat is Qlik support en beheer?

• Wat gaat er mis zonder beheer?

• Proactief vs reactief: het verschil in de praktijk

• Qlik Cloud vs on-premise: wat verandert er?

• Governance: hoe houd je grip als de omgeving groeit?

• Performance: waar zit de pijn echt?

• Wanneer schakel je een support partner in?

• Wat mag Qlik support kosten en wat levert het op?

• Veelgestelde vragen

Wat is Qlik support en beheer?

Qlik-beheer is meer dan een helpdesknummer bellen als er iets kapotgaat. Het omvat alles wat nodig is om een Qlik-omgeving gezond, beheersbaar en betrouwbaar te houden: monitoring van omgevingsgezondheid, app-onderhoud, governance, release-analyse, performance-reviews en gebruikersbeheer.

Dat is wezenlijk anders dan generieke IT-support. Een IT-generalist die een ticket afwerkt heeft niet de kennis om een stille fout in een incrementele laadroutine te diagnosticeren. Of om te beoordelen of een nieuwe Qlik Cloud feature release gevolgen heeft voor de custom extensies die je gebruikt, de visualisaties die zijn uitgefaseerd, of de API-integraties die op jouw omgeving leunen.

Het onderscheid dat ik altijd maak:

Reactief beheer: je lost problemen op nadat ze zichtbaar zijn geworden. Gebruikers melden dat een dashboard niet klopt. Je duikt erin, repareert het, en wacht op de volgende melding.

Proactief beheer: je monitort, analyseert en onderhoudt de omgeving structureel, zodat problemen zich niet voordoen, of in elk geval niet als complete verrassing.

Dat klinkt logisch. In de praktijk kiezen veel organisaties toch voor het eerste, simpelweg omdat het concreter voelt: je betaalt voor wat er kapot is, niet voor wat er niet kapotgaat. De ironie is dat reactief beheer structureel duurder uitpakt. Niet in de maandelijkse factuur, maar in de cumulatieve kosten van incidenten, hersteltijd en de technische schuld die zich stap voor stap opbouwt.

Bekijk onze Support & Onderhoud-dienst

Wat gaat er mis als je Qlik-beheer verwaarloost?

Op basis van de omgevingen die we de afgelopen jaren binnenkwamen, zien we steeds dezelfde problemen terugkomen. Niet altijd alle zeven tegelijk, maar zelden minder dan drie.

1. (Incrementele) load die stilletjes faalt

Een QVD-laadroutine die elke nacht draait maar al weken geen verse data inleest. De foutmelding verdwijnt in een logbestand dat niemand leest. Gebruikers zien data van drie weken geleden als “actueel”. Dit is een van de gevaarlijkste problemen, omdat het onzichtbaar is totdat iemand de cijfers naast een andere bron legt.

Dit soort fouten is volledig te voorkomen met een eenvoudige monitoring-alert. Maar die alert moet dan wel iemand hebben ingesteld.

2. Kennis die weggaat met de mensen

De architect die de datamodellen heeft gebouwd is weg. Wat hij heeft neergezet werkt, maar waarom het zo is ingericht weet niemand meer. Geen documentatie, geen commentaar in de scripts, geen architectuurbeschrijving. Elke wijziging is nu een gok, want je weet niet wat je kunt aanraken zonder iets anders te breken.

Het voorbeeld uit de inleiding is hier het extreme geval. Maar een mildere versie herken ik in vrijwel elke nieuwe klantomgeving.

3. Hardcoded referentiedata

Productcategorieën, kostenplaatsen, regiocodes: hardcoded in het script, of ingeladen uit een Excel die door één collega werd bijgehouden. Die collega is weg. De Excel staat ergens op een gedeelde schijf. Of niet meer.

Dit klinkt triviaal totdat de organisatie een herstructurering doorvoert en de kostenplaatscodes veranderen. Dan kom je erachter dat dertien apps allemaal een eigen versie van die tabel bevatten.

4. Wildgroei van apps én sheets

Ik noem dit Qlik-sprawl, naar het bekende spreadsheet-sprawl: dezelfde ongecontroleerde wildgroei, nu in apps en sheets in plaats van Excel-bestanden. Het begint met apps: elke afdeling laat op enig moment een eigen rapport bouwen. Maar met de komst van self-service analytics gaat het verder: iedereen kan sheets aanmaken, visualisaties dupliceren, eigen versies opslaan. Dat is een voordeel van het platform. Alleen ruimt niemand ooit op.

Het gevolg is een omgeving vol overlappende apps en sheets, met net andere definities van dezelfde begrippen. “Omzet” in het financieel dashboard telt anders dan “omzet” in het salesdashboard. En niemand weet meer welke versie klopt, of welke sheets nog actief worden gebruikt.

5. Stille wijzigingen in de brondata

De databron verandert. Een veld krijgt een nieuwe waarde. Een tabel wordt hernoemd. Een nieuwe optie wordt toegevoegd aan een keuzelijst. Qlik geeft geen foutmelding: de data laadt gewoon, maar de uitkomst klopt niet meer.

Dit is verraderlijker dan een harde fout. Een harde fout valt op. Een stille afwijking kan weken of maanden onopgemerkt blijven, totdat iemand de cijfers naast een externe bron legt.

6. Ontbrekende documentatie

De omgeving draait. Maar waarom een specifiek datamodel er zo uitziet, welke keuzes zijn gemaakt bij de inrichting van spaces, wie waarom toegang heeft tot welke databron: dat staat nergens. Bij elke wijziging moet je het opnieuw uitzoeken, en je maakt fouten omdat je de context mist.

7. Governance-gaten: toegang en gebruikersbeheer

Wie heeft toegang tot welke data? Is dat nog correct na de laatste reorganisatie? Zijn er gebruikers met te ruime rechten? En, misschien nog urgenter: zijn er voormalige medewerkers die nog steeds actief zijn in de omgeving?

Gebruikersbeheer is een onderdeel van governance dat regelmatig vergeten wordt. Mensen die van rol wisselen, naar een andere afdeling gaan of het bedrijf verlaten worden niet altijd uit Qlik verwijderd. Dat is niet alleen inefficiënt, het is ook een compliance-risico.

Proactief vs. reactief: het verschil in de praktijk

Proactief Qlik-beheer bestaat uit een set concrete activiteiten die je structureel uitvoert, los van of er op dit moment iets kapot is. Het heeft een duidelijk ritme.

Ter illustratie: dit is hoe wij het bij Bitmetric aanpakken, gestructureerd per frequentie.

Continu en bij incidenten

Supportvragen behandelen, foutmeldingen in apps en reloads onderzoeken, databronnen en automatiseringen ondersteunen, platformproblemen escaleren naar Qlik Support indien nodig, en objecten herstellen vanuit back-up.

Wekelijks

Nieuwe apps, spaces, data connections, automatiseringen en taken signaleren. Wijzigingen in toegangsrechten en licenties beoordelen. Terugkerende reload- en automationfouten analyseren. Openstaande supportmeldingen reviewen.

Maandelijks

Gebruik en inrichting analyseren met de Qlik Analyzers: App Analyzer, Reload Analyzer, Data Connection Analyzer, Entitlement Analyzer. Controleren of apps voldoen aan tenantstandaarden. Inventariseren van ongebruikte apps, spaces, alerts, subscriptions, automatiseringen, data connections en taken. Rapportage van incidenten, bevindingen en verbeterpunten.

Per kwartaal

Extensions en themes beoordelen op gebruik en noodzaak. App- en sheetadoptie analyseren. Ongebruikte sheets signaleren. Reloadplanning en batch windows optimaliseren. QVD-performance beoordelen. Structurele bevindingen uit support bespreken en verbetervoorstellen prioriteren.

Jaarlijks

Tenantarchitectuur beoordelen. Schaalbaarheid evalueren in relatie tot gebruikers, apps en datavolume. Governance, rollen en verantwoordelijkheden reviewen. Licentie- en capaciteitsbehoefte opnieuw beoordelen. Disaster-recoveryplan actualiseren en herstelprocedure oefenen, inclusief een restoretest vanuit de Qlik Cloud-back-up.

Dit is wat proactief beheer concreet betekent. Geen vage beloftes over “proactief meedenken”, maar een gestructureerde aanpak met een ritme dat past bij de aard van het platform.

	Proactief	Reactief
Detectie	Voordat de gebruiker het merkt	Na melding van gebruiker
Releases	Impact vooraf geanalyseerd	Fix na productie-incident
Documentatie	Actueel en doorzoekbaar	Fragmentarisch of afwezig
Governance	Continu bijgehouden	Handmatig na audit of incident
Kosten	Voorspelbaar en planbaar	Variabel, vaak hoog bij incidenten
Kennisoverdracht	Geborgd in proces en documentatie	Afhankelijk van persoon
App-beheer	Periodieke review en opschoning

Qlik Cloud vs on-premise: wat verandert er bij beheer?

Een veelgehoorde aanname: Qlik Cloud is SaaS, dus de leverancier zorgt voor het beheer. Dat klopt deels. De infrastructuur is inderdaad Qlik’s verantwoordelijkheid: servers, beschikbaarheid, updates van de core software.

Maar het beheer van de omgeving is nog steeds jouw verantwoordelijkheid.

Bovendien is Qlik Cloud Analytics een aanzienlijk rijker platform dan Qlik Sense on-premise ooit was. Elke feature die je inzet vraagt ook om beheer. Qlik Automate brengt automatiseringen die kunnen falen en die je moet monitoren. Reporting brengt subscriptions en distributieschema’s die bijgehouden moeten worden. Qlik Predict brengt AutoML-deployments die een eigen levenscyclus hebben. En API-integraties en third-party connectoren komen er nog bij.

In mijn ervaring verschuift Qlik Cloud de beheerlast, maar verlaagt het hem niet. De infrastructuurverantwoordelijkheid verdwijnt. Daarvoor in de plaats komt een bredere functionele scope die actief beheerd moet worden.

Andere belangrijke verschillen:

Release-cadans

Qlik Cloud brengt wekelijks feature releases uit, doorgaans op dinsdag, naast doorlopende technische updates. Dat is significant vaker dan de halfjaarse releases van on-premise Qlik Sense. Elke release kan gevolgen hebben voor bestaande apps, visualisaties die zijn uitgefaseerd, of extensies die niet meer worden ondersteund. Proactieve release-impact analyse is daardoor geen luxe maar een structurele beheeractiviteit.

Data Gateway

On-premise stond de data dicht bij de Qlik-server. In Qlik Cloud heb je een Data Gateway nodig voor toegang tot on-premise databronnen. Die gateway heeft zijn eigen levenscyclus en vereist monitoring en onderhoud.

Backup en herstel

On-premise werd de Qlik-omgeving vaak gewoon meegenomen in de bestaande serverback-ups: bestandssysteem, QVD’s, de repository database. Qlik Cloud heeft sinds kort soft-delete voor apps: een verwijderde app is tot veertien dagen terug te halen. Voor configuratie en andere artefacten geldt dat niet, die zijn na verwijdering direct weg. Dat verschuift de verantwoordelijkheid voor een volwaardige back-up- en herstelstrategie grotendeels naar jou, of naar de partij die de omgeving voor je beheert.

Voor organisaties die de overstap naar Qlik Cloud overwegen: reken op een beheer-transitie, niet alleen op een technische migratie.

Governance: hoe houd je grip als de omgeving groeit?

Governance in Qlik gaat over wie wat mag zien, aanpassen en publiceren, wie verantwoordelijk is voor de kwaliteit van de data, en of dat allemaal geborgd is in de inrichting. In een omgeving met vijf gebruikers en tien apps kun je dit informeel houden. Bij vijftig gebruikers en honderd apps is dat niet meer verantwoord.

Maar governance is geen standaard recept dat je overal hetzelfde toepast.

De juiste governance-inrichting hangt af van een aantal factoren: wie er ontwikkelt en voor wie, wie de omgeving gebruikt en op welk niveau, wie eigenaar is van de data en wie van de analytics, hoe volwassen de datacultuur is, en hoe gevoelig de data is. Bedrijfsbrede financiële data vereist striktere governance dan een lokale marketinganalyse.

Vier patronen, oplopend in complexiteit

In de praktijk onderscheid ik vier veelvoorkomende patronen:

Personal BI
De maker beantwoordt zijn of haar eigen vragen. Weinig of geen delen, geen formele publicatie. Flexibel en informeel. Werkt prima voor individuen, maar schaalt niet.

Team BI
Een groep collega’s deelt analyses in een gedeelde omgeving. Ontwikkelaars zijn vaak vakinhoudelijk experts die hun eigen data ontsluiten. Processen zijn informeel, maar het werkt voor de groep.

Departmental BI
Een klein team binnen de afdeling bouwt analytics voor alle gebruikers van die afdeling. Hogere kwaliteitseisen, meer formele publicatie. De behoefte aan lifecycle management begint hier te spelen: gebruikers kennen de apps niet intiem, dus de apps moeten voor zichzelf spreken.

Enterprise BI
Een centraal team, vaak een CoE (Center of Excellence) of BICC (Business Intelligence Competency Center), is verantwoordelijk voor alle analytics. Hoge technische expertise, formele processen voor requirements en delivery, verplicht lifecycle management. Vaak ook verantwoordelijk voor het faciliteren van self-service datasets voor departmental en team BI.

Het patroon dat dominant is in jouw organisatie bepaalt de governance-inrichting die je nodig hebt. Maar een organisatie hoeft niet overal op hetzelfde niveau te zitten. Sommige afdelingen werken prima met Team BI, terwijl de financiële afdeling Enterprise BI-governance vereist.

Wie beheert wat: data en analytics

Een tweede dimensie is de verdeling van verantwoordelijkheid tussen business en IT.

In een volledig gedecentraliseerd model beheert de business zowel de data als de analytics. Flexibel, maar moeilijk te schalen en te borgen.

In een “middle-out” model beheert IT de data-laag en de business de analytics. Dit geeft een goede balans tussen governance en self-service, en is in de praktijk een veelgekozen aanpak.

In een volledig centraal model beheert IT of een CoE alles. Strakkere governance en meer controle, maar ook minder flexibiliteit voor de business en een hogere afhankelijkheid van het centrale team.

Welk model het beste past, hangt af van de omvang, de datacultuur, de gevoeligheid van de data en de capaciteit van zowel IT als de business.

Eén waarschuwing

Te strakke governance werkt averechts. Als je self-service doodreguleert, gaan mensen om het systeem heen werken. Excel, eigen tooling, shadow IT. De omgeving die je zorgvuldig beheerst, wordt omzeild door een schaduwomgeving die je niet kunt zien. Kies een basisniveau dat past bij de dominante patronen in jouw organisatie, en maak ruimte voor afwijkingen waar dat zinvol is.

Praktische governance-elementen

Ongeacht het gekozen patroon zijn een aantal elementen altijd relevant:

• Space-structuur: heldere indeling met duidelijk eigenaarschap per space

• Toegangsmodel (RBAC, Role-Based Access Control): gedocumenteerd, periodiek gecontroleerd, bijgewerkt napersoneelswisselingen

• Data-eigenaarschap: elke dataset heeft een eigenaar in de business, niet in IT

• Section Access: voor rij-niveau beveiliging, maar alleen robuust als de logica actueel blijft na organisatiewijzigingen

• Change management: wie mag wat aanpassen in productie, en via welk proces

Governance is geen eenmalig project. Het is een continu proces dat je structureel bijhoudt.

Performance: waar zit de pijn echt?

Performance-problemen in Qlik Cloud zitten bijna nooit in de infrastructuur. Qlik beheert de servers, de capaciteit is in de meeste gevallen toereikend, en “Large Apps support” is zelden wat je werkelijk nodig hebt.

De performance-pijn die ik tegenkom zit vrijwel altijd in een van de volgende vier lagen. En ze versterken elkaar.

Het datamodel

Een slecht opgezet datamodel is de meest voorkomende oorzaak. Te brede tabellen met velden die nergens voor worden gebruikt, overbodige joins, onnodige tussentabellen. Het gevolg: langere laadtijden en een zwaarder geheugengebruik.

Maar het echte probleem is het cascade-effect: een slecht datamodel dwingt ontwikkelaars tot kunstgrepen in de front-end expressies om de gewenste berekeningen toch te krijgen. Die kunstgrepen maken de app traag, wat de aanleiding is voor de aanname dat er meer infrastructuur nodig is. Terwijl de oplossing in het datamodel zit.

Het laadscript 

Scripts die door de jaren heen zijn uitgebreid zonder refactoring. Dode code, dubbele transformaties, variabelen die nergens meer naar verwijzen. Taken die sequentieel draaien terwijl ze prima parallel kunnen lopen. En het meest voorkomende: geen incrementele load voor tabellen die dat wel zouden kunnen, waardoor elke reload een volledige herlaad is van data die grotendeels al aanwezig was.

Laadprocessen en planning

Reload-taken die niet optimaal zijn gepland. Afhankelijkheden die niet goed zijn ingericht, waardoor een vertraagde taak een keten van problemen veroorzaakt. Batch windows die niet zijn afgestemd op de beschikbare capaciteit. Dit is beheerswerk, geen ontwikkelwerk.

Front-end expressies

Inefficiënte Set Analysis-expressies. Berekeningen die voor elke gebruikersinteractie opnieuw worden uitgevoerd omdat de onderliggende datastructuur ze niet ondersteunt. Aggregaties in visualisaties die eigenlijk in het datamodel thuishoren.

De oplossing is in alle gevallen hetzelfde: periodiek onderhoud en review. Geen hardware, geen licentie-upgrade, maar iemand die er regelmatig naar kijkt met voldoende technische kennis om de oorzaak te herkennen.

Wanneer schakel je een Qlik support partner in?

Niet elke organisatie heeft een externe Qlik support partner nodig. Als je een goed ingericht intern team hebt met voldoende Qlik-expertise en capaciteit voor proactief onderhoud, kun je het prima zelf doen.

Maar er zijn situaties waarin uitbesteden zinniger is dan zelf doen.

Signalen dat partner-support de moeite waard is

• Intern heeft niemand de diepgaande Qlik-kennis om release notes te analyseren of datamodel-issues te diagnosticeren
• De omgeving is groter dan één persoon bij kan houden naast de dagelijkse werkzaamheden
• Een Qlik Cloud feature release heeft al eens onverwachte problemen veroorzaakt in productie
• Een sleutelpersoon is weggegaan en de kennis is niet overgedragen
• Je staat voor een migratie, een ERP-wisseling of een grote architectuurwijziging
• Analytics-downtime heeft directe gevolgen voor operationele beslissingen

Waar je op let bij het kiezen van een partner

Een goede Qlik support partner doet meer dan tickets afwerken. Let op of ze release impact analyses uitvoeren voor elke update, of ze jouw omgeving kennen en niet elke keer opnieuw hoeven in te werken, en of ze bereid zijn kritisch te zijn. Als een partner altijd ja zegt en nooit terugduwt, is dat geen goed teken.

Pas ook op voor partners die na de initiële implementatie de aandacht laten verslappen. De support is het werk dat na de implementatie begint, niet ervoor. Vraag altijd naar wat er in de eerste zes maanden na go-live concreet gedaan wordt, en door wie.

Bekijk onze supportpakketten

Wat mag Qlik support kosten en wat levert het op?

De waarde van professioneel Qlik-beheer zit voor een groot deel in wat er niet gebeurt. Incidenten die worden voorkomen. Releases die geen verrassingen opleveren. Een omgeving die bruikbaar blijft zonder dat elke wijziging meer inspanning vereist dan de vorige.

Dat laatste punt is misschien de beste indicator voor de kwaliteit van beheer: de moeite die het kost om een wijziging door te voeren. In een goed beheerde omgeving is dat stabiel. In een verwaarloosde omgeving groeit die inspanning met elke toevoeging, omdat de technische schuld en de onduidelijkheid over de bestaande structuur elke stap zwaarder maken. Op een gegeven moment durft niemand meer iets aan te raken.

Wat bepaalt de kosten?

De prijs van een support contract hangt af van een aantal factoren: de omvang van de omgeving (apps, gebruikers, datavolume), de complexiteit van de architectuur (on-premise databronnen, legacy-integraties, maatwerkextensies), het gewenste SLA (responstijd bij incidenten, beschikbaarheid buiten kantooruren), en of proactief onderhoud is inbegrepen of alleen break-fix service.

Bij Bitmetric begint proactief Qlik Cloud beheer vanaf €950 per maand.

Een goede partner maakt vooraf inzichtelijk wat de scope is en wat het kost. Vage uurtarievenafspraken zonder duidelijke scope zijn een signaal dat je niet weet wat je koopt, en de rekening daarna ook niet. Bij Bitmetric vormt de Bitmetric Blueprint de basis van onze hele dienstverlening, niet alleen van Qlik Cloud Analytics.

Veelgestelde vragen

Conclusie

Een Qlik-omgeving die goed werkt, is best wat werk. Dat werk is (helaas) meestal onzichtbaar: zolang het goed gaat, merk je er niets van. Precies dat maakt het kwetsbaar, je ziet pas dat er iets ontbrak op het moment dat het wegvalt.

Structureel Qlik-beheer is geen garantie dat er nooit iets misgaat. Het is wel de garantie dat je het eerder ziet aankomen, sneller reageert, en minder last hebt van de verrassingen die anders ongezien opbouwen en in productie opduiken.

De keuze tussen intern beheer en uitbesteden hangt af van je kennis, capaciteit en de complexiteit van je omgeving. Beide kunnen werken. Wat niet werkt: geen keuze maken en hopen dat het vanzelf goed blijft gaan.

Wil je weten hoe jouw Qlik-omgeving er nu voor staat? Ik bespreek dat graag vrijblijvend met je. Gebruik de knop hieronder om een gesprek met mij via Teams in te plannen op een moment dat jou schikt.