Vorige week las ik het berichtje “Reimerswaal implementeert zaakgericht werken met vallen op opstaan” van KING. De boodschap die na het lezen blijft hangen, is dat deze gemeente jarenlang zo druk is geweest met het werkend krijgen van de techniek, dat ze aan de organisatie, laat staan de inwoner, nog nauwelijks is toegekomen. En dat terwijl het verbeteren van de dienstverlening en optimaliseren van werkprocessen nu juist de drijfveren waren om met zaakgericht werken aan de slag te gaan. Ruim tien jaar na de opkomst van zaakgericht werken is Reimerswaal helaas nog steeds geen uitzondering.

Zoek de verschillen
Zaakgericht werken had nu juist het antwoord moeten zijn op de vele projecten die zijn verzand in technische onmogelijkheden. Wat destijds zo aantrekkelijk was aan het concept, is dat het met relatief eenvoudige ingrepen de gemeentebrede informatievoorziening kan verbeteren.

Na eindeloze projecten om processen in te richten in workflow, beperkte zaakgericht werken zich liever tot het vastleggen van de gemaakte afwegingen, statussen en doorlooptijd.
In plaats van een ingewikkelde architectuur waar de informatie van één proces wordt versnipperd over losse applicaties voor bijvoorbeeld webformulieren, klantcontact, zaakinformatie, documentcreatie en documentopslag, maken voortvarende gemeenten vooral gebruik van een zaaksysteem dat dat allemaal integraal kan. En murw van moeizame projecten om specialistische backoffice applicaties te koppelen, werd veelal volstaan met ‘kloppelen’ (overtikken), of bleek men het vaak zelfs zonder een apart backoffice pakket te kunnen stellen.
Om de vaart er in te houden en de kosten in de hand, is het minstens zo belangrijk dat de organisatie niet meer afhankelijk is van de specialistische kennis van de leverancier(s) voor de inrichting van processen en zaaktypen. De voorlopers boekten hun successen met systemen waarin dit snel, flexibel en gebruiksvriendelijk zelf kan worden gedaan.

Beter ten halve gekeerd...
Herken je je eigen project voornamelijk in het verhaal van Reimerswaal en nauwelijks in bovenstaande pragmatische keuzes? Vraag je dan eens af of je echt de tijd en het geld hebt om te accepteren dat je constant met leveranciers aan tafel moet om technische strubbelingen op te lossen. En of je aan je opdrachtgever en de organisatie wilt blijven uitleggen dat je aan het oorspronkelijk doel van betere dienstverlening en efficiëntere werkprocessen nog steeds niet bent toegekomen.

Soms kun je beter een paar stappen terug zetten, om een grote sprong vooruit te maken. Als je terugkeert naar de tekentafel om je informatiearchitectuur van overbodige complexiteit te ontdoen, dan moet je misschien zelfs opnieuw beginnen. Maar als je op die manier je tijd en geld weer kunt gaan steken in het realiseren van je doel, in plaats van de technische randvoorwaarden, dan is het dat in mijn ogen dubbel en dwars waard.