Kerndata Informatie aan het werk in uw bestuur
Een uitgave van V-ICT-OR vzw
1010101010101010101010101010101010101010101010101010101010101010101010101010101
Colofon Deze tekst kwam tot stand tijdens zes vergaderingen van de Denktank Midoffice en informatiearchitectuur in lokale besturen. Aan de vergaderingen namen deel: • • • • • • • • •
Herman Callens (VVSG vzw) Katrin Janssen (Gemeente/OCMW Zoersel) Jan Godderis (Corve) Brian Greven (Stadsbestuur Mechelen) Peter Hautekiet (V-ICT-OR vzw) Bruno Koninckx (Memori - Lessius Mechelen vzw) Peter Moreels (Digipolis Antwerpen) Luk Van Beneden (Stadsbestuur Kortrijk) Eddy Van der Stock (Stad/OCMW Lokeren)
Elke deelnemer bracht eigen ervaring en kennis in. De hier verwoorde inzichten en stellingen zijn de neerslag van deze persoonlijk inzichten en vertolken geen officiële standpunten van de organisatie waarvoor zij werken.
Deze publicatie gebeurt in het kader van het 3xI-project. 3xI staat voor: Informatiekwaliteit, Informatieveiligheid en Informatie-architectuur in Vlaamse lokale besturen. Het project wordt ondersteund door IWT en uitgevoerd door V-ICT-OR in samenwerking met Memori - Lessius Mechelen vzw. Het project 3xI wil, naast de nodige informatievoorziening, vooral de focus leggen op het daadwerkelijk stimuleren van innovatieve acties bij bedrijven op het vlak van informatiemanagement bij de lokale overheid. Via thematische werkgroepen en individuele adviezen aan bedrijven willen we komen tot een vernieuwing van het aanbod aan lokale besturen, door bedrijven uit te nodigen mee te werken aan concrete cases inzake informatiekwaliteit, informatieveiligheid en informatievoorziening. Interesse of meer weten? Neem contact op met Peter Hautekiet,
[email protected], +32 473 997664.
0101010101010101010101010101010101010101010101010101010101010101010101010101010
Herkent u onderstaande situaties? Marnix, die enkele jaren geleden zijn bedrijf verhuisde, krijgt nog steeds brieven van de gemeente op het oude adres. Andere actieve bedrijven ontvangen helemaal geen brieven… Luna, tien jaar, kwam zes maand geleden om bij een verkeersongeluk. Haar ouders ontvangen een uitnodiging op naam van Luna voor de nieuwe grabbelpas-activiteiten… Een factuur voor het bestuur legt vaak een grillige weg af binnen het bestuur voor ze een goedkeuring krijgt en betaald kan worden. Dit leidt tot achterstallige betalingen en extra kosten voor het bestuur. Een melding over een defect wegdek kan per telefoon of per e-mail het bestuur binnenkomen, bij de technische dienst, het secretariaat of op het spreekuur van de burgemeester,… Een centraal overzicht ontbreekt. Gevolg: dubbele meldingen, “vergeten” meldingen,… Het is niet zo moeilijk dit lijstje aan te vullen met gelijkaardige verhalen. We willen met zijn allen slimme besturen die klantgericht werken maar we beseffen dat de uitdagingen niet gering zijn en dat er nog heel wat werk aan de winkel is.
Sinds de opkomst van het internet in de jaren negentig is het aantal kanalen waarover een lokaal bestuur (gemeentebestuur, OCMW, politiezone) kan beschikken, alleen maar toegenomen: e-mail, website, klassieke briefwisseling, balie, telefoon, digitale TV,… Bovendien is het aantal taken dat door lokale besturen wordt uitgevoerd de laatste decennia eveneens toegenomen. De grote meerderheid van deze taken verloopt geautomatiseerd aan de hand van gespecialiseerde toepassingen. We werken al sinds het begin van de jaren tachtig in de backoffice met verticale, dienstgebonden applicaties: boekhouding, bevolking, bibliotheek,… Deze applicaties hebben ons toegelaten om de taken van de verschillende diensten (de financiële dienst, de dienst burgerzaken,…) te automatiseren en daardoor efficiënter te laten verlopen. Steeds meer communicatiekanalen en een veelheid van bestaande toepassingen zorgen voor een complex landschap. Het dwingt ons tot het maken van een sprong op het vlak van informatiebeheer, zo niet raken we als organisatie verlamd. Deze sprong kunnen we omschrijven als het invoeren van een midoffice.
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -1-
1. Waarom midoffice? Wat verwachten we van het informatiebeheer in lokale besturen, nu en in de volgende jaren? Wie om het even welk gemeentebestuur of OCMW in het begin van de jaren tachtig vergelijkt met de huidige toestand, beseft dat lokale besturen de afgelopen decennia een heuse gedaanteverwisseling hebben ondergaan. Lokale besturen doen meer, vervullen steeds meer taken, dan enkele decennia geleden. Automatisering heeft daarin een belangrijke rol gespeeld. Door het informatiseren van dienstgebonden taken worden zaken sneller, efficiënter en correcter afgehandeld. Toch hebben veel lokale besturen het gevoel dat het water hen aan de lippen staat en dat
ze nauwelijks kunnen voldoen aan de steeds groeiende verwachtingen (niet alleen van buitenaf, maar ook van binnen de organisatie): • Als burger verwachten we in de eerste plaats een kwaliteitsvolle dienstverlening, op basis van correcte en volledige gegevens. • Als medewerker hebben we het meeste nood aan een geïntegreerde werkomgeving, waarin we de verschillende vragen die op ons afkomen kunnen afhandelen. • Als beleidsmaker zijn we op zoek naar gegevens die beleidsbeslissingen kunnen ondersteunen en willen we zicht hebben op het presteren van de organisatie.
1.1 Wat wil de burger? Een burger meldt zich aan op de website en wil daar niet alleen de algemene informatie over zijn gemeente en gemeentebestuur, maar ook informatie op zijn maat gesneden vinden. Welke boeken en DVD’s heb ik momenteel ontleend in de bib en wanneer moeten die binnen? Hoever
staat het met de inschrijving van mijn jongste zoon voor de handbalstage deze zomer? Is er nieuws uit de gemeenteraad over mijn straat? Hoeveel gemeentebelastingen heb ik de laatste jaren betaald? Kloppen de contactgegevens (gsm-nummer, e-mailadres,…) die de gemeentelijke diensten van mij bijhouden nog?
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -2-
1.2 Wat wil de medewerker? Een medewerker van het gemeentebestuur wil alle voor hem/haar bestemde vragen, meldingen, taken, … binnen krijgen in een digitale werkomgeving. Dossiers en taken die een organisatiebrede behandeling behoeven zijn ook organisatiebreed zichtbaar. Dit betekent dat de medewerker niet noodzakelijk toegang moet hebben tot alle specifieke backoffice applicaties om toch over de relevante informatie in verband met een vergunning, een melding, een aanvraag voor feestmateriaal,… te kunnen beschikken. De medewerker kan de dienstverlening efficiënter uitvoeren omdat hij toegang heeft tot gerelateerde relevante
basisinformatie (bijvoorbeeld alle informatie in verband de burger die een aanvraag indient), onafhankelijk van waar die informatie opgeslagen is. Een PIP (Persoonlijke Internet Pagina) maar dan toepasselijk voor de interne werking. Hoe kan ik nagaan of een burger nog schulden heeft bij de gemeente? Werd de melding van een kapotte straatlamp reeds eerder geregistreerd? Hoever staat het met de bouwaanvraag van de burger die ik momenteel aan de telefoon heb? Welke taken moet ik vandaag dringend uitvoeren?
1.3 Wat wil de beslissingsnemer? Om de vinger aan de pols te kunnen houden hebben het schepencollege en het management team in een lokaal bestuur nood aan beleidsinformatie over bijvoorbeeld hoeveel bedrijven deze maand hun grondgebeid verlaten hebben. Wat is de gemiddelde tijd voor het behandelen van een melding? Maakt men in de verschillende wijken evenveel gebruik van ons aanbod cultuur? Welke plaatsen zijn het meest kwetsbaar voor vandalisme
en sluikstorten? Hoever wonen de meeste senioren van een dienstencentrum? Over welke vormen van dienstverlening (producten) krijgen we het meest vragen?... Een dashboard voor de beslissingsnemer laat hem toe zicht te houden op zowel de organisatie als het grondgebied.
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -3-
1.4 Uitdagingen Bovenstaande vragen zijn waarschijnlijk herkenbaar, ze wijzen op de noden zoals die in bijna elk lokaal bestuur leven. De oplossingen om hieraan tegemoet te komen zijn absoluut geen science fiction, maar liggen binnen handbereik. Toch hebben lokale besturen enkele horden te nemen:
1. We
hebben heel wat gegevens ter beschikking, maar deze zijn niet geïntegreerd. Adresbestanden zitten verspreid, geografische gegevens zijn niet voor alle diensten beschikbaar,… Bovendien beschikken we over een goudmijn aan informatie, maar hebben we grote moeite om die informatie zichtbaar en leesbaar te maken voor het beleid.
2. Er komen steeds meer kanalen bij, wat een communicatiestrategie en beheersbare dienstverlening niet gemakkelijker maakt. Kanalen (mail, brief, loket, telefoon) zijn niet op elkaar afgestemd.
3. We werken al jaren met e-mail, maar medewerkers hebben eerder het gevoel dat e-mail één grote chaos is in plaats van dat het ons toelaat greep op de zaak te houden. Vragen en meldingen van klanten en collega’s lopen het risico ondergesneeuwd en begraven te worden in individuele mailboxen en zijn niet organisatiebreed zichtbaar.
4. We werken al sinds het begin van de jaren tachtig in de backoffice met verticale, dienstgebonden applicaties: boekhouding, bevolking, bibliotheek,… Deze applicaties hebben ons toegelaten om de taken van de verschillende diensten (de financiële dienst, de dienst burgerzaken,…) te automatiseren en daardoor efficiënter te laten verlopen. Momenteel dreigen deze applicaties echter eerder een hypotheek op de verdere groei van lokale besturen te leggen, doordat ze:
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -4-
• Ontworpen zijn om één taak of één set van taken binnen een dienst naar behoren te vervullen, niet om organisatiebreed handelen te ondersteunen.
• Deze applicaties vaak opereren als “zwarte dozen”, waarin gegevens slechts opgesloten zitten en niet of moeilijk beschikbaar zijn, onafhankelijk van deze applicatie.
De groeiende complexiteit van de frontoffice (steeds meer kanalen) en de bestaande complexiteit van de backoffice (veel applicaties) dwingt ons tot het maken van een sprong op het vlak van informatiebeheer, zo niet raken we als bestuur verlamd. Het gaat hier over het invoeren van een midoffice. We willen nagaan hoe we dat vage idee van een midoffice concreter kunnen maken. Waaraan moet een midoffice voldoen om een Persoonlijke Internet Pagina voor de burger mogelijk te maken, een geïntegreerde werkomgeving voor de medewerker te kunnen realiseren en een dashboard met nuttige statistische informatie aan het beleid te kunnen aanbieden? Dat is de vraag die ons in de volgende pagina’s zal bezighouden.
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -5-
2 Midoffice? Que? Een midoffice is niet zomaar een stukje software dat je uit de doos haalt in en installeert. Een midoffice is ook geen bestand dat ergens op een server staat. Een midoffice is niet één “ding” en dat maakt het soms moeilijk grijpbaar. Wat is een midoffice dan wel? Een midoffice is een verzameling van kerndata en toepassingen die optreedt als schakel tussen de frontoffice en backoffice . Met kerndata bedoelen we gegevens die voorkomen in verschillende applicaties en die daarom het best centraal kunnen worden beheerd (denk aan persoonsgegevens, adressen, statussen van een melding,…). Van frontoffice naar backoffice : Een vader schrijft zijn zoon of dochter in voor een sportactiviteit. Dit kan wellicht via verschillende kanalen: aan de balie, telefonisch, via de website,… Er voor zorgen dat deze verschillende kanalen goed op elkaar zijn afgestemd, is typisch een taak voor de frontoffice. De inschrijving zelf moet natuurlijk deugdelijk worden afgehandeld. Zo is er waarschijnlijk een maximum aantal deelnemers dat in het oog moet gehouden worden, er moet gefactureerd worden,… Dit zijn typisch taken voor een gespecialiseerde backoffice applicatie.
Maar hoe vermijden we dat we de gegevens van zoon of dochter steeds opnieuw opvragen, ook al zijn deze gegevens (naam, adres, leeftijd,…maar ook een e-mail adres) ongetwijfeld reeds ‘ergens’ in de organisatie opgeslagen? Hoe zorgen we er voor dat we de status van de inschrijving ook buiten de sportapplicatie kunnen zien, zodat deze kan verschijnen op een Persoonlijke Internet Pagina of vlot kan meegedeeld worden door een onthaalmedewerker zonder dat deze daarvoor iemand op de sportdienst nodig heeft? Een midoffice treedt op als schakel tussen de frontoffice en de backoffice door:
1. Kerndata uit de backoffice en frontoffice te halen: kerndata zijn gegevens die in meer dan één applicatie (zowel in de front als in de back) worden opgeslagen. Denk bijvoorbeeld aan iemands e-mail adres, bepaalde bedrijfsgegevens, adrespunten,… Kerndata worden best minstens conceptueel, in de praktijk ook vaak fysiek, gescheiden van de verschillende applicaties.
2. Deze
kerndata ter beschikking te stellen aan applicaties en personen. Omdat deze data moeten gedeeld worden doorheen de organisatie is het nodig dat de juiste mechanismen voorhanden zijn om deze data te delen.
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -6-
3. Dossiergegevens
als kerndata uit de backoffice en frontoffice te halen. Naast het bijhouden van de bovengenoemde kerndata over bijvoorbeeld persoonsgegevens, bedrijfsgegevens, adressen is het ook noodzakelijk om vanuit de hele organisatie zicht te hebben op bepaalde aspecten van een dossier, bijvoorbeeld de status.
4. Een organisatiebrede dossierbehandeling mogelijk te maken via bestaande of nieuwe applicaties, zoals een CRM-, DMS- of workflow-toepassing.
CRM: Customer Relationship Management
De uitdagingen zijn niet mis. Is midoffice zoals het hierboven wordt geschetst niet te ambitieus voor menig Vlaams lokaal bestuur? Wat is het verband tussen de vragen waarop midoffice -tools een antwoord willen bieden en de doelstellingen die door het bestuur zelf worden geformuleerd? Midoffice ondersteunt een organisatiebrede werking, maar hoever wil of kan het bestuur zelf gaan in die organisatiebrede werking? Is midoffice sowieso een antwoord op al deze vragen? Het antwoord op deze vragen verschilt van bestuur tot bestuur. Dit zal onvermijdelijk gevolgen hebben voor de manier waarop je midoffice aankaart binnen je eigen organisatie.
DMS: Document Management System
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -7-
3 Midoffice in uw organisatie: kantelen of koppelen? Het invoeren van een midoffice in uw bestuur is geen doel op zich, maar moet helpen om de doelstellingen van uw organisatie te behalen: een meer klantgerichte organisatie, een efficiëntere werking, minder fouten en minder dubbel werk, snellere beleidsinformatie,…. Geen twee organisaties zijn gelijk, doelstellingen en ambities verschillen natuurlijk van bestuur tot bestuur. Het is noodzakelijk om de invoering van een midoffice zo goed mogelijk af ter stemmen op de algemene plannen van uw bestuur. Het gaat om het samenspel tussen organisatie en ICT. Besturen kunnen zeer verschillende keuzes maken. Kantelen in Zoersel De gemeente Zoersel greep de verhuis naar een nieuw administratief centrum aan om een totaal nieuw dienstverleningsconcept uit te bouwen. Dit concept is gebaseerd op een verregaande integratie van gemeentebestuur
en OCMW, en op een gekantelde organisatie met duidelijke scheiding binnen de organisatie tussen frontoffice en backoffice . De aansturing van dit veranderingsproces gebeurde duidelijk vanuit de (top van de) organisatie. De vraag waar Zoersel nu mee geconfronteerd wordt, is of IT nog kan volgen. Baliemedewerkers die bijvoorbeeld vanuit de frontoffice een vraag van een klant willen beantwoorden, worden nu gedwongen in verschillende backoffice applicaties te duiken, die elk hun eigen logica en look and feel hebben. Kantelen van een organisatie vereist een midoffice omdat verticale applicaties hier geen antwoord op hebben. Koppelen in Lokeren In Lokeren was het de IT-dienst, de enige dienst die tot nog toe overkoepelend voor stad en OCMW werkt, die het project voor een verbeterde dienstverlening startte. De nadruk ligt niet op organisatorische verandering maar op het inrichten van de nodige centrale gegevensbronnen en het leggen van de nodige koppelingen tussen applicaties en gegevensbronnen. De vraag waar Lokeren mee geconfronteerd wordt is: zal de organisatie kunnen volgen? Zullen de mogelijkheden die IT voorziet om klantgericht te werken de organisatie niet onder druk zetten? Wordt de kans gegrepen om een meer geïntegreerde dienstverlening uit te bouwen en de muren tussen diensten en besturen te slopen? Het verschil tussen beiden wordt wel eens omschreven als het verschil tussen kantelen en koppelen. Kantelen we de organisatie (en moet IT volgen) of laten we de organisatie (voorlopig intact) en leggen we achter de schermen de nodige verbindingen? In beide contexten is de inzet van een midoffice zinvol, maar in beide gevallen zal de invoering van een midoffice en het uiteindelijke resultaat verschillend zijn. Deze organisatorische context is een gegeven waarop men vanuit ICT vaak weinig of geen invloed heeft, maar waarbinnen ICT moet werken. Is het dan wel mogelijk om één algemeen model naar voor te schuiven dat voor de meeste lokale besturen nuttig is?
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -8-
Midoffice als geheel van gegevensbronnen en applicaties is een deel van het geheel. Wanneer we spreken in termen van architectuur1, kunnen we zeggen dat midoffice veronderstelt dat op het niveau van de infrastructuur (hardware, basissoftware, netwerk,…) de belangrijkste voorzieningen voorhanden zijn. In de meeste lokale besturen blijkt zich trouwens op dit niveau geen probleem voor te doen (zoals blijkt uit het I-Scan onderzoek2). Ook de organisatiearchitectuur valt buiten de horizon van de midoffice, al zal het wel invloed hebben op de manier waarop midoffice wordt geïntroduceerd.
• De organisatiearchitectuur gaat over het wie en het wat: hoe zijn we onderverdeeld, welke diensten en producten leveren we,… • De procesarchitectuur richt zich op het hoe: wat doen we om de producten en diensten te leveren? • De informatiearchitectuur buigt zich over inrichting van de informatie, zowel de digitale als niet-digitale. • De applicatiearchitectuur heeft betrekking op de functionele aspecten van het informatiebeheer. Welke applicaties doet wat? • De infrastructuurarchitectuur beschrijft het geheel van hardware, netwerkcomponenten en generieke applicaties (bijvoorbeeld groupware, bureauticasoftware,…)
MidOffice en architectuur Organisatie architectuur
Procesarchitectuur
MidOffice
Informatiearchitectuur
Applicatiearchitectuur
Infrastructuurarchitectuur
1
Beeldhouden: Handvatten voor Werken onder Architectuur. – Gorinchem: VIAG, 2009. – 128 p.
2
E-Government, nieuwe kans of nieuw probleem? Achter de schermen bij Vlaamse gemeenten. – Brugge: Die Keure, 2009. - 123 p.
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -9-
Bij het uittekenen van een midoffice model gaat het er niet om hoe de zaken op het niveau van de infrastructuur geregeld zijn, noch om de keuzes die op het niveau van de organisatie worden gemaakt. Midoffice gaat wel over:
proceslaag, informatielaag en applicatielaag en hoe deze onderling met elkaar verbonden zijn. En daar kunnen we zeker enkele algemeen geldende zaken naar voor schuiven.
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -10-
4. Processen en producten staan centraal In de hoop meer greep te krijgen op “waar we mee bezig zijn” is procesmanagement voor veel lokale besturen in Vlaanderen belangrijk geworden. Nogal wat pogingen om de eigen organisatie uitputtend in kaart te brengen via procesbeschrijvingen zijn echter halverwege gestrand of hebben niet het verhoopte resultaat opgeleverd.
Vaak leven binnen één bestuur verschillende verwachtingen over wat procesbeschrijvingen zullen opleveren. Vanuit ICT-kant hoopt men dat procesbeschrijvingen quasi-automatisch in een workflow systeem kunnen worden ingebracht, terwijl het beleid eerder vanuit een vogelperspectief zicht op de organisatie wil krijgen.
Wanneer procesbeschrijvingen geen deel uitmaken van een verbeterproces verworden ze al vlug tot een administratieve plicht waar na afloop weinig mee gebeurt.
Daarom: leg de prioriteit bij de horizontale processen en niet bij dienstgebonden procedures. Leg bij het maken van procesbeschrijvingen de nadruk op wat elk proces gemeenschappelijk heeft, zodat de overgang van de algemene procesbeschrijvingen naar de concrete dossiers vlotter kan gemaakt worden.
Wanneer we geen prioriteiten stellen en meteen alles willen beschrijven, lopen we het risico dat we beginnen bij de gemakkelijkste processen. Dit zijn dan meestal die processen die zich binnen één dienst afspelen, bijvoorbeeld de uitreiking van een identiteitskaart. De horizontale processen, die zich tussen verschillende diensten afspelen, (bijvoorbeeld notulering) zijn heel wat moeilijker en worden gemakkelijk uitgesteld. Maar hier is net de grootste winst op het vlak van efficiëntie te halen.
Een kruidenier die niet weet wat hij verkoopt kan zijn klanten niet helpen. De laatste jaren wordt vaak het belang van een productencatalogus aangehaald. Een productencatalogus voor elk lokaal bestuur is belangrijk, niet alleen als communicatie-instrument (voor verschillende
Maar de inrichting van een midoffice kan niet wachten tot alle processen volledig in kaart zijn gebracht. Het is belangrijk bij procesbeschrijvingen de nadruk te leggen op de stappen (en hun status) die een proces doorloopt.
doelgroepen) maar ook als intern werk- en beleidsinstrument. Het is immers belangrijk om te weten wat we doen. Een productencatalogus beschrijft de output van het bestuur.
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -11-
5 Informatiearchitectuur: wat zijn onze kerndata? Kerndata zijn data die hergebruikt worden door verschillende diensten. Het gaat hier in de eerste plaats over personen, bedrijven, verenigingen, adressen en dossiers. Deze kerndata komen vaak uit andere bronnen (RR, VKBO, CRAB,…). Deze authentieke bronnen zijn niet steeds perfect maar leveren meestal de best beschikbare data waarmee het lokale bestuur aan de slag kan. Personen Het gemeentebestuur is bevoegd voor het bijhouden van de lokale bevolkingsgegevens. Dit levert op zich al een schat aan informatie die vaak nog onvoldoende hergebruikt wordt. De zogenaamde wettelijke gegevens (en dan vooral: naam, voornaam, geboortedatum, geslacht, wettelijk adres, gezinssamenstelling en rijksregisternummer) leveren onmisbare informatie die noodzakelijk is als we de burger niet steeds met dezelfde vragen willen lastig vallen. Het wordt nog interessanter als we ook andere gegevens kunnen opslaan en deze als kerndata kunnen hergebruiken, bijvoorbeeld e-mail adressen en telefoonnummers. Gebruik het lokaal bevolkingsbestand als eerste basis voor een Lokale Authentieke Bron voor personen en vul dit verder aan met andere contactgegevens. Niet enkel inwoners van de gemeente zullen in uw bestand voor personen voorkomen. Hier is het uitkijken naar de webservice van het rijksregister die toelaat gegevens van niet-inwoners op een vlotte manier over te nemen en de globale machtiging (zie verder: privacy). Bedrijven en verenigingen Anders dan met persoonsgegevens is het zeer moeilijk om zelf de vinger aan de pols te houden voor wat betreft verhuisbewegingen en andere veranderingen van ondernemingen binnen het grondgebied. Een centraal register van ondernemingen in België (KBO) is een relatief recent verschijnsel (2003). De VKBO, een realisatie van de Vlaamse e-governmentcel
CORVE, staat voor Verrijkte Kruispuntbank Ondernemingen. Verrijkingen zijn gegevens zoals geografische coördinaten, jaarrekeninggegevens en tewerkstellingsgegevens. De VKBOgemeentebestanden bieden een overzicht van de vestigingen en ondernemingen binnen de gemeente met optioneel de gerelateerde ondernemingen en vestigingen buiten de gemeente. Deze gemeentebestanden zijn geschikt om ingelezen te worden in databanken en vormen daarom een goede aanzet voor de aanleg van een bedrijvendatabank. Hier kunnen we beroep doen op de VKBO-webservices die deze data actualiseren. Gebruik KBO of VKBO als eerste basis voor een Lokale Authentieke Bron voor ondernemingen en vul dit verder aan met andere contactgegevens. Plaatselijke verenigingen zijn voor lokale besturen belangrijke contacten, die bovendien vaak met verschillende diensten binnen uw bestuur te maken krijgen. Het centraal bijhouden van de verenigingsinformatie loont dan ook de moeite. We zien echter dat in vergelijking met personen en ondernemingen, het centraal bijhouden van verenigingsinformatie nog in de kinderschoenen staat. Plaatselijke verenigingen zijn zowel sportverenigingen, cultuurraad of andere adviesraden, jeugdbewegingen, … Deze zijn niet opgenomen in (V)KBO, tenzij ze een vzw vorm hebben. Adressen Men schat dat 80% van de informatie die binnen de overheid wordt verwerkt een ruimtelijke component heeft. Heel vaak gaat het hier om adresinformatie. Het verdient aanbeveling om de adresinformatie (straatnamen, huis-nummers) in een centraal bestand op te slaan. Het Centraal Referentie Adressen Bestand (CRAB) is de adresstandaard in Vlaanderen en wordt vanaf 2011 de authentieke bron (incl. alle huisnummers en straatnamen en met geo-referentie).
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -12-
Gebruik CRAB als eerste basis voor een Lokale Authentieke Bron voor adressen. Het CRAB wordt bijgewerkt door het lokale bestuur zelf en via AGIV ter beschikking gesteld aan derden (nutsmaatschappijen maken reeds intensief gebruik van CRAB). Dossiers Een dossier begint met een verzoek van burger, bedrijf of instelling (vraag, klacht, melding) of een beslissing van het bestuur en wordt behandeld door diensten en medewerkers. Meestal doorloopt een dossier diverse vastgelegde fasen en kent daardoor verschillende voorgedefinieerde statussen. Kerndata zijn bijvoorbeeld aanvragers, onderwerp, behandelende dienst/ambtenaar, status, begin en einddatum (deadline), …
Privacy Een midoffice opent veel perspectieven, maar brengt ook nieuwe aandachtspunten met zich mee, zoals privacy. Sleutelwoorden zijn hier voorzichtigheid, proportionaliteit en finaliteit. Voorzichtigheid: zorg dat een midoffice geen open archiefkast wordt waarin álles wordt opgeslagen. Toon binnen de gestructureerde werkomgeving enkel die gegevens die de gebruiker nodig heeft. Proportionaliteit: vraag overbodige gegevens.
en
bewaar
geen
Finaliteit: alle informatie die je opvraagt moet gebaseerd zijn op een bestuurlijke opdracht (dit kan erg ruim zijn)
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -13-
Moeten dossiers van gemeentelijke administratieve sancties worden opgenomen in het midoffice? Dat een behandelende ambtenaar meteen ziet dat je als burger recht hebt op goedkopere vuilniszakken in het kader van het OMNIOstatuut is wellicht mooi meegenomen. Maar moet die behandelende ambtenaar op de hoogte zijn van jouw klachtenbrief naar de burgemeester en moet de sportfunctionaris van uw recht op het OMNIO-statuut op de hoogte zijn? Privacy-overwegingen spelen trouwens niet enkel een rol bij het verwerken van pure persoonsgegevens maar ook bij ondernemingsgevens (bijvoorbeeld gegevens zelfstandigen), verenigingen (bijvoorbeeld lidmaatschappen) en dossiers (informatie over de aanvrager).
Enkele vuistregels: • Centrale opslag en gebruik van persoonsgegevens van inwoners (wettelijke gegevens zoals naam, voornaam, geboortedatum, geslacht, wettelijk adres, gezinssamenstelling en rijksregisternummer) binnen uw bestuur kan zonder bijkomende machtiging. • Voor centrale opslag en gebruik van persoonsgegevens van niet-inwoners in het kader van bepaalde welomschreven taken en bevoegdheden van het lokale bestuur loopt momenteel een machtigingsaanvraag bij de privacy-commissie. De verwachting is dat hier binnenkort een regeling zal over komen. • Voor het doorgeven van privacy-gevoelige gegevens aan derden is een machtiging vereist. Er wordt momenteel onderzocht in welke mate dit door een globale machtiging zal kunnen worden opgevangen. • Overweeg het gebruik van opt-in waar nodig, bijvoorbeeld voor de niet-wettelijke gegevens zoals telefoonnummer, e-mailadres,…
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -14-
6 Applicatiearchitectuur: de vier basiscomponenten van midoffice Een broker en Lokale Authentieke Bronnen zijn noodzakelijke voorwaarden om een gestructureerde werkomgeving en centraal dossierbeheer te kunnen realiseren.
2. Garantie op volledigheid en betrouwbaarheid: kerndata worden centraal opgeslagen; Dit is een set van Lokale Authentieke Bronnen (LAB) als gegevensbron op de achtergrond.
Wat willen we bereiken en op welke manier? 1. Beschikbaarheid: gegevens opgeslagen op één plaats moeten ter beschikking kunnen gesteld worden op een andere plaats; Een broker of berichtencentrale kan hier voor zorgen en werkt op de achtergrond.
Een berichtencentrale (broker) is erop gericht om berichten uit te wisselen tussen
3. Uitwisselbaarheid van dossiers tussen medewerkers en afdelingen dank zij een “gestructureerde werkomgeving” voor de medewerkers (Workflow, CRM, DMS,…) 4. Gemeenschappelijke dossiergegevens worden centraal opgeslagen in een centrale dossierkast.
verschillende applicaties en lokale authentieke bronnen
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -15-
De lokale authentieke bronnen bevatten de kerndata die uit de verschillende verticale applicaties worden gelicht. Concreet betekent dit dat we een aparte databron voorzien die algemene gegevens bevat waarvan de voornaamste personen (burgers), organisaties (ondernemingen, verenigingen, …) en adressen zijn. De specifieke informatie blijft in de Backoffice . De algemene informatie wordt gelinkt met elkaar via een broker. Bijvoorbeeld: persoonsgegevens
systemen bieden ook een stuk workflow aan. Toch benaderen ze elk de problematiek vanuit een andere invalshoek. Elke organisatie dient na te gaan welke invalshoek het beste bij haar past. Dossiers in de centrale dossierkast vormen het hart van de gemeentelijke of OCMWadministratie. Dit kan om zeer verschillende zaken gaan. Leeflonen, reispaspoorten, klasbezoeken in de bib, milieuvergunningen, aanvragen poetshulp,… Hoe sterk deze zaken ook van elkaar verschillen, ze hebben ook een aantal zaken gemeen.
In diverse Backoffice applicaties en bestanden worden specifieke persoonsgegevens bijgehouden die enkel voor die applicatie relevant zijn: • Is lid van de sportraad stemgerechtigd of niet? • Uitleengeschiedenis van de bibliotheekklant
In het LAB worden algemene persoonsgegevens bijgehouden, deze gegevens worden immers door verschillende toepassingen gebruikt: • • • •
Naam en voornaam Geboortejaar Thuisadres …
De gestructureerde werkomgeving is de component waarmee de eindgebruiker (de medewerker van het lokale bestuur) aan de slag gaat. Dit is meer dan de chaos die Outlook ons biedt. Deze midoffice toepassingen richten zich typisch op organisatiebrede dienstverlening, die niet (uitsluitend) door één van de aanwezige verticale toepassingen in het Backoffice kan uitgevoerd worden, bijvoorbeeld meldingen, briefwisseling, dossieropvolging,… Deze toepassingen kunnen worden onderverdeeld in drie grote groepen: Customer Relationship Management systemen, Workflow Management systemen, en Document Management systemen. De scheidingslijnen zijn niet absoluut. DMSsystemen bevatten ook CRM-functies, CRM-
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -16-
7 Groeipad of groeipijn? De invoering van een midoffice is liefst geen Big Bang. Het zal dan ook gefaseerd verlopen.
input van webformulieren doorspelen aan de betrokken backoffice applicatie.
Enkele vragen zijn daarbij belangrijk:
Een Persoonlijke Internet Pagina voor de burger is echter nog niet mogelijk. Er is nog geen centrale gegevensbron of dossierkast, wat betekent dat de PIP slechts kan worden opgebouwd door de informatie bij verschillende backoffice applicaties te gaan opvragen. Dit is qua performantie onhaalbaar.
Welke componenten worden het eerst ingevoerd en waarom? Begin met een broker en/of een LAB, vooraleer je aan workflow of dossier management systeem begint. Welke mate van integratie kan en moet er gerealiseerd worden? Welke kerndata worden “overgeheveld” van de backoffice naar de midoffice? Wat winnen we er mee? Gaat het om een zwakke integratie of sterke integratie? Vermijd een superapplicatie en een superdatabank. Kunnen we fases herkennen? Niet elk bestuur zal er ook voor kiezen om door te groeien naar een volwaardig midoffice. Een midoffice is bovendien nooit af, maar blijft een dynamisch geheel. Om duidelijk te maken wat de implicaties zijn, geven we bij elke fase weer welke gewenste situatie hiermee wordt gerealiseerd (zie hoofdstuk 2: meerwaarde voor de burger, de medewerker, de beslissingsnemer).
7.1 Starten met een broker? De installatie van een broker biedt het voordeel dat de informatiebeheerder beschikt over een instrument om de wildgroei aan ad hoc koppelingen enigszins te beheersen. We stoppen bijvoorbeeld met het leggen van “aparte lijntjes” tussen toepassingen. Een broker zorgt dat dit snel en eenvoudig kan waar en wanneer nodig. Dit is slechts een eerste stap, waarbij eigenlijk nog niet van een midoffice kan gesproken worden. Maar er zijn al enkele belangrijke voordelen. Er is een betere beheersing van de koppelingen tussen verschillende applicaties in de backoffice en een eerste minimale beheersing van de link tussen backoffice en frontoffice. In plaats van bij elke applicatie een webluik te voorzien, kan een broker de
Een gestructureerde werkomgeving (“werkbakjes”) voor de medewerker of real time beleidsinformatie is met deze oplossing nog niet voorhanden. Deze brokeroplossing is uiteraard enkel zichtbaar voor de informatie- en/of systeembeheerder. Voor de rest van de organisatie blijft deze oplossing “onder water”. Dit maakt het soms moeilijk verkoopbaar binnen het bestuur.
7.2 Dan maar liever starten met een LAB? De uitbouw van een LAB biedt het voordeel dat de informatiebeheerder beschikt over een instrument om de wildgroei aan verschillende informatiebronnen over personen, bedrijven, adressen en dossiers enigszins te beheersen. Dit is slechts een eerste stap, waarbij een centraal LAB wordt geïnstalleerd dat echter quasi-manueel wordt bijgehouden. Dit LAB is niet automatisch gekoppeld aan de verschillende backoffice applicaties maar wordt gevoed door het regelmatig inlezen van bronbestanden zoals VKBO en CRAB en manuele bijhoudingen. De informatie in het LAB is voor zoveel mogelijk medewerkers in het bestuur bereikbaar die op die manier toegang krijgen tot de kerndata. Goede afspraken en procedures hierover zijn van groot belang voor het succes.
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -17-
Een Persoonlijke Internet Pagina voor de burger is hier ook nog niet mogelijk. Een gestructureerde werkomgeving (“werkbakjes”) voor de medewerker is niet beschikbaar, maar
hij heeft wel toegang tot kerndata en verliest geen tijd met het beheren en opzoeken ervan. Beperkte beleidsinformatie wordt in deze fase mogelijk door opzoekingen in het LAB.
7.3 Lab + Broker = Kern midoffice De combinatie van een broker en een LAB zorgt ervoor dat kerndata beter kunnen gedeeld worden over de gehele organisatie. De kerndata worden opgeslagen in een centraal bestand, de broker zorgt voor de data-uitwisseling tussen centraal gegevensbestand en applicaties in de backoffice en frontoffice. Voordelen worden stilaan duidelijk. Diensten vermijden dubbele invoer van bijvoorbeeld adresgegevens in tientallen verschillende databronnen. Gecentraliseerde data kunnen gemakkelijker en zonder extra inspanning beschikbaar gesteld worden aan verschillende diensten zonder ingewikkelde kennis van specifieke backoffice applicaties. Een Persoonlijke Internet Pagina wordt mogelijk voor wat betreft gemeenschappelijke gegevens (bijvoorbeeld ‘mijn contactgegevens’, ‘mijn buurt’,…). Er is wel nog geen centrale dossierkast, wat betekent dat de PIP geen statusinformatie over alle lopende dossiergegevens bevat. Ook dit kern midoffice blijft grotendeels “onder
water”. De broker en het LAB “praten” met applicaties, niet rechtstreeks met medewerkers. Dit gebeurt pas bij het toevoegen van een gestructureerde werkomgeving (Workflow, DMS, CRM). Volgens sommigen is deze configuratie voldoende als midoffice. Waar het immers om gaat is de integratie van gegevens en applicaties, niet zozeer om het toevoegen van nóg een nieuwe applicatie. We moeten er inderdaad over waken dat de midoffice geen gesloten doos naast de andere wordt. Daartegenover staat dat velen bij het woord midoffice vooral aan bepaalde nieuwe werkomgevingen denken die momenteel op de markt worden aangeboden: CRM-systemen, workflowtoepassingen, document management systemen,… Het is echter belangrijk om, wanneer we deze omgevingen in de organisatie introduceren, verder te bouwen op een stevig fundament (in de vorm van een broker en een LAB) en niet op los zand.
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -18-
7.4 Naar een gestructureerde werkomgeving Door een digitale werkomgeving met centrale dossierkast in gebruik te nemen, wordt het mogelijk om de gemeenschappelijke aspecten van dossiers zichtbaar en behandelbaar te maken binnen de midoffice. Dit gebeurt vanzelfsprekend niet voor alle dossiers in één keer. Per product en/of proces moet bekeken worden waar het meeste winst te halen valt (zie ook procesarchitectuur). De integratie kan afhangen van proces tot proces. Voor sommige processen bestond misschien geen backoffice toepassing. Vaak kunnen die binnen de midoffice worden opgenomen,
bijvoorbeeld het meldingsproces. Voor andere processen bestaat een gehele of gedeeltelijke backoffice toepassing. Belangrijk is dat de gemeenschappelijke dossiergegevens via de midoffice zichtbaar worden (bijvoorbeeld status van een uitgeleend boek in de bib) en eventueel aanpasbaar (bijvoorbeeld mogelijkheid om een boek te verlengen). Beleidsinformatie op basis van gegevens uit de centrale dossierkast wordt mogelijk. Bijvoorbeeld de gemiddelde doorlooptijd van een bouwvergunning, aantal meldingen, klachten en infovragen per maand,…
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -19-
8 Een pragmatische aanpak De theorie in het vorige hoofdstukje gaat er van uit dat we eerst de fundamenten leggen om vervolgens de zichtbare delen daarop te bouwen. Dit klinkt logisch maar binnen nogal wat besturen zullen medewerkers de grootste moeite hebben om hun bestuur ervan te overtuigen aanzienlijke bedragen te investeren voor een resultaat dat noch voor de burger, noch voor de medewerker een zichtbare verandering en onmiddellijke verbetering met zich meebrengt. Een CRM, Workflow of DMS -systeem dat wordt geïnstalleerd zonder gegevensdeling (verzorgd door een broker) of dat geen beroep doet op authentieke data (aangeleverd door een LAB) is niet meer dan een zoveelste gesloten doos in het bestuur. Toch lijkt vaak de drang naar een CRM, Workflow of DMS systeem veel groter dan deze naar een LAB en/of broker. Daarom is een zichtbare ‘quick win’ soms belangrijk. Behandeling van meldingen, inscannen binnenkomende facturen, postregistratie zijn kandidaten voor deeloplossingen die de mogelijkheden van een informatiearchitectuur kunnen demonstreren. Maar ook bij deze deeloplossingen is het noodzakelijk om meteen het goede fundament te leggen en de brokerfunctie en opslag
van kerndata mee te voorzien als we willen vermijden dat we een silo naast de andere silo’s bouwen. Een “one size fits all” oplossing bestaat niet. Een gemeente met slechts vijftig bouwaanvragen per jaar moet deze niet per se in een opvolgingssysteem willen stoppen, maar wellicht is dit voor middelgrote en grote besturen anders,… Voor kleinere gemeenten is samenwerking wellicht een aangewezen oplossing, niet alleen wat betreft applicaties, maar ook voor het delen van competenties en personeel. Zoals reeds aangehaald in het hoofdstuk over midoffice en organisatie mogen we zeker niet alle heil verwachten van een doorgedreven automatisatie. Een intelligente informatiearchitectuur kan niet als bedoeling hebben de intelligentie van de individuele medewerker buitenspel te zetten. Klantgerichte dienstverlening, verstandige interpretatie bij uitzonderlijke dossiers, goede afweging bij beleidsondersteuning en –uitvoering, …het blijft mensenwerk. Een duurzame en goed uitgebouwde informatiearchitectuur blijft daarbij wel onmisbaar willen we van onze lokale besturen klantgerichte en slimme organisaties maken.
0101010101010101010101010101010101010101010101010101010101010101010101010101010 -20-
INHOUDSTAFEL 1 Waarom midoffice?............................................................................................................. 2 1.1
Wat wil de burger?............................................................................................. 2
1.2
Wat wil de medewerker?.................................................................................... 3
1.3
Wat wil de beslissingsnemer?............................................................................. 3
1.4
Uitdagingen....................................................................................................... 4
2 Midoffice? Que?.................................................................................................................. 6 3 Midoffice in uw organisatie: kantelen of koppelen?............................................................ 8 4 Processen en producten staan centraal............................................................................... 11 5 Informatiearchitectuur: wat zijn onze kerndata?................................................................. 12 6 Applicatiearchitectuur: de vier basiscomponenten van midoffice........................................ 15 7 Groeipad of groeipijn?........................................................................................................ 17 7.1
Starten met een broker?..................................................................................... 17
7.2
Dan maar liever starten met een LAB?................................................................ 17
7.3
Lab + Broker = Kern midoffice............................................................................ 18
7.4
Naar een gestructureerde werkomgeving........................................................... 19
8 Een pragmatische aanpak.................................................................................................. 20
1010101010101010101010101010101010101010101010101010101010101010101010101010101 -21-
0101010101010101010101010101010101010101010101010101010101010101010101010101010
