menu
(enkel voorstelling van de auteurs en een drietal korte recensies)
Al van in de inleiding krijg je de indruk dat de structuur van het boek voor de auteurs zeer belangrijk was. Het boek is ingedeeld in vijf "delen", die elk nog verder onderverdeeld zijn in "hoofdstukken" of iets dergelijks. De term "hoofdstukken" wordt echter niet gebruikt, en sommige zijn zo kort (één pagina) dat ze nauwelijks een "hoofdstuk" waard zijn. Vermoedelijk was dat laatste ook de reden voor de afwijkende benamingen.
De globale aanpak is goed, maar bij de uitwerking worden m.i. hier en daar foutjes gemaakt. Het boek draagt ook de stempel van het adviesbureau van de auteurs, dat allicht klanten wil aantrekken. Verder niks mis mee; ze overdrijven niet. De informatie en kennis wordt gortdroog gepresenteerd, en op die manier ontstaat een bruikbaar naslagwerk. De behandeling van ICT is realistisch; mijn vrees dat dit weer een promotie voor "digitalisering" zou zijn (die mogelijk nog doorschijnt in de bespreking hieronder) was niet terecht. Hier en daar schieten ze wel door in nutteloze detaillering, maar dat doet in feite geen afbreuk aan de waarde van het boek als naslagwerk over procesoptimalisatie in de openbare sector. De aanpak zorgt ervoor dat ook effectiviteit zijn plaats krijgt, en niet enkel efficiëntie.
Tekst [tussen rechte haken] betreft inhoud uit het boek; aanhalingstekens wijzen op "begrippen" en "letterlijke citeringen".
Hier heb je weinig aan. Dit is een poging om de elementen die verder nog besproken worden in een schema bij elkaar te zetten. Vermits je de elementen nog niet kent heb je ook weinig aan een overzicht. De bedoeling is vermoedelijk om de structuur te benadrukken. Was niet nodig. Idem in deel 2.
Dit is zeker OK. Bij het begin definiëren waarover je het hebt is altijd goed. De definities zijn duidelijk, de uitwerking (klant is functie van de scope, klanten in de publieke sector, de maatschappij als klant) is helder.
Definitie van belanghebbenden. Is OK.
Beschrijving van [behoeften, van gebeurtenissen als aanleiding tot behoeften, van behoeften als aanleiding tot de keuze van een product.] [Behoeften zijn], zeer terecht, [de basis voor het ontwerpen en realiseren van producten] ("producten" bevat hier ook "diensten"). [Voor het in kaart brengen van behoeften wordt de vorm van een user story gebruikt: als "wie" wil ik "wat" zodat "waarom"], en dat maakt mij achterdochtig; ik begin te vrezen dat technologie te veel aandacht gaat krijgen. Maar laat ons even afwachten…
Het doet toch vreemd aan dat een "dienst" ook een "product" genoemd wordt. In de publieke sector gaat het uitsluitend over diensten. Het afleveren van een document is ook een dienst, omdat het in de eerste plaats gaat over het afleveren van informatie, en niet over het "product", dat bestaat uit informatie op papier. Het gebruik van de term "producten" is een veralgemening die op zich niet verkeerd is, maar in het kader van de publieke sector m.i. niet nodig is, en bijgevolg eerder stoort. Onder de algemene term "producten" vatten de auteurs "diensten" en "goederen" (wat dus een wijziging inhoudt t.o.v. de gangbare indeling diensten/producten). Een mondeling advies vinden zij een dienst, een neergeschreven adviesnota vinden ze een product. Mijn vrees wordt groter. Iets telbaar (adviezen, vergunningen, …) zou een product zijn, begrippen als cultuur, onderwijs e.d. niet…?
[Attesten, verklaringen e.d. zijn de output van een dienst, maar zijn zeer dikwijls ook de input van een volgend proces.] De auteurs stellen daarom dat "producten kunnen verbonden zijn via processen". Oeps?! Processen kunnen verbonden zijn via producten, ja; het omgekeerde snap ik niet. Vervolgens wordt gedefinieerd wat wel een output is maar geen product, en wat het verschil is tussen een product en een productvariant. Waar gaat dit eindigen? Is een ontsporing in zicht?
Wel goed: [een productencatalogus kan niet in een boomstructuur weergegeven worden, wel in een platte lijst met gebruikmaking van tags, omdat een bepaald product in verschillende categorieën kan voorkomen (bv. "subsidie voor duurzaam plattelandstoerisme" valt onder toerisme, landbouw, duurzaamheid en subsidies).] Het nut van een productencatalogus wordt beschreven in maar liefst 14 punten, waarbij heel wat veronderstellingen gemaakt worden over de beschikbaarheid van gegevens, en over de verwerking daarvan; ICT lijkt al op voorhand ingebakken.
Een "generiek interactiepatroon tussen klant en aanbieder" wordt voorgesteld. Dit zijn details die niets bijbrengen.
Verschillende mogelijke communicatiekanalen worden beschreven: [fysiek loket, informatiesessie, videoconferentie, telefoon, chatbox, sociale media, postbedeling, elektronische post, digitaal loket, website, automaat, informatiebord, elk met hun kenmerken.] De uitspraak "door in te zetten op het virtuele loket in plaats van het fysieke loket, wordt de dienstverlening vaak klantgerichter en goedkoper", in dit vroege stadium van het boek, doet mij vrezen dat het betoog weer de technologische kant opgaat, met meer aandacht voor efficiëntie dan voor effectiviteit.
Hier worden verschillende niveaus van besluitvorming beschreven: [strategisch, tactisch en operationeel. Daaruit volgen meerjaren- en/of jaarplannen. Doelstellingen kunnen gerealiseerd worden via eenmalige acties (projecten) of via reguliere werkzaamheden (processen)]; het onderscheid is klassiek, maar m.i. voor discussie vatbaar.
[Een definitie van het begrip proces, beschrijving van kenmerken (bv. end-to-end), de voordelen van procesbenadering t.o.v. een functionele benadering.] De vuistregel voor naamgeving is [werkwoord + zelfstandig naamwoord]. Een regel is goed, maar deze komt uit het Engels. In het Nederlands is het beter omgekeerd, nl. [zelfstandig naamwoord + werkwoord]; jammer dat weinigen zo ver nadenken.
Hier een beperkende definitie van het begrip "activiteit"; dit is niet OK. Verwarring tussen de algemene en deze specifieke betekenis van "activiteit" is onvermijdelijk. De definitie "een activiteit is een verzameling van taken of werkzaamheden" draagt verder bij tot de verwarring, zeker als even verder blijkt dat activiteiten weer kunnen gedetailleerd worden in onderliggende activiteiten.
[Sommige activiteiten leveren waarde voor de klant; optimaliseren is dan het maximaliseren van die waarde. Sommige processen zijn noodzakelijk om te voldoen aan de wetgeving; optimaliseren is hier het minimaliseren van de kost.]
[Uitvoerders zijn doorgaans ofwel medewerkers, ofwel rollen, maar ook ICT-applicaties of machines kunnen uitvoerders zijn. Een RASCI-analyse kan nuttig zijn om problemen bij de toewijzing van uitvoerders aan processen te detecteren.]
Het gaat hier om de procesinhoud. De auteurs vertrekken van het m.i. eerder onbekende schildpaddiagram van Crosby (met in de figuur de output aan de kop en input aan de staart??; oeps, foutje…), om dat vervolgens uit te breiden tot iets wat sterk lijkt op het aloude IDEF0 diagram: links input, rechts output, vanboven sturing, vanonder middelen. Je kan slechtere voorstellingen kiezen, maar dat ze het een schildpaddiagram blijven noemen is te gek. Tussendoor een verwijzing naar de baten van procesoptimalisatie: verhoging van waarde voor de klant (niet klantenwaarde), doorlooptijdreductie, foutenreductie en kostenreductie. Correcte opsomming, lijkt mij, maar sommige zijn vermeld in het overzicht (hoofdstuk 1), andere niet?
Hier gaat het om de processtructuur. De klassieke insteek, het zwembanendiagram, wordt beschreven, met voordelen, beperkingen, en goede praktijken. Verder het waardestroomdiagram, en het (op UML gebaseerde?) interactiediagram, zeer summier.
(Terzijde: (1) niet de klantwaarde, wel de waarde voor de klant, en (2) de titels lijden aan het Engels-euvel, zoals de procesnamen; beter was simpelweg "Waarde voor de klant verhogen".)
De subtitel "Klantenwaarde en klantentevredenheid" bevestigt dat "klantenwaarde" fout is; het gaat om de tevredenheid van de klant en de waarde voor de klant. Jammerlijk voor een boek dat zoveel aandacht heeft voor details; ze bedoelen allicht "Productwaarde".
Nog een tool: de klant-empathiekaart of Customer Empathy Map (in het Engels klinkt het altijd wat minder vreemd). De bedoeling is een voorstelling te maken van de leefwereld van de klant. Zijn ze nu niet aan het doorschieten? Hebben we echt zoiets nodig om te registreren dat speeltuigen roesten of toiletten stinken? En de klant hierbij betrekken lijkt mij al helemaal geen goed idee. Analoog kan de processtructuur worden weergegeven in een "klantreisdiagram" (of Customer Journey Map :-). En als we nog tijd hebben maken we ook een klantinteractiediagram, zodat we het aantal interacties kunnen minimaliseren, en de overblijvende interacties kunnen optimaliseren. Klanten kunnen bevraagd worden met een enquête, via diverse kanalen. Wel opletten met enquêtes, zeker als ze door een externe partij worden opgezet.
Een belangrijk aspect bij optimalisaties is het verminderen van de administratieve lasten voor de klant.
Het stuk over "hefbomen voor het verhogen van de productwaarde" is interessant. Dit geeft een overzicht van aandachtspunten voor verbeteringen, zowel extern als intern. Beetje typisch voor het boek: het overzicht wordt ook gepresenteerd als een mind map, maar die heeft geen toegevoegde waarde…
Goed hoofdstuk over de doorlooptijd, met een definitie, manieren om gegevens te verzamelen en voor te stellen, inzicht te verwerven, en ook hier weer de hefbomen voor reductie.
Beschrijving van enkele algemeenheden over kosten, met o.m. het verschil tussen kosten en efficiëntie: je kan een proces proberen efficiënter te maken door de verhouding input/output te verkleinen, of je kan het goedkoper maken door de uurkost te verminderen. Jammer genoeg is dit een nutteloze spitsvondigheid, omdat de term "efficiëntie" evengoed gebruikt wordt voor kosten. Als je geld als een middel beschouwt, zitten de kosten ook in de input, en is het onderscheid niet meer geldig. Positief is dat de auteurs grondig nadenken, negatief is dat ze daarin soms te ver gaan, en dat zijn net elementen die processen complexer en dus duurder maken. Ook bij de berekening van personeelskosten is er een risico dat detaillering meer problemen creëert dan oplost, zeker als je werknemers gaat bevragen of reële tijden gaat opmeten, maar daar wordt realistisch mee omgegaan. De berekening van andere kosten wordt geïllustreerd met enkele simpele voorbeelden.
Ook hier weer een mooi overzicht van hefbomen voor kostenreductie. Opvallend is wel dat hier maar liefst 12 pagina's aan gespendeerd worden. Veel details (en ICT komt dikwijls ter sprake), maar het geheel blijft eerder realistisch. Hoewel hier en daar toch een adder in het gras zit. Bijvoorbeeld bij het verbeteren van de beschikbaarheid van medewerkers: "dit vraagt een cultuurwijziging in de organisatie, en dit kan gebeuren via [..] metingen, opname in functionerings- en evaluatiecriteria van medewerkers", en dat gaat in de (verkeerde) richting van command-and-control (en er gaan nog andere voorbeelden in die richting; zie ook boek "Systems thinking in the public sector"). Uiteindelijk is dit wel één van de meer nuttige delen in het boek.
Fouten worden hier met naam en toenaam genoemd, in plaats van ze in de doofpot te steken. Zalige beschrijving van fouten en hun kenmerken, gevolgen, behandeling, … en reductie. Geruststellend teken van gezond verstand: "hoe minder regels, hoe minder controles op deze regels nodig zijn".
Summier. [Werkwijze: wetgeving omzetten in toetsbare eisen. Hefbomen: wetgeving wijzigen…]
Hier gaat het zonder meer over projectorganisatie. Dat is begrijpelijk vanuit het oogpunt van een externe aanbieder van procesoptimalisatie (zoals het adviesbureau van de auteurs), vermits die enkel voor de duur van een specifiek project wordt aangesteld. Voor de organisatie zelf gaat het om procesbeheer, en is projectbeheer bijkomstig. Idealiter is procesoptimalisatie op zichzelf ook een continu proces, zonder dat daar veel projectorganisatie bij komt kijken (en dan heb je ook dat gedoe met stuurgroep en opdrachtgever en andere rollen niet nodig). De pagina over het verschil tussen optimaliseren en verbeteren is er weer te veel aan.
Eén van de vele mogelijke theoretische stappenplannen. Dit zal in de praktijk sterk afhankelijk zijn van het specifieke geval.
Gaat verder op het idee van projectorganisatie.
In een organisatie met procesbeheer is dit continu beschikbare informatie. Elders moet je rekenen op bevragingen van uitvoerders en klanten (doorgaans weinig betrouwbaar), observaties en metingen.
Selectie van toepasselijke hefbomen uit de hoger vermelde lijsten.
Gaat verder op het idee van projectorganisatie.
(Hier weer een voorbeeldje van het gevolg van een verkeerde vorm in de titel. In eerste instantie leest men "de waarborgen van …" (zelfstandig naamwoord), en pas daarna blijkt dat bedoeld wordt "het waarborgen van…" (werkwoord). Met de betere vorm zelfstandig naamwoord / werkwoord zou dat worden "De geoptimaliseerde situatie waarborgen", en dat is meteen duidelijk.)
Dit waarborgen is de laatste stap die in projecten dikwijls wordt overgeslagen, zeker als het om documentatie gaat. Bij procesbeheer is dat een integraal deel van het proces; dit is een belangrijke reden om voor volledig procesbeheer te kiezen i.p.v. te optimaliseren via projecten.
Lijstje van overwegingen die nuttig zijn bij procesoptimalisaties via zowel projectbeheer als procesbeheer.
Beetje chaotisch overzicht van mogelijke verbeteringen in publieke organisaties. Vermoedelijk vooral bedoeld om organisaties aan te zetten na te denken over wat ze eventueel kunnen optimaliseren, om vervolgens daarvoor een aanbieder in te schakelen (bv. het adviesbureau van de auteurs).