Columns Wouter Keller

Polder-RUD

inGovernment 2012, nr. 4

Den Haag heeft weer eens iets bedacht: de Regionale UitvoeringsDienst oftewel RUD. Een soort specialisatie op het gebied van vergunning, toezicht en handhaving (VTH), met name voor milieu. De verwachte bezuinigingen zijn reeds ingeboekt maar gemeenten/provincies mogen het verder vooral zelf uitzoeken. Is dat niet prachtig?

Het gevolg is dat we inmiddels een stuk of 28 RUDs hebben en sommige provincies tellen bijna meer RUDs dan gemeenten. Wie heeft dat bedacht? Staalkaart van bestuurlijk onvermogen, zowel centraal als decentraal, als je het mij vraagt. En dan ook nog roepen dat alles begin 2013 gereed moet zijn, inclusief de ICT-integratie.

Het idee om specialisten op het gebied van complexe VTH-zaken als milieu te bundelen is natuurlijk niet verkeerd. Kleine gemeenten hebben immers te weinig schaal om dit goed in te vullen. Waar het aan schort (zoals altijd) is de uitvoering. En dan vooral de ICT-integratie tussen een RUD en de 10-30 deelnemende gemeenten (en provincies).

Dossiers moeten immers digitaal worden uitgewisseld tussen een gemeente en de RUD. Hier was een prachtrol weggelegd voor het OLO: waarom die niet gebruiken als landelijke ‘hub’, waar RUDs met hun gemeenten de digitale klantendossiers kunnen delen? Vergeet het maar! Het OLO moet bezuinigen dus worden dossiers amper bewaard. Handig!

Dus gaan alle RUDs eigen VTH systemen aanschaffen. Als we niet opletten moet iedere RUD hun systeem straks tig keer integreren met de lokale systemen van de gemeenten. En dat zijn natuurlijk allemaal verschillende systemen van verschillende leveranciers. En koppelen tussen verschillende leveranciers is een drama, dat weten we inmiddels. Dat wordt lachen!

De oplossing is heel simpel. Laat iedere RUD een goed VTH-/zaaksysteem in de cloud aanschaffen en laat alle aangesloten gemeenten daarin gaan werken, ook voor hun eigen (behandel)processen. Gemeenten kunnen dan allemaal hun VTH-systeem afstoten. SNO's met RUDs kunnen worden gebaseerd op de zaaktypecatalogus 2.0 van KING. Uitwisseling van dossiers is dan geen enkele probleem meer. En dankzij de cloud kunnen zelfs buitendienstmedewerkers er altijd bij.

Onmogelijk zegt u? En waarom gaat deze ‘ideale’ oplossing dan niet werken? Wat zegt u, geen bestuurlijk draagvlak? Wordt het weer een polder-RUD met een prut-integratie? Of pakken we toch even door, bestuurders?

naar boven naar boven

Kleine gemeente, kleine budgetten?

inGovernment 2012, nr. 3

De gemeentesecretaris van Minidam (20.000 inwoners) was woest. Wanneer hield dat ICT-gedonder nu eens op? Weer was een goede systeembeheerder weggelopen. Zonder (dure) inhuur was het onmogelijk om de ICT-systemen draaiende te houden. Maar waar moest het geld vandaan komen? Minidam betaalde zich al blauw aan die dure ICT’ers en ICT-systemen. En Den Haag wist ook niet van ophouden. WABO, BAG, GBA, WOZ, … allemaal zaken die vernieuwd en geïntegreerd moesten worden. Wie moest dat allemaal betalen en beheren?

Er zijn in Nederland bijna 200 gemeenten met minder dan 25.000 inwoners. Voor deze gemeenten is ICT vaak een nachtmerrie. Maar er gloort licht aan de horizon. Juist kleine gemeenten hebben baat bij twee actuele ICT-ontwikkelingen: zaakgericht werken en cloud computing. Een zaaksysteem kan een boel geld besparen, het beheer vereenvoudigen en de dienstverlening verbeteren. Iets soortgelijks geldt voor uitbesteding van de ICT naar de cloud.

Met een zaaksysteem kunnen kleine gemeenten verschillende backofficesystemen vervangen door één overkoepelend systeem: het zaaksysteem of midoffice-suite. Tevens kan daarmee in één klap het e-loket (inclusief webformulieren et cetera), KCS (klantcontactsysteem), CMS (webcontent-managementsysteem) en DMS (document-managementsysteem) worden vervangen. En wel door één geïntegreerd systeem dat veel minder beheer vraagt dan al die losse systemen. Dat scheelt een boel geld en een boel beheer!

Hetzelfde geldt voor de cloud: kleine gemeenten zouden moeten stoppen met zelf rekencentrumpje te spelen. Uitbesteden die handel! Wij hebben hiertoe recent een Europese cloud-aanbesteding gedaan. Daarbij werden alle ICT-systemen en het bijbehorende systeembeheer uitbesteed, inclusief (virtuele) werkplek, alle backoffice¬systemen en natuurlijk de midoffice-suite (met zaaksysteem). Hier valt echt iets te besparen. Dus kijk eens naar de cloud; niet alleen als je ontzorgd wilt worden maar ook als je moet bezuinigen!

Voor gemeenten kleiner dan 25.000 inwoners is er nog een tip: doe voor een midoffice-suite (met zaaksysteem) een zogenoemde meervoudig onderhandse aanbesteding met een maxprijs van 199.000 euro over drie jaar. Wel netjes aankondigen met een selectiefase op de aanbestedingskalender natuurlijk, maar dus niet Europees. De gemeentesecretaris zal blij verrast zijn als hij de offertes ziet.

naar boven naar boven

Het Burger Zaaksysteem

inGovernment 2012, nr. 2

Onlangs werd bekend dat de VNG aanbesteding van de zgn. Burgerzaken modules (BZM) voor het nieuwe GBA niet doorgaat. Dit wegens gebrek aan gemeentelijke belangstelling. De BZM systemen geven ondersteuning aan lokale GBA processen. De opslag van gegevens gebeurt daarbij in de “cloud”: het BRP. De verwachting is dat BZM/ BRP in 2016 door alle gemeenten wordt gebruikt.

VNG (en KING) wilde de BZM systemen via een gezamenlijke Europese aanbesteding in twee stappen selecteren. Eerst wordt een shortlist van leveranciers geselecteerd door VNG. Vervolgens moeten gemeenten individueel een zgn. minicompetitie doen om aldus hun BZM systeem uit de shortlist te kiezen. Ik denk dat er twee redenen waren waarom gemeenten weinig zagen in deze aanpak. Ten eerste omdat het onduidelijk was welke leveranciers op de shortlist kwamen. Helaas is daar geen garantie voor bij een aanbesteding. Wel vergroot een groot aantal deelnemende gemeenten de kans dat alle leveranciers inschrijven. Typisch gevalletje kip-ei dus.

Ten tweede was mogelijk de offerte-uitvraag bij de minicompetities per gemeente reden van afhaken. Hoewel VNG wat steun (uren) aanbood, moesten gemeenten dit zelf doen. Dat impliceert een extra kostenpost naast de (niet verwaarloosbare) kosten van de VNG aanbesteding. Dat de samenwerking mislukt is, is teleurstellend. Nu moeten alle 400 gemeenten weer bijna alles zelf doen. Dat betekent een boel gedoe (tijd en kosten) per gemeente. Ik zie dit als een gemiste kans, wat helaas weinig goeds voorspelt voor toekomstige landelijke samenwerkingsinitiatieven. Iedereen gaat nu weer het wiel zelf uitvinden. Weinig innovatief.

Had het beter gekund? Ja en nee. Nee, want zo’n shortlist kan je niet beïnvloeden bij een aanbesteding. Ja, want VNG had een generiek bestek voor die minicompetities kunnen maken. Wensen van gemeenten voor bv. backofficekoppelingen kan je dan eenvoudig toevoegen. Daarna zouden gemeenten met dezelfde wensen samen een systeem kunnen selecteren, zonder shortlist.

Tenslotte nog dit. Het gaat om burgerzakenmodules. Zou KING daarom niet BZM als inrichting van een zaaksysteem moeten beschrijven? Dan had dit een kans geboden aan de 15+ leveranciers van zaaksystemen. Stel je voor: koop nu een zaaksysteem en krijg een BZ-module gratis (en vice versa)! Einde backofficesysteem. Dat was pas echt innovatief geweest, als je het mij vraagt!

naar boven naar boven

Make-or-buy

inGovernment 2012, nr. 1

Dat grote projecten bij de overheid vele valkuilen kennen, is bekend. Legio zijn de projecten van onze overheid die moeite hadden binnen budget en/of binnen tijd te blijven. Overschrijdingen zijn haast de norm, met name bij grote gemeenten. En dan hebben we het dus niet alleen over de Noord-Zuidlijn of het Rijksmuseum in Amsterdam. Ook bij vele andere gemeenten lopen met name ICT-projecten uit de hand.

Recent werd ik me een belangrijke faalfactor gewaar toen we weer eens de problemen van een grote gemeente bespraken. Niet alleen de G4-gemeenten maar ook de G20-gemeenten (met ruim 100K inwoners) houden van “zelf doen”. Anders gezegd, men wantrouwt de markt en maakt het liefst de systemen zelf. Grote gemeenten hebben vaak een dozijn techneuten in dienst (of ingehuurd) om leuke dingen te doen. Sommige gemeenten maken eigen zaaksystemen, midoffices of zelf hele backoffice pakketten.

Wat mij daarbij altijd opvalt is een heilig geloof in het eigen kunnen, en een blinde vlek voor wat de markt kan leveren. Er zijn G20-gemeenten die in tijden van bezuiniging jaarlijks rustig 5 tot 10 programmeurs inhuren (kosten meer dan een miljoen) om zelf een zaaksysteem of iets dergelijks in elkaar te knutselen. En dat terwijl je op de markt voor 2 euro per inwoner per jaar (dus ruim 200K per jaar) een prachtig zaaksysteem, annex front/midoffice suite kan kopen en vaak meteen afscheid kan nemen van je bestaande (en dure) DMS/RMA, CMS, KCS, et cetera.

Hoe voorkomen we hobbyisme? Ik zie hier een belangrijke rol voor echte architecten. Start een discussie over make-or-buy: moeten we echt systemen zelf ontwikkelen of heeft de markt genoeg te bieden? Is al die zelfbouw functionaliteit wel nodig en kan het niet anders? Kunnen we niet configureren in plaats van programmeren? Laat eens een marktscan/RfI doen en je zal verbaasd zijn wat er bv. aan front/midoffice functionaliteit te koop is. Vraag geen advies aan de techneut, want die wil altijd door met zijn speeltje. Voer een serieuze discussie over make-or-buy op boardroom niveau. En vergeet de bezuinigingen niet, de business case kan vaak achter op het bierviltje!

naar boven naar boven

Besparen met zaakgericht werken!

Proces & Document (inGovernment) 2011, nr. 4

Wat staat er bij de gemeenten hoog op de agenda, naast bezuinigen? Dat is zaakgericht werken en het Klant Contact Centrum (KCC). Zaakgericht werken impliceert dat zaken op een uniforme (en vaak digitale) manier worden behandeld. Zaken zijn processen met een begin en een eind. Zie de gemeentelijke productencatalogus voor honderden zaaktypen.

Wat doet een zaaksysteem? Die maakt de digitale dossiers en digitale processen mogelijk. Digitale dossiers betekent dat alle relevante documenten digitaal (eventueel gescand) worden verwerkt. Door digitalisering van documenten kunnen we overal bij onze dossiers: in het KCC, in het backoffice, en zelfs in het veld via een iPad. Maar ook klanten kunnen via het web bij al hun dossiers en zien de status. Dat scheelt KCC calls.

Die statussen zijn de kern van de digitale processen. Ontvangen, geaccepteerd, in behandeling, en behandeld zijn de eenvoudigste statussen. Samen vormen ze een serieel proces. Een zaaksysteem bewaakt dat proces bijvoorbeeld met checklists en andere controles. Door deelzaken te onderscheiden kunnen we naast seriele processen ook complexe parallele processen met een zaaksysteem verwerken. Een zaaksysteem is dus erg universeel.

Iedere zaaktype heeft zijn eigen dossierinrichting en processtappen. Denk aan de aanvraag van een uittreksel. Zo’n zaaktype kunnen we eenvoudig configureren in een zaaksysteem. Voorbeelden zijn de rollen en rechten, statussen (zowel seriele als parallelle stappen), maar ook checklists, kenmerken en documenttypen per stap. Daarmee zorgen we ook voor een compleet digitaal archief, inclusief de dossiers en de procesinfo.

De kracht van een zaaksysteem is de eenvoud van dergelijke configuraties. Die inrichting gebeurt vaak door simpelweg parameters aan te passen in de zaaktype catalogus, de ZTC. Dus zonder ingewikkelde programmering. We noemen dat zero-coding. U bent dus niet meer afhankelijk van de leverancier om iets aan te passen.

Maar het allermooiste is dat een zaaksysteem heel universeel en erg goedkoop is, met dank aan de concurrentie. Voor een paar euro per inwoner per jaar kan je de mooiste zaaksystemen krijgen, vaak met een geïntegreerde KCC en DMS functionaliteit. Daarmee kan je steeds meer backoffice systemen gaan vervangen. Die kosten gezamenlijk al gauw vijf tot tien keer zo veel. Dat kan op termijn wel een besparing van wel 30 euro per inwoner per jaar opleveren. Dat is pas echt bezuinigen!

naar boven naar boven

Basisregistraties en Open Standaarden

Proces & Document 2011, nr. 3

In ieder Programma van Eisen (PvE) kunt u ze vinden: de vraag naar open standaarden. Het komt erop neer dat elke leverancier ervoor moet zorgen dat zijn systemen aan bepaalde open standaarden voldoen. Bij gemeenten kom je dan KING-standaarden tegen als RSGB en vooral ook StUF voor berichten tussen systemen. En om het allemaal nog wat simpeler te maken zijn er van bijvoorbeeld StUF ook nog vele versies. Dat is zoiets alsof elke stekker weer andere pootjes heeft en ze dus allemaal hun eigen stopcontact nodig hebben.

Sinds enkele jaren worden gemeenten geacht informatie over basisobjecten, zoals gebouwen, tussen hun backoffice-systemen uit te wisselen. Afdeling BAG is dan bijvoorbeeld als bron verantwoordelijk voor de registratie van gebouwen en de andere backoffice-afdelingen (zoals Vergunningen) dienen hier gebruik van te maken. Dit soort gegevensdistributie is niet alleen een organisatorisch maar ook een stevig technisch probleem. Daarvoor is StUF-BG als open standaard uitgevonden. Die regelt de pootjes van de 'stekker' die op alle backoffice-afdelingen moet passen.

Je zou dus denken dat dankzij zo'n StUF-BG-stekker het geen moeite is om bijvoorbeeld een burgerzakensysteem van Centric aan een BAG-systeem van Pink te koppelen. Vergeet het maar. De StUF-pootjes van Pink zijn net even anders dan die van Centric, ook bij dezelfde versies. En erger nog, je hebt in beide gevallen per leverancier een dure schakelkast (gegevensdistributiesysteem) nodig. Maar ook die passen niet op elkaar. Sommige klanten hebben zelfs een eigen schakelkast moeten maken om die van Pink en Centric met elkaar te verbinden. Dus extra kosten voor iets wat op basis van de StUF-BG-standaard 'gewoon' had moeten werken.

Wat leren we hiervan? Wel, open standaarden zijn heel belangrijk maar niet altijd zaligmakend. Sommige van die standaarden zijn helaas te open, en dus zo lek als een mandje. Vaak zijn de specs (pootjes) onvoldoende uitgewerkt en getest. Wat kan KING hieraan doen? Dat is nogal eenvoudig: voordat een standaard zoals StUF-BG in beton gaat moet hij in de praktijk worden getest, liefst met zo veel mogelijk leveranciers (bijvoorbeeld in een plugfest). En daarna de leveranciers echt certificeren, zodat, als ze 'ja' zeggen bij een PvE, het ook echt werkt.

naar boven naar boven

Pas op voor stip-architecten!

Proces & Document 2011, nr. 2

Boardroom woensdagochtend. De architect was gevraagd een toelichting te komen geven bij zijn voorstellen. Hij toonde prachtige plaatjes op de beamer, met veel blokjes en kleurtjes. Lid RvB Pietersen vroeg: Wat moeten we hier nu mee? Wel, zei de architect, zie het als een stip-op-de-horizon. Zo moet onze toekomstige ICT-architectuur eruitzien over vijf tot tien jaar. Pietersen: Stip-op-de-horizon? Dus iets wat nooit dichterbij komt? Hoe zit het dan met de huidige ICT-architectuur? Eh..., zei de architect, daar kunnen wij ons niet mee bezig houden.

Ik weet niet hoe het met u is, maar ik word niet goed van collega-architecten met dit soort verhalen. Eigenlijk wil ik van die term architect helemaal af, want de meeste collega's zien het als een vrijbrief voor technologische natte dromen op de horizon. En iedereen noemt zich architect. Maar zelfs als ik me beperk tot echte (oeps...) architecten, dan nog is het aantal stip-architecten helaas in de meerderheid. En dat is zorgwekkend.

Wat zou een architect dan wel moeten doen? Architectuur impliceert samenhang en samenwerken. Daarom moet een goede architect vóór alles weten hoe de huidige ICT-architectuur in elkaar steekt. En hoe dat zo gekomen is. En dan proberen stapje voor stapje een en ander te verbeteren qua samenhang. Dus voordat je naar die stip op de horizon gaat staan staren, eerst om je heen kijken. Dat is door de modder lopen en dat doen stip-architecten liever niet.

En bekijk samenhang ook niet alleen technisch. Veel architecten zijn van de SOA-kerk en kunnen helemaal wegzwijmelen bij webservices, servicebusjes en ander technisch speelgoed. De harde praktijk is anders. Daar moeten we vaak nog werken met ouderwetse technologieën, zoals dikke clients (in plaats van webclients). Maar het moet helemaal niet gaan om de techniek. Je moet met name kijken naar samenhang tussen applicaties, gegevens en processen. En de afstemming tussen organisatieonderdelen.

En daarmee kom ik op het tweede aspect: samenwerken. Veel wat ik als architect zou willen veranderen, loopt stuk op een gebrek aan samenwerking. Tussen frontoffice en backoffice, tussen de backoffices onderling en met ketenpartners. Misschien is samenwerken wel de grootste uitdaging voor architecten. Maar natuurlijk niet voor stip-architecten.

naar boven naar boven

De gemeente in de Cloud

Proces & Document 2011, nr. 1

Het hoofd van de afdeling Facilitair was tegen zijn zin ook hoofd ICT van de gemeente Kleindam geworden. Kleindam telt maar liefst 14.000 inwoners. Naast het hoofd Facilitair is er ook nog een overspannen I&A-medewerker. En ergens loopt nog een applicatiebeheerder rond, die ook wat van ICT af weet. Ze kunnen het werk niet aan en kennis is een schaars goed. Zeker bij ICT, waar alles snel verandert.

Het rekencentrum van Kleindam stond op instorten. Daarom hadden ze vorig jaar besloten om het huidige serverpark geheel te vervangen. Dat ging om veel geld. Het hoofd Facilitair kon dus niet om een Europese aanbesteding heen. Geld voor adviseurs hadden ze niet, dus vroegen ze advies aan een verkoper van een backofficesysteem. Die zei: 'Servers van merk X zijn het beste'.

De aanbesteding mislukte eerst, want je mag niet naar X vragen. Uiteindelijk kregen ze toch de gewenste dure servers van merk X. Vraag niet hoe. De gemeenteraad was vooraf ingelicht maar het prijskaartje viel tegen. Zeker toen er nog een test- en uitwijkvoorziening moest komen (vergeten). De teller stond inmiddels op een paar ton. Maar dan had je ook wat. Het hoofd Facilitair vertelde op de nieuwjaarsborrel trots dat ze nu een echt mainframe hadden.

Kort daarop moest het DMS worden vervangen. Helaas bleek daarna pas dat het nieuwe DMS niet op dat dure mainframe kon draaien. Wel op gewone servers, die nog veel goedkoper waren ook. De raad vroeg een second opinion. Het bleek toen dat de backofficesystemen prima op de goedkope servers hadden kunnen draaien, en nu zat men met een strop van enkele tonnen.

Wat leren we daarvan? Volgens mij dat kleine gemeenten geen eigen rekencentrum moeten willen hebben. Doe al dat staal alsjeblieft de deur uit. Bandbreedte is het probleem niet meer, kennis wel. Er zijn genoeg ASP-leveranciers die je systemen in de cloud kunnen hosten en beheren. Of kijk eens bij een grote buurgemeente. Kan je eindelijk focussen op I (informatiseren) in plaats van A (automatiseren).

naar boven naar boven

Het einde van het midoffice?

Proces & Document 2010, nr. 4

In 2005 schreef Cap Gemini een rapport met de titel Het midoffice bestaat niet. Kort daarop verscheen een rapport van Egem waaruit bleek dat het midoffice wel bestond. Recent verscheen een leuke blog van Marcel Hoogwout met de titel Het einde van de midoffice? Hij heeft hiervoor vier argumenten:

De techniek is onvolgroeid en duur. Deels mee eens. Met name het dunne midoffice met webintake en backoffice-stekkers blijkt moeilijker te implementeren en duurder dan voorzien. Dan komt vooral door die stekkers en de afhankelijkheid van meerdere leveranciers. Ook zijn er nog weinig standaarden of veel versies (bijvoorbeeld bij Stuf). Aan de andere kant is juist voor de aansluiting op overheidsbrede ketens (denk aan basisregistraties, Suwi en Wabo) een midoffice een goede zaak.

Het voordeel van het zakenoverzicht in een zaaksysteem is beperkt. Niet mee eens. Een klantcontactsysteem (KCS) wordt rijker als de achterliggende processen in een dik midoffice ofwel in een zaaksysteem plaatsvinden. Daarbij is het belangrijk om status en dossiers via het KCS te ontsluiten, ook als het behandelproces extern of in een backoffice gebeurt. Digitale documenten (geen papier!) zijn een belangrijke reden om een zaaksysteem in te zetten.

Het takenpakket van de gemeente verschuift naar extern, met desinvesteringen als gevolg. Deels mee eens. Enerzijds blijven bij Wabo/OLO, Suwi, WMO en Shared Service Centra gemeenten het loket voor de burger. Sommige behandelprocessen komen dan in een backoffice of externe applicatie in plaats van in het zaaksysteem. Maar ook daar past het KCS inclusief status en digitale dossiers van het zaaksysteem juist prima bij. Zie ook Antwoord©. En een zaaksysteem met KCS heb je al voor 1 à 2 euro per inwoner.

Er zijn aantrekkelijke, landelijke initiatieven. Helemaal mee eens. Het is van de gekke dat gemeenten met 10.000 inwoners zich druk moeten maken over servers, stekkers en midoffices. Dat kan allemaal veel beter naar de cloud. Maar ook daar (zie Dimpact, Govunited) blijft het midoffice en/of het zaaksysteem een belangrijke rol spelen. Datzelfde geldt voor OLO en DKD.

Kortom, vrij naar Mark Twain zeg ik: de geruchten over de dood van het midoffice zijn sterk overdreven!

naar boven naar boven

Workflow of Zaakstroom?

Proces & Document 2010, nr. 3

De architect sprak het met enig aplomb uit: jullie moeten echt onder architectuur gaan werken. Wat betekent dat, vroeg iemand. Je moet, zo zei de architect geheimzinnig, uitgaan van een servicegerichte architectuur met losse best-of-breed-componenten.

Over welke componenten heb je het dan? Tja, natuurlijk een servicebus met daarop een webintake-systeem, een medewerkersportaal voor je klantcontactcentrum, een DMS voor documenten en natuurlijk een workflowapplicatie voor de processen. Maar voordat jullie dat allemaal gaan aanschaffen, moeten we natuurlijk eerst al die processen analyseren en herontwerpen, zo zei hij.

Twee jaar en vele (dure) workshops later was het zover. We gingen het eerste proces, de evenementenvergunning, implementeren. Daarbij moesten we de workflowapplicatie koppelen met de e-formulieren, het KCS, het DMS en een backofficesysteem. Behalve de aanvragen moesten ook statusberichten en dossiers heen en weer worden gezeuld tussen de systemen, die allemaal met stekkers aan elkaar zaten. En de best-of-breed-aanpak betekende veel leveranciers en dus veel stekkers en dus veel facturen...

Maar dat was niet het enige. Ons zorgvuldig ontworpen en gedetailleerde vergunningsproces bleek in de praktijk niet gedetailleerd genoeg. Er waren uitzonderingen die we niet in het workflowpakket geprogrammeerd kregen. Medewerkers hadden het gevoel in een betonnen pak te zitten, want iedere stap was voorgeschreven en je kon er nooit van afwijken. Het draagvlak onder behandelaars nam zienderogen af.

En ten slotte, na een jaar hard werken aan het gedetailleerde herontwerp van de evenementenvergunning, hadden we nog 499 van onze 500 gemeentelijke producten en diensten te gaan. U begrijpt het, na drie jaar en veel tijd en geld, zijn we ermee gestopt. Te duur, te langzaam, te star, die workflowaanpak.

Nu hebben we één zaaksysteem, met een eenvoudige procesinrichting en veel ruimte voor de medewerkers. En het DMS (inclusief archief), het KCS en de webintake zijn allemaal al geïntegreerd in het zaaksysteem. In enkele maanden tijd hebben we maar liefst 50 zaaktypes geïmplementeerd! Weliswaar zonder al te veel procesdiepgang, maar o wat scheelt dat! Eindelijk van dat papier af, de klant heeft inzage in de voortgang en het management krijgt informatieve rapportages. Waarom hebben we dat niet eerder gedaan?

naar boven naar boven

De flitsaanbesteding: een Midoffice in 100 dagen

Die afdeling inkoop ook altijd. Alsof u nog niet genoeg aan uw hoofd heeft. Is er eindelijk akkoord om de dienstverlening in te richten conform Antwoord © en daarvoor een Midoffice, een zaaksysteem of klantcontactcentrum aan te schaffen, sturen zij u regelrecht het moeras van een Europese aanbesteding in. Bent u weer een half jaar verder. En dan heeft u het nog niet eens over de honderden uren van uw specialisten die het kost om een Programma van Eisen (PvE) op te stellen, en over het vermogen aan juridisch advies. Wie heeft dat aanbesteden eigenlijk bedacht? Wat een ellende ...

Niet getreurd. Argitek, de firma van Midoffice goeroe Wouter Keller (u weet wel, die van het seminar) biedt hoop. In minder dan 100 dagen (ca. 3 maanden) en voor een zeer schappelijke prijs kan zij voor u een flitsaanbesteding doen, waarbij u de gewenste componenten à la carte kunt kiezen. Wilt u een zaaksysteem met DMS/RMA, een klantcontactcentrum (KCC), een website (CMS/PDC/PIP), een e-formulieren voorziening met Digid/Ogone of een dun Midoffice (servicebus) met stekkers en magazijnen? Alles is mogelijk. Voor het einde van het jaar kunt u de trotse eigenaar zijn.

Hoe is dat mogelijk? Wel, Argitek heeft de afgelopen jaren vele Midoffice aanbestedingen verzorgd, te beginnen met de welbekende ANDEZ aanbestedingen en daarbij een schat aan ervaring opgebouwd. Niet alleen functioneel-technisch, als het bijv. het PvE van een Midoffice suite of zaaksysteem betreft, maar ook juridisch en procedureel. Deze ervaring hebben we vastgelegd in een innovatief standaardbestek. Dit bestek hebben we voorzien van een menukaart waaruit u als gemeente (maar natuurlijk ook als provincie, waterschap, etc.) de gewenste componenten kunt kiezen. Natuurlijk bevat de menukaart ook de benodigde stekkers voor uw backoffices etc. Daarnaast kiest u zelf de gewichten voor de kwalitatieve aspecten en bepaalt u de prijs/kwaliteitsverhouding. Alles op basis van de zeer uitgebreide menukaart. De enige voorwaarde is dat u het standaardbestek van Argitek accepteert.

Het gebruik van een standaardbestek maakt de aanbesteding niet alleen flexibel en snel, maar ook goedkoop. In feite betaalt u niet voor het bestek maar alleen voor de begeleiding door Argitek. De prijs zal u verbazen en hij staat ook nog eens van tevoren vast. Er zijn echter nog meer voordelen. Het gebruik van standaard PvE tekstblokken voor iedere functionele component, stelt leveranciers in staat om een bibliotheek met standaard offerteteksten te maken. Dit zal meer en betere offertes opleveren, zeker naarmate meer gemeenten, provincies, waterschappen etc. voor deze aanpak kiezen. Het mes snijdt dus aan twee kanten: het is niet alleen sneller en goedkoper maar u krijgt ook meer en betere offertes. Het klinkt als het ei van Columbus.

De ervaring van Argitek blijkt ook uit de scherpe, doordachte planning. Na het tekenen van de opdracht begint de klok te tikken en binnen een week wordt de zgn. selectieleidraad uitgestuurd. Daarin worden leveranciers uitgenodigd om deel te nemen aan de aanbesteding. Binnen 8 weken selecteren we, mede op basis van omzeteisen en referenties, 6 leveranciers, die op basis van het bestek een offerte mogen indienen. In de tussentijd organiseren we een aantal workshop om de precieze functionele scope van de aanbesteding te bepalen en op basis van de menukaart het bestek op te maken. Na 13 weken zijn alle offertes binnen. Medewerkers van de gemeente beoordelen deze offertes, maar wel volgens de strikte procedures en onder begeleiding van Argitek. Na 14 weken is de nr. 1 bekend en kan er worden gegund.

Natuurlijk is het ook mogelijk om gemeentespecifieke wensen te vervullen. Zo kan er bijvoorbeeld worden gekozen voor een aansluitende Proof of Concept (PoC) of demo, voor extra verduidelijkingssessies met de leveranciers of voor extra begeleiding bij de gunning. Dit alles kost wel extra doorlooptijd en dus ook extra geld. Nodig is dit echter niet! Ook zonder deze extra's garandeert Argitek in drie maanden een kwalitatief goede aanbesteding. Je moet er maar op komen...

lees meer Download de PDF
lees meer Nadere informatie via flits@argitek.nl

naar boven naar boven

Gezocht ZTC of DSP: dood of levend?

Proces & Document 2010, nr. 2

'Zaaktypencatalogus, wat is dat nou weer?', zuchtte het hoofd DIV. 'We hebben al jaren een DSP, is dat niet gewoon hetzelfde?' Nee, dat is het dus niet. Ik zal proberen aan te geven waar de crux zit. Kort gezegd: een zaaktypencatalogus (ZTC) is veel 'levendiger' dan een documentstructuurplan (DSP).

Een DSP bevat beschrijvingen van behandelprocessen en archiefdossiers voor bepaalde gemeentelijke producten en diensten, zoals een bouwvergunning. Een beetje gemeente heeft zo'n 500 producten en diensten, die we zaaktypen noemen als we zaakgericht werken. De ZTC beschrijft net als het DSP de processen en dossiers per zaaktype. Wat is dan het verschil?

Dat zit hem in het karakter van de ZTC. De ZTC is actief, wat bijvoorbeeld betekent dat procesveranderingen in de ZTC direct doorwerken in het zaaksysteem. Anders gezegd, de ZTC is veel 'levendiger' dan een DSP: als je een parameter verandert in de ZTC, dan verandert direct het gedrag van het zaaksysteem. Voeg bijvoorbeeld een checklist-item toe bij statusovergang 3 van zaaktype bouwvergunning, en onmiddellijk verandert het desbetreffende behandelscherm.

De meeste DSP's zijn uitsluitend beschrijvend. Beschrijvingen zijn net als geschiedschrijving: goed voor historici. Net als de vele AO-ordners met procesbeschrijvingen: ze zijn meestal al verouderd (dood) zodra de beschrijving is afgerond. Daarnaast zijn DSP's vaak gericht op de koude kant (archief). Wat we willen is een actieve, levendige beschrijving van de processen. Dat doet een ZTC: die stuurt direct het (warme) behandelproces aan, zonder ingewikkelde workflow-poespas.

Dat levert een bijkomend voordeel op: we hoeven niet voor iedere wissewasje terug naar de softwareleverancier. Iedere zaaktypenbeheerder kan immers zelf de ZTC aanpassen. Zonder programmeren, zonder moeilijke workflows en zonder complexe datamodellen te kennen. Dat noemen we zero-coding. Met dank aan het Dordtse procesmodel, zoals ook vastgelegd in het RGB-Zaken van Egem/KING.

Het woord is nu aan de leveranciers van zaaksystemen. Maken zij de droom waar? Krijgen we actieve ZTC's met zero-coding? Ik heb goede hoop, ook gezien ons mini-lab van 2009 en de recente aanbestedingen voor zaaksystemen. Dat is goed nieuws voor gemeenten!

naar boven naar boven

Help, de post is zoek!

Proces & Document 2010, nr. 1

Recent deed EF3 een onderzoek naar de postbehandeling bij 60 gemeenten. De resultaten zijn onthutsend. Op sommige brieven komt het antwoord pas na 6 wekenen en op bijna 20% komt helemaal geen antwoord. Een G4-gemeente reageerde zelfs op meer dan de helft van de brieven helemaal niet. Hoe kan dat?

Bijna alle gemeenten hebben een postregistratiesysteem maar de behandeling gaat desondanks vaak op papier. Papieren dossiers kunnen zoekraken en bewaking is moeilijk. Als een papieren dossier hier ligt, kun je er elders niet bij, en ze liggen vaak tot aan het plafond opgestapeld. En dat in de digitale eeuw!

De oplossing lijkt niet moeilijk. Sommige gemeenten kopen dure workflow-oplossingen. Meestal met weinig succes. Na maanden van gedetailleerde procesanalyse blijkt de workflow niet flexibel te zijn. En dan heb je nog maar 1 van de 500 gemeentelijke processen gedaan. Een alternatief is om alles te scannen wat er binnenkomt. Maar hoe bewaken we dan de behandeling?

Het gemeentebrede zaaksysteem (soms 'dik midoffice' genoemd) biedt een oplossing. Geïnspireerd door de gemeente Dordrecht, het RGB-Zaken en andere standaarden van Egem (nu King), heeft recent een groot aantal leveranciers zich op het zaaksysteem gestort. In ons onderzoek hielden we na selectie nog 10 zaaksystemen over. Deze markt is booming!

Een goed zaaksysteem digitaliseert en bewaakt. Na de scan van papieren aanvragen, controleert het zaaksysteem het digitale dossier, inclusief emails en andere toevoegingen. Tevens wordt de behandeling bewaakt op basis van 4 stappen, met simpele checklists per stap en per zaaktype ("is het advies brandweer aangevraagd?"). Publicatie en digitale archivering per zaaktype gaan volledig automatisch en de burger ziet de status via mijnoverheid.nl. Alle post moet dan natuurlijk wel via DIV gaan en het systeem moet gemeentebreed gebruikt worden.

Zo'n zaaksysteem hoeft helemaal niet duur te zijn. Voor 2 euro per inwoner per jaar heb je al een heel behoorlijk systeem, maar de invoering ervan is vooral een kwestie van goede organisatie. Als dat lukt raken we geen post meer kwijt en kan de burger (en de manager!) de voortgang volgen. Dan kunnen we eindelijk ook eens die stapels papier gaan opruimen.

naar boven naar boven

All-in-One of Best-of-Breed?

Proces & Document 2009, nr. 4

Mijn buurman kijkt graag tv. Dat doet hij, zegt-ie, principieel alleen op basis van (vaderlandse) Philips-technologie. Hij heeft een joekel van een Philips-lcd-tv-scherm en een bijbehorende Philips-dvd-recorder met Philips-versterker. Daartussen zit één kabel. Hij bedient dat allemaal met één Philips-afstandsbediening. Werkt perfect. Ik noem dat de All-in-One-oplossing.

Best-of-Breed-oplossing Ik ben van huis uit een perfectionist. Ik heb dus een tv-scherm van Philips (jawel), een tuner van Humax, een versterker van Pioneer en een dvd-recorder van Panasonic. Daartussen 'tig' draden, je wilt het niet zien (is ook een verschrikkelijk stofnest, maar dat terzijde). Dit wordt bediend met maar liefst 4 afstandsbedieningen, waar mijn vrouw niet blij mee is ('hij doet het niet') en waarvoor onze 'helpdesk' (ik) dus overuren moet maken om het allemaal uit te leggen. Dat heet een Best-of-Breed-oplossing. Ik ben inmiddels jaloers op mijn buurman, met zijn geïntegreerde setje.

Iets soortgelijks zien we bij financiële pakketten. Steeds meer bedrijven stoppen met de best-of-breed-oplossing van allemaal losse pakketten, bijvoorbeeld voor FIN, HRM en CRM. Dat geeft veel te veel integratieproblemen. Niet alleen veel slecht passende 'stekkers' maar ook slecht passende gegevens (syntax en semantiek) en niet aansluitende processen tussen de pakketten. Gevolg: bijna iedereen kiest tegenwoordig voor zogenoemde ERP-suites zoals van SAP, Oracle of Microsoft. Allemaal All-in-One. Dit ondanks de belofte van de zogeheten Service Oriented Architectures (SOA), waarmee je alles aan alles zou moeten kunnen knopen.

Integratie is trouwens niet alleen een functioneel/technisch probleem. Ook commercieel blijkt het moeilijk te zijn om al die verschillende leveranciers te laten samenwerken. Dat vraagt om goede afspraken tussen de leveranciers onderling, zoals ook bleek ook bij sommige 'gelegenheidsconsortia' bij aanbestedingen. Het meest omvangrijke en minst hechte leveranciersconsortium leverde de minste prestaties, zoals we uit een recente ANDEZ-evaluatie weten. Sterke hoofdaannemers met geen of weinig onderaannemers en een breed aanbod aan eigen functionaliteiten (type all-in-one-midoffice-suites) deden het het best.

Ik heb mijn lesje geleerd. Volgende keer koop ik gewoon een geïntegreerde oplossing, ook voor mijn tv. Misschien iets minder mooi, maar wel zo handig!

naar boven naar boven

Opensource - no free lunch!

Proces & Document 2009, nr. 3

Het was weer raak in de politiek. Staatssecretaris Heemskerk riep dat opensource voorrang moet krijgen en Exact en anderen schreeuwen moord en brand. Leveranciers met software op basis van Microsoft-tools! Behalve Microsoft levert bijna niemand meer gesloten ontwikkeltools. Oracle en IBM zweren bij Java, geprofileerd als opensource, maar houden veel aanvullende tools gesloten.

Daags na het gedoe rond Exact c.s. schreef Jan Baan (CEO Cordys) een interessant artikel over opensource. Samengevat zegt hij dat opensource gevaarlijk is voor de klant (meer maatwerk), ideaal voor de dienstverlener (meer uren) en effectief voor de IT-professional (meer tools). Hij heeft het dan over tools (zoals JBoss) voor grotere systemen, dus niet over eindgebruikerstools zoals Firefox of OpenOffice. Ik ben het met Jan eens. Met name die combi van kostbaar maatwerk en een grotere afhankelijkheid van de maatwerkleverancier zien we vaker.

Opensource wordt gratis genoemd. Dat is twijfelachtig, want systeemkosten zitten immers in integratie, implementatie en beheer. Bij kleine opensource-tools ontbreekt vaak de regie van een sterke leverancier. Resultaat: vele niet-onderhoudbare versies. En pas op voor leveranciers met systemen op basis van opensource en gesloten eigen tools. Weer een lock-in.

Integratie is belangrijk. Kijk naar closedsource-leveranciers als SAP en Apple. SAP heeft de integratie tussen de modules als meerwaarde en Apple is heel erg gesloten. Niemand klaagt. Waarom niet? Omdat juist die vergaande integratie van hardware en software voor een betere gebruikerservaring zorgt. In die zin is Microsoft meer open (qua hardware) en dus minder fijn.

Is opensource-software dus inferieur? Wis en waarachtig niet. Opensource kan uitstekende functionaliteit bieden. Mijn Firefox- browser doet het beter dan Microsofts IE en PostgreSQL is een prima alternatief voor Oracle. Alfresco doet niet onder voor closedsource-ECM-oplossingen. Allemaal sterke merken of bedrijven die garant staan voor integratie, implementatie en ondersteuning.

Ga dus als gemeente niet zelf hobbyen met opensource maar zorg voor sterke partners. Realiseer je dat ook hier niks gratis is en dat leveranciersafhankelijkheid vaak onvermijdelijk is. Er bestaat immers geen free lunch.

naar boven naar boven

De Concurrentie Gerichte Dialoog

Proces & Document 2009, nr. 2

Veel gemeenten worstelen met Europese aanbestedingen. Een boel rompslomp en je doet het zelden goed, zeker als bijvoorbeeld een ICT-pakket wordt aangeschaft.

De specificaties zijn het eerste probleem. Als je niet van te voren alles hebt vastgelegd in een programma van eisen gaat de winnende leverancier daar later zeker op afdingen, al helemaal als je fixed-price afspraken hebt gemaakt. Aanbesteden is dus zoiets als het Russische meerjarenplan: je moet alles vooraf weten anders gaat het achteraf fout.

Behalve het pakket moet je zeker de implementatie van dat pakket niet vergeten. Bij vergunningen praten we al gauw over de omgevingsvergunning (Wabo) en dus over procesherinrichting en kleine reorganisaties. Dat is niet kinderachtig! Een offerte waarbij de implementatie minder kost dan het pakket zou ik daarom niet vertrouwen. Wij gaan er meestal van uit dat over een periode van vijf jaar de implementatie twee tot vijf maal zo duur is als het pakket. Veel ICT-projecten gaan fout op de implementatie. Het project is te laat klaar en/of te duur. Maar ook op harde zaken, zoals koppelingen tussen systemen of migraties, kan een project uit de hand lopen. Een goed contract kan dit soort ellende voorkomen.

Vaak is een goed bestek afgestemd op de markt. Je moet niet meer vragen dan de markt kan leveren. De markt moet tevens precies weten wat je wilt. Dat vraagt om een soort dialoog, doch tot voor kort kon dat amper. Aanbesteden is immers juridisch redelijk dichtgetimmerd: als het bestek uit is kun je niet meer met de leveranciers praten. Gelukkig is er tegenwoordig de zogenaamde concurrentiegerichte dialoog. Die stelt je in staat om met een beperkt aantal leveranciers in gesprek te gaan over wat zij kunnen leveren en wat jij wilt hebben. Dat is vooral nuttig bij complexe ICT-implementaties. Na een eerste leverancierselectie volgen een of meerdere dialoogrondes, waarin het bestek wordt aangescherpt. Daarna kunnen de overgebleven leveranciers optimaal offreren op het aangescherpte bestek.

naar boven naar boven

Wat is architectuur?

Proces & Document 2009, nr. 1

Architectuur bij ICT is in. Iedereen noemt zich tegenwoordig architect en het Landelijk Architectuur Congres (LAC) trekt honderden bezoekers, jaar in jaar uit. Sommige topambtenaren willen alleen nog ICT-nota's zien als ze aan de NORA voldoen. Ik zie dikke rapporten waarin architecten bij gemeenten, provincies en andere overheidsorganen het bestuur dringend vragen om 'onder architectuur' te gaan werken. Wat is hier aan de hand?

Wel, in de eerste plaats is architectuur een mooie term, dus iedereen gebruikt die in de ICT. Op het LAC zitten businessarchitecten (jasje-dasje), informatiearchitecten (jasje) en technische architecten (spijkerbroek) door elkaar heen. De eerste groep heet eigenlijk businessconsultants, de laatste systeemontwerpers. Ik denk dat we er goed aan zouden doen ons te beperken tot de groep informatiearchitecten. Een informatiearchitect hoort - de naam zegt het al - primair te kijken naar informatie en de bijbehorende processen, alhoewel hij ook in staat moet zijn met techneuten en bestuurders te discussieëren. Anders gezegd: een informatiearchitect is een generalist, geen specialist.

Veel architecten zijn een tikje verdwaald in de techniek. Ze praten dan voornamelijk in twee- of drieletterwoorden als SOA, ESB, BPM of BI. Een informatiearchitect die alleen maar dit soort kreten slaakt, zou ik verbannen naar de afdeling Automatisering. Een informatiearchitect kijkt naar de samenhang van processen, over afdelingen heen, zowel in de huidige situatie als in de toekomst. Dus hoe hangen processen en systemen met elkaar samen en welke standaarden gaan we hanteren om meer samenhang te krijgen. Daarnaast kijkt de architect naar samenwerken: hoe 'klantelen' en 'ontkokeren' we onze processen, gegevens en systemen, rekening houdend met de huidige cultuur. Beide (samenhang en samenwerken) zijn essentieel voor de architect.

Veel architecten maken indrukwekkende blauwdrukken voor de toekomst. Dat heeft mijns inziens weinig zin als je niet precies weet waar we nu staan en hoe we dat aan kunnen passen. Welke applicaties gebruiken we? Welke gegevens spelen daarbij een rol (inclusief documenten en berichten)? Welke kanalen en processen, rollen en rechten zijn er nu? Welke informatie blijft binnen de afdeling? Wat gaat naar buiten? Waar willen we naar toe? Hoe doen we dat? Hoe krijgen we onze processen gekanteld, meer klantgericht? Hoe komen we van die verkokering af? Dit vraagt alles vooral om betrokkenheid van architecten, niet om blauwdrukken!

naar boven naar boven

ICT Overlevingsadviezen

Proces & Document 2008, nr. 4

Zoals mijn trouwe lezers weten, ben ik erg voor eenvoud en tegen ingewikkeld gedoe. Ik zeg wel eens: ambities zijn het grootste risico bij ICT-projecten. We geven wat voorbeelden en volgen daarbij de bekende architectuurindeling: organisatie, processen, gegevens, applicaties, techniek.

Organisatie
Gevaarlijke ICT-ambities hier zijn omvangrijke veranderprocessen. Sommige overheidsklanten roepen dat E-dienstverlening niet kan starten als je niet alle backoffices volledig gedigitaliseerd en 'gekanteld' hebt. Vaak horen we dat soort geluiden ook bij de aanschaf van een midoffice. Levensgevaarlijk! Advies: begin van buiten naar binnen te werken en doe niet alles te gelijk.

Processen
Met de moderne BPM (Business Process Management) rage wil iedereen vandaag de dag alles door een workflow pakket laten regelen. Levensgevaarlijk! Een beetje gemeente kent vijfhonderd processen, ieder met vele uitzonderingen en verschillen tussen behandelaars. Advies: neem een eenvoudige seriële workflow (bijvoorbeeld vier stappen), zoals bij het Dordtse zaakmodel, en laat de rest aan mensen over.

Gegevens
Met de open standaarden hype wil iedereen digitaal stekkeren. Neem de gezondheidszorg, waar HL7 is bedacht om informatie uit te wisselen tussen applicaties op basis van complexe berichtenstructuren. Wordt amper gebruikt. Eenvoudige alternatieven voor HL7 zoals XDS (met slechts een paar documenttypes en wat meta-informatie) zijn wel succesvol. Advies: keep it simple, forget the hype!

Applicaties
Gemeenten die voor miljoenen buitenlandse DMS'en aanschaffen denken dat ze een wereldpakket binnenhalen waar je niet fout mee kan gaan. Meer dan de helft van de implementaties van dergelijke pakketten mislukt. Levensgevaarlijk! Advies: neem een eenvoudig en betaalbaar Nederlands DMS-pakket en focus op een gefaseerde zaaksgewijze inrichting.

Techniek
Collega-architecten willen alleen nog maar praten over Service Oriented Architecture, waarin alle applicaties via webservices zijn gekoppeld. Levensgevaarlijk! De praktijk is weerbarstig en velen lopen dood op bestaande applicatielandschappen, zoals bij de gemeentelijke backoffices. Advies: schroom niet zonodig te koppelen door overtypen ('kloppelen'): vaak nog steeds de effectiefste methode.

naar boven naar boven

De aanbesteding als schoonheidswedstrijd?

Proces & Document 2008, nr. 3

E-dienstverlening verbeteren betekent vaak aanschaf van software. Veel gemeenten zien daarbij op tegen een Europese aanbesteding, vanwege een lange doorlooptijd. Bij de gangbare openbare aanbesteding moeten leveranciers minimaal 40 dagen de tijd krijgen om een offerte uit te brengen. Dat is te overzien. De meeste tijd gaat op aan de kant van de gemeente; sommige gemeenten doen er vele maanden over om een bestek op te stellen. Vaak zien we dikke bestekken, met lange lijsten van eisen waar de software aan moet voldoen. Nou is het opstellen van een programma van eisen ook geen sinecure. De meeste organisaties proberen zich aan alle kanten in te dekken tegen het volgende ICT-fiasco. Het probleem bij de aanschaf van software is echter dat het heel moeilijk is om harde eisen te formuleren. Tientallen eisen stellen aan bijvoorbeeld workflow functionaliteiten is niet erg zinnig. Meestal wint dan de leverancier die overal 'ja' heeft geroepen op de eisen, waarna later blijkt dat belangrijke eisen net even anders geïnterpreteerd zijn door de leverancier. Neem daarom vragen op, geen eisen. Laat de leveranciers maar beschrijven wat ze kunnen leveren aan functionaliteit en kies dan de beste, gegeven de wensen. Maak er een soort (objectieve) schoonheidswedstrijd van in plaats van een ja/nee filter. Het liefst met na de offerte een 'verduidelijking' op basis van een proof of concept. Dan kan het bestek ook redelijk beknopt blijven.

Maar de belangrijkste reden om terughoudend te zijn met al die eisen aan de applicatie is nog een geheel andere. Met alleen software ben je er namelijk niet. Ik roep wel eens dat een offerte die voor het grootste deel bestaat uit software (dus kosten van licenties, onderhoud etc) al bij voorbaat tekort schiet. Het succes staat of valt met een goede implementatie van een pakket. Dan gaat het om de kennis en ervaring van de leverancier met het pakket en de organisatie. Referenties, plan van aanpak en met name het team zijn misschien wel belangrijker zijn dan al die eisen aan het pakket. Als we ons dat realiseren, dan hoeft het opstellen van een bestek ook geen jaren te duren.

naar boven naar boven

DMS fiasco's: it's the implementation, dummy!

Proces & Document 2008, nr. 2

De laatste jaren horen we heel wat griezelverhalen over mislukte projecten bij de gemeente op het gebied van document management systemen (DMS). Ik durf de stelling wel aan dat meer dan de helft van de selectie- en implementatietrajecten voor een DMS bij de gemeenten mislukt dan wel zwaar teleurstelt. Hoe komt dat toch?

Of er nou wel of niet Europees wordt aanbesteed, een programma van eisen is er meestal wel. De meeste bevatten tientallen of soms honderden ja/nee vragen. Kan uw pakket A of B? Soms is het aantal eisen zo uitgebreid dat alleen heel grote, dure pakketten eraan kunnen voldoen. Gemeente X koopt dan een groot, complex en duur pakket zoals FileNet, omdat die op alle vragen ja scoort. Ga er maar aan staan met je 25.000 inwoners. Dat kan niet goed gaan.

Soms zie ik ook een prima bestek, waar echter meerdere partijen zo goed als hetzelfde resultaat behalen. Dat krijg je met al die ja/nee vragen. Beter is om leveranciers een tiental wensen (soms vragen) voor te leggen en de antwoorden op een vijfpuntsschaal te vergelijken. Dat geeft meer onderscheid. En probeer dan eens niet het grootste, beste en duurste pakket uit Amerika te selecteren. Voor veel gemeenten zijn kleinere Nederlandse leveranciers een beter alternatief, met meer kennis en ervaring dichtbij. Maar de echte problemen ontstaan meestal tijdens de implementatie. Het pakket maakt weinig uit, het succes zit hem in de implementatie. Gouden regel is: als je een ton uitgeeft aan licenties over drie jaar, trek dan minstens hetzelfde bedrag uit voor implementatie. Liefst het dubbele of meer. Vergelijk het met een ijsberg: alleen die ton voor het pakket steekt boven water, de andere kosten zijn vaak verscholen. Juist bij de implementatie van een DMS zijn de aspecten als configuratie, migratie, procesinrichting en cultuur van wezenlijk belang.

Ten slotte nog dit: pas op voor grote ambities! Niet alleen het verlangen naar het grootste, mooiste, duurste pakket, ook het verlangen om mee te tellen op ICT-vlak is dodelijk. Pas dus op voor moderne hypes als Business Process Management (BPM) en Service Oriented Architecture (SOA). Geen grote en complexe workflow designs alstublieft, maar een eenvoudig statusflow (à la het Dordtse Mozaïek) met goede metadata en bewaartermijnen in een eenvoudig zaaksysteem. Keep it simple, en onderschat de implementatie niet!

naar boven naar boven

Niet te filmen

Proces & Document 2008, nr. 1

De kranten staan er vol van. Weer een ICT-project mislukt bij de overheid en weer X miljoen euro's over de balk. Als ICT'er wordt je er niet blij van. Wat gaat er fout? Veel. Ik noem een paar factoren (gezien door mijn bril).

Ambitie
Grote ambities vormen het grootste risico bij ICT. En dan vooral als bestuurders ambities hebben op het gebied van ICT, waar ze weinig van begrijpen. Levensgevaarlijk! Laatst werd een projectleider op het matje geroepen bij de hoogste ambtenaar van een ministerie: of zijn oplossing wel voor 100 procent overeenkomstig NORA was. Terwijl die ambtenaar natuurlijk geen flauw benul had wat dat inhield. Niet te filmen! De eerste stelregel bij ICT-projecten moet dan ook zijn: keep it simple! Kijk niet voortdurend naar het plafond (wat zou er nog meer kunnen), maar naar de vloer (wat moet er minimaal kunnen). Weinig geld is daarom vaak beter dan veel geld bij een ICT project, hoe gek het ook mag klinken.

Techniek
Die is tegenwoordig zo complex dat het een van de belangrijkste faalfactoren is bij ICT-trajecten. En zeker met al die hypes rond politiekcorrecte technologie (SOA, Open Source, BPM, etc). Wees dus terughoudend met nieuwe technologie en kijk eerst naar bestaande oplossingen die zich bewezen hebben in de praktijk, ook al zijn ze niet zo 'sexy'. En investeer in kennis en mensen met kennis.

Proces
Automatiseren is veel moeilijker dan een huis bouwen. Dat komt doordat het om mensen en hun processen gaat, en daar kan je moeilijke een maquette van maken. Een succesvol ICT-project resulteert meestal in een andere, betere, procesinrichting. Beter in termen van proceskwaliteit (intern), dienstverlening (extern), en efficiency (geld en tijd). Maar o wat is het moeilijk om hier te scoren. Draagvlak, communicatie, leiderschap en begrip zijn hier bepalend. Ook hier geldt: keep it simple! Pas dus op met al die goeroes die dagen de hei op willen voor proces herontwerpsessies... Probeer daarentegen de procesherinrichting stapje voor stapje te realiseren en neem daarbij veel tijd voor ervaring en feedback in de praktijk. Prototypes, proof of concepts, iteraties, etc. zijn daarbij belangrijke hulpmiddelen.

Casting
Ik zie steeds meer zogenaamde projectleiders (sorry programmamanagers) met een recente HBO-opleiding communicatie en een cursus Prince2 die grote ICT-trajecten moeten trekken. Gaat bijna altijd fout. Wilt u een succesvol ICT-project, zoek dan een ervaren ICT-projectleider met een bewezen gevoel voor bovenstaande faal- en succesfactoren!

naar boven naar boven

DMS-pakketten: koud of warm?

Proces & Document 2007, nr. 4

De meeste grote Document Management Systemen (DMS) worden vooral gebruikt voor documentopslag, en dan in het bijzonder archivering. We noemen dat ook wel record management. Wij maken graag een onderscheid tussen warme en koude dossiers. Warme dossiers (ook wel genoemd het dynamische archief) betreffen lopende zaken, koude dossiers de 'statisch' gearchiveerde en afgehandelde dossiers. In de US en Canada (waar de grote DMS-pakketten zoals Hummingbird vandaan komen), hebben ze zogenaamde 'fileplans' voor de koude dossiers die geheel kunnen verschillen van de indeling van de warme dossiers. Dat onderscheid is met Sarbanes-Oxley (SOX) niet minder geworden. In Nederland zijn beide dossierindelingen meestal gebaseerd op hetzelfde documentstructuurplan (DSP), wat volgens mij een goede zaak is.

Het DSP bevat tevens procesbeschrijvingen. Dat is verstandig, want via een proces is veel beter te bepalen welke documenten in welke stappen in het dossier moeten komen. Steeds meer gemeenten en andere overheden willen daarbij een nadruk op 'zaken'. Voor de elektronische dienstverlening bijvoorbeeld is het niet ongebruikelijk het DMS uit te breiden met multi-channel intake (incl. E-formulieren), een zakenmagazijn (met onder andere de status van de afhandeling) en een workflow module voor de proceskant. Behalve een behoorlijke workflow, webformulieren en een zakenmagazijn moeten 'warme' DMS-pakketten ook bepaalde processen ondersteunen. Hierbij zijn Nederlandse sjablonen voor processen en dossiers van groot belang. Denk bijvoorbeeld aan een standaard vergunningsjabloon (met een aantal statussen), sjablonen voor bezwaar en beroep, en beleidsprocessen in een bestuurlijk informatiesysteem. Bij de warmere pakketten (zoals SharePoint van Microsoft) komen ook ongestructureerde processen zoals rond kennismanagement, communities, etc. in beeld.

Uit ons onderzoek naar acht DMS-pakketten bleek dat er duidelijke verschillen zijn tussen warme en koude DMS-systemen. Het maakt dus een verschil of de pakketten gericht zijn op de warme (voorkant) of de koude (achter)kant, het archief. Ook zijn koude pakketten minder gericht op eindgebruikers, naast de DIVmedewerkers. In ons lab bleken maar weinig pakketten sterk te scoren op zowel de koude als de warme kant.

Er worden tegenwoordig vele DMS-pakketten aanbesteed en geselecteerd. De vraag is of daarbij het onderscheid tussen warm en koud niet wat nadrukkelijker moet worden gemaakt. Anders kon je nog wel eens van een koude kermis thuis komen!

naar boven naar boven

SOA, de nieuwe religie

Proces & Document 2007, nr. 3

Als het over architectuur gaat begint iedereen over SOA. Jawel, die beruchte Service Oriented Architecture. Ook als de hele klantomgeving een grote monoliet is zoals SAP ERP zal en moet er weer een servicebusje onder. En natuurlijk overal stekkers op basis van open standaarden. Bij NORA struikel je over de bijbehorende geloofsbrieven. Andere geluiden worden niet op prijs gesteld. De nieuwe religie dus. Ik zal er maar meteen voor uit komen: ik erger me vaak aan al die SOA-busjes. Met name het gemak waarmee leveranciers alles onder het SOA-tapijt vegen. Natuurlijk, geachte klant, zijn wij 100% open en volledig ingericht op servicebussen en open standaarden. Eerlijk gezegd: ik geloof er vaak niks van. Er zijn helaas een boel klanten die dat wel geloven. En al die busjes en open standaarden in hun programma van eisen opnemen. Waarna in negen van de tien gevallen slechts een beetje tussen die grote logge applicaties met wat opgepoetste XML-records wordt geschoven. Wat we vroeger eenvoudig met SQL deden en vaak nog veel sneller. Tjonge, wat een indrukwekkende SOA!

Waar het mijns inziens echt om gaat bij SOA zijn transacties tussen machines. Wij hebben in onze labs verschillende pogingen gezien om echte transacties op basis van webservices tussen applicaties uit te wisselen. Gaat meestal fout, zeker als er verschillende softwareleveranciers bij betrokken zijn. Webservices kennen velen standaarden. Sommige zijn regelrechte concurrenten. OASIS is er groot mee geworden en ondersteunt (wat heet) zelfs meerdere tegenstrijdige standaarden (kijk eens naar ebMS). De eenvoudigste webservices standaard is SOAP, dat gaat nog wel, maar dat is alleen de envelop om een XMLbericht. Dat kan zelfs KPN al een paar jaar bezorgen. Daarboven wordt het moeilijker.

De volgende laag is WSDL: de definitie van het koppelvlak. De daarbij behorende meest gangbare 'open standaard' WSDL versie 1.1 is zo lek ('open') als een mandje. Verschillende leveranciers implementeren dat verschillend. Je hebt dan weer een andere standaard nodig om uit de ruzies te komen.

Wie spreekt al die leveranciers toch eens tegen? Wie durft gewoon te zeggen: hoepel op met je zogenaamde open standaarden en servicebusjes? Ik niet, want klanten willen het allemaal van hun leveranciers. En wat de klant wil, dat leveren ze (dus niet).

naar boven naar boven

DE toekomst is aan de dikke midoffice

Proces & Document 2007, nr. 2

Met al die ANDEZ aanbestedingen ligt de term midoffice bij velen op de lippen. Maar wat is dat eigenlijk, zo'n midoffice? Sommigen denken (terecht) dat het een technische voorziening is om berichten uit te wisselen tussen front- en backoffice. Anderen beweren (terecht) dat het primair om het multi-channel frontoffice gaat (met de kanalen web, telefoon, balie en post). Weer anderen denken (ook terecht) dat een midoffice iets is om een klantcontactcentrum (KCC) te ondersteunen bij de afhandeling van lichte bouwvergunningen etc. Wat is het nou?

Wel, eigenlijk is het midoffice sec slechts een onderdeel van een hele 'suite' van applicaties voor elektronische dienstverlening. Vandaar dat we in de ANDEZ aanbestedingen liever spreken van een midoffice suite. Nog liever spreek ik van een 'dienstverleningsarchitectuur'. De midoffice suite is immers primair bedoeld om multi-channel dienstverlening bij gemeenten, provincies maar ook banken etc. mogelijk te maken.

De dienstverleningsarchitectuur (de suite) omvat applicaties (en misschien nog wel belangrijker: de inrichting!) voor webintake (E-formulieren), voor PIP (Persoonlijke Internet Pagina met o.a. status van mijn aanvragen), voor de ondersteuning van KCC-medewerkers en voor de vastlegging en monitoring van aanvragen voor gemeentelijke producten. Daarbij kennen we twee smaken: dun en dik.

De kern van een 'dun' midoffice is de 'broker', waarmee berichten elektronisch worden doorgeschakeld van front- naar backoffice. Ook zorgt de broker voor verbindingen tussen alle onderdelen van de midoffice suite. Met behulp van de broker kan een elektronische aanvraag voor bijvoorbeeld een bouwvergunning worden doorgeleid naar de juiste afdeling van de backoffice (en backoffice applicatie, zoals BWT4all). De kern van een 'dik' midoffice is dat de afhandeling geheel in het KCC (dus in het front- en/of midoffice) gebeurt. Dus zonder toedoen van de traditionele backoffice. Daartoe is de midoffice suite vaak uitgebreid met een Document Management Systeem (DMS) of relatiebeheersysteem, waarin de verschillende afhandelingprocessen kunnen worden ingericht en de administratie kan worden gevoerd.

In plaats van een applicatie per product/proces (zoals in de meeste backoffices), is er dus een generieke applicatie in het KCC waarmee meerdere producten/processen kunnen worden afgehandeld. Maastricht doet de bouwvergunning niet meer met BWT4all maar met een generiek DMS, waar ook andere zaken mee kunnen worden geregeld. Zo kunnen steeds meer producten en processen worden gekanteld van backoffice naar KCC.

Door producten volledig in het KCC af te handelen wordt de doorlooptijd verkort, de dienstverlening verbeterd en de kosten gereduceerd. De toekomst is dus aan het dikke midoffice (ofwel het KCC-systeem), waarbij de afdelingen (en applicaties) van de backoffice allemaal geheel overbodig zijn geworden. Dan gaat bijvoorbeeld het Centric midoffice concurreren met de vele Centric backoffice applicaties. De leveranciers van backoffices zijn dus gewaarschuwd!

naar boven naar boven

Stokoud van achteren, sexy van voren

Proces & Document 2007, nr. 1

Laatst was het weer zover. Met een zaal vol gemeenteambtenaren en wat prikkelende stellingen mijnerzijds kwamen de fundamentalisten weer naar voren: 'mijnheer Keller, het heeft toch geen zin om een 'sexy' digitale voorkant op te trekken als de achterkant niet op orde is?'

Mijn antwoord: het grootste gevaar voor ICT zijn te grote ambities. En een overmaat aan onrealistische architecturen (zoals bij NORA). De crux zit hem in realistische faseringen: hoe kom ik van de feitelijke situatie naar de gewenste situatie, van ist naar soll? Vandaar mijn stelling: eerst kantelen en de frontoffice opnieuw inrichten, dan pas de backoffice op orde brengen.

De hele discussie is geboren uit de wens van het kabinet om in 2007 de elektronische dienstverlening van bijvoorbeeld gemeenten grotendeels op orde te hebben (de 65% norm). Dat kun je bereiken door alleen de voorkant te moderniseren. Dat adviseren we ook vaak. Zet dienstverlening in ieder geval voorop. Laat gemeentelijke klanten maar van buiten naar binnen duwen op de organisatie, maak de voorkant digitaal, dan worden de belemmeringen achter de voorkant snel duidelijk. Op termijn moet je die achterkant natuurlijk ook aanpakken.

Maar dan nog zou ik terughoudend zijn met de backoffices. Het volledig digitaliseren van bijvoorbeeld de Sociale Dienst of sector Belastingen - inclusief warm archief en workflow - is een stevige klus. Niet alleen technisch en functioneel, maar vooral procesmatig en organisatorisch. We hebben immers op basis van rechtmatigheid al tientallen jaren een bepaalde manier van werken en een administratieve organisatie. Dat gooi je niet zo maar om. Bij de Sociale Dienst zou ik dus niet beginnen met de hele backoffice omver te halen. Probeer eerst maar eens wat eenvoudige vergunningen, meldingen en bezwaren. Het grote voordeel van deze aanpak is dat veel van die eenvoudige producten geen zware backoffice applicaties nodig hebben (zoals GWS4all bij de Sociale Dienst). Die lichte vergunningen, meldingen en bezwaren kunnen we prima met een Document Management Systeem (DMS) of met Customer Relationship Management (CRM) systeem doen. Zelfs de workflow is vaak erg eenvoudig. De aldus gedigitaliseerde eenvoudige producten kunnen we daarom heel goed of zelfs beter in een zogenaamde 'dikke' midoffice afhandelen.

Dus beginnen van voren (dienstverlening) en dan pas de achterkant (efficiency). Dit voorkomt ook dat alle hakken in het zand gaan. Een webintake systeem, een zakenmagazijn en een koppeling met backoffice systemen vormen een goede start. Zo wordt de fasering in de gemeentebrede digitalisering ook veel transparanter. En bedenk daarbij dat de Belastingdienst en de ABN-AMRO u voorgingen. Ook daar draaien nog stokoude legacy systemen in verticale backoffices achter een sexy voorkant.

Tegeltjeswijsheid: laat klanten maar van buiten naar binnen duwen op de organisatie.

naar boven naar boven

Joomla Templates by Joomlashack