BUSINESS INTELLIGENCE VOOR LOKALE OVERHEDEN

BUSINESS INTELLIGENCE VOOR LOKALE OVERHEDEN een studie van het BICC-Thomas More (2012 2013) als bijdrage aan het IWT-project 3 x I. Informatiekwaliteit, Informatieveiligheid en Informatiearchitectuur in Lokale Besturen (2009 2013) Hans Tubbax, Tim Kastanovics en Dirk Pauwels http://bicc.thomasmore.be oktober 2013

Inhoudsopgave Inleiding... 3 Onderzoek en dienstverlening van het BICC voor 3 x I... 5 Lijst van afkortingen en verklarende woordenlijst... 6 1. Datawarehousing en beleidsinformatie... 8 1.1. Het veld in kaart gebracht. Jomme Dockx 2.0... 8 1.2. De Beleids- en Beheerscyclus (2014). Nieuwe uitdagingen, nieuwe kansen.... 10 1.3. Datawarehousing en informatiebeheer.... 11 1.3.1. De datastortvloed. Geschiedenis en uitdagingen.... 11 a. De jaren tachtig. Transactionele en operationele data... 11 b. Van de jaren negentig naar de 21 ste eeuw. Web 2.0 data... 12 c. Vandaag en de toekomst. The Internet of Things en Datawarehouses... 12 1.3.2. Nadelen van operationele systemen en de nood aan datawarehousing... 13 a. De datakwaliteit is niet verzekerd... 13 b. De data zijn niet beschikbaar op lange termijn... 13 c. Afwezigheid van externe data... 13 d. Operationele versus analytische databanken of datawarehouses... 13 1.3.3. Datawarehousing: wat het is en hoe het werkt... 14 a. Sterstructuur... 16 b. Denormalisatie... 17 1.3.4. Voordelen van een datawarehouse... 17 a. Eenheid van waarheid... 18 b. Overzichtelijke structuur... 18 c. Scheiding van operationeel systeem en BI systeem.... 18 1.3.5. Voorlopige conclusies en nood aan verder onderzoek... 20 2. PoC 1. Naar een gemeenschappelijk BI-platform voor lokale overheden.... 21 2.1. Inleiding. Voordelen van een gemeenschappelijk BI-platform... 21 2.2. SaaS BI voor lokale overheden. Beschrijving van PoC 1.... 22 2.2.1. Analyse... 22 2.2.2. Bouw van het systeem... 23 2.2.3. Aftoetsing bij gemeentelijke overheden... 25

2.3. Conclusies uit PoC 1... 27 3. PoC 2. Een Esperanto voor overheidsinformatie? Een testplatform voor OSLO.... 28 3.1. Situering. De nood aan uniforme data.... 28 3.2. OSLO... 29 3.2.1. OSLO en semantische interoperabiliteit... 29 3.2.2. OSLO als technische standaard voor PoC 2... 29 3.3. Esperanto test-case... 30 3.3.1. De samenwerkingsverbanden binnen PoC 2.... 30 3.3.2. Conceptuele afbakening... 31 3.3.3. De OSLO mapping tool... 32 3.3.4. Exporteren en omvormen van data... 33 3.3.5. Importeren van data... 34 3.4. Conclusies uit PoC 2... 36 4. Conclusie en aanbevelingen. Naar een BI maturiteit voor lokale overheden... 38 5. Referenties... 41

Inleiding Vijf jaar geleden, in 2008, schreef het IWT, het agentschap voor Innovatie door Wetenschap en Technologie een projectoproep uit om te zoeken naar innovatieve modellen en technologieën die op korte termijn inzetbaar zijn in het bedrijfsleven en die een duidelijk economisch effect realiseren bij beoogde doelgroepen. De Vlaamse ICT Organisatie V-ICT-OR en het onderzoekscentrum Memori van de toenmalige Katholieke Hogeschool Mechelen (vandaag: Thomas More) gingen graag in op deze oproep met het project 3 x I. Informatiekwaliteit, Informatieveiligheid en Informatiearchitectuur in Lokale Besturen. De algemene doelstelling van dit project dat in 2009 door het IWT werd goedgekeurd voor een duur van vier jaar bestond erin het informatiebeleid en beheer van lokale besturen te optimaliseren en ICT-bedrijven (vendors en consultants) beter in te lichten over de diverse noden die lokale besturen hebben rond dataverwerking en informatiebeheer. Voortbouwend op de ervaring die werd opgedaan met het project Bedrijfsconsortium Lokaal e-government, werd gekozen voor vijf concrete cases rond informatiekwaliteit, informatieveiligheid en informatiearchitectuur. Het betreft: 1. Brokers voor interbestuurlijke gegevensuitwisseling 2. Single Sign On en andere beveiligingsissues 3. Datawarehousing en beleidsinformatie 4. Digitale kluizen of PIP s 5. Web 2.0-technologie voor data-valorisatie Naarmate het project vorderde, groeide de behoefte aan extra expertise en eind 2011 werd het Business Intelligence Competence Centre (BICC) van Thomas More ingezet. Omdat het BICC een onafhankelijk onderzoekend en dienstenverlenend kenniscentrum is rond Informatiemanagement in het algemeen en Business Intelligence (BI) in het bijzonder en omdat het BICC op ervaring kan bogen in BI-maturiteitsonderzoeken zowel bij KMO s als bij lokale overheden, bleek het BICC de geschikte partner om de derde case Datawarehousing en beleidsinformatie uit te werken. De uitwerking van deze case verliep via verschillende acties en in verschillende stappen die we in de chronologie van voorliggend verslag willen respecteren: 1. Het informatiebeheer en beleid van lokale overheden werd in kaart gebracht en tijdens verschillende seminaries van het BICC werden er presentaties gegeven om het belang van een gedegen informatiebeheer bij lokale overheden onder de aandacht te brengen. Ook trad het BICC op als facilitator van de communicatie tussen ICT-bedrijven en lokale overheden zodat vraag en aanbod beter op elkaar konden worden afgestemd. 3

2. Tijdens een eerste Proof of Concept (PoC) werd een gemeenschappelijk BIplatform voor diverse lokale overheden ontwikkeld. 3. Tijdens een tweede Proof of Concept (PoC) werd een gemeenschappelijke semantiek voor overheidsinformatie uitgeprobeerd: de OSLO-standaard. Deze werd door het BICC in een pilootproject rond gegevensuitwisseling door verschillende leveranciers uitgetest. 4. Op basis van de bevindingen uit de voorgaande stappen werden er vervolgprojecten opgestart bij diverse leveranciers die erop gericht zijn de automatisering van beleidsinformatie en managementrapportering bij lokale overheden te optimaliseren. Om voorliggend verslag te besluiten, zullen we deze oplijsten en enkele best practices formuleren voor alle stakeholders: zowel bedrijven (vendors en consultants) als overheden. Alvorens de hierboven geschetste stappen nader onder de loep te nemen, willen we er op wijzen dat dit verslag niet het gehele 3 x I -project beschrijft (2009-2013), maar slechts de uitwerking van de derde case waarvoor het BICC de eindverantwoordelijke was (2012-2013). 4

Onderzoek en dienstverlening van het BICC voor 3 x I 16/02/2012 CCSP - benchmark Aalter overleg Lessius/CORVE/CCSP (Aalter,Gent,Diksmuide,Lokeren,Maaseik,Maldegem,Menen,Mol,Zedelgem ) Voordracht Hans Tubbax: Wat is BI? Wat is SaaS BI? Hoe inzetten bij lokale besturen? Analyseren van mogelijke domeinen voor Benchmarking tussen gemeenten. Kennisdeling over BI naar gemeenten toe. Gedachtewisseling met Corvé over welke interessante data zij beschikken 24/04/2012 Stuurgroep bijeenkomst Walburg Kasteel st niklaas Overleg met andere 3xI partners over stand van zaken, samenwerkings verbanden bespreken ivm SAAS BI platform voor Benchmarking Met Athena is de dienstenverlenende vereniging Cipal een SaaS BI platform aan het bouwen voor hun leden lokale overheden. Eerste overleg Cipal over eventuele samenwerking andere partners, en data uitwisseling. 26/04/2012 Shopt-IT Affligem Voordracht Hans Tubbax:Business Inteligence in de cloud voor lokale besturen Overleg Cipal/Schaubroeck/Remmicom status BI bij Vendors. Contact met verschillende bedrijven/lokale besturen aanwezig op de 25/05/2012 Overleg OCMW Sint-Niklaas-Cipal: Sint-Niklaas aanleveren real case data voor het SaaS BI platform 27/06/2012 Consortium vergadering Walburg Kasteel st niklaas overleg met esri en Belgacom, Tijdens dit overleg werd afgetast in welke mate open-gis kon worden geïntegreed. Ook het uitrollen van de SaaS BI oplossing op het Belgacom cloud platform kwam ter sprake 22/08/2012 CORVE Coördinatiecel Vlaams e-government Brussel Overleg in welke mate data, die werd beheerd door Corve, mee kon worden genomen in het het SaaS Bi verhaal. Hoe Corve mee in de samenwerking kon stappen 20/09/2012 ICT-inspiratiedagen/Confenis Gent voordracht Hans Tubbax: Stimuleren van managementrapportering. De rol van het BICC 26/09/2012 Gebruikersgroep stadhuis st niklaas tussenstand POC 1,0 12/12/2012 Gebruikersgroep Sint Niklaas Walburg Kasteel st niklaas stand van zaken POC1,0 6/02/2013 Consortium vergadering stadhuis lokeren conclusie POC 1,0 oproep POC 2,0; overleg schaubroeck, cipal, remmicom voor integreren van hun data mbv OSLO op athena platform 9/02/2013 Overleg Cipal: poc 2,0 Geel Overleg over: - aanleveren van data - inladen in athena platform - structuur van athena platform 27/03/2013 Consortium vergadering stadhuis lokeren Voordracht Hans Tubbax: Samen innoveren om meer te bereiken 9/04/2013 BI competence Forum Amsterdam networking event met oa. Pentaho, tableau, Oracle. Voordracht Cipal: BI bij lokale overheden 23/04/2013 IIBA: Business Analysis for Business Intelligence Brussel Hoe behoeften bepalen en oplossingen aanbevelen voor business intelligence. BI brengt verandering teweeg in de organisatie en de manier van werken/denken van de meewerkers. 25/04/2013 Shopt-IT Antwerpen Netwerking event. Overleg met stakeholders in het 3xI project en met de aanwezige dienstenleveranciers 14/05/2013 3xI Studiedag Tervuren "betere afspraken maken tijdens de offertefase en hoe een innovatieve project methodologie (iteratief werken) kan worden verzoend met goede formele afspraken." Voordracht Hans Tubbax: 3xI gaat verbintenissen aan 15/05/2013 Cornet meeting Duitsland Dirk Pauwels Duitsland 31/05/2013 OSLO staten generaal voordracht Hans Tubbax: OSLO de geboorte van een standaard 14/06/2013 Open data dag Brussel voordracht Hans Tubbax: Apps for Flanders - de race naar de top 5

Lijst van afkortingen en verklarende woordenlijst BBC: Beleids- en beheerscyclus, een geïntegreerd instrumentarium voor lokale overheden (gemeenten, provincies en OCMW s) om hun beleid te plannen, de financiële vertaling daarvan te maken (budgetteren), te bewaken en te registreren (boekhouding) en om over het beleid te rapporteren en het te evalueren. BI: Business Intelligence: geheel van competenties om de juiste en gewenste informatie te filteren uit de vele gegevens die in een bedrijf omgaan en om deze informatie te visualiseren en communiceren op een klare en heldere manier. Broker: software die data van applicaties ontvangt, omzet en doorgeeft naar andere applicaties. CRAB: Centraal Referentieadressenbestand. CRM: Customers Relations Management. Het in kaart brengen van alle contacten met stakeholders en externen. CSV: Een komma gescheiden bestand, of CSV-bestand, bestaat enkel uit tekstgegevens, waarbij de waarden worden gescheiden door komma's, en regels door het nieuweregelteken. Dashboard: een makkelijk te lezen, vaak op één pagina, grafische presentatie van de huidige status (momentopname) en historische trends van de belangrijke prestatie-indicatoren van een organisatie. Denormalisatie: het intentioneel gedeeltelijk terugdraaien van de normalisatie van een gegevensmodel. Operationele databanken worden over het algemeen genormaliseerd om spaarzaam om te gaan met opslagruimte en redundantie te vermijden. Voor analytische databanken, waar veel historische gegevens zijn opgeslagen, is de snelheid van de bevraging het belangrijkste. ERD: Entity Relationship Diagram ERP: Enterprise Resource Planning ETL: Extract Tranform Load is een groep technologieën die veelal gebruikt worden bij de koppeling tussen systemen, waarbij er gestreefd wordt naar een minimale technische en semantische koppeling. GRB: Het Grootschalig Referentie Bestand is een geografisch informatiesysteem dat dient als topografische referentie voor Vlaanderen. GUI: Graphical User Interface 6

ISA Programma: Programma van de Europese Commissie dat elektronische samenwerking tussen overheidsdiensten stimuleert en grensoverschrijdende en/of cross-sectorale transacties faciliteert. KBO: Kruispuntbank van Ondernemingen is een gegevensbank aangemaakt door en in beheer van de FOD Economie, K.M.O., Middenstand en Energie waarin de identificatiegegevens van ondernemingen zijn opgenomen. Kettle: het data integratie-platform van Pentaho dat bestaat uit een ETL engine en een GUI tool waarmee de gebruiker data-integratie-jobs en transformaties kan definiëren. Mapping: de identiteit van velden uit twee toepassingen op elkaar afstemmen. Middleware: de laag tussen de toepassingen en het communicatie- en besturingssysteem. Midoffice: verzameling van middleware. SaaS: Software-as-a-Service: software die als een onlinedienst wordt aangeboden. De klant hoeft de software niet aan te schaffen, maar sluit bijvoorbeeld een contract per maand per gebruiker, eventueel in combinatie met andere parameters. De SaaS-aanbieder zorgt voor installatie, onderhoud en beheer, de gebruiker benadert de software over het internet bij de SaaS-aanbieder. Performance management: de verzameling van processen, methodes, toepassingen en technologieën die een organisatie gebruikt om haar prestaties op te volgen, te beheren en te sturen. SOAP: Simple Object Access Protocol, een computerprotocol dat wordt gebruikt voor communicatie tussen verschillende componenten met behulp van XML berichten. SQL-server: een relationeel databasebeheersysteem ontwikkeld door Microsoft. SSIS: SQL-server integration services is het data integratie platform van Microsoft dat wordt meegeleverd met SQL-server. Staging area: een deel van een databank waar data tijdelijk worden opgeslagen, georganiseerd en opgeschoond voordat ze worden opgeladen in het datawarehouse. Tag: een voor de lezer onzichtbare code in een digitaal document die meta-informatie bevat over de data. W3C: Het World Wide Web Consortium is een internationale gemeenschap van ledenorganisaties, medewerkers en het publiek, die samen werken aan de ontwikkeling van webstandaarden. XML: taal waarin data worden doorgegeven. XSD: syntax van de taal waarin data worden doorgegeven. 7

1. Datawarehousing en beleidsinformatie 1.1. Het veld in kaart gebracht. Jomme Dockx 2.0. Vlaanderen telt 308 steden en gemeenten. Veelal gaat het om kleinere gemeenten die het met minder middelen moeten stellen dan grote steden, ook voor ICT. Toch moeten ook kleinere lokale overheden beschikken over veel informatie om naar behoren te kunnen functioneren en om de dienstverlening voor klanten burgers, bedrijven en verenigingen te kunnen verzekeren. Maar de grondstoffen voor deze informatie, de data, zijn vaak moeilijk vindbaar en moeilijk te ontginnen. Soms zijn de data niet lokaal aanwezig, maar worden ze beheerd door hogere overheden. Of zijn ze verspreid aanwezig over verschillende diensten en niveaus, beheerd en verwerkt in diverse systemen, applicaties en bestanden... Omdat data explosief blijven toenemen en de nood aan performante en klantvriendelijke informatie daarmee gelijke tred houdt, groeit ook bij lokale overheden de nood aan een transparant, organisatiebreed en applicatieoverstijgend performant informatiebeleid en beheer, aan business intelligence (BI). Uit een onderzoek (2013) van het BICC naar het informatiebeleid en beheer van lokale besturen 1 blijkt echter dat hun ICT-beheer zich (naast hardware- en netwerkmanagement) vooral beperkt tot een al te versnipperd applicatiebeheer. Vele vragen naar informatie zijn echter dienst- en applicatieoverschrijdend. Bijvoorbeeld: Welke diensten leveren we aan senioren? Hoeveel bedrijven hebben verleden jaar onze gemeente verlaten? Hoeveel onbebouwde percelen zijn er op ons grondgebied? Enzoverder. Hoewel het hier om schijnbaar eenvoudige vragen gaat, kunnen vele openbare besturen ze slechts via onnodig zoekwerk en omwegen beantwoorden. Enerzijds zijn de nodige data moeilijk te ontginnen, anderzijds is het niet altijd duidelijk hoe de data moeten worden omgesmeed tot de gewenste informatie. Veruit de populairste applicatie bij lokale overheden om data te beheren, verwerken en informatie te rapporteren, is nog steeds Excel. Daaraan zijn echter zo blijkt uit het onderzoek manifeste nadelen verbonden: 1. De meeste data worden in Excel manueel ingevoerd. Dat is tijdrovend en laat fouten insluipen waardoor de betrouwbaarheid van de rapportering ondermijnd wordt. 2. Bij het gebruik van Excel is er ook een significante tendens om veel verschillende extracten te gebruiken waardoor dezelfde data tot verschillende, tegensprekelijke en dus onbetrouwbare informatie kunnen leiden. Een minderheid van de besturen, vooral bij steden, die aangaven Access te gebruiken of een ERP-systeem dat toelaat alle administratieve en logistieke processen te verbinden en 1 Thomas Van Gorp, Dries Van Nieuwenhuyse, Business Intelligence Maturiteit bij Steden en Gemeenten, 2013, niet gepubliceerd. 8

centraal te beheren, hadden minder twijfels over de betrouwbaarheid van de verkregen informatie, ervaarden rapportering minder tijdrovend, voerden de data minder manueel in en gebruikten minder extracten. De behoefte aan een goed informatiebeleid en beheer blijkt overduidelijk uit quickscans van het BICC. Maar liefst 84% van de respondenten geeft aan dit belangrijk te vinden. Maar tegelijkertijd geeft eenzelfde meerderheid aan daarvoor geen tijd of middelen te hebben. Vaak is men zelfs bij het ICT-team en op managementsniveau niet bewust van de uitdagingen en valkuilen. Het gevolg is dat slechts 11 % op het vlak van informatiebeheer een maturiteitsscore (>3) haalt die wijst op een duurzaam beleid, niet verrassend treffen we hier de steden en grotere gemeenten aan. Maar 75% haalt een lage maturiteitsscore (<2) of staat zelfs nog helemaal nergens. Kortom, het vervangen van een papieren administratie door een administratie gebaseerd op ICT heeft niet onmiddellijk en automatisch gezorgd voor meer efficiëntie, transparantie, gebruiksvriendelijkheid en betrouwbaarheid. In onderstaand citaat is Karel Van Eetvelt, de bestuurder van UNIZO, misschien zelfs te optimistisch als hij stelt dat administratieve inefficiëntie zoals beschreven in de BRT-serie De Collega s niet meer representatief is voor het hedendaagse e-government (al geeft hij toe dat het beter kan). De papieren dossiers mogen dan wel weg zijn, maar de komst van ICT bracht ook de komst van data-overkill en informatiewanbeheer met zich mee. Wie herinnert zich niet de taferelen uit de beroemde BRT-serie De Collega s? Een eindeloos geschuif van papieren dossiers, manueel aan- of ingevuld met balpen of potlood en daarna (verticaal?) geklasseerd door de onvolprezen Jomme Dockx. Gelukkig is De Collega s, hoewel nog steeds uiterst vermakelijk, niet meer representatief voor de werking van de overheid anno 2010. De Vlaamse overheid beschikt over een modern korps van gedreven en bekwame ambtenaren met steeds meer en steeds betere toegang tot moderne informatica- en communicatiemiddelen. Maar alles kan beter. Internationale vergelijkingen tonen het aan, de efficiëntie van de Vlaamse overheid, inclusief de lokale besturen, staat nog niet aan de top. 2 Hoe de efficiëntie van e-government en het informatiebeheer van lokale besturen kan worden verbeterd, vormt de verdere inzet van deze studie. 2 Karel Van Eetvelt, Een open en transparante overheid met behulp van ICT en internet: winst voor burgers, bedrijven en overheid, lezing op een VIA-rondetafel i-vlaanderen, Vlaamse overheid interactief, 17 december 2010. 9

1.2. De Beleids- en Beheerscyclus (2014). Nieuwe uitdagingen, nieuwe kansen. Op 25 juni 2010 vaardigde de Vlaamse Regering een besluit uit om de Beleids- en Beheerscyclus (BBC) van gemeenten, OCMW s en provincies beter te kunnen stroomlijnen en controleren. De belangrijkste vernieuwing die de BBC met zich meebrengt betreft de planning die van korte termijn (één jaar) naar lange termijn evolueert (zes jaar). Dit heeft ingrijpende gevolgen voor de manier waarop gemeenten, OCMW s en provincies hun beleid voorbereiden, budgetteren, uitvoeren, opvolgen en evalueren. Het betekent vooral dat ze bewuster zullen moeten omgaan met hun informatiebeleid en beheer en dat ze strategieën zullen moeten uittekenen hoe ze zichzelf willen verbeteren en welke budgettaire ruimte ze hiervoor willen vrij maken. In 2014 gaan de regels van de BBC in voege. Deze uitdaging biedt aan lokale overheden kansen om hun huidige, vaak falende informatiebeleid te evalueren en om manieren te zoeken om het informatiebeheer betrouwbaarder, sneller, transparanter en performanter te maken. Of met andere woorden: om BI te implementeren. Om dat proces te faciliteren, testte het BICC enkele onderzoek pistes en Proofs of Concept uit, die we in de volgende hoofdstukken zullen bespreken. Een eerste Proof of Concept (PoC 1) had betrekking op het introduceren van een BI-platform voor lokale overheden via SaaS-technologie en wordt besproken in hoofdstuk 2. Een tweede Proof of Concept (PoC 2) onderzocht de implementatiemogelijkheden van de OSLO-standaard die V-ICT-OR ontwikkelde. Voor het OSLO-project dat een gemeenschappelijke semantische standaard voor overheidsinformatie vastlegde, ontwikkelde het BICC een testplatform dat in hoofdstuk 3 wordt beschreven. Maar om dit eerste hoofdstuk te besluiten, willen we nog even ingaan op de oorspronkelijke case Datawarehousing en beleidsinformatie, zoals deze in de projectaanvraag voor het IWT werd beschreven, en de dienstverlening van het BICC hierrond. 10

1.3. Datawarehousing en informatiebeheer. Hoe kunnen we gegevens opslaan zodat ze, anders dan in een traditionele en onoverzichtelijke database, efficiënt kunnen worden verwerkt tot bruikbare informatie en aanleiding kunnen geven tot performante beleidsbeslissingen? Dat is de centrale vraag van datawarehousing. De antwoorden op deze vraag zijn divers en hebben ook betrekking op verschillende systemen en applicaties die diverse ICT-leveranciers aanbieden. Enerzijds speelt het aanbod van ICT-bedrijven niet altijd in op concrete noden van lokale overheden omdat ze deze niet altijd kennen. Anderzijds zijn lokale overheden niet altijd op de hoogte van wat het meest beantwoordt aan hun noden (die ze vaak moeilijk kunnen articuleren). Het faciliteren van de communicatie tussen vraag en aanbod inzake ICToplossingen, behoort tot de missie van het BICC. Ook inzake datawarehousing werden tal van seminaries, workshops en andere samenkomsten georganiseerd waarbij bedrijven en overheden met elkaar in dialoog konden gaan. De onafhankelijke expertise van het BICC werd daarbij ingezet om tot de beste oplossingen te komen op maat van de behoeften van de lokale overheden. Hieronder volgt een overzicht van inzichten die het BICC op diverse samenkomsten deelde met stakeholders. 1.3.1. De datastortvloed. Geschiedenis en uitdagingen. Sinds de introductie van ICT zijn de hoeveelheden digitale data die we her en der opslaan en proberen te verwerken met een onvoorziene vaart toegenomen. Met elke introductie van nieuwe technologieën komen er nieuwe golven data bij. In deze data-tsunami kunnen we drie revoluties onderscheiden. a. De jaren tachtig. Transactionele en operationele data Met de introductie van de PC en de digitale netwerken hebben heel wat bedrijven (en overheden die ook als een soort bedrijf worden geleid) hun informatiestromen geautomatiseerd en bewaren ze de gegevens waarmee ze werken elektronisch, als data. Sinds de jaren 80 zijn de meeste processen systematisch geautomatiseerd en daarmee is ook de hoeveelheid opgeslagen data steeds meer gegroeid. De creatie/input van deze gegevens gebeurt over het algemeen nog steeds inhouse door een beperkte groep van mensen (medewerkers, leveranciers, eventueel klanten). Het handelt hier over gegevens die worden gegenereerd bij transacties die nodig zijn voor de operationele processen. (opstellen order, productie planning, logistiek, boekhouding, ) 11

b. Van de jaren negentig naar de 21 ste eeuw. Web 2.0 data Met de popularisering van het internet in de jaren negentig dienden zich nieuwe golven van data aan. Eerst was het internet het werkterrein van webmasters en web developers die statische websites maakten. Meer geavanceerde sites waren dynamische webapplicaties die als gebruikersinterface moesten dienen voor de bestaande bedrijfsapplicaties. De golf groeide pas uit tot een echte tsunami van data met de introductie van het web 2.0. Plots kon iedereen die toegang had tot het internet zelf content/data genereren. Met de opkomst van social media rond de milleniumwisseling werden er plots zoveel data gegenereerd dat er een nieuwe term werd geboren, Big Data. c. Vandaag en de toekomst. The Internet of Things en Datawarehouses Met de opkomst van sensoren die met internet zijn verbonden in auto s, smartphones, horloges, deuren, speelgoed, rookmelders, sportschoenen, lichtknoppen, thermostaten en zoveel meer stromen er straks meer data tussen onze machines, apparaatjes en gadgets en hun servers dan ooit tevoren. In dit Internet of Things zullen de vorige golven data verbleken tot kleine rimpels en zal men niet meer over Big Data maar over Huge Data spreken. Om die overvloed aan data te kunnen beheren, volstaan traditionele databases niet langer. Er is nood aan datawarehouses: krachtige, relationele databases die draaien op centrale, dedicated servers met een structuur die volledig is toegespitst op het snel vinden van de juiste informatie in het juiste formaat. Grote bedrijven (bpost, Belgacom...) en overheden investeerden al in geïntegreerde applicaties die meerdere processen ondersteunen en in grote, relationele datases als ERP, CRM... Maar tegelijkertijd draaien er gemiddeld 600 applicaties op hun systemen die onafhankelijk van elkaar data opslaan en verwerken. Kleinere bedrijven en overheden daarentegen hebben vaak nog niet geïnvesteerd in geïntegreerde applicaties of datawarehouses. Daar worden data lokaal opgeslagen en per mail of over het netwerk gekopieerd naar andere plaatsen waardoor verschillende versies en extracten van dataverwerking (meestal in Excel) hun eigen leven gaan leiden. Bovendien worden die data meestal manueel ingevoerd, gecombineerd, opgepoetst en samengevat. Dat is niet alleen erg arbeidsintensief het beslaat maar liefst 80% van de tijd van de dataverwerking maar ook erg foutgevoelig. Zoals eerder geschetst (1.1. Het veld in kaart gebracht. Jomme Dockx 2.0.), groeit het bewustzijn bij kleinere bedrijven en overheden dat er een ander plan van aanpak nodig is om data te verwerken zodat er geen foute beleidsbeslissingen worden genomen of cliënten verkeerd geïnformeerd. Vele ICT-firma s lijken hierbij te hulp te schieten. Zij brengen nieuwe tools op de markt die rechtstreeks op de data van de operationele systemen gaan rapporteren en dashboards bouwen. Waar deze manier van werken snel resultaat oplevert en aan bedrijven en overheden voldoende informatie geeft voor dagelijkse beslissingen, zijn er toch heel wat 12

nadelen aan verbonden aan deze operationele databases en systemen. We zullen deze hieronder opsommen. 1.3.2. Nadelen van operationele systemen en de nood aan datawarehousing a. De datakwaliteit is niet verzekerd Operationele systemen willen dataverwerkingsprocessen optimaal ondersteunen, zonder onnodige vertragingen. Maar het inbrengen van data blijft mensenwerk. Dat zorgt voor fouten en het invoeren van dubbele gegevens (een naam wordt als Jansen én als Janssen ingevoerd, bijvoorbeeld). Bovendien hebben verschillende mensen verschillende gewoontes waardoor dezelfde applicaties telkens anders gebruikt worden. Tenslotte is er vaak kunsten vliegwerk ( escape ) nodig om bij het ontbreken van data het verwerkingsproces toch te laten doorgaan, zij het amper optimaal. Om deze nadelen te verhelpen, kan datawarehousing een uitkomst bieden. b. De data zijn niet beschikbaar op lange termijn Operationele systemen beheren slechts data van een proces op een gegeven ogenblik. Bijvoorbeeld: voor het uitreiken van een identiteitskaart heeft een overheid het huidige adres van een burger nodig. Waar die burger vorig jaar woonde, is niet belangrijk voor de verwerking en wordt niet bijgehouden. Maar voor informatiegaring op langere termijn en om evoluties te analyseren, kan dergelijke informatie wel belangrijk zijn. Om data op langere termijn te kunnen bewaren en analyseren, is datawarehousing een uitkomst. c. Afwezigheid van externe data Onvoorziene, externe factoren hebben heel wat invloed op zaken die lokale overheden liever meer beheersbaar zien. Zo kan bijvoorbeeld het weer een invloed hebben op het aantal bezoekers aan evenementen of op ongevallen die in een stad of gemeente gebeuren. Maar externe data als weersomstandigheden worden veelal niet opgeslagen in de operationele databanken waarvan lokale overheden gebruik maken. Om die data toch efficiënt op te kunnen slaan, verbanden bloot te leggen en informatie te genereren die rekening houdt met externe factoren, biedt datawarehousing een oplossing. d. Operationele versus analytische databanken of datawarehouses We kunnen twee types databanken onderscheiden, elk met een andere functie én een andere architectuur: 1. In operationele databanken worden continu data opgeslagen, gewijzigd, verwijderd en geraadpleegd. Operationele systemen behandelen één datarecord per keer. Bijvoorbeeld, als een burger een misdrijf aangeeft, gaat het om één persoon, die op één moment, één melding laat rapporteren. Als een lokale overheid echter wil analyseren hoeveel misdrijven er over een bepaalde tijd zijn gerapporteerd en 13

hoeveel personen er hierbij waren betrokken, dan moet de hele databank tegelijkertijd kunnen worden overzien en geraadpleegd. Operationele databanken kunnen moeilijk met deze vraag om. De machines waarop ze zijn geconfigureerd worden door analytische vragen zodanig belast dat het operationele proces aanzienlijke vertraging oploopt of zelfs mank loopt. 2. Analytische databanken of datawarehouses die alle historische data bevatten, kunnen wel om met analytische vragen. De data erin kunnen wel enkel worden geraadpleegd, niet bewerkt. Maar het voordeel is dat in een datawarehouse alle data die nodig zijn om beslissingen te nemen centraal worden opgeslagen in een toegankelijk formaat dat zowel rapportering als verdere analyse door beleidsmakers mogelijk maakt. Datawarehousing maakt het zowel mogelijk om op korte termijn performante beslissingen te nemen als om op langere termijn het overzicht te bewaren. Operationele databank Creëren, lezen, aanpassen, verwijderen Beperkt aantal gegevens per transactie Live gegevens Ondersteunt een proces Datawarehouse Alleen lezen Miljoenen gegevens per vraag Historische gegevens Dient om vragen te beantwoorden 1.3.3. Datawarehousing: wat het is en hoe het werkt In 1992 definieerde Bill Inmom een datawarehouse als volgt: A data warehouse is a subjectoriented, integrated, time-variant, non-volatile collection of data in support of management s decision-making process. 3 De verschillende aspecten van deze definitie verdienen verduidelijking: subject-oriented (onderwerp-georiënteerd) De structuur van een datawarehouse is geoptimaliseerd om data vanuit verschillende invalshoeken te kunnen bekijken. Zo kan men gaan kijken hoeveel meldingen er zijn per buurt en per leeftijdsgroep of per jaar en per familie. integrated (geïntegreerd) Een datawarehouse bevat alle informatie die nodig is om beslissingen te nemen. Deze data zijn verzameld uit verschillende interne en externe data bronnen. De data zijn daar zodanig zuiver en combineerbaar dat verschillende vragen kunnen worden beantwoord. 3 William H. Inmon. Building the Data Warehouse. QED Information Sciences, Wellesley, MA, 1992. 14

time-variant (tijdsgebonden) Een datawarehouse is het geheugen van het bedrijf. Historische data en wijzigingen in data worden zodanig opgeslagen dat zowel het verleden kan worden gereconstrueerd als evoluties in kaart gebracht en de toekomst geanticipeerd. non-volatile (persistent) Omdat de data in een datawarehouse enkel kunnen worden gelezen (niet bewerkt) en enkel worden aangevuld met kopies van operationele data, zijn deze data onveranderlijk. Dat is logisch omdat het doel van een datawarehouse er net in bestaat dat je kan analyseren wat er is gebeurd. We kunnen er nog een aspect aan toevoegen. Waar operationele databanken genormaliseerd werken, werken datawarehouses gedenormaliseerd. Operationele databanken dienen om snel transacties te verwerken. Een van de belangrijkste concepten die daarbij wordt gehanteerd om de data consistent te houden en redundantie te vermijden is het normaliseren van de databank. Het gevolg van dergelijke normalisatie is dat: - elk gegeven maar 1 keer mag worden opgeslagen en alle afgeleide gegevens moeten worden berekend tijdens de query (bijv. dat 28/10/2013 een maandag is en dat die valt in de maand oktober); - de gegevens verspreid zitten over een groot aantal tabellen waarvan de structuur niet altijd overzichtelijk en duidelijk is; - de tabellen via sleutelvelden met elkaar in verband worden gebracht. Deze relaties moeten bij elke vraag opnieuw worden berekend, hetgeen rekenkracht en tijd kost. In de datawarehouse wordt alles geoptimaliseerd om heel snel de juiste informatie op een begrijpbare manier uit een grote dataset te kunnen halen. Om zoveel mogelijk berekeningen tijdens de bevraging te gaan vermijden worden de data in een datawarehouse - opgeslagen in een zogenaamde sterstructuur; - gedenormaliseerd. 15

a. Sterstructuur In een sterschema, zijn de gegevens verdeeld in: - feiten: over het algemeen numerieke transactiegegevens waarmee gerekend wordt (tellen, optellen, ratio s berekenen, gemiddelden, ) - dimensies: hierin zit de referentie-informatie die context geeft aan de feiten. Bijvoorbeeld, een verkooptransactie kan worden opgedeeld in feiten, zoals het aantal bestelde producten en de prijs die voor de producten, en in dimensies zoals orderdatum, naam van de klant, productnummer, verschepings- en factuurlocatie, de verkoper verantwoordelijk voor de bestelling, Een belangrijk voordeel van een dergelijk sterschema is - dat het voor de zakelijke gebruiker makkelijker te begrijpen en te gebruiken is; - dat het ophalen van data uit de datawarehouse zeer snel gaat omdat er maar een beperkt aantal relaties moet worden gelegd. 16

b. Denormalisatie Een sterstructuur brengt op zich reeds voor een deel denormalisatie met zich mee. Zo worden gegevens die in een operationeel systeem verspreid zaten over verschillende tabellen, nu in één tabel samengebracht waardoor herhaling van dezelfde gegevens een noodzaak wordt. Bepaalde gegevens worden ook op verschillende manieren opgeslagen om tijdswinst te boeken tijdens het opvragen van informatie. Het meest typische voorbeeld zijn datums. In plaats van een datum enkel en alleen als datum (het gegevenstype) op te gaan slaan, wordt een datum volledig ontrafeld in al zijn elementen. 28/10/2013 28 10 2013 Oktober maandag 201310 Q4 Week 44 Werkdag. Dergelijke opsplitsing heeft als voordeel dat de omrekening van de datum naar de relevante gegevens niet tijdens de opvraging van informatie moet gebeuren, maar dat deze al gebeurd is bij de opslag van de datum. Hierdoor kan men veel sneller de antwoorden vinden op vragen zoals: - Wat is de gemiddelde omzet op een maandag? - Vergelijk het aantal bezoekers van Q4 met Q3. - Hoeveel aantal stuks hebben we meer verkocht in oktober 2013 t.o.v. oktober 2012? 1.3.4. Voordelen van een datawarehouse Operationele databanken en datawarehouses verschillen technisch nauwelijks van elkaar. Buiten de structuur handelt het in beide gevallen over: - databanken die worden opgeslagen in een relationele database; - een aantal tabellen met gegevens die in records worden georganiseerd; - relaties tussen de tabellen die met sleutels worden verbonden. Vaak wordt rapportering dan ook rechtstreeks gebouwd op de operationele databank. In sommige gevallen is daar niets mis mee, maar een datawarehouse heeft toch verschillende voordelen die we hieronder op een rijtje zullen zetten. 17

a. Eenheid van waarheid Alle data staan op één plaats. Voor herhaalde terugkerende vragen wordt er vermeden dat er telkens opnieuw complexe SQL queries worden uitgevoerd, deze manueel gecorrigeerd worden en dan per mail naar jan en alleman doorgezonden. Ook vergt het veel minder moeite om bepaalde bedrijfsregels op één plaats toe te passen zodat de kwaliteit van de data beter is gegarandeerd. b. Overzichtelijke structuur Het doel van een datawarehouse is het beantwoorden van bedrijfsvragen. De structuur ervan wordt dan ook helemaal afgestemd op bedrijfsnoden, zodat ook mensen met een beperkte technische bagage ermee aan de slag kunnen. c. Scheiding van operationeel systeem en BI systeem. Scheiding van de applicatie-database en de datawarehouse zorgt er voor dat de business intelligence-oplossing schaalbaar is, beter gedocumenteerd en beter beheerbaar. Hierdoor kunnen beleidsvragen veel efficiënter worden beantwoord. Ook bij aankoop van nieuwe applicaties blijft een organisatie beschikken over de historiek van de data. Door de scheiding van het operationeel systeem en het BI systeem, is het noodzakelijk om data van het proces-georiënteerde platform naar het onderwerp-georiënteerde platform te kopiëren. Dit geautomatiseerde proces behelst het extraheren, transformeren en laden van de data en heet ETL (Extract Transform Load). We zullen deze drie facetten hieronder bespreken. 18

Extractie Extractie behelst het verzamelen van ruwe gegevens uit bronsystemen en het voorlopig opslaan in een speciale staging-omgeving. Om de juiste data te extraheren, moet er een duidelijk beeld zijn van de beschikbare bronsystemen en een goede definitie van de overkoepelende gegevens. Het gebruik van authentieke bronnen (CRAB, KBO, GRB) is hier zeker een pluspunt omdat deze gegevens reeds op een hoog niveau gecontroleerd en opgeschoond zijn. In een Logical Data Map wordt er gedocumenteerd van waar en naar waar welke gegevens komen/gaan. Ook de wijze van opslag in het bronsysteem moet goed gedocumenteerd zijn. Zo kunnen bijv. datumwaarden problemen geven omdat de schrijfwijze niet noodzakelijk overal gelijk is; zo is de schrijfwijze van een datum in Europa anders dan in de Verenigde Staten. Daarom is 01-02-2012 (1 febr) niet noodzakelijk gelijk aan 01-02-2012 (2 jan). De extractie zelf moet zo snel mogelijk gebeuren, om te vermijden dat het operationeel proces niet wordt verstoord en dat er geen wijzigingen gebeuren tijdens het extract proces. Verder moet er een eerste kwaliteitscontrole op de gegevens uitgevoerd kunnen worden om anomalieën te detecteren en ongewenste gegevens te verwijderen uit de extracten. Ook moeten fouten gerapporteerd kunnen worden zodat deze in het bronsysteem kunnen rechtgezet worden. Transformatie Transformatie behelst het wijzigen van gegevens, zodat deze kunnen worden gebruikt voor het beoogde doel (verbetering van de kwaliteit, formaat, samenvoegen,...) Hierbij worden de data: - geïntegreerd: zodat de overeenkomstige data uit verschillende bronnen samen wordt gezet; - opgeschoond: het probleem met ontbrekende data en dubbele data wordt opgelost; - geaggregeerd: een datawarehouse moet niet hetzelfde detailniveau hebben als een operationeel systeem; - omgezet: hier denken we vooral aan wisselkoersberekeningen of het berekenen van bepaalde gegevens uit andere velden. (cf. supra datums) 19

Laden De dimensies en feiten van de datawarehouse worden bijgewerkt en aangevuld met de nieuwe data. Naargelang de eisen van de organisatie, kan er voor een verschillende laadstrategie gekozen worden. Dit proces gaat op regelmatige strategisch gekozen momenten (dagelijks/wekelijks) de bestaande informatie in batch overschrijven met aangepaste, bijgewerkte data. Meer complexe systemen kunnen een geschiedenis bijhouden en een spoor auditten van alle veranderingen van de data, die geladen waren in het datawarehouse. 1.3.5. Voorlopige conclusies en nood aan verder onderzoek Vanuit de hierboven geschetste voordelen groeide de behoefte om datawarehousing in te zetten bij Vlaamse lokale overheden. Het BICC onderzocht daarbij of een lokale overheid dezelfde noden heeft om goed gerund te kunnen worden als een bedrijf. Ook werd onderzocht welke BI-oplossingen het best beantwoorden aan de specifieke noden van lokale overheden. In een eerste Proof of Concept, dat we in het volgende hoofdstuk beschrijven, onderzocht het BICC de mogelijkheid van een gebruiksvriendelijk en performant gemeenschappelijk BIplatform voor lokale overheden op basis van SaaS-technologie. Omdat de performantie van het getoetste gemeenschappelijke BI-platform echter te wensen overliet, koos het BICC ervoor om een andere piste te proberen en een tweede Proof of Concept te ontwikkelen die in het derde hoofdstuk wordt beschreven. Hierin werd onderzocht of het mogelijk is om een gemeenschappelijke taal of Esperanto voor data te ontwikkelen die door alle applicaties kan worden begrepen. Meer concreet werd de inzetbaarheid van de OSLO-standaarden voor lokale overheden via een concrete casus getest. Omdat deze testcasus naast vele pluspunten ook enkele pijnpunten aan het licht bracht, zullen we in een vierde en besluitende hoofdstuk aangeven wat de beste BIoplossingen voor lokale overheden zijn. 20

2. PoC 1. Naar een gemeenschappelijk BI-platform voor lokale overheden. 2.1. Inleiding. Voordelen van een gemeenschappelijk BI-platform Datawarehouse concepten en tools werden tot nog toe zelden op de realiteit van Vlaamse lokale besturen toegepast. Daarom nam het BICC zich voor een Proof of Concept (PoC) te ontwikkelen met als hoofddoelstelling een gebruiksvriendelijk en kostenefficiënt aanbod te formuleren rond het gebruiken van deze concepten en tools en het inzetten van een BIplatform bij lokale overheden. Dat komt ook het opmaken van de vele beleidsplannen waar Vlaamse lokale besturen toe verplicht zijn, ten goede en het faciliteert de ontwikkeling van het Vlaamse (lokale) e-government. In plaats van individuele datawarehouses te ontwikkelen voor elke lokale overheid afzonderlijk, kozen we ervoor om op zoek te gaan naar een gemeenschappelijk BI-platform. Lokale overheden worden immers allemaal met gelijkaardige beleidsvragen geconfronteerd. Ondanks kleine nuanceverschillen in de vragen, is het kostenefficiënter om een gemeenschappelijk informatieplatform te bouwen waarop iedere overheid zijn eigen beleidsinformatie kan raadplegen, met respect voor de privacy van elke burger. Naast de kostenefficiëntie kunnen we nog andere voordelen opsommen: - benchmarking tussen overheden wordt mogelijk; - aggregatie op een hoger niveau (arrondissementen, provincie, ) is veel eenvoudiger; - veiligheid en privacy verzekeren op één gemeenschappelijk systeem is moeilijker, maar ook veel zekerder; - schaalvoordelen. De ontwikkeling van een gemeenschappelijk platform waarvan alle lokale overheden kunnen gebruik maken, werd mogelijk gemaakt door de grote veranderingen in de software-industrie onder invloed van trends zoals cloud computing, software-as-a-service (SaaS) en nieuwe mobiele technologieën. De SaaS-trend om traditionele geïnstalleerde software te vervangen door applicaties die via het internet worden aangeboden, wordt versterkt door de kosteffectiviteit en de verlaging van de IT-complexiteit. Het implementeren van een SaaS BI-systeem zorgt voor meer flexibiliteit, schaalbaarheid en toegankelijkheid (overal en altijd) tegen een aanzienlijk lagere kostprijs. Een betere en snellere toegang tot beleidsinformatie geeft de lokale overheid de mogelijkheid om sneller betere strategische beslissingen te nemen en zich meer te concentreren op de kerntaken. 21

2.2. SaaS BI voor lokale overheden. Beschrijving van PoC 1. De pilootstudie die het BICC opzette rond SaaS Business Intelligence voor lokale besturen wilde automatische rapporteringen tot stand brengen met indicatoren die relevant zijn voor beleidsmakers. Zo krijgen beleidsmakers de mogelijkheid om beslissingen te nemen die steunen op reële feiten i.p.v. op veronderstellingen. Met deze pilootstudie gingen we na of een gemeenschappelijk platform, technisch en functioneel, haalbaar is. Het proces dat op een dergelijk platform draait omvat volgende elementen (rood) en activiteiten (blauw): 2.2.1. Analyse Op basis van interviews met stakeholders werden gewenste rapporten gedefinieerd. Voor deze studie werd contact opgenomen met het Common Citizen Service Platform (CCSP), een netwerk van lokale besturen is die onderling oplossingen voor hun Customers Relations Management (CRM) wilden uitwisselen om zo efficiënter te werk te gaan. In samenspraak met CCSP en enkele vertegenwoordigers van de Vlaamse overheid werd beslist dat de rapportering rond Meldingen een interessante case zou zijn. Hierbij wilden ze: - een maandelijks rapport van de klachten en meldingen die een lokaal bestuur ontvangt, verkrijgen; - benchmarking hierover mogelijk maken over lokale besturen heen; - uit de maandelijks rapportering conclusies trekken om het beleid te sturen. Vervolgens werd een informatiematrix afgeleid waarin de link wordt gelegd tussen het gewenste rapport en de data die daartoe nodig zijn. Op basis hiervan kan men een conceptueel datamodel en sterschema voor de datawarehouse opstellen waarbij de nodige feiten en dimensie gegevens worden bepaald. 22

Om de transfer van data van de verschillende gemeenten naar de centrale datawarehouse zo transparant mogelijk te maken en de transformatie van de gegevens op de centrale server tot een minimum te beperken, werd een dataformaat opgesteld waarin de verschillende locale overheden hun data moesten aanleveren. Naast vormelijke en technische afspraken (XML of CSV, structuur van de datafile, protocol van de transfer, wanneer wordt de file doorgestuurd, ) moesten er ook inhoudelijke regels worden opgesteld. Wat moet er gebeuren met lege velden? Hoe wordt een datum doorgegeven? Omdat verschillende overheden met verschillende systemen werken, waren zij zelf verantwoordelijk om de gegevens (personeelsbezetting, meldingen, producten, documenten en diensten) in het opgelegde formaat uit hun operationele systemen te extraheren. 2.2.2. Bouw van het systeem Omdat de nadruk van PoC 1 lag op de technische en functionele haalbaarheid van een gemeenschappelijk informatieplatform, werd er gekozen voor het Microsoft BI platform op een SQL server. Deze keuze was pragmatisch omdat dit systeem en de personen met een goede kennis ervan onmiddellijk beschikbaar waren. De studie welk het meest geschikte platform is en welke bijhorende tools hiervoor best te gebruiken zijn, behoorde niet tot de scope van deze PoC. Van het conceptueel datamodel werd een technisch datamodel afgeleid waarvan feiten en dimensietabellen op een SQL-server werden gebouwd. 23

Bij de bouw van het Transformatie & Load script, gingen we ervan uit dat de gemeenten in staat zijn om de nodige data in het juiste gevraagde formaat aan te leveren. Dit script werd gemaakt in Microsoft SSIS (SQL server integration services) Om de datakwaliteit van de gegevens in de datawarehouse te garanderen moesten er op de binnenkomende gegevens verschillende kwaliteitscontroles worden uitgevoerd en extra wijzigingen aangebracht. Hiervoor worden enkele standaard technieken gebruikt. Met mapping zorgen we ervoor dat de nieuw geïmporteerde gegevens van feiten of dimensies worden gelinkt aan de bestaande gegevens die reeds in de datawarehouse zitten. Cleansing wordt gebruikt om ontbrekende informatie aan te vullen, dubbele records te dedupliceren en onbekende waarden aan te duiden. 24

Transforming wordt gebruikt om gegevens uit andere velden af te leiden. Zo kan men uit het rijksregisternummer ook de geboortedatum en het geslacht van de betrokken persoon bepalen. Bij het laden van de datawarehouse worden eerst de dimensies up to date gebracht waarna de nieuwe feiten worden geaggregeerd tot het juiste niveau en toegevoegd. Omdat alle beleidsmakers in de gemeenten beschikken over een ipad werd de rapportering gebouwd op het Microstrategy platform, omdat deze (op dat moment) een goede ondersteuning had voor publicaties van rapporten in de cloud. Naast de innovatieve dynamische rapportering, was ook de security en privacy makkelijk te implementeren. 2.2.3. Aftoetsing bij gemeentelijke overheden Nadat elk onderdeel individueel gebouwd en getest was, zijn we naar enkele gemeenten toegestapt om het hele traject (van operationele data naar rapport) uit te testen. Verschillende pilootgemeenten werden gevraagd om meerdere CSV-bestanden in een gestandaardiseerde vorm af te leveren. De data interface specificatie, nodig om een PoC te maken op basis van Meldingen bij de lokale overheid, werd naar verschillende gemeenten doorgestuurd met de vraag om eenmalig de data aan te leveren zoals gespecifieerd. Ondanks aandringen en de zeer bereidwillige medewerking van sommige gemeenten, bleek dat geen enkele gemeente de data exact kon aanleveren zoals gevraagd. Slechts 1 gemeente slaagde er in om een onvolledige CSV-file set af te leveren. De andere gemeenten konden niet aan de vraag voldoen omdat: - zij weinig kennis hadden van de operationele datastructuur; - niemand tijd had; - de data uit verschillende bronnen moesten komen waarvoor verschillende mensen verantwoordelijk waren. Omdat veel gemeenten hun ICT toevertrouwen aan externe partners, hebben we getracht om via de vendors van applicaties voor gemeenten toch aan geschikte data te geraken. De opgelegde datastructuur bleek ook hier een probleem te vormen om een dubbele reden. Enerzijds waren de gesprekken rond OSLO (Open Standaarden voor Lokale Overheden) nog volop aan de gang waardoor er geen eenduidige structuur van uit te wisselen data was (cf. infra 3.2 OSLO). Anderzijds waren er door vendors reeds andere extracties gebouwd om toch enigzins tegemoet te komen aan de vraag naar openheid van data. Het extraheren van data is kostelijk omdat het tijd van consultants vergt om specifieke data in een specifieke structuur te krijgen. Omdat het hier enkel over een PoC ging werd dan ook besloten om de aangeleverde XML-files te gebruiken als bron, en de andere stappen van het proces hieraan aan te passen. 25

Nadat de XML van 1 gemeente succesvol was geladen, werd aan de vendor gevraagd of we dezelfde extracts konden krijgen van andere gemeenten, zodat er toch een beperkte benchmark kon worden opgesteld. Verder werden ook enkele PoC schermen gemaakt op basis van de data van de ene gemeente. Op basis van de geladen data is een beperkte set van schermen gemaakt. Omdat het niet evident was om benchmark data te bekomen, zijn we op zoek gegaan naar eventuele andere bronnen waarmee de detailgegevens van een gemeente konden worden vergeleken. Gemeenten geven op bepaalde tijdstippen geaggregeerde gegevens door naar de Vlaamse en federale overheid. Daar zijn deze gegevens voor iedereen beschikbaar zijn, konden ze ook gebruikt worden voor benchmarking. Hiervoor hebben we bij CORVE (Coördinatiecel Vlaams e-government) onderzocht of hun gegevens voor dit bruikbaar waren. Het bleek dat hun gegevens op een vrij hoog niveau geaggregeerd zijn, waardoor het toevoegen van CORVE gegevens aan gemeentelijke detailgegevens weinig meerwaarde had. 26

2.3. Conclusies uit PoC 1 Alle gemeenten leveren grotendeels dezelfde diensten. Het opstellen van conceptuele modellen levert weinig discussie op, ook omdat er veel uniforme regelgeving is vanuit hogere overheden. Er schuilen echter grote verschillen in de verdeling van de dienstverlening over de verschillende gemeentelijke diensten heen. Deze versnipperde dienstverlening heeft ook consequenties voor de het gebruik van ICT en de opslag van operationele data. Ook is er een bevoegdheidsverdeling tussen gemeente en OCMW, waardoor bepaalde gegevens dubbel in aparte databanken worden opgeslagen. De rol van een gemeentelijke ICT dienst verschilt bovendien zeer sterk tussen verschillende gemeenten. Dit is afhankelijk van de grootte van de gemeente, maar ook van het ICT-beleid binnen een gemeente. Vaak wordt ICT beschouwd als een noodzakelijke investering om de operationele workflow efficiënt te maken. Voor het ontwikkelen of aanpassen van applicaties doen zij dan ook beroep op gespecialiseerde bedrijven. Hierdoor beperkt de interne ICT-kennis zich dan ook voornamelijk tot het operationeel gebruik ervan. Voortbouwend op de vorige punten kan gesteld worden dat, om data transversaal over verschillende diensten heen te kunnen ontsluiten, er best beroep kan worden gedaan op de vendors van de operationele software. Zij hebben immers de resources en de kennis in huis. Het belangrijkste besluit is echter dat uniforme data een noodzakelijke voorwaarde zijn om de uitwisseling van data tussen de verschillende diensten en naar een BI-platform mogelijk te maken. Het zoeken naar een manier om deze uniformisering mogelijk te maken, vormde dan ook de belangrijkste inzet van PoC 2 die we nu zullen bespreken. 27

3. PoC 2. Een Esperanto voor overheidsinformatie? Een testplatform voor OSLO. 3.1. Situering. De nood aan uniforme data. In het voorgaande beschreven we hoe de explosieve toename aan data de nood aan een performante informatievergaring en een efficiënt informatiebeheer vergrootte, ook bij lokale besturen. Die nood werd versterkt door het besluit van de Vlaamse Regering (25/06/2010) inzake de beleids-en beheerscyclus (BBC, cf. supra, 1.2.). De BBC confronteert gemeenten, provincies en openbare centra voor maatschappelijk welzijn met een reeks nieuwe regels m.b.t. meerjarenplanning, boekhouding en evaluatie achteraf. De meeste operationele systemen en ICT-voorzieningen van lokale besturen kunnen echter niet beantwoorden aan de nieuwe vereisten van een eigentijds informatiebeheer. Al te lang werd ICT slechts beschouwd als een noodzakelijke investering om de operationele workflow efficiënt te maken. Als gevolg hiervan werd ICT bij lokale overheden door de jaren heen zeer versnipperd uitgebouwd, met verschillende toepassingen op verschillende gemeentelijke diensten die niet met elkaar kunnen praten als gevolg. Bovendien moeten vele data ook uitgewisseld kunnen worden met centrale overheden. Sommige data worden decentraal beheerd, maar andere in Brussel. Uitwisseling tussen de eigen applicaties en deze zogenaamde authentieke bronnen is echter niet evident. Adoptie van deze kruispuntbanken, zoals het Centraal Referentieadressenbestand (CRAB) of de kruispuntbank ondernemingen (VKBO) blijft dikwijls beperkt tot één enkele dienst. Om data transversaal over die verschillende diensten en toepassingen heen te kunnen ontsluiten, zijn uniforme data een must. En daar knelt het schoentje. Uit de beschrijving van PoC 1 in het vorige hoofdstuk, bleek dat het grootste struikelblok er net in bestond dat het onmogelijk was om data op een uniforme manier aangeleverd te krijgen van verschillende diensten en/of lokale overheden. Toch is het is essentieel om linken te kunnen leggen tussen de gegevens in verschillende toepassingen en domeinen om relevante informatie te bekomen. Dergelijke linken zijn enkel mogelijk als de data qua verpakking en semantiek elektronisch naar elkaar kunnen worden vertaald. Binnen het 3xI-project had V-ICT-OR al onderzocht om datauitwisseling te organiseren met behulp van data brokers. Dit is middleware software waarin de mapping gebeurt tussen verschillende databronnen, waarna deze in staat is om op basis van voorgedefinieerde regels, de data van 1 applicatie door te geven naar een andere. Zulke brokers zijn zeer handig en performant. Maar naarmate het aantal applicaties die met elkaar moeten worden verbonden toeneemt, neemt de complexiteit en ook de kostprijs van dergelijke brokers toe. Zo werd het plan om Open Standaarden voor Lokale Overheden (OSLO) te ontwerpen, geboren. 28

3.2. OSLO Omdat data uitwisseling met behulp van brokers al snel een dure aangelegenheid kan worden, is V-ICT-OR op zoek gegaan naar een alternatieve oplossing om data over verschillende diensten en toepassingen heen te kunnen ontsluiten. Door alle toepassingen dezelfde taal en het hetzelfde dialect te laten spreken, begrijpen zij elkaar en moet men geen brokers of vertalers voorzien tussen de individuele formaten. Met andere woorden, het is de bedoeling om een soort van Esperanto te ontwikkelen dat door alle applicaties wordt begrepen. Binnen het 3xI project heeft V-ICT-OR samen met verschillende consortium partners OSLO (Open Standaarden Lokale Overheden) ontwikkeld. Binnen OSLO tracht men ten eerste, een generiek datakader /een open standaard te ontwikkelen en ten tweede, deze gedefinieerde standaarden laten bekrachtigen. Hierdoor zal een vlotter interbestuurlijk gegevensverkeer (o.a. koppeling met authentieke bronnen) en een vlotter intrabestuurlijk gegevensverkeer (tussen de verschillende toepassingen) mogelijk zijn. 3.2.1. OSLO en semantische interoperabiliteit Om toepassingen met elkaar te laten gegevens uitwisselen zijn afspraken over technische standaarden (XML, SOAP) nodig maar niet voldoende. Er moeten ook afspraken zijn rond semantische interoperabiliteit: weten hoe je de gegevens van de ander precies moet interpreteren en hoe je elkaars informatie direct kan hergebruiken. Bij het uitwisselen van gegevens geeft de semantiek de structuur van de gegevens aan, de betekenis van de verschillende onderdelen. Door de context te bepalen waarin de onderdelen moeten worden gebruikt, wordt elke vorm van ambiguïteit vermeden. De OSLO datastandaard focust zich in eerste instantie op kerndata, gegevens die voorkomen in verschillende applicaties en domeinen en die daarom het best centraal worden beheerd (personen, organisaties en adressen). Dankzij de samenwerking met W3C en het ISA Programma werd de OSLO-standaard aan de internationale standaarden afgetoetst wat de universaliteit en duurzaamheid ervan verzekert. OSLO werd op 31 mei 2013 op de Staten Generaal Open Standaarden voor het grote publiek gelanceerd. De specificaties zijn vrij beschikbaar op het platform van de Europese Commissie. 3.2.2. OSLO als technische standaard voor PoC 2 Om de datastandaard technisch vorm te geven deed V-ICT-OR beroep op de expertise van het iminds-ugent-multimedia Lab (MMLab). MMLab is een onderzoeksgroep binnen de Universiteit Gent die onder andere onderzoek voert naar datastandaarden. Met het technische model voor OSLO dat door MMLab werd gebouwd, tracht het BICC de brug te slaan naar beleidsinformatie en te onderzoeken welke rol de OSLO standaarden bij inter- en intra-bestuurlijk uitwisseling van gegevens kan vervullen. 29

Op technisch vlak is de OSLO XSD (beschrijven van de structuur van XML-documenten) een canoniek datamodel, een gedeeld dataformaat voor de uitwisseling van data tussen services. Hierdoor moet men geen vertalers voorzien tussen alle individuele formaten, maar slechts één vertaler tussen elk formaat en het canonieke formaat. In het OSLO-model staat betekenisvol verwerken van ontvangen informatie met gegevens van andere bronnen centraal. Het model zorgt voor een correcte representatie van de data volgens de verwachte interpretatie van de gebruikers. De OSLO XSD definieert op zakelijk of dienstverleningsniveau een woordenlijst van herbruikbare veelvoorkomende objecten en definities. Waar uit PoC 1 duidelijk bleek dat de verschillende stakeholders er zonder afgesproken standaard niet in slaagden data op een uniforme manier te exporteren, gingen we in PoC 2 de OSLO XSD als standaard gebruiken om een mapping te maken naar het interne datamodel van de stakeholders. Omdat de verantwoordelijkheid voor dergelijke mapping ligt bij de implementatie, werkten we dit in PoC 2 samen met de participanten concreet uit. Bij de opzet van de PoC hadden we beschikking over versie 0.93 van OSLO specificaties. De gepubliceerde specificaties kunt u hier terugvinden. Voortbouwend op de ervaringen van PoC 1 en op de nieuwe inzichten van OSLO heeft het BICC de onderzoeksvraag voor PoC 2 als volgt gedefinieerd: Kunnen er, op basis van OSLO standaarden, data worden ontsloten van één platform (dienstverlener) om door te sturen naar het BI platform van een andere dienstverlener? 3.3. Esperanto test-case 3.3.1. De samenwerkingsverbanden binnen PoC 2. Om de onderzoeksvraag van PoC 2 te kunnen beantwoorden, zochten we samenwerking met dienstverleners die: - ofwel data vanuit hun applicaties kunnen ontsluiten volgens de OSLO standaard. - ofwel een BI-systeem ontwikkelen waarin zij de ontsloten data van anderen kunnen inladen. PoC 2 was de eerste reële test-case waarbij de OSLO standaarden voor data uitwisseling werden geïmplementeerd. Dit gaf iedereen de gelegenheid om te zien wat er al was en waar het nog beter kon. De doelstelling van deze PoC was tweeërlei. Enerzijds hebben we aan de hand van een praktische implementatie van OSLO, het OSLO protocol zelf uitgetest en de hiaten en fouten er zoveel mogelijk uitgehaald. Anderzijds probeerden we uit of OSLO standaarden nuttig en voldoende zijn om inter- en intra-bestuurlijk uitwisseling van gegevens te vergemakkelijken. De groep van mogelijke participanten aan PoC 2 was eerder beperkt. Enerzijds verwachtten we dat zij voldoende data kunnen aanleveren die geschikt was voor de PoC. Anderzijds 30

moesten zij ook enige kennis hebben van OSLO zodanig dat een vlotte samenwerking gegarandeerd was. Drie ervaren dienstverleners voor lokale overheden zegden hun medewerking toe. Remmicom (Jan Buelens), Schaubroeck (Wim Van Acker) hebben reële data uit de operationele systeem van één van hun klanten ontsloten en ter beschikking gesteld van het BICC. CIPAL (Kurt Erauw) wilde de ontsloten data inladen in hun BI-systeem Athena. Omdat de technische en semantische specificaties van OSLO nog niet volledig waren bij de start van PoC 2, was het voor de dienstverleners nog niet onmiddellijk mogelijk om exports te leveren/data te importeren die voldeden aan de OSLO normen. Wij veronderstellen dat, indien de dienstverleners in de toekomst OSLO zullen ondersteunen, zij ook in staat zullen zijn om OSLO-compliant data af te leveren/te importeren. Om toch van start te kunnen gaan met PoC 2 werd het volgende afgesproken: - Op basis van de OSLO standaarden en met input van dienstverleners, bepaalt het BICC het domein dat onderwerp van de PoC zal uitmaken. - Remmicom en Schaubroeck leveren de geëxporteerde data aan in het technische formaat zoals zij dat vandaag ter hunner beschikking hebben. - Het BICC vormt deze data om volgens de door iminds opgestelde technisch en semantisch specificaties naar een OSLO gevalideerde dataset. - CIPAL importeert deze dataset in hun BI-platform. 3.3.2. Conceptuele afbakening Binnen OSLO spelen de entiteiten (rood) Persoon en Adres een belangrijke centrale rol. Daarnaast is er ook een entiteit voor persoonsrelatie (paars) 31

Op het Athena platform van CIPAL is een informatiedomein bevolking_huwelijk gedefinieerd waarvoor de drie bovengenoemde entiteiten perfect in aanmerking komen. Omdat Remmicom en Schaubroeck deze data konden aanleveren werd besloten om ons op het domein van huwelijken te concentreren. 3.3.3. De OSLO mapping tool Op basis van de OSLO specs v0.93 werd getracht een aangeleverde dataset om te zetten naar een OSLO compliant en gevalideerde XML. Bij het maken van een XML-document, kunnen fouten worden gegenereerd. Bij nieuwe projecten, neemt de waarschijnlijkheid op fouten nog toe. Het testen van documenten of standaarden op fouten is zeer tijdrovend. Voor de definitie en de validatie van de XSD werd gebruik gemaakt de <oxygen/> tool om gemakkelijk fouten te identificeren en te lokaliseren. De eerste dataset in verband met huwelijken werd ons aangeleverd door de dienstverlener Remmicom. Omdat Remmicom zijnapplicaties bouwt op het.net platform, werd geopteerd om eerst de nodige.net applicaties te maken om de data om te zetten naar OSLO compliant XML bestanden. De OSLO mapping tool werd op de bulk gegenereerde identiteitsbestanden uitgetest en de output XML file werd ter verificatie doorgestuurd naar MMLab. In verschillende testen werd de OSLO definitie in de XSD verfijnd en gecorrigeerd. De belangrijkste technische XSD verbeteringen omvatten onder andere: 32

- De mogelijkheid om een hele lijst van bijv. personen door te geven. OSLO specifieerde enkel hoe enkelvoudige elementen (1 persoon, 1 adres) moesten worden doorgegeven. Initieel werd gebruik gemaakt van de <OSLO> tag om lijsten door te geven. In de nieuwe versie van de XSD werden hiervoor lijst tags (bijv. <persons>) toegevoegd. - Metadata in verband met de identificatie van de gegevens doorgeven. Door op verschillende niveaus de <indentifier> tag te implementeren, werd het koppelen van data van verschillende entiteiten (bijv. persoonsgegevens en relatiegegevens) evident. <ovc:identifier> <cvb:identifier>00010315790</cvb:identifier> <cvb:identifiertype>rrn</cvb:identifiertype> <cbc:issuedate>2012-08-26</cbc:issuedate> <cvb:issuingauthority>bicc</cvb:issuingauthority> </ovc:identifier> Voor sommige entiteiten kunnen ook meerdere identifiers worden meegegeven waarmee, afhankelijk van de ontvangende applicatie, andere relaties kunnen worden gelegd. Bijv. het rijksregisternummer, dat een generieke identifier is waarmee iedereen aan de slag kan, en een sleutelveld uit de databank, hetgeen voor intrabestuurlijk uitwisseling zeer handig kan zijn. - Metadata in verband met de herkomst van de gegevens doorgeven. De herkomst van de gegevens dient om de betrouwbaarheid van een entiteit na te gaan. Indien deze gegevens rechtstreeks uit een authentieke bron komen (KSZ, RRK, KBO(V)KBO, CRAB, GRB, ) dan mag men veronderstellen dat deze gegevens correct en betrouwbaar zijn, zodat de ontvangende applicatie deze direct kan overnemen. Bij lokaal verrijkte data moet er omzichtig mee worden omgesprongen, en afgewogen of de verrijking wenselijk is. - Ook voor lege velden (NULL, geen waarde) worden de tags opgenomen in de XML met effectief geen waarde tussen de tags <cbc:issuedate></cbc:issuedate>. M.a.w. de volledige lijst van attributen, zoals gespecifieerd in de XSD, wordt steeds volledig opgenomen in de XML. 3.3.4. Exporteren en omvormen van data Door hun betrokkenheid bij het OSLO consortium en hun staat van verdienste in verband met overheidsautomatisering, waren Remmicom en Schaubroeck twee geschikte partners om huwelijksdata aan te leveren. Remmicom was de eerste van de ervaren dienstverleners die data i.v.m. huwelijken van de gemeente Berlaar aanleverde. De OSLO mapping tool (geschreven in.net) werd initieel gebruikt om de OSLO XSD technisch te verbeteren (zie supra). In een tweede fase werd de tool verbeterd en verfijnd. 33

Ook Schaubroeck leverde huwelijksdata aan van de gemeente Bornem. Omdat zij op het Java-platform programmeren werden de.net klassen van Remmicom vertaald naar Java klassen. Voor beide dienstverleners werd dus een eigen applicatie gebouwd waarmee de data, aangeleverd volgens hun eigen formaat, werden omgevormd naar het OSLO formaat. Door deze manier van werken konden beiden de gebouwde klassen hergebruiken. Hierdoor was ieder in staat om op hun eigen platform een generieke OSLO vertaalmodule te bouwen. In de applicaties werden, vertrekkende van de dataset Dot.net klassen en Java klassen gedefinieerd voor de verschillende domeinen: adres, contact, identifiers, person, personrelation en extension. Deze klassen zorgden voor de serialisatie naar XML, rekening houdende met de validatieregels van de XSD. Omdat er op het moment van programmatie geen stabiele versie van het XSD was, moesten ook de vertaalprogramma s regelmatig worden bijgestuurd. Na de publicatie van OSLO versie 1.0 werd de broncode aan de dienstverleners overhandigd en besproken zodat zij hiermee zelf verder aan de slag konden gaan. Ondanks de verschillende bronnen en de verschillende platformen, zijn we er in PoC 2 in geslaagd om de data afkomstig van klanten van Schaubroeck en Remmicom om te zetten naar hetzelfde formaat en dezelfde OSLO compliant structuur. Door deze eenvormigheid van gegevens wordt het een stuk eenvoudiger om data in te laden in een ander systeem. 3.3.5. Importeren van data Met Athena Beleidsinformatie biedt CIPAL een complete BI-suite aan voor lokale overheden. De informatie in Athena gaat organisatie breed en biedt ook een historisch perspectief. Via de webtoepassing Athenaweb kan men beleidsinformatie over domeinen heen ontsluiten in rapporten, dashboards en analysetools. Dit en hun betrokkenheid bij het OSLO consortium maakt dat CIPAL de geschikte kandidaat was om het importeren van data uit te testen. 34

CIPAL beschikt over een volledig BI-platform. Als data integratie tool gebruiken ze Pentaho s Kettle waarmee ze alle transformaties van data definiëren en de data integratie in de datawarehouse regelen. Om de voordelen van OSLO op de semantische interoperabiliteit van systemen aan te tonen, moet er een Kettle script worden geschreven waarmee de geëxporteerde OSLO XML s kunnen worden ingeladen in de staging-area van het CIPAL BI systeem. Vanaf de staging-area moet het standaard load-script de data automatisch in de datawarehouse laden, alsof de data van CIPAL zelf afkomstig is. Omdat de data van Schaubroeck en Remmicom naar hetzelfde formaat en dezelfde OSLO compliant structuur werden omgezet, konden beide datasets met behulp van hetzelfde kettle script worden ingeladen in de staging area van het BI systeem van Cipal. Hieruit kwam het werkelijke voordeel van de OSLO standaard naar voor. Door dit initieel succes was de teleurstelling dan ook groot toen bleek dat bij het laden van de data uit de staging area naar de datawarehouse, meer dan 80% van de data verworpen werden omwille van data kwaliteitsproblemen. Omdat OSLO enkel afspraken omvat over de structuur en niet over inhoud, is dit niet iets dat in OSLO wordt opgevangen. Enkele praktische voorbeelden maken dit duidelijk: - Niet alle personen hebben een identificatie (rijksregisternummer). Men zou dit kunnen opvangen door eventueel het rijksregisternummereen verplicht veld te maken. Echter hebben we gemerkt dat ook dit geen soelaas biedt omdat het rijksregisternummer regelmatig met een fictief gegeven wordt gevuld. (00000199900 = man en 00000100000 = vrouw) - Wat het adres betreft, wordt het busnummer in de bron niet op een uniforme manier ingevuld. De ene keer wordt het ingevuld in het huisnummer. De andere keer staat 35