Niet zo lang geleden stelde een klant ons de vraag die wij regelmatig tegenkomen: “Hoe kan ik een proces het beste ontwerpen?”. Wij vinden die vraag niet zo gek, want zoals de titel al zegt, er zijn zoveel mogelijkheden. Welke kies je dan. En waarom kies je daarvoor?
Bij het inrichten van processen zijn meerdere partijen (wij noemen ze graag stakeholders) betrokken. Uiteindelijk is er één partij die in onze ogen het belangrijkste is: de eindgebruikers. De direct betrokkenen in het proces, de lezers en uitvoerders van het proces. Zij moeten begrijpen hoe het proces loopt, welke uitkomsten er zijn en waar alle benodigde informatie is terug te vinden.
Dus bij het (opnieuw) ontwerpen van het proces zou je de eindgebruiker voorop moeten stellen. Wat vinden ze makkelijk, overzichtelijk en begrijpelijk? Tegen welke punten lopen ze nu aan bij de bestaande procesbeschrijving, die invloed kan hebben op het indelen? Het verdient dan ook de nadrukkelijke voorkeur om het ontwerpen van het proces samen met de betrokkenen te doen.
Andere uitgangspunten:
Zoals een klein beetje duidelijk is geworden, is er niet zomaar een antwoord. Het hangt van tal van zaken af. Hieronder een aantal voorbeelden zodat je toch een idee krijgt over de mogelijkheden.
Wat ons betreft is het belangrijkste uitgangspunt daarbij: KISS (Keep It Simple, Stupid of Keep It Smart & Simple).
De voorbeelden zijn uitgewerkt in de zogenoemde SIPOC methode.
Dat staat voor Supplier – Input – Process – Output – Customer.
De supplier is waar de input vandaan komt. De input geeft aan wat er binnenkomt in het proces. In het midden vinden we de activiteiten of processtappen (handelingen die uitgevoerd worden) en daar komt tot slot een output uit. De output kan weer een input worden in een volgend proces of in de vervolgactiviteit.
Om een idee te geven van een mogelijke aanpak bij het inrichten van een helder proces nemen we de helpdesk als voorbeeld. Een redelijk generiek proces waar iedereen zich wel wat bij kan voorstellen.
Bij de helpdesk komen gebruikersmeldingen binnen. Die worden beoordeeld en vervolgens zo snel mogelijk afgehandeld.
De beoordeling vindt plaats aan het begin van het proces. Is het een melding waarvan de oorzaak bekend is, en die dus direct is op te lossen, dan kiezen we voor een ‘bekende oorzaak’.
Is het een melding waarvan de oorzaak nog niet bekend is, dan is er eerst onderzoek nodig en wordt de melding geclassificeerd met ‘onbekende oorzaak’.
Hieronder beschrijf ik 3 verschillende manieren om dit, ogenschijnlijk eenvoudige, helpdeskproces te ontwerpen.
(Aan het einde van deze blog vertel ik voor welke procesindeling de klant in kwestie heeft gekozen).
In het eerste proces komt de helpdesk melding binnen. Deze wordt beoordeeld en daaruit komt als resultaat een ‘bekende oorzaak’, waarvan de oplossing reeds is voorgekomen, of een ‘onbekende oorzaak’ waar nog geen directe oplossing voorhanden is.
Is het een bekende oorzaak dan wordt deze direct opgelost en daarna wordt gecommuniceerd over de oplossing met de melder.
De indeling die hier is gekozen, is om eerst de melding te beoordelen. Daarmee wordt in de output bepaald waar een melding verder gaat. Een bekende oorzaak wordt direct opgelost en gecommuniceerd. Bij een onbekende oorzaak moet eerst onderzoek worden gedaan om een oplossing te vinden. Als dat het geval blijkt, wordt de oplossing gecontroleerd en volgt er een ‘opgelost’ melding (output). Deze output is weer input voor het communiceren over de melding zodat er uiteindelijk een ‘afgesloten’ melding komt.
Omwille van de eenvoud laten we een flink aantal wellicht logische details achterwege. Het is slechts een voorbeeld.
Proces 2a: Helpdesk melding (bekende oorzaak)
Proces 2b: Helpdesk melding (onbekende oorzaak)
In voorbeeld proces 2a en 2b zien we dat er hier is gekozen om de onbekende oorzaken niet in het initiële proces te behandelen. Er is voor gekozen om te verwijzen naar een ander proces waar meldingen met onbekende oorzaak worden afgehandeld.
Hier zien we dus duidelijk de scheiding, die aan het einde weer terugkomt voor de communicatie over de oplossing van de melding, met als resultaat de afgesloten melding.
Het voordeel van twee aparte processen is dat er meerdere activiteiten in terug kunnen komen en dat bij de onbekende melding andere activiteiten kunnen worden gebruikt. Er hoeft dus geen vaste werkwijze te zijn voor beide processen in dit geval. Bij de onbekende melding kan er zelf extra informatie worden gegeven over hoe je onderzoek doet en tot een gewenste oplossing kan komen.
Het nadeel is dat er voor een deel ‘dubbele’ activiteiten terug kunnen komen. Met de Comm’ant webbased BPM software is dat geen probleem, omdat de software automatisch consistent is. Wanneer je de activiteit op plek A zou wijzigen, wordt dit ook direct op plek B gedaan.
In het 3e voorbeeld doen we het precies andersom. We beginnen met de onbekende oorzaak en het vervolgonderzoek om tot een instructieoplossing te komen. Als we die hebben, wordt de instructie input bij het ‘oplossen bekende oorzaak’ en komt er een ‘opgeloste’ melding uit. Deze is tegelijkertijd de input voor de ‘bekende oorzaak’-melding, die op dezelfde manier wordt afgerond.
Indeling
We zien hier dat door te beginnen met de onbekende melding, er later in het proces minder stappen nodig zijn. Dit is dus de meest efficiënte manier van beschrijven. Omdat je eerst de ‘onbekende oorzaak’ hebt afgehandeld en daarna gebruik kan maken van dezelfde input/output en activiteiten van de ‘bekende oorzaak’-melding.
Of dit voor eindgebruikers ook de meeste prettige manier is, is een andere vraag. Het is misschien even wennen.
Wat uit deze voorbeelden blijkt, is dat het op allerlei manieren kan. Niks is goed of fout. Het is vaak ook een kwestie van smaak, die de indeling bepaalt, uiteraard en vooral in overleg met de eindgebruikers. Dit kan een persoonlijke smaak zijn, het is beter om een generieke smaak of style te creëren voor de organisatie. Zodat andere procesontwerpers het op dezelfde manier doen.
En het fijne van de Comm’ant software is dat je met de basisingrediënten (input, output en activiteiten) heel makkelijk kunt sleutelen aan jouw eigen ‘beste’ proces. Wij noemen dat Rapid prototyping.
Die klant koos voor optie twee. Waarom? Dat vonden de eindgebruikers het makkelijkst. Hoewel de procesontwerper zelf een ander idee had en liever voor optie 3 was gegaan.
Processen ontwerpen en inrichten doe je niet alleen, dat doe je samen.