Van GARBAGE-IN naar… GOUD-OUT - deel 2

In het vorige blog (deel 1) zag je dat je vooral van de throughput van een proces af moeten blijven in het begin. Doen we dan helemaal niets met die throughput waar we normaal zo fanatiek mee beginnen? Jawel hoor, maar dat komt straks in Deel 3.

Deel 1 sloten we af met de volgende tip:

GBV (Gezond Boeren Verstand) tip nummer 1

Beschrijf van een proces eerst alle processtappen en focus je per processtap op:

1. Wat gaat er in.
2. Wat moet er uit komen.
3. Laat de throughput (verwerking) voorlopig met rust -want dat is een werkinstructie.

Oh ja, nog even ter herinnering. Een proces ziet eruit als op het onderstaande plaatje:

Er gaat “iets” het proces in.

Dat “iets” wordt verwerkt.

En er komt “iets” uit.

Spannender wordt het niet.

Hebben we hem weer te pakken? Top! Dan kunnen we doorrrrr!

Wat is dat “iets” dat erin gaat en dat “iets” wat er uit moet komen nu precies?

Laten we bij het makkelijkste stukje beginnen: de output. De output van een proces is simpelweg het resultaat dat je beoogt of behaald moet worden. En de output verraadt zichzelf meestal in de procesnaam.

- Wat is de output van een proces inkopen?                     Juist ja, een inkoop!

- Wat is de output van een vergunningsaanvraag?          Yep, een beschikking over de aanvraag.

- Wat is de output van een subsidieaanvraag?                 Duh, een beschikking over de subsidie.

Dat gaat lekker rap. Die output hebben we dus zo te pakken. (En de throughput laten we qua beschrijven -voorlopig- met rust.) Blijft er voor de snelle lezers onder ons alleen nog de input over.

Nou ja, niet helemaal. De oplettende lezer heeft opgemerkt dat we de throughput qua beschrijven voorlopig met rust laten. Maar we gaan deze tóch even besnuffelen.

Waarom toch stilstaan bij throughput?

We moeten namelijk wel uitpluizen wat dat “iets” is dat het proces ingaat. Én wat er nog meer bijgesleept wordt wanneer we de boel gaan verwerken. Plus, dan zijn er nog fatale termijnen (ook wel deadlines genoemd) die we moeten halen. Genoeg te doen dus! Maar gelukkig kan dat heel systematisch. Al is het wel -voor wie het goed wil doen- een monnikenwerk.

"Wat je wilt weten van een proces is welke gegevens er door het proces verwerkt worden. Immers, ken je de gegevensstroom, dan heb je een hele grote stap gemaakt in je informatiemanagement én je verantwoording wordt een stuk makkelijker. Dus kom maar op met die voordelen!"

It’s all about the data

Wat je wilt weten van een proces is welke gegevens er door het proces verwerkt worden. Immers, ken je de gegevensstroom, dan heb je een hele grote stap gemaakt in je informatiemanagement én je verantwoording wordt een stuk makkelijker. Dus kom maar op met die voordelen!

Hoe pak je dat nu aan? Simpel (toverwoord): door het proces te bekijken en de gegevensstroom in kaart te brengen. Opschrijven of typen dus. En ja ik zeg dat erbij omdat we meestal deze oefening overslaan, omdat we 1) denken dat we het toch wel weten en 2) geen zin hebben in dat monnikenwerk.

 Dus pen en papier of laptop in de aanslag. Check? 

Yes! ✅

“Uhm, maar wat leg ik dan precies vast?” Goede vraag! Per proces/processtap leg je de informatie vast zoals opgesteld in de onderstaande tabel:

En ja. Met gegevenssets bedoelen we dus ALLE gegevens. Dus bij een subsidieaanvraag niet alleen “het aanvraagformulier”, maar de gegevens die op het aanvraagformulier ingevuld moeten worden (bijvoorbeeld NAW-gegevens) en alle andere gegevens die opgevraagd worden in bijlagen et cetera.

Zijn die gegevens lastig te achterhalen? Nee. Is het vastleggen een vervelend werkje? Yep. Maar… gelukkig eenmalig.

Verbazingwekkend

😱 Gelet op dat een gemeente feitelijk slechts een informatieverwerkend bedrijf is, verbaas ik me altijd over het feit dat de gegevenssets zo slecht inzichtelijk zijn. Nog nooit heeft een gemeente -van welk proces dan ook- mij binnen een paar tellen een overzicht kunnen laten zien van alle gegevens die door het proces heen lopen. Dat is en blijft vreemd.

Het mag duidelijk zijn dat voor de andere informatie ook geldt dat je alle applicaties, medewerkers et cetera in beeld brengt.

Nu weet je dus ook precies wat dat “iets” is dat door het proces beweegt én welke instrumenten gebruikt worden door welke medewerkers, wat de fatale termijnen zijn, welke wet- & regelgeving van toepassing is, welke beheersmaatregelen je hebt getroffen en wat de procesrisico’s zijn.

Je weet nu dus alles van je proces en de gegevensstroom. Heerlijk toch?

"Nog nooit heeft een gemeente -van welk proces dan ook- mij binnen een paar tellen een overzicht kunnen laten zien van alle gegevens die door het proces heen lopen. Dat is en blijft vreemd."

Doen we nog iets met die fatale termijnen?

Je bent ze niet vergeten merk ik. Die fatale termijnen. Uiteindelijk vertellen fatale termijnen/deadlines je iets over wanneer een processtap klaar moet zijn. En als hierin tussen verschillende processtappen een afhankelijkheid bestaat (de ene stap moet klaar zijn voor een volgende kan beginnen) dan kan je voor procesoptimalisatie kijken of lineaire programmering mogelijk is voor de meest optimale doorlooptijd.

Maar let op. Hoofdzaak is ‘wanneer’ iets klaar moet zijn. Niet ‘hoe’ dit tot stand komt, want dat is weer… juist ja, ‘hoe’ is onderdeel van de werkinstructie en nog niet rijp voor optimalisatie.

En nu simpelweg tekenen

Nu je alle informatie hebt kan je het proces simpelweg uittekenen, inclusief de fatale termijnen/deadlines en alle overige informatie die door het proces stroomt.

Tijd om af te sluiten met de GBV tip

Als je het proces uiteindelijk gaat beschrijven (en kom ik weer… het proces, niet die throughput) zijn de volgende vuistregels handig. Althans dat vind ik zelf, maar dit is geen vast stramien, geen swimming-lane, geen flow-chart of wat dan ook. Dit gaat om 1) wat jij zelf prettig vindt en 2) een manier die anderen ook kunnen lezen en begrijpen.

Beschrijf van een proces/processtap alle informatie op een duidelijke manier:

1. Zet boven het proces de gegevensset die door het proces stroomt.
2. Zet bij de output van de processtappen de fatale termijnen/deadlines.
    (Heb je er meerdere in één processtap -wat dus uit gegevens van de throughput blijkt- vraag je dan af of dit niet twee processtappen moeten zijn.)
3. Zet onder het proces de overige informatie.

Schematisch ziet dat eruit als het onderstaande plaatje:

Simpel hè?!

En nu op naar deel 3

In deel 3 komt ‘ie dan echt hoor; dan gaan we werkelijk iets zeggen over de throughput! Maar dat is voor de volgende keer.

Heb je na het lezen toch nog een vraag? Loop je ergens tegenaan wat ik nu nog niet behandeld heb? Stuur me gerust een berichtje!