Bliep

039Bewegende stukken metaal; da’s niks nieuws, natuurlijk

Zelfs Bassie en Adriaan hadden er al één; een robot.  Een in elkaar geknutseld stuk blik met een wekkerhoofd dat iets kon vasthouden en een grappig stemmetje had.

En zo kennen de meeste van ons robots (afgezien van het stemmetje en het wekkerhoofd); ronddraaiende machines met mechanische armen die bijvoorbeeld kunnen lassen of dingen oppakken.

En die worden al decennia lang toegepast in industriële processen. En onder de noemer “Industrialisering 4.0” worden deze robots nu ook steeds slimmer. Doordat ze, via sensoren en internetconnectie, data kunnen uitwisselen, beschikken de robots over veel meer informatie om hun gedrag aan te passen of andere “processen” aan te sturen.

Dus naast het fysieke werk wat ze al deden, kunnen robots, doordat ze aangestuurd worden door software steeds beter data begrijpen en verwerken.  Maar dat wist u natuurlijk al, want zelfs die robot van die clown en die acrobaat kon al telefoonboeken lezen en de data met een onwerkelijke snelheid verwerken. 

Dus robots in de industrie worden door deze “connectiviteit ” steeds slimmer en zelflerender.

En, als je de verhalen op Linkedin mag geloven, hebben robots nu zelfs hun intrede gedaan in administratieve processen . Onder de naam “Robotic Process Automation” (RPA) betreden zij de kantoren van de gegevensverwerkende organisaties.

Heeft iedereen straks een lezende wekker op z’n bureau staan? Nee, dat niet. RPA is gewoon software waarmee je data verwerkende transacties kunt automatiseren.

Maar in administratieve processen wordt toch al flink geautomatiseerd? 

Automatisering in gegevensverwerkende processen gebeurt inderdaad al vele jaren. Eerst op taakniveau door het gebruik van specialistische applicaties, later op procesniveau door gebruik te maken van workflowmanagement en BPM achtige tools.

Wat doet Robotic Process Automation dan?

RPA richt zich op data verwerking wat nu nog handmatig gaat

Ondanks dat we in gegevensverwerkende processen al veel ondersteuning zien door software, blijkt dat veel systemen nog niet altijd even goed met elkaar communiceren.

Met name de uitwisseling van data is een gebied waar nog veel te winnen valt. En RPA richt zich met name op gebieden waar het verwerken van data (opzoeken, bewerken en verwerken) nog door mensen wordt gedaan.

Handmatige verwerking, gebeurt dat nog?

Zekers. Met name in processen die een beetje tussen wal en schip zitten en waar, om van (vergeef me de uitdrukking) end-to-end te komen, diverse systemen en databronnen gebruikt moeten worden.

Neem als voorbeeld alles wat er moet gebeuren wanneer een nieuwe medewerker in dienst treedt. Waarschijnlijk zijn er diverse systemen waar de medewerker “opgevoerd” moet worden.  Het personeelsinformatieysteem, salarissysteem, intranet, mail systeem; verzin het maar.

RPA richt zich op organisaties waar dat nog veel met de hand gebeurt. Dus waar mensen al die systemen openen, data opzoeken, bewerken en weer ergens anders invoeren, zodat al deze systemen uiteindelijk over de juiste medewerker-informatie beschikken.

RPA wordt daarom ook wel eens “Draaistoel automatisering” genoemd.

Een robot in RPA speelt dit handmatige riedeltje na

Door het toepassen van RPA tools kunnen deze handmatige acties overgenomen worden door robots. Deze robots voeren dezelfde handelingen uit die eerst door mensen werden gedaan.

Om deze robots te bouwen moeten deze de handmatige taken in een ontwerpomgeving “nagespeeld” worden en “opgenomen”.

Bijvoorbeeld:

  • Open excelbestand <naam medewerker>.xls
  • Ga naar de 2e rij, eerste kolom
  • Kopieer de naam
  • Formateer de naam in [Achternaam],[Voornaam] [tussenvoegsels]
  • Start MIS.exe
  • Klik op “Nieuwe medewerker opvoeren”
  • Selecteer veld “Naam”
  • Plak
  • Ga terug naar Excel
  • Ga naar de 2e rij, 2e kolom
  • etc

En uiteindelijk kan de robot al deze handelingen zelfstandig uitvoeren. Vanzelfsprekend zijn er diverse bewerkingen van data mogelijk, kunnen vele systemen worden “gelezen”en komen de RPA suites met uitgebreide monitoring en logging functionaliteit.

Bestaat dat al niet?

Tuurlijk kunnen er scripts, macro’s, SOA’s, webservices e.d gebouwd worden om al deze data heen-en-weer-stuur acties uit te voeren. Levert wellicht hetzelfde eindresultaat op.

Het idee achter een RPA suite is dat dit allemaal vanuit 1 omgeving gebeurt en makkelijk te bouwen is. Daarnaast zijn robots her te gebruiken, aan elkaar te linken etc. Kortom; een RPA suite is een grote robot bouwdoos.  En de belofte is dat je niet veel programmeerkennis nodig hebt om een robot te bouwen.

RPA suites beloven dus makkelijk bouwen en goed beheer van al deze robots die de handmatige data verwerkingstaken overnemen.

Ben je met RPA eigenlijk niet de “cowpaths aan het paven”?

Vanuit een idealistisch procesverbeter standpunt kun je je afvragen of RPA wel een goed idee is. Iets wat met de hand gebeurde, wordt nu 1 op 1 door robots gedaan.

Dus niet eerst kijken of het ook slimmer kan (waarom hebben we eigenlijk 8 systemen met medewerkerinformatie? Is al die data wel nodig?), maar gewoon automatiseren die hap.

Zoals u weet, wordt dat ook wel “paving the cowpaths” genoemd.

Ik heb een leverancier van RPA gehoord die dat ook helemaal niet ging verdedigen. “RPA is duct tape; niet elegant maar het werkt uitstekend”.

RPA maakt het proces dus niet persé leaner, maar simpelweg goedkoper. En daarmee kom ik op de consequentie van RPA; mensen raken hun baan kwijt.

Waardevoller werk? 

Door leveranciers van RPA wordt altijd benadrukt over het feit dat je heel veel kunt besparen op loonkosten. Dat zorgt meestal voor blije gezichten in de boardroom, maar die loonkosten waren ook iemands salaris.

Ik vind dat er dan altijd net iets te makkelijk wordt gezegd dat die mensen dan werk kunnen gaan doen dat meer waardevol is. En natuurlijk komen de leveranciers dan met mooie voorbeelden daarvan. Ik vraag me af of dat wel altijd het geval zal zijn. Wie doet dan nu dat waardevolle werk? Niemand?  Hoe waardevol is het dan daadwerkelijk?

Vanzelfsprekend komen RPA leveranciers ook met mooie voorbeelden waar de inzet van RPA juist nieuwe banen opleverde. Maar dat kan toch niet waar zijn in alle gevallen?

Maar wie ben ik? 

Maar ja, als je als organisatie alleen maar kunt overleven door kosten te besparen, wie ben ik dan om te zeggen dat dat kort door de bocht is?

Want, als je in een sterk concurrerende markt zit, is de enige manier om te overleven vaak kosten besparen. En dan is het inzetten van robots die niet klagen of moe worden een logische stap.

De maatschappelijke gevolgen zullen breder getrokken moeten worden door bijvoorbeeld discussies over het basisinkomen.

Maar, wie ben ik om me daar mee te bemoeien? Ik typ alleen maar stukjes over procesmanagement.

Bliep.

 

 

 

‘het nieuwe goud’ en uw processen

Data is al heel wat jaartjes hip. Processen worden altijd als een beetje saai gezien.

Toch zijn ze onlosmakelijk met elkaar verbonden.  Tenminste, dat is zoals ik er naar kijk.

Dus, hoe kijk ik er naar?

Doel is het laten presteren van processen; procesmanagement dus

In een eerdere post kon u al lezen dat ik procesmanagement zie op 3 niveaus.

  1. De uitvoering van een proces voor een individuele zaak
  2. Besturing van alle lopende zaken in een bepaald proces
  3. Verbeteren van het procesontwerp voor een bepaald zaaktype

Wanneer ik organisaties help om al deze niveaus van procesmanagent in te richten, is belangrijk om te begrijpen wat je allemaal nodig hebt om een proces te laten presteren.

Zodat je niveau 3 niet zo vaak hoeft te doen.

Dat betekent dat we dan kijken naar diverse samenwerkende proces aspecten als:

  • Wat is het werk dat moet gebeuren (de werkstroom)?
  • Wat voor type mensen met welke capaciteiten zouden zijn daar voor nodig?
  • Welke hulpmiddelen zijn benodigd?
  • Wat is de beste manier om dit proces te besturen (bijv. taakgericht of doelgericht)?

Er zijn meer aspecten, maar degene waar ik in dit verhaaltje op in wil gaan is Data.

Want u heeft waarschijnlijk al diverse artikelen gelezen waarin u las dat data ‘het nieuwe goud ‘ is.  Ook herinnert u zich vast de gloriedagen van ‘Big Data’ of leest u weer een quote dat we nu meer data in een minuut produceren dan onze grootouders in een heel milennium.

Super cool, maar wat heeft het te maken met processen inrichten, besturen en verbeteren?

Veel. Want in bijna alle processen speelt data (of zou het beter zijn om het informatie te noemen?) een grote rol. Maar data in het algemeen is ook maar data, dus daarom maak ik altijd onderscheid, net als de cirkeltjes uit een eerder artikel,  in het gebruik van data op verschillende niveaus van procesmanagement:

  1. Data om een proces voor een individuele zaak uit te voeren
  2. Data om alle zaken die momenteel lopen te kunnen besturen
  3. Data om het proces(ontwerp) te kunnen verbeteren
  4. Data als verbinding tussen verschillende processen

Om dit uit te leggen, gebruik ik weer m’n ‘Bezorgen pizza’ proces:

Data die nodig is om het proces uit te voeren

In het proces ‘Bezorgen pizza’, is het gewenste procesresultaat een bezorgde pizza. Maar, het start allemaal met een klant die de wens heeft om een pizza te laten bezorgen. Om alle tussenliggende handelingen uit te kunnen voeren, is informatie benodigd.

Om de pizza te maken is informatie nodig als:

  • Welke pizza wil de klant?
  • Welk formaat?
  • Welke extra toppings zijn er besteld?

Om de pizza te kunnen bezorgen, is informatie nodig als:

  • Bezorgadres
  • Gewenste bezorgtijd
  • Telefoonnummer

Dit maakt ook duidelijk dat stappen die je vaak in het begin van een proces ziet, als ‘Vastleggen bestelling’ alleen maar nodig zijn om bovenstaande data te verkrijgen. Het vastleggen van deze data voegt geen waarde toe aan het maken of bezorgen van de pizza. Het voorziet het proces enkel van informatie. Maar wel nodig natuurlijk.

En daarom moet er, zeker in de huidige ‘multi-channel-tijd’, tijdens procesontwerp nagedacht worden over hoe de data in het proces belandt.

  • Telefoon
  • E-mail
  • Bestelwebsite
  • Bestel app

Omdat de Customer Journey ook een hip ding is, is het belangrijk dat het de klant niet heel erg moeilijk wordt gemaakt om u van deze data te voorzien.

Bovenstaande is dus data voor een individuele case. Hopelijk krijgt deze pizzeria meer dan 1 bestelling per dag. En daarmee kom ik op het volgende niveau van data.

Data om alle zaken in een proces te managen

Veronderstel dat op een bepaald moment in de avond zich 8 bestellingen in het proces bevinden. Medewerkers werken aan de individuele bestellingen, maar tenminste één iemand zal de rol van procesmanager moeten spelen om ‘alle zaken in de gaten te houden’.  Dat betekent dat er informatie nodig is over hoe de zaken er voor staan.

Voor mij zou dat betekenen dat je de status van alle zaken in het proces weet en dat duidelijk is of ‘de belofte wordt waargemaakt’

En die belofte kan, vanzelfsprekend, van proces tot proces verschillen. In een vorige post hield ik het simpel door alleen de bezorgtijd (binnen 50 minuten) in ogenschouw te nemen. Omdat waar te kunnen maken is dus voor elke bestelling inzicht in deze belofte nodig:

Dit is traditioneel proces monitoring, maar voor mij nog steeds essentieel in ‘doen wat je belooft’.  Dit is wat ik ‘op het veld’ noem. Want op dit moment kan nog ingegrepen worden in zaken waar de belofte mogelijk niet waar gemaakt kan worden.

Wanneer u nadenkt over de inrichting van zaakmonitoring, kunt u ook nadenken over in hoeverre u deze gegevens beschikbaar wilt stellen aan een klant. Het schijnt ‘the age of the customer’ te zijn, dus wilt u hem/haar informeren over de voortgang van de zaak?

Dit monitoring niveau van procesdata gaat om ‘doen wat je belooft voor de individuele klant’. In dit geval pizza’s op tijd bezorgen.

Nadat je meerdere individuele klanten hebt geholpen, wordt waarschijnlijk ook duidelijk hoe goed het proces in het algemeen is ingericht.

Tenminste, als u daar de juiste data voor verzamelt. En daarmee zijn we op niveau 3 van data in procesmanagement beland.

Data om processen te verbetern

Dit derde niveau van data gaat over traditioneel procesverbeteren.  Presteert het proces zoals we het ooit hebben bedacht, of heeft het een opknapbeurt nodig? Het is de klassieke Village People hit ‘PDCA’.

Maar om te weten of het ‘beter’ moet, zul je eerst ‘goed’ moeten definiëren.

In mijn simpele pizza voorbeeld is dat ‘Bezorgd binnen 50 minuten’. Maar in het echt gelden vast meer doelen als:

  • Lekker (hoewel smaken verschillen)
  • Warm (> 78 graden)

Of interne doelen als:

  • Winstmarge op pizza > 34%

En dan hebben we het nog niet eens gehad over doelen opgelegd door andere belanghebbenden als wetgever of controlerende instanties als de NVWA.

Om te kunnen bepalen hoe goed het proces het doet (of eigenlijk ‘heeft gedaan’), is data over procesprestaties benodigd. Dat kan natuurlijk verzameld worden door te meten, spreadsheets bij te houden of misschien zelfs met mooie management informatie dashboards in een BPM tool.

En dat maakt mij verder ook niet uit, zolang de data je maar iets zinvols vertelt over de prestaties van je proces. Sinds een aantal jaar zou ook Process Mining hierbij een toepasbaar hulpmiddel kunnen zijn.

Process Mining is technologie dat data gebruikt van de systemen die worden toegepast om processen uit te voeren. Vervolgens wordt deze data (die over de verschillende afgehandelde zaken gaat) omgezet naar een ‘procesgeoriënteerde kijk’, om op die manier iets over het proces te weten te komen.

De meeste process mining tools hebben diverse mogelijkheden om deze data te representeren. Een basisplaatje is vaak een figuur van de werkstroom met daaraan gekoppeld de gemiddelde bewerkingstijd van activiteiten en de gemiddelde wachttijd tussen de activiteiten (weergegeven op verbindingen).

Na een beetje rekenen (wat de process mining tool vanzelfsprekend ook voor u kan doen) is de conclusie dat de gemiddelde doorlooptijd 50 minuten en 33 seconden bedraagt.

Maar, wat heb je nou aan gemiddeldes? Ik heb op school niet zo heel goed opgelet bij statistiek, maar niet zo heel veel, geloof ik.  Daarom hebben de meeste process mining tools ook de mogelijkheid om doorlooptijden, wachttijden etc. anders te tonen.

Bijvoorbeeld de minimale en maximale waarde. Dit geeft al een kleine indicatie van de variantie.

Het volgende plaatje laat de minimum en maximum bewerkingstijd van activiteiten en de minimum en maximum wachttijd op verbindingen zien.

Even de TI 30 stat er bij pakken en u ziet dat de snelste bestelling in 38 minuten werd bezorgd en dat de langzaamste er 1 uur en 25 minuten over deed. Is dat erg? Waarschijnlijk niet zo leuk voor de klant die 35 minuten langer dan beloofd moest wachten. Maar maakt dat het direct noodzakelijk om te sleutelen aan het procesontwerp?

Meer inzicht daarin verkrijg je door alle doorlooptijden in een grafiek te laten zien (ook standaard functionaliteit van veel process mining tools).

Nu is zichtbaar dat 7 van de 23 bestellingen een langere doorlooptijd dan het doel van 50 minuten hadden. Of dat goed of slecht is, mag elke organisatie zelf bepalen. Maar voor de 7 klanten die de pizza te laat kregen, is er niks meer aan te doen. We kijken immers naar gegevens uit het verleden. Vandaar dat ik traditioneel procesverbeteren ook wel ‘kleedkamerpraat’ noem.

Een ander ding om te beseffen, is dat al deze proces prestatie informatie slechts symptomen laten zien. Om het proces te verbeteren, zul je echter op zoek moeten naar de oorzaken.

Toch kan process mining al wel wat indicaties geven over waar te zoeken naar de oorzaken van bijvoorbeeld een lange doorlooptijd.  Zo was te zien dat bestellingen een behoorlijke tijd spenderen aan wachten. Bijvoorbeeld tussen de stappen ‘Verpakken pizza’ en ‘Bezorgen pizza’.

Nog steeds een symptoom, maar dit zou kunnen leiden tot een onderzoek waarin duidelijk wordt waarom bestellingen gemiddeld 8 minuten wachten voordat ze worden opgepakt voor bezorging.

Om nog meer inzicht te krijgen in verstoringen van ‘de flow’, bieden process mining tools ook de mogelijkheid om de stroom van gevallen in een soort van filmpje te tonen. Wat er in feite gebeurt is dat het logbestand op een procesgeoriënteerde manier wordt nagespeeld. Hierdoor worden bottlenecks nog visueler (dit is overigens een statisch plaatje) weergegeven.

En dan ‘nog even’ een oplossing bedenken en implementeren 😉

En dat was niveau 3 van data; procesverbetering. Niveau 2 ging over de dagelijkse procesgang van zaken (in dit geval pizzabestellingen) en op niveau 1 zagen we de data benodigd voor een individuele bestelling.

Wanneer ik organisaties help met het knutselen aan processen, benoem ik ook altijd nog een ander type data; data die stroomt tussen processen.

Data die stroomt tussen processen

De meeste organisaties hebeen meer dan één proces. We weten al dat de pizzeria een proces heeft voor ‘Bezorgen pizza’, maar er zullen ook processen zijn voor ‘Afhalen pizza’  en misschien ook wel voor ‘Eten in het restaurant’.  Daarnaast verwacht ik processen om de voorraad (van deeg, tomaten, saus, dozen, etc) op het gewenste niveau te houden.

En tussen al deze processen bestaan ook datastromen. Want als je 50 pizza’s per dag verkoopt, heeft dat gevolgen voor de voorraad. Dus het proces ‘Bezorgen pizza’ genereert data (50 pizza’s gemaakt), wat weer gevolgen heeft voor data in andere processen (de huidige voorraad van goederen).

‘Bezorgen pizza’  en ‘ Voorraad op gewenste niveau houden’ zijn dus processen met een relatie. Die relatie is niet de stroom van een zaak, maar gebaseerd op de data die in die processen gegenereerd wordt:

Processen sturen dus data naar ‘databases’ met informatie en ander processen maken weer gebruik van die data. Hier zijn vele voorbeelden van te bedenken. Bijvoorbeeld klantinformatie die in het ene proces wordt geactualiseerd en in het andere proces weer nodig is.

Dit maakt weer mooi duidelijk dat ‘de processelarij’  heel veel andere vakgebieden raakt zoals informatiemanagement en data-security.

En dat komt omdat dit niveau 4 van data zich meer op een organisatie- of procesarchitectuurniveau bevindt. Hiermee wordt ook duidelijk dat de prestatie van het ene proces invloed kan hebben op een ander proces.

Heel wat data, dus. Een belangrijk aspect van presterende processen, denk ik.  Maar niet het enige. Vandaar ook dat ik processen altijd een goed uitgangspunt vind om naar organisaties te  kijken.

Een proces is een verzameling van allerlei samenwerkende factoren. Niet alleen blokjes en pijltjes (en als u van BPMN houdt, ook wat cirkeltjes). Daarom blijf ik procesmanagement zo interessant vinden.

Gebruik uw data slim en happy processing!

Een documentstroom is geen proces, toch?

030

 

Degene die mij kennen, weten vast wel (bijvoorbeeld via facebook voor mensen met een stropdas) dat ik ook werk voor een grote Amerikaanse printerreus die via allerlei acquisities ook een Enterprise software leverancier is geworden.

Veel van die software probeert oplossingen te bieden voor problemen die zich in het informatiewereldje bevinden.

Dan lijkt procesmanagement soms slechts een speldenknop te zijn binnen het geweld van documenten die gescand, geprint, rond-geworkflowed, gezocht en opgeslagen moeten worden.

En omdat veel organisaties worstelen met grip krijgen op een grote verzameling documenten vergeet men al snel dat er maar één plaats is waar die documenten nodig zijn; in processen!

Wanneer u bijvoorbeeld een lening aanvraagt bij een bank, worden er in dat proces heel wat documenten gebruikt om u, de bank en andere belanghebbenden te voorzien van de benodigde informatie voor procesuitvoering. En daarmee hebben we gelijk de 2 punten om die documentgekken om de oren te slaan.

Ze betitelen vaak de stroom van een document als een proces. Da’s een zeer beperkte kijk. Het gaat om het verstrekken van een lening, niet om het rondsturen van het aanvraagformulier. Het is de aanvraag die stroomt, niet het document.

En daarmee kom je op het punt dat een document slechts een gegevensdrager is. De aanvrager wil zijn aflossingsbedrag weten en dat hoeft niet persé op een document te staan. Het gaat om de informatie. Dat heeft een proces, naast andere enablers, nodig om te presteren. Niet de documenten.

Maar, als u dan toch documenten maakt en print, dan wel op een ******* printer!

 

Ik heb toch ook al een aantal jaren geen klei-tabletten meer gezien

008Degene die mij kennen, weten dat ik naast deze procesje-flauwekul ook mijn tijd besteed aan het werken voor een groot Amerikaans concern dat organisaties helpt met de ‘ongestructureerde data uitdaging’. Eigenlijk betekent dat gewoon dat zij software verkoopt voor proces– en informatiemanagement en ik klanten help met het implementeren daarvan. Best saai, maar omdat software altijd een hulpmiddel moet zijn in processen, ligt procesmanagement gelukkig altijd op de loer.

Software en processen dus. In het huidige digitale tijdperk zijn deze 2 als Bassie en Adriaan; een onafscheidelijk duo.

En software kan vele rollen spelen in processen. Het kan complete processen (of delen daarvan) autonoom uivoeren. Het kan taken handiger maken voor de uitvoerders. Maar, terugkomend op het procesje van vandaag; Een niet te onderschatten toepassing van software is het beschikbaar stellen van informatie ter ondersteuning van procesuitvoering en -besturing.

Het merendeel van processen presteert namelijk niet zonder informatie. Dit kan informatie zijn voor het uitvoeren van het proces of prestatie-informatie voor het (achteraf) verbeteren van het proces. Maar ook, naar mijn mening het belangrijkste, informatie om het proces live te besturen.

Dus heeft u zich wel eens afgevraagd of de manier hoe u informatie binnenkrijgt, opslaat, rondstuurt en uitstuurt wel ondersteunend is aan uw processen? Bevindt het zich op analoge documenten, digitaal op usb stick, in databases in the cloud?

Of vertrouwt u op een pratende wekker om het proces-informatie duo te laten presteren?