M&I/Argitek - e-business architects

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...

Download de PDF
Nadere informatie via flits@argitek.nl

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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