Externe aanvragen bestuurbaar verwerken van intake tot opvolging

Veel organisaties automatiseren hun interne processtappen, maar de echte bestuurbaarheid begint vaak eerder: bij de intake. Een aanvraag komt binnen via een partner, een klantformulier of een ander systeem. Daarna moet je zeker weten dat het juiste proces start, dat de juiste gegevens beschikbaar zijn en dat een haperende koppeling niet ongemerkt de doorlooptijd opblaast. Precies op die grens zijn de afgelopen periode verbeteringen aan Odigos doorgevoerd.

Stel je een installatiebedrijf voor dat storingsmeldingen ontvangt van woningcorporaties, eigen monteurs en externe servicepartners. Als elke ingang anders werkt, ontstaan er snel uitzonderingen: een melding start geen proces, een onderliggende regel ontbreekt, of een externe terugkoppeling blijft hangen zonder dat iemand het ziet. Met de nieuwe verbeteringen kun je die intake als procesgrens modelleren, controleren en volgen.

Een externe aanvraag start direct het juiste BPMN-proces

In Orchestra kan een BPMN-start-event nu ook gekoppeld worden aan een inkomende contract-API-aanroep. Daarmee wordt een aanvraag van buiten niet meer eerst een losse registratie die later handmatig opgepakt moet worden, maar direct het startpunt van een procesmodel. In het voorbeeld van het installatiebedrijf kan een storing vanuit een partnerportaal meteen een storingsproces starten.

In BPMN-termen modelleer je een start-event voor de externe melding, gevolgd door een taak die de melding registreert en een gateway die bepaalt of het om spoed, regulier onderhoud of een vervolgafspraak gaat. Daarna kunnen parallelle paden lopen, bijvoorbeeld één pad voor planning en één pad voor controle op contractafspraken. Omdat de gegevens uit de gekoppelde datastructuur als herkenbare tags beschikbaar zijn in de modeler, kun je beslissingen en taakteksten baseren op dezelfde informatie die bij de intake is binnengekomen.

Belangrijk voor bestuurbaarheid is dat Odigos processen met een starttrigger naar een ontbrekend formulier of ontbrekende datastructuur bij opslaan weigert. Dat voorkomt weesprocessen: modellen die er op papier goed uitzien, maar in de uitvoering nooit betrouwbaar kunnen starten. Je borgt dus niet alleen het procesverloop, maar ook de ingang waardoor werk het proces binnenkomt.

De intakegrens blijft herkenbaar voor partners en beheersbaar voor jou

Bij externe aanvragen wil je vaak niet dat de buitenwereld jouw interne gegevensmodel hoeft te kennen. Odigos ondersteunt daarom veld-mapping voor datastructuur-API's. Daarmee kun je externe namen gebruiken die logisch zijn voor partners, terwijl het proces intern met een stabiele contractstructuur blijft werken. Ook gekoppelde lijsten kunnen als subitems in dezelfde aanvraag worden meegenomen, bijvoorbeeld meerdere werkzaamheden, onderdelen of locaties bij één storingsmelding.

Voor het installatiebedrijf betekent dit dat een woningcorporatie een complete melding kan aanleveren met hoofdgegevens en onderliggende werkregels. In Orchestra kun je daarna een taak modelleren voor intakecontrole, een gateway voor volledigheid en een foutafhandeling wanneer verplichte gegevens ontbreken. Waar een medewerker nodig is, kun je via Interact een taak of formulier inzetten om ontbrekende informatie op te vragen. Zo blijft de procesregie duidelijk: een stap is pas klaar als aantoonbaar de juiste gegevens aanwezig zijn.

Ook aan menselijke formulieren is de intakekant aangescherpt. Formulieren negeren een tweede verzending zolang de eerste actie nog loopt. Dat helpt dubbele aanvragen voorkomen in processen waar een gebruiker ongeduldig nogmaals op verzenden klikt. Het resultaat is geen belofte van foutloosheid, maar wel een sterkere procesgrens: minder ruimte voor dubbele startmomenten en meer voorspelbaarheid in de audit trail.

Vervolgacties via koppelingen blijven bestuurbaar

Na de intake volgt vaak een keten van koppelingen: planning, dossieropbouw, financiële controle of terugmelding aan een partner. Daarvoor is Backlog uitgebreid tot een werkbaar overzicht voor afhandeling van uitgestelde, lopende en mislukte verzoeken. Beheerders zien per wachtrij wat wacht, wat in uitvoering is, wat is mislukt en hoe oud het oudste wachtende verzoek is.

In het BPMN-model kun je na de intake een servicetaak opnemen die een extern systeem benadert, met foutafhandeling en eventueel een timer voor vervolgcontrole. Als dat externe systeem hapert, hoeft het proces niet onzichtbaar stil te vallen. Backlog kan herhaalpogingen afhandelen en geeft nu ook beheersacties zoals opnieuw proberen, annuleren, pauzeren en hervatten. Voor het installatiebedrijf betekent dit dat een terugmelding naar een planningssysteem niet verdwijnt in een technische fout, maar als bestuurbaar werk zichtbaar blijft.

Voor procesmanagers sluit dit aan op StatusQuo : je volgt niet alleen waar procesinstanties staan, maar kunt ook gericht ingrijpen wanneer een koppeling het proces vertraagt. Daarmee wordt doorlooptijd beter verklaarbaar. Niet op basis van gevoel of losse meldingen, maar op basis van zichtbare processtatus, historie en concrete uitzonderingen.

Onderzoek waar jouw intake procesregie nodig heeft

Als aanvragen van klanten, partners of externe systemen bij jou nog als losse uitzonderingen binnenkomen, is dat een goed startpunt voor procesautomatisering. Onderzoek welke intakekanalen direct een BPMN-proces kunnen starten, welke gegevens aantoonbaar gecontroleerd moeten worden en welke koppelingen bestuurbaar moeten blijven als iets hapert. Plan een gratis adviesgesprek om dit voor je eigen processen te verkennen, of maak direct een gratis Odigos-account aan om zelf te beginnen.

Al het nieuws · Volg via RSS