De Amsterdamse politie experimenteert met een geïntegreerd management-informatiesysteem . Daarbij wordt gebruik gemaakt van de concepten ‘datawarehousing’ en ‘executive information system’ (eis). De proef heeft aangetoond dat het ontwikkelen en invoeren van een dergelijk geïntegreerd informatiesysteem een geheel eigen aanpak behoeft. Dat geldt eveneens voor de modelvorming, de organisatie- en systeemontwikkeling en het beheer.
Ook na de grote reorganisatie van 1994 is de kritiek op het Nederlandse politie-apparaat niet verstomd. Zo wijst de Algemene Rekenkamer op de gebrekkige informatievoorziening. Het door de politiek gewenste ‘blauw op straat’ blijkt niet te tellen. De verschillende corpsen hebben verschillende geautomatiseerde systemen in gebruik en hanteren bovendien verschillende definities voor het begrip ‘politieagent’. Onduidelijk is waarvoor de vele miljoenen guldens die extra beschikbaar zijn gesteld, nu precies zijn ingezet. De kritiek spitst zich toe op de (slechte) kwaliteit van de bestuurlijke informatievoorziening, waardoor het management lastig kan sturen op resultaten en effecten.
Toch hebben politiemanagers steeds meer aandacht voor zaken als ‘planning en control’, kwaliteitsmeting en -borging, prestatie-indicatoren, besturingsmodellen en integrale managementconcepten. De relatie tussen begrote en feitelijk ingezette capaciteit in mensen, geld en materiaal, de uiteindelijke resultaten en de mogelijkheden om daarop anticiperend te sturen, worden voor hen steeds interessanter. Vandaar dat er ook een toenemende behoefte is aan een integrale informatievoorziening.
Het probleem is echter dat de bestaande systemen die integrale informatie niet kunnen leveren. De politie kent voornamelijk functioneel georiënteerde informatiesystemen die slechts één aspect van de bedrijfsvoering beslaan. Zo zijn er ondermeer systemen voor personeelsinformatie, inzetplanning, de meldkamer, financiën en het opmaken van processen verbaal. Ze hebben als kenmerk dat zij zich richten op administratieve registratie, stuksgewijze transactieverwerking en rapportage op het eigen gebied.
De politiemanager moet verschillende informatiesystemen raadplegen om inzicht in zijn organisatie-onderdeel te krijgen. Daarvoor is hij afhankelijk van de applicatiebeheerders van de diverse systemen. Zij programmeren de vraag van de manager en laten die los op het betreffende systeem. Afhankelijk van de frequentie waarmee een politiechef de stand van zaken wil bekijken, kan dit voor beide partijen een behoorlijk tijdrovende klus zijn. De manager zal de verschillende gegevens naast elkaar leggen en met elkaar in verband (trachten te) brengen om vervolgens actie te ondernemen. Om dit te kunnen doen, dient voldaan te zijn aan zogeheten sturingsvoorwaarden (zie tabel 1).
| Sturingsvoorwaarde: | Probleem: |
| Gegevens over het werkaanbod (Input). | Gegevens over de omgeving van het organisatieonderdeel vaak niet beschikbaar. |
| Een beeld hebben van het te besturen systeem (throughput). | Vaak ontbreekt een systematische beschrijving van de administratieve organisatie. |
| Gegevens over de resultaten (output). | Geen samenhangend beeld aanwezig door functionele scheiding informatiesystemen. Weinig kengetallen. |
| Minimaal één stuurmaatregel per activiteit. | Stuurmaatregelen raken vaker de symptomen dan de onderliggende oorzaken. |
| Een beeld hebben van de actuele toestand. | Niet integraal, wel per aspect. |
| Normen voor de resultaten om (bij) te kunnen sturen. | Normen en doelstellingen vaak niet kwantificeerbaar geformuleerd. |
Tabel 1. Overzicht van de knelpunten. Uit Organisatie: Management, analyse, ontwerp en verandering. Een systeemvisie. Prof. dr A.C.J. de Leeuw. Van Gorcum, Assen, 1990
Uiteraard zijn er afdelingen die relevante (statistische) gegevens voor het korps verzamelen en bundelen. De actualiteit van die informatie is meestal snel achterhaald, aangezien de frequentie waarmee de informatie wordt uitgebracht in het algemeen laag is en de gegevens tussentijds worden gemuteerd. De informatie is dan ook meer bedoeld om achteraf beslissingen te kunnen verantwoorden, dan om vóóraf op te kunnen sturen.
Proefproject Stuurhut
Het ondersteunen van het management bij de integrale besturing van zijn organisatie is dus in de eerste plaats een kwestie van het ontwikkelen van een politie-specifiek besturingsmodel en in de tweede plaats van informatisering. Momenteel wordt in een landelijk platform gezocht naar een standaard besturings- en gegevensmodel voor de politie-organisatie. Voor de verbetering van de informatievoorziening is in 1996 het proefproject ‘Stuurhut’ gestart. De proef vindt in Amsterdam plaats en richt zich op de verbetering van de informatievoorziening voor een integrale bedrijfsvoering. De beeldspraak in de naam verwijst naar de wens om op overzichtelijke wijze managementinformatie en daarmee stuurmogelijkheden aan het, vooralsnog, tactisch management ter beschikking te stellen.
Het achterliggende idee is dat het management de beschikking moet krijgen over een gebruikersvriendelijk geautomatiseerd hulpmiddel waarmee het op elk gewenst moment juiste en actuele gegevens over een aantal kritische indicatoren kan raadplegen. Het gaat dan om wekelijkse of maandelijkse gegevens en kengetallen die relevant zijn voor de sturing van de bedrijfsvoering op tactisch niveau en voor management-rapportages aan de korpsleiding. Gezien de toenemende aandacht voor de samenleving waarin de politie acteert, worden ook gegevens uit externe bronnen, zoals sociaal-economische en demografische statistieken en justitiële informatiesystemen, opgenomen. Uit privacy-overwegingen is gekozen voor het opslaan van uitsluitend geaggregeerde gegevens in het gegevenspakhuis. Voor informatie op detailniveau, die meestal toch operationeel gericht is, wordt verwezen naar de rapportagefuncties van de bronsystemen.
De ervaringen van de gebruikers met het systeem moeten inzicht geven in het impliciet aanwezige sturingsmodel en in de vraag welke indicatoren relevant zijn. Daarbij wordt aansluiting gezocht bij de bevindingen van het eerder genoemde landelijke platform.
Bewust is voor gekozen om niet het zoveelste onderzoek uit te voeren naar de problematiek van de integrale informatievoorziening. Die zijn er al genoeg, zonder dat er veel mee gebeurt. In plaats daarvan is besloten om een werkend model te ontwikkelen volgens de principes van timeboxing en prototyping en met dit model de mogelijkheden en beperkingen van een integraal informatiesysteem te demonstreren. Er werd een projectteam geformeerd dat bestond uit interne deskundigen die de conceptuele ontwikkeling voor hun rekening namen. Voor de technische ontwikkeling van het systeem werd gebruikt gemaakt van externe expertise. Het team werd gehuisvest op één kamer, hetgeen de communicatie sterk bevorderde.
De projectaanpak kende een sterk bottom-up karakter. Eerder formuleerden managers in decisionroom-sessies de in hun ogen kritieke stuur-indicatoren. Van de 34 benoemde indicatoren, werden er 22 in het model geïmplementeerd. De beschikbaarheid van de informatie en de haalbaarheid om deze ook werkelijk in het systeem getoond te krijgen, waren belangrijke selectiecriteria.
Aan de districten werd vervolgens gevraagd het prototype te beoordelen en hun bevindingen vast te leggen in een logboek. Op één na hebben alle districten het model gebruikt. Hun ervaringen werden individueel en groepsgewijs door het ontwikkelteam geëvalueerd en dienden als input voor de tweede versie van het prototype.
Soort automatische piloot
De bevindingen uit die demonstratiefase vormden de basis voor de bouw van een productieversie van het systeem. Om de betrokkenheid van de gebruikers hoog te houden is gekozen voor een incrementele aanpak, waarbij het productiesysteem in vier releases werd gerealiseerd; de evaluaties van iedere release werden verwerkt in de volgende release.
De verwachtingen bij de gebruikers waren hooggespannen. Zij dachten met ‘Stuurhut’ een soort automatische piloot voor de bedrijfsvoering te krijgen. Binnen de politie leefde bijvoorbeeld het idee dat het systeem bij een stijging van het aantal woninginbraken automatisch zou gaan uitrekenen hoeveel uren extra surveillance waar en wanneer zouden moeten worden ingezet om deze toename terug te dringen. Het managen van deze verwachtingen vormde een belangrijk aandachtspunt voor het ontwikkelteam. De gebruikers is nadrukkelijk te verstaan gegeven dat de ‘Stuurhut’ uitsluitend ondersteunend is bij het nemen van beslissingen, maar nooit de kunde en vaardigheden van de manager kan vervangen bij de beoordeling van situaties en het bepalen van de te nemen acties.
Op dit moment bestaat nog weinig inzicht in de samenhang en causale relaties tussen inzet, resultaten en effecten van politiezorg. Het ambitieniveau van het proefproject is daarop afgestemd. Dat betekent dat in deze fase van de ontwikkeling de eerste prioriteit ligt bij het tonen van de juiste cijfers. De volgende stappen lopen van het ontwikkelen van enkelvoudige kengetallen voor een indicator tot het uiteindelijk vaststellen van een causale relatie voor een indicator.
Simpel, bijna naïef systeem
De eindgebruiker beschikt over een Windows-PC die is aangesloten op het korpsnetwerk. Via de eis-applicatie krijgt de gebruiker met de muis toegang tot gegevens (in tabel- en grafiekvorm) over een aantal rubrieken (zie tabel 2).
| Omgeving (in) | Organisatie | Omgeving (uit) |
| Inwoners | Formatie/sterkte | Meldingen |
| Huishoudens | Personeelsbezetting | taakstraffen (HALT) |
| Bedrijven/instellingen | Inzet capaciteit | Slachtofferhulp |
| Bodemgebruik | Budgetten | Justitiële afdoeningen |
| Urbanisatie | Ziekteverzuim | |
| Woningen | ||
| Leefbaarheid | ||
| Veiligheid |
Tabel 2. Via de eis-applicatie is toegang mogelijk tot een aantal gegevensrubrieken.
Aan de hand van selectieschermen kiest hij de tijdsperiode waarover en de organisatie-onderdelen (regio, district, wijkteam) waarvan hij gegevens wil hebben. Binnen de schermen kan hij met de muis inzoomen op detailinformatie. Overigens kunnen de gegevens alleen geraadpleegd en afgedrukt worden. De gebruikersinterface is verder simpel, zelfs op het naïeve af. Binnen vijf minuten kan iedere politiechef met het systeem werken.
Een aandachtspunt bij het ontwerpen en beheren van de gebruikersinterface vormt het feit dat de eis-omgeving niet intelligent genoeg is om te reageren op veranderingen in de structuur van de bronsystemen. Wanneer in een bronsysteem een bepaald veld niet meer bestaat of van naam verandert (bijvoorbeeld het veld ‘arbeidsrelatie’ heet voortaan ‘dienstverband’) dan heeft de gebruikersinterface daarvan geen ‘weet’. De beheerder moet hierop alert zijn en handmatig de interface aanpassen.
Via het netwerk is de gebruiker verbonden met een centrale server waarop het gegevenspakhuis en de applicatie zijn geplaatst. Het pakhuis is in feite een afzonderlijke database, waarin gegevens worden opgeslagen die uit verschillende bronsystemen afkomstig zijn, zonder dat daarbij de functionele omgeving waarin die systemen functioneren of de daarin opgeslagen data worden aangetast. De gebruiker heeft op deze wijze de mogelijkheid om op elk moment van de dag het gegevenspakhuis te bevragen op (actuele) informatie zonder dat dit de performance van de bronsystemen beïnvloedt.
Historie van de gegevens
Een andere functie van het gegevenspakhuis is het opbouwen van historie van de verzamelde gegevens om tijdreeksen en periode-vergelijkingen mogelijk te maken. Het vasthouden van een consistente historie is geen eenvoudige opgave. Dat heeft niet alleen te maken met de genoemde veranderingen en hergebruik van coderingen en omschrijvingen. Ook de continue veranderingen in de externe en interne omgeving van de organisatie spelen een rol. Waar bijvoorbeeld in het ene jaar een bepaald soort delict door ieder wijkteam wordt aangepakt, wordt in een volgend jaar daarvoor een centrale projectorganisatie ingesteld. In een tijdreeks verdwijnt hierdoor de mogelijkheid gegevens zinvol te vergelijken. Continu komt het voor dat organisatie-onderdelen verdwijnen, ontstaan, samengevoegd of juist gesplitst worden. Ook komt het voor dat de naam van een onderdeel hetzelfde blijft, maar dat de taakstelling verandert.
Het gegevenspakhuis beschikt ook over functies om de vaak cryptische veldbenamingen te vertalen in begrijpelijke termen. De functionele scheiding van de bronsystemen en het gebruik van verschillende coderingen maken het noodzakelijk om in het pakhuis een grote hoeveelheid vertaal- en koppeltabellen in te richten. Dit vergt een aanzienlijke beheersinspanning omdat er geen mechanisme is om deze tabellen automatisch aan te passen bij iedere wijziging in de bronsystemen. Er is geen duidelijk centraal punt dat de wijzigingen in coderingen coördineert. Door de applicatiebeheerders van de diverse systemen wordt nog te weinig gekeken naar de impact van een codeverandering voor het gegevenspakhuis (en andere systemen). Daarnaast worden op handen zijnde veranderingen meestal achteraf aangekondigd.
Tenslotte worden ‘oude’ bedrijfsprocessensystemen vervangen door nieuwe, waardoor het risico op een trendbreuk reëel aanwezig is. Gezien het aantal bronsystemen is er op enig moment altijd wel een systeem dat vervangen wordt. Als tijdens de migratie niet ‘schaduw’ wordt gedraaid, ontstaan er onherroepelijk trendbreuken.
Integrale informatie noodzaak
Middleware is programmatuur die zorgt voor het fysiek benaderen van de bronsystemen, het uitvoeren van selecties, het aggregeren van de gewenste velden en records en het overbrengen van gegevensverzamelingen naar het gegevenspakhuis. Afhankelijk van het soort gegevens, vindt de verversing van het pakhuis wekelijks, maandelijks of jaarlijks plaats. Gegevens uit externe bronnen worden vanaf diskette ingelezen.
Om de bronsystemen fysiek te kunnen benaderen, moet bekend zijn welke tabellen en velden opgehaald dienen te worden. Wijziging van tabelnamen in het bronsysteem, leidt ertoe dat de middleware die niet langer kan benaderen. Ook hier geldt dat meestal achteraf wordt geconstateerd dat deze zijn gewijzigd.
Zowel voor de opbouw van de historie als voor de benadering van de bronsystemen zou het wenselijk zijn een centrale database administrator aan te stellen. Deze functionaris zorgt voor de ontwikkeling en het beheer van een (corporate) datamodel. Daarnaast zou ook het harmoniseren van de niet eensluidende coderingen van dezelfde entiteiten (bijvoorbeeld organisatiecodes) tot het takenpakket van de database administrator moeten behoren.
Bronsystemen zijn de systemen die ten behoeve van de bedrijfsprocessen on-line benaderd kunnen worden en waar de feitelijke gegevensinvoer plaatsvindt. Zowel het functioneel scheiden van de bronsystemen als de noodzaak om een horizontale doorsnede van de bronsystemen te maken, vormen een uitdaging. Ten eerste dient de verdeling van het functionele beheer over enerzijds management-informatiesystemen en anderzijds de bedrijfsprocessensystemen helder te worden gemaakt. Daarnaast moet het inzicht worden gestimuleerd dat integrale managementinformatie noodzakelijk is voor een efficiënte en effectieve politiezorg en dat daarvoor in de informatiehuishouding nieuwe randvoorwaarden en condities gecreëerd moeten worden. Tenslotte dienen niet-eensluidende definities van gegevens uit eigen bronsystemen en externe bronnen, te worden geharmoniseerd. In deze fase van het proefproject is gebleken dat het helder krijgen van indicatoren die werkelijk van belang zijn voor de besturing van een dienstverlenende organisatie als de politie een geleidelijk leer- en ontwikkelingsproces is. Gegevensdefinities vormen daarbij een groot probleem. Over voor de hand liggende items blijken geen of geen eensluidende definities voorhanden. Vraag zes politiemensen wat zij verstaan onder een ‘opgeloste zaak’ en er komen zes uiteenlopende antwoorden.
Proces ’t moeilijkst
Gezien de positieve reacties van de in het traject betrokken managers kan geconcludeerd worden dat een toenemende behoefte bestaat aan concepten als ‘datawarehousing’ en ‘executive information system’ waarmee managementinformatie is te genereren, te bewerken en toegankelijk is te maken. Daarbij ligt de moeilijkheid van de toepassing van dit soort concepten niet zozeer op het technische vlak als wel op het procesmatige. Om een gegevenspakhuis en een eis met succes te realiseren en te beheren is een bottom-up aanpak met een incrementeel karakter noodzakelijk. De beheertools behoren voldoende intelligentie te bezitten om het handmatige beheer tot een minimum te beperken. Daarnaast is de beschikbaarheid van heldere en eenduidige gegevensdefinities op basis van een ‘corporate datamodel’ noodzakelijk. Tenslotte is de aanwezigheid geboden van een centrale en met bevoegdheden beklede data administration-functie en een eigen applicatiebeheersfunctie die eisen mag stellen aan de bronsystemen geboden.
J.E. de Boer en mw drs C. Pranger, respectievelijk projectleider en beleidsmedewerker bij de Dienst Informatiezaken en Automatisering van de Regiopolitie Amsterdam-Amstelland.
