Kies eerst één documentproces.
Begin met een terugkerend documenttype en een beperkt aantal velden. Bijvoorbeeld een onderhoudsaanvraag waaruit je het aantal vestigingen, de gewenste start en de gevraagde werkzaamheden wilt overnemen. Leg vast waar het document binnenkomt, wie het verwerkt en welk systeem de gegevens uiteindelijk ontvangt.
Meet hoe dit nu gebeurt. Hoeveel documenten komen binnen, welke varianten bestaan er en hoeveel tijd gaat naar controleren en herstellen? Met die uitgangssituatie kun je later beoordelen of een oplossing werkelijk iets verbetert.
Een voorbeeld: de onvolledige aanvraag.
Stel: een fictieve onderhoudsaanvraag gaat over drie vestigingen, met een gewenste start op 1 januari. Welke werkzaamheden inbegrepen zijn en of die startdatum haalbaar is, staat nog open. De toepassing zet de gevonden gegevens met hun bron klaar. De scope en definitieve ingangsdatum krijgen de status “te bevestigen”; een gewenste datum wordt niet als gemaakte afspraak overgenomen.
De medewerker heeft zo een overzicht voor de vervolgvraag en offertevoorbereiding: wat is bekend en wat moet eerst worden afgestemd? Pas na controle worden de gegevens klaargezet voor de volgende stap. Dit is een uitlegvoorbeeld zonder live klantgegevens, geen klantcase of bewijs van gemeten nauwkeurigheid.
Ontwerp de uitzonderingen mee.
De kwaliteit zit niet alleen in het goed verwerken van een duidelijk document. Denk ook aan een slecht leesbare scan, tegenstrijdige datums, dubbele aanvragen en een onbekende indeling. Spreek af wanneer de toepassing stopt en hoe een medewerker de verwerking overneemt.
Maak onderscheid tussen een ontbrekend veld en een verkeerd herkend veld. Beide kunnen extra werk veroorzaken, maar vragen een andere controle. Bij belangrijke vervolgacties moet duidelijk zijn wie akkoord geeft. Een waarschuwingslabel helpt alleen als iemand weet wat ermee moet gebeuren.
- Toon de oorspronkelijke bron naast de gevonden gegevens.
- Maak ontbrekende en tegenstrijdige informatie zichtbaar.
- Leg vast wie controleert en hoe correcties worden verwerkt.
Een pilot is nog geen dagelijkse voorziening.
Een pilot onderzoekt met een beperkte set documenten of de aanpak bruikbaar kan zijn. Houd een deel van de voorbeelden apart voor de beoordeling. Alleen testen met de documenten waarop je de oplossing hebt aangepast, geeft een te gunstig beeld.
Voor dagelijks gebruik zijn extra afspraken nodig: toegang, opslag, koppelingen, monitoring, foutenafhandeling en onderhoud. Ook moet een medewerker kunnen terugvallen op een werkbare handmatige route. Neem deze onderdelen mee in de beslissing om na een pilot verder te gaan.
Reken het hele proces mee.
De kosten bestaan uit meer dan het uitlezen van een document. Denk aan inrichting, software, opslag, integratie, menselijke controle, herstelwerk en beheer. Een snellere eerste verwerking kan weinig opleveren als een medewerker daarna veel moet corrigeren.
Onderzoek ook wat je bestaande software al kan. Bij een vaste indeling kan een eenvoudige formulierinrichting of regelgestuurde verwerking voldoende zijn. De beste eerste stap is de aanpak die het afgesproken werk betrouwbaar ondersteunt en waarvan de kosten in verhouding staan tot de waarde.
Welk documentwerk wil je verbeteren?
Beschrijf het documenttype en wat je nu handmatig overneemt. Vertrouwelijke documenten zijn voor een eerste gesprek niet nodig.
Bespreek je automatiseringsvraag