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 21ste 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

3

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.

4

2. Tijdens een eerste Proof of Concept (PoC) werd een gemeenschappelijk BI-

platform 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).

5

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

6

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

7

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.

8

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

besturen1 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.

9

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.

10

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.

11

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 ICT-

oplossingen, 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 onder-

scheiden.

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, …)

12

b. Van de jaren negentig naar de 21ste 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

13

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 kunst-

en 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

14

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 Datawarehouse

Creëren, lezen, aanpassen, verwijderen Alleen lezen Beperkt aantal gegevens per transactie Miljoenen gegevens per vraag Live gegevens Historische gegevens Ondersteunt een proces 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 subject-

oriented, 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.

15

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.

16

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.

17

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.

18

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.

19

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)

20

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 BI-

platform 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 BI-

oplossingen voor lokale overheden zijn.

21

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 BI-

platform 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.

22

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.

23

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.

24

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 de-

dupliceren en onbekende waarden aan te duiden.

25

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.

26

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.

27

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.

28

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.

29

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.

30

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

31

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)

32

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:

33

- 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.

34

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.

35

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

36

het correct in het ‘locator’ veld. Een gelijkaardig probleem doet zich voor met

voornamen, die soms allemaal tegelijk worden meegegeven in één voornaam veld.

- Adressen van 2 samenwonenden komen niet overeen omdat deze data uit de

huwelijksakten komt van toen het huwelijk beklonken is in plaats van de “huidige”

status waar ze nu effectief samenwonen

- Indien de exacte (geboorte) datum niet helemaal gekend is, wordt er in plaats van de

volledige datum enkel een jaartal (00001980) of een fictief jaar (01019999)

meegegeven

3.4. Conclusies uit PoC 2

Semantische interoperabiliteit. Uit PoC 2 is duidelijk naar voor gekomen dat OSLO de

uitwisseling en delen van informatie zeker vereenvoudigt en transparanter maakt. Zo ligt de

structuur van de gegevens vast en wordt elke dubbelzinnigheid vermeden. Door de OSLO

standaard te implementeren zullen dienstverleners in de toekomst zeker heel wat kostbare

tijd en resources besparen. Ook zal de integratie tussen applicaties van verschillende

dienstverleners eenvoudiger zijn. Op zich is OSLO een eerst grote stap om gegevens

uitwisselbaar te maken, maar is OSLO voldoende?

Praktische implementatie van OSLO. Bij de doelstelling van OSLO 1.0 werd duidelijk gesteld:

“OSLO biedt hierbij een generiek model voor de structuur van de data, maar niet voor de

inhoud.”4 Waar dit een correct uitgangspunt is om een semantische standaard te creëren,

ligt hier ook de achilleshiel van OSLO.

Voor de verschillende data kwaliteitsproblemen voorziet OSLO 1.0 geen oplossing. Maar als

men effectief gegevens tussen verschillende systemen wil gaan uitwisselen dan zullen ook

inhoudelijke afspraken moeten worden gemaakt rond vragen zoals:

- Wanneer is een rijksregisternummer vereist?

- Moet het adres CRAB geverifieerd zijn?

- Welke velden zijn echt verplicht voor welke data?

Zo zal bijv. het rijksregisternummer van een persoon die een melding maakt niet essentieel

zijn, terwijl voor het doorgeven van een acte van ‘goed gedrag en zeden’ het cruciaal is om

de persoon eenduidig te kunnen identificeren.

De praktische inzetbaarheid van OSLO kan enkel maar bewerkstelligd worden door OSLO in

verschillende testcases te implementeren zodanig dat vele onvermoede praktische

probleemstellingen ook een ‘inhoudelijke’ standaard afdwingen. Alleen zo zal de OSLO

standaard werkelijk levensvatbaar en bruikbaar zijn.

4 Open Standaard voor Lokale Overheden. Een betere én elektronische dienstverlening.

37

Vormelijk is OSLO een grote vooruitgang die de uitwisselbaarheid van gegevens

standaardiseert. Maar OSLO op zich is niet voldoende om werkelijk volledige

interoperabiliteit van data te garanderen. Ook inhoudelijk (datakwaliteit) zullen regels

moeten worden afgedwongen.

Zeker wat betreft de initiële case “Datawarehousing en beleidsinformatie” is er nog een hele

weg af te leggen. Maar OSLO zal het zeker makkelijker maken voor de ervaren of nieuwe

dienstverleners om gegevens te ontsluiten, verzamelen en structureren en om zo

beleidsinformatie te ontsluiten of benchmarking mogelijk te maken.

38

4. Conclusie en aanbevelingen. Naar een BI maturiteit voor

lokale overheden.

De regelgeving van de Beleids- en Beheerscyclus of BBC (besluit van de Vlaamse Regering

van 25/06/2010) die in 2014 in voege gaat, maakt een performant en efficiënt

informatiebeleid en –beheer onontkoombaar voor lokale overheden. Omdat de data die

lokale overheden moeten verwerken en de informatie die ze uit die data willen puren

grotendeels overeenstemmen, is een gemeenschappelijk en kostendelend platform in the

cloud en via SaaS-technologie een (kosten)efficiënte en aangewezen oplossing, zoals

beschreven in hoofdstuk 2.

Een pijnpunt is wel dat verschillen in kennis en aanpak rond ICT bij lokale overheden en het

gebruik van verschillende bronsystemen de ‘samenspraak’ tussen data en de transfer van

data naar de cloud ernstig belemmeren. Zoals beschreven in hoofdstuk 3 is OSLO is een stap

in de goede richting, maar niet zaligmakend. In het ontsluiten van data naar een

gemeenschappelijk platform en de automatisering van beleidsinformatie en beleids-

rapportering liggen voor dienstenleveranciers heel wat opportuniteiten.

Kortom, om tot een degelijke informatiebeleid en –beheer te komen is de huidige ICT-

infrastructuur een pijnpunt dat de meeste lokale besturen moeten overbruggen.

Samengevat stellen er zich drie problemen of tekortkomingen waar veel lokale overheden

mee te maken hebben:

- data zitten opgeslagen in datasilo’s, waardoor cross-departementale

gegevensuitwisseling sterk wordt bemoeilijkt;

- in die silo’s zitten verscheidene versies van dezelfde kerndata die door

verschillende diensten anders worden geïnterpreteerd;

- data worden gebruikt zonder enige controle op de juistheid ervan.

Om deze problemen te verhelpen kan elk lokaal bestuur gebruik maken van een centrale

plaats om de ene versie van de ‘waarheid’ te bewaren. Omdat alle gemeenten met dezelfde

data aan de slag gaan en gelijkaardige informatie nodig hebben, zou het nog efficiënter zijn

(naar expertise, resources en workload) om een gemeenschappelijk platform te ontwikkelen

in de cloud. Dit heeft als bijkomend voordeel dat er ook interbestuurlijke informatie kan

worden uitgewisseld of benchmarks mogelijk worden. Met PoC 1 hebben we aangetoond dat

een dergelijk gemeenschappelijk platform mogelijk en efficiënt is.

Maar nogmaals, één van de grootste struikelblokken in PoC 1 was om de data op een

uniforme manier aangeleverd te krijgen van verschillende dienstverleners of lokale

overheden. De operationele data zitten immers opgeslagen in verschillende applicaties.

Maar ook de datakwaliteit uit één applicatie is niet altijd zeker door variërend gebruik van

die applicatie. Toch is het essentieel om linken te kunnen leggen tussen de gegevens in de

verschillende toepassingen en domeinen om de gewenste en relevante informatie te

39

verwerven. Veel aandacht moet ook uitgaan naar datakwaliteit en interoperabiliteit van

data.

In PoC 2 gingen we na of de OSLO standaard een oplossing biedt voor het probleem van

uniforme data-uitwisseling. OSLO maakt het makkelijker voor ervaren of nieuwe

dienstverleners om gegevens te ontsluiten, verzamelen en structureren en om zo

beleidsinformatie te ontsluiten en benchmarking mogelijk te maken. Maar OSLO is op zich

niet voldoende om werkelijk volledige interoperabiliteit van data te garanderen. Ook

inhoudelijk moeten regels worden afgedwongen om de kwaliteit van de data te garanderen.

Op het vlak van informatiebeleid en –beheer is er bij lokale overheden dus nog veel werk

aan de winkel. De BBC is een eerste aanzet om hiermee te beginnen.

Gebaseerd op voorgaande bevindingen kunnen we volgende aanbevelingen geven aan lokale

overheden:

1. Datasteward

Menselijke fouten, oneigenlijk gebruik van applicaties, nieuwe versies van software,

downtime van systemen,... het zijn slechts een paar redenen waarom de gegevens in

operationele systemen soms niet correct zijn. Maar de kwaliteit de van data in de

bronsystemen bepaalt ook de kwaliteit van de informatie die dient om beslissingen te

nemen. Daarom is het primordiaal om over de juiste data te beschikken en over de juiste

systemen om deze te bewaren, te verwerken en met elkaar te laten communiceren.

Om te vermijden dat er veel geld en tijd moet worden geïnvesteerd in het opschonen van

bestaande data, kan het probleem beter aan de bron worden aangepakt bij de creatie van de

data in de operationele systemen. Maak iemand verantwoordelijk voor datakwaliteit op

operationele systemen en maak heel uw organisatie bewust van het belang ervan.

Een datasteward heeft als rol de processen, het beleid, de richtlijnen en de

verantwoordelijkheden voor het beheer van alle data van de organisatie in

overeenstemming te brengen met operationele noden en/of verplichtingen. Een

datasteward zorgt ervoor dat er gedocumenteerde procedures en richtlijnen zijn voor de

toegang tot en het gebruik van gegevens. Ultiem zou dit kunnen leiden naar master data

management waarbij de kerndata over de verschillende operationele systemen centraal

worden beheerd.

2. Performance management

Waar de BBC door velen wordt gezien als een noodzakelijk kwaad, zouden overheden van

de gelegenheid gebruik kunnen maken om door te schakelen naar een volledig performance

management en zelfs nog verder te gaan dan wat de BBC vraagt.

De opzet van zo een performance management platform gebeurt best in een nauwe

samenwerking met dienstenleveranciers. De dienstenleveranciers hebben immers de know-

how in huis om lokale overheden te begeleiden bij de te nemen stappen. Voor het opzetten

van een (SaaS) informatieplatform en de technische begeleiding bij de extractie en

40

transformatie van de data zijn er verschillende mensen nodig met uiteenlopende expertises

die niet tot de corebusiness behoren van lokale overheden.

3. Kostendelende samenwerkingsverbanden

De vaste (hardware/software) en set-up (installatie/configuratie) kosten van een

beleidsinformatiesysteem kunnen hoog oplopen. Ook het onderhoud van dergelijk systeem

vraagt heel wat resources en expertise. Voor kleinere lokale overheden is het niet evident,

laat staan opportuun, om dit volledig in eigen beheer te doen op een eigen toegewijd

systeem. Kostendelende samenwerkingsverbanden bieden schaalvoordelen waardoor

iedereen meer waar voor zijn geld zal krijgen. Ook voor de dienstverlener is dit een

voordeel, omdat er dan een uniform systeem kan worden uitgewerkt.

Er zijn al SaaS oplossingen voorhanden waardoor het niet meer noodzakelijk is de hele

infrastructuur zelf te moeten uitrollen en beheren. Omdat deze SaaS oplossingen niet meer

plaatsgebonden zijn, is het onderhoud en de kost van dergelijk systeem veel makkelijker

over de partners te verdelen. Bij de opzet van het systeem is de keuze van de juiste

technologiepartner cruciaal. De technologische en sectoriële ervaring van deze partner zal

bepalend zijn of het geïnvesteerde geld optimaal zal renderen.

4. Ga op zoek naar quick wins

Business Intelligence implementeren in een organisatie kan niet op een drafje gebeuren. De

grootste meerwaarde van Business Intelligence wordt verkregen als ze in de hele

organisatie is ingebed. Deze inbedding is een intensieve operatie die lang kan duren. Om te

vermijden dat de eindgebruiker het vertrouwen in BI zou verliezen en om de time-to-value

te reduceren, gaat men best op zoek naar quick wins. Dergelijke korte termijnsuccessen

garanderen op lange termijn een duurzame en door de organisatie gedragen oplossing.

Voor een quick win in BI focust u best op een specifieke doelgroep waarvoor u één simpel en

gemakkelijk rapport/dashboard maakt met essentiële informatie voor het beleid.

41

5. Referenties Beirens, D., Lombaert, S., Maebe, M. & Moyersons, S. 2012. Handboek Beleids- en Beheercyclus. Vanden Broele.

Van Nieuwenhuyse, D. & Vanhoudt, D. 2008. Performance Management. Lannoo.

Van Nieuwenhuyse, D. & Knapen K. 2010. Best practices in Performance Management. Lannoo.

Fockenier, M., Hellebosch, R., Mertens, G., Pauwels, J., Van Dooren, B. & Van Vaerenbergh, V. 2011. De beleids- en beheercyclus van de gemeenten, de OCMW’s en de provincies: de beleids en beheersrapporten. Agentschap voor Binnenlands bestuur.

Leroy, J. 2010, De beleids- en beheerscyclus van de gemeenten de OCMW’s en de provincies: De nieuwe regels toegelicht in 60 vragen en antwoorden, Politeia.

Plas, H. 2012. Werken met het meerjarenplan en de BBC in cultuur, cultureel erfgoed, jeugd en sport, Politeia. De beleids- en beheercyclus van de gemeenten, OCMW’s en provincies: beleidsplanning, -monitoring en –evaluatie. Agentschap voor binnenlands bestuur Vlaamse regering, 2010. Besluit van de Vlaamse Regering betreffende de beleids- en beheercyclus van de gemeenten, de provincies en de openbare centra voor maatschappelijk welzijn. Van Moerkerke, B. 2011. Beleids en Beheercyclus: eerste ervaringen, bestuurskracht financieel beleid: 20-22.

Van Nieuwenhuyse, D. 2012. Zijn uilen in control?, Controlling: 28-30.

42

Van Nieuwenhuyse, D., & Adriaens D. Bestuurlijk Performance Management: meer dan plannen alleen, White Paper.

Van Nieuwenhuyse, D. 2011. Waarom falen zo veel BI projecten, Smart Business Strategies: 14- 16.

Maebe, M. 2011. BBC klaar voor de start?, Binnenband: 25 – 27.

De Clercq, L. 2011. Beleids- en beheercyclus in oost Vlaanderen, Binnenband: 9 – 11.

Van Nieuwenhuyse, D. 2011. Hoeveel prestatieindicatoren heeft u nodig?, Smart Business Strategies: 38 – 39.

Van Nieuwenhuyse, D. 2012.Strategische beslissingen: doordacht en niet te snel, Smart Business Strategies: 18.

Van Nieuwenhuyse, D. 2012. Wat bedrijven kunnen leren van muizen en mieren, Smart Business Strategies: 16 – 18.

Van Nieuwenhuyse, D. 2012. Waardecreatie: mythe of realiteit?, Controlling: 16-18.

Cobbaert, P., & Van Caenegem R. 2011. Eerste BBC ervaringen uit het werkveld over groeipijnen en kansen, Vlaams tijdschrift voor sportbeheer: 15-23.

Van Den Broeck, J., Cunningham, S., Eeckels, R., & Herbst, K. 2005. Data Cleaning: Detecting, Diagnosing, and Editing Data Abnormalities, Plos.

Federale Overheid. 2013. Globaal bevolkingscijfer per gemeente, http://www.ibz.rrn.fgov.be/fileadmin/user_upload/Registre/nl/statistieken_bevolking/stat_1_n.pdf