business intelligence voor lokale overhedenbicc.thomasmore.be/files/files/rapporten/3 x i...
Post on 26-Feb-2019
216 Views
Preview:
TRANSCRIPT
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
top related