Door middel van een zaaksysteem een aantal werkprocessen binnen je organisatie moderniseren. Het klinkt simpel, maar bij de gemeente Best hebben ze de afgelopen jaren ervaren dat de werkelijkheid vaak weerbarstiger is. Omdat het probleem groter is dan Best of Brabant, wil zij de geleerde lessen graag delen met collega-gemeenten.
Kermis in Best. De gemeente leerde veel van een showcase rondom het proces evenementenvergunningen.
Betere dienstverlening richting burgers en bedrijfsleven, efficiëntere bedrijfsvoering en meer regie over het eigen informatiebeleid. Vraag het een willekeurige Nederlandse gemeente en grote kans dat het bovenaan de agenda staat. Zo ook bij Best, een gemeente met bijna 29.000 inwoners en gelegen ten noordwesten van Eindhoven.
Een van de acties die in het kader van de optimalisering van de dienstverlening, bedrijfsvoering en informatiebeleid eind 2012 werd opgestart, was de modernisering van een aantal werkprocessen. “Ter ondersteuning hebben we gekozen voor een zaaksysteem dat aansloot bij onze wensen”, aldus Magda Klomp, afdelingsmanager Ondersteuning en verantwoordelijk voor onder meer informatiemanagement en automatisering. “In eerste instantie verliep dat soepel, waren we ook erg trots dat het gerealiseerd was, maar na drie maanden gebruik kwamen de eerste lasten. In plaats dat het systeem voordeel opleverde, moesten onze mensen extra handelingen verrichten. Ondanks afspraken met de leverancier van het zaaksysteem bleken koppelingen tussen de diverse systemen niet te werken of te maken. Dat heeft ertoe geleid dat we besloten hebben om even een rustpauze in te gelasten.”
Showcase
De rustpauze duurde tot januari 2014. In die maand werd in Best een bijeenkomst gehouden waarbij met KING en meerdere leveranciers afspraken werden gemaakt over een gezamenlijk vervolg. Een showcase rondom het proces evenementenvergunningen stond daarin centraal. Afgesproken werd onder meer dat het proces in juni 2014 zou zijn afgerond. Dat bleek te ambitieus. “Onderweg hoor je dat de operationele overleggen plaats hebben gevonden, maar dat het allemaal weerbarstig is. Dat het soms moeilijk was om partijen bij elkaar te laten komen en dat het niet altijd duidelijk was wie de regie had”, zo schetst Philip Bosman, directeur bij de Brabantse gemeente. “Op verzoek van de andere partijen hebben wij in juni meer de regisseursrol gepakt, onder meer door het aanstellen van een extern adviseur. Daarbij hebben we de voorwaarde gesteld dat de showcase in december 2014 klaar moest zijn. Ook dat bleek uiteindelijk niet haalbaar.”
De extern adviseur stelde onder meer een lijst van 175 acties samen die nodig waren om één evenementenvergunning te regelen. “Dat ging om een aantal basale acties, maar er zaten ook zwaardere acties bij”, aldus Magda Klomp. “Zoals het upgraden van software, het realiseren van nieuwe versies en het ontwikkelen van standaardkoppelingen.”
Cocreatie
Waarom het halen van een deadline met betrekking tot de showcase zo moeilijk bleek? Bosman geeft een combinatie van factoren aan. “De gebruikte definities van de door KING opgestelde en ontwikkelde standaarden bleken in de praktijk niet altijd overeen te komen. En ook door een andere manier van werken. Met leveranciers en KING zijn we in feite bezig met gezamenlijk innoveren, met cocreatie. Dat maakt dat er een gezamenlijk belang in zit. In dat kader hebben we ook aangegeven dat wij er graag een steentje bovenop plaatsen mochten de problemen aan ons te wijten zijn. Gezamenlijk hebben we er immers belang bij dat het slaagt. Want als de showcase werkt in Best, werkt het waarschijnlijk ook voor andere gemeenten.”
Ook Magda Klomp geeft aan dat, ondanks de problemen, het voortdurend de intentie is geweest om er samen uit te komen. “Gezamenlijk wilden we het probleem neerzetten en zoeken hoe we in de nabije toekomst dit als gemeente, leveranciers en KING beter zouden kunnen doen zodanig dat andere gemeenten er ook baat bij hebben.”
Identieke bedrijfsprocessen
Dat gemeenten, leveranciers en KING meer moeten samenwerken en standaardiseren, daar is ook wethouder Peet van de Loo van overtuigd. Zo zou zij maar wat graag zien dat gemeenten aan vraag- en aanbodzijde meer zaken gaan bundelen. “Onze inwoners verwachten steeds meer van ons als het gaat om digitale dienstverlening. Ik vind het niet verstandig dat iedere gemeente zelf zoveel belastingcenten steekt in de ontwikkeling van die digitale processen. Natuurlijk zitten er verschillen in die processen, producten en dienstverlening, maar in feite zijn er 600 werkprocessen die voor iedere gemeente bijna identiek zijn. Als gemeente kun je je onderscheiden, bijvoorbeeld als het gaat om het openhouden van het zwembad of de aanleg van extra wegen. Maar als gemeenten moeten wij niet uniek willen zijn als het gaat om de achterliggende bedrijfsprocessen.”
Leveranciers
Ook al omdat de gemeentemarkt een vrij kleine markt is (“Er zijn minder dan 400 gemeenten waar leveranciers hun producten kunnen slijten”), pleit Van de Loo voor vraag- en aanbodbundeling. Iets dat voor leveranciers nog niet altijd vanzelfsprekend is. “De meeste van hen hebben producten ontwikkeld die ze eerst terug willen verdienen, waardoor er relatief veel maatwerk wordt geleverd. Dat zou je eigenlijk niet moeten willen, maar vanuit het gezichtspunt van de leverancier is het ook wel weer begrijpelijk. Die moeten er alles aan doen om hun broek op te houden. Hoe we dat toch kunnen doorbreken? Het zou mooi zijn als alle spelers een stuk budget vrijmaken om gezamenlijk een soort ontwikkelteams te formeren waarbij gekeken wordt welke dingen voor de toekomst écht nodig zijn. Wat is de basisinfrastructuur die iedere gemeente nodig heeft? Dan maak je tenminste een slag. Nu blijven we hangen.”
Dat de situatie in Best niet op zichzelf staat, blijkt onder meer uit een bezoek dat Van de Loo, Klomp en Bosman recent brachten aan de gemeente Utrecht. “Daar merkten we dat zij tegen dezelfde problematiek aanliepen. Interessant, want dat betekent dat geld of de grootte van een gemeente geen rol speelt”, aldus Philip Bosman.
Lessons learned
Wat een paar jaar geleden begon met ideeën over modernisering van werkprocessen, heeft in februari geleid tot de oplevering van de showcase evenementenvergunning. Een proces dat de gemeente Best veel heeft geleerd. Bosman: “Ondanks alles is de relatie met leveranciers en met KING goed gebleven. Ik denk dat de open relatie en de ruimte die we hebben gehad, geboden en gecreëerd voor cocreatie daaraan heeft bijgedragen.”
Wat Peet van de Loo betreft is het ook positief geweest dat partijen verder hebben gekeken dan alleen het praktijkprobleem. “Omdat én directies van gemeenten én directies van leveranciers samen met KING om tafel zaten, konden we ook naar de achterliggende problemen kijken. Daardoor kwamen we ook met oplossingen op een hoger niveau, zoals de constatering dat vraag- en aanbodbundeling noodzakelijk zijn. Met nieuwe spelers op de markt lossen we het probleem niet op en ook aan de houding van mensen of het agendabeheer mankeert niets. We hebben een systeemverandering nodig. Doen we dat niet, dan zullen we nog lang door blijven modderen. Dat moeten we niet willen…”
Het is niet de eerste keer dat geluiden zoals die van de gemeente Best naar buiten komen. Al een paar jaar wordt er gesproken over standaardiseren van het gemeentelijk applicatielandschap. Op dat punt zijn ook al de nodige stappen gezet, maar tot een echte doorbraak is het tot heden niet gekomen. Ik onderschrijf het betoog van wethouder van de Loo: er moet meer bundeling van vraag en van aanbod komen. Maar wat gebeurt er dan nu? In de directe omgeving van de gemeente Best zijn er meerdere gemeenten die in dezelfde situatie als Best verkeren v.w.b. hun ICT huishouding. Lopen er al gesprekken om vraag te bundelen?
Het gaat mij er niet om Best te kijk te zetten. Verre van dat, want het siert deze gemeente om nu eens niet een plat succesverhaal naar buiten te brengen, maar de harde werkelijkheid te benoemen. Dat zouden meer gemeenten moeten doen, om een bekende reclamespreuk aan te halen. Dan wordt namelijk duidelijk hoe vastgelopen de relatie tussen IT-leveranciers en gemeenten is.
KING verlangt van leveranciers dat zij hun software applicaties laten voldoen aan standaarden. Die standaarden hebben primair op individuele producten betrekking. Maar de meeste software producten werken niet stand alone maar worden in een keten van applicaties geïnstalleerd. Uiteindelijk gaat daar het principe van de zwakste schakel op. Voldoet één van de softwareproducten niet aan een standaard, dan werkt de keten niet. Het testen van die keten, feitelijk de interoperabiliteit van een softwareproduct gebeurt nu veelal bij de opdrachtgever, de gemeente dus. En die mag de extra (consultancy) kosten betalen. Doordat gemeenten dit probleem niet samen maar ieder voor zich met hun leveranciers proberen op te lossen wordt veel tijd en geld verspild. Uw en mijn belastinggeld. Hoe dat anders kan: gemeenten ga samenwerken. Luister naar mevrouw van de Loo. Bundel je vraag en ga samen met je leveranciers in gesprek. Misschien dat Best dan zorgt voor de dringend noodzakelijke ommekeer.
Beste,
Ik heb met dit bijltje vaker gehakt. Diverse IT systemen ge- implementeerd die niet goed liepen zowel weer functionerend gemaakt. Soms met behoorlijke operationele en financiele gevolgen.
Het gaat daarbij om een paar zaken:
1. waarom moet er een ander systeem komen en wat is het nut?
Resultaat van deze stap is dus de aanpak en de oplossing van het probleem inclusief budget, capaciteit en minimalisatie van de risico’s.
2. Gevolg is van het missen van stap 1 is vaak een foutief ontwerp en geen goed zicht hebben op de dagelijkse processen is het opleveren van IT systems die niet doen wat ze moeten doen.
Dit wordt vaak onderschat, men gaat er te snel overheen en kiest al doende voor de onjuiste oplossing. En dat er vaak meerdere mogelijkheden zijn.
Bij 90% van de recovery klussen was dat het geval. Daarbij het niet uit hoeveel leveranciers, partijen, processen, interfaces, ERP’s etc er aan de orde waren.
Ofwel: wat doen we, waarom en wat levert het op?
En wat is dan de beste oplossing?
Staan hier de neuzen dezelfde kant op dan is de slag naar de oplossing snel te maken. Men weet dit vaak allang.
Kan ook raar gaan, ik heb meegemaakt dat dat men al ver gevorderd was met het invoeren van nieuwe ERP systemen terwijl bestaande systemen vaak makkelijk konden worden aangepast of kleine maatwerk applicaties kunnen worden toegevoegd. Wel zo makkelijker want medewerkers kennen dat en is de acceptatie groter. Ook vaak veel goedkope met veel minder operationele risico’s!
Devies is dus, neem de tijd voor de oplossing. Doe je dit niet, calculeer dan tegenslagen of vertragingen of niet passende systemen in.
Hoe doe je dat? Werk dus top down werkt: welk probleem, welke processen, welke taken vervullen de diensten vervult. Welke taak en hoe ziet die workflow eruit en hoe sluiten die systemen daarop aan en wat doen ze nog (niet goed).
Werk eerst een voorstel deels uit en ga dat dan met de andere compleet maken. Dan is de buy in groot en klopt de oplossing. En hou het simpel!
Kijk ook eens buiten de deur!
Daarbij maakt het niet uit of taken over verschillende gemeenten zijn verdeeld, het principe blijft hetzelfde: begin dus top down.
Volgt u deze aanpak, dan is succes vaak gegarandeerd en de risico’s zijn minimaal. Inzicht doet wat dat betreft wonderen en het draagvlak groeit zienderogen.
Wat ook goed werkt een heldere planning maken en deze goed aan alle muren hangen. Doe dat pas als de oplossing helder is, dan is het concreet en dat werkt vaak fijner.
Neem daarbij rustig de tijd om de zorgen van medewerkers door te nemen: ze hebben vaak gelijk en het gaat om voor hun wezenlijke zaken. Vergeet niet dat zij de processen en taken goed kennen!
Wat het best werkt is “plaats een bureau op de afdeling”. Je bent dan een vraagbaak en kunt snel problemen oplossen.
Tip: een periode testen en schaduwdraaien met de gebruikers samen doet ook wonderen. Vaak zitten er verschillen tussen regio’s of afdelingen zodat je ze goed kunt bedienen.
De proeffabriek methode werkt dan vak het beste, immers bewezen resultaten verkopen zichzelf beter.
Ook kun je zo veel systeemfouten herstellen.
Ten derde kun je oplossingen makkelijker kopieren omdat ze bewezen zijn en goed getest zijn.
De aanpak one size fits all werkt vaak dus niet!
En last but not least, ga niet duwen, neem de tijd voor de oplossing, creeer budget, het verdient zich echt terug.
Dus om een beeld te geven van de doorlooptijd:
Ontwerp en voorwerk is vaak de eerste 30%.
Programmeren en ontwikkeling 20%
testwerk en de invoering vaak 50%
Ook hier geldt: 1 jaar is niets, 2 jaar is vaker reeel om het geheel goed functionerend te krijgen.