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.

 

 

 

Lekker efficiënt, niet?

023

Je kunt haast nergens meer een proces project opentrekken of het doel is wel om processen efficiënter te maken. Het zij via Lean, het zij via een andere verbetermethode; efficiëntie, dat is de heilige graal!

Wanneer ik dan zachtjes fluister dat efficiëntie eigenlijk geen doel van een proces kan zijn, word ik, zoals wel vaker, uitgelachen. ’Kom op Procesje, je kunt wel merken dat jij niet naar de procesverbeter-school bent geweest’ tuurlijk is efficiëntie wel een doel van het proces’

Maar, stel dat u gewoon lekker kon aanklooien, beetje lanterfanteren en waailappen terwijl toch iedereen tevreden was over het resultaat van uw processen. Wie heeft het dan nog over efficiëntie? Niemand toch?

En daarmee kom ik op het punt achter dit procesje.  De meeste processen hebben als doel om een product of dienst op te leveren. Over dat procesresultaat belooft u vast iets. Niet zelden op het gebied van tijd of kosten.

En dat is dus het procesdoel; iets opleveren tegen bepaalde kosten of in een bepaalde tijd.  En als dat allemaal prima gaat, mooi toch?

Maar als het plots, omwille van concurrentie, wetgeving, etc, sneller of goedkoper moet, dan zal er wellicht een efficiëntie slag gemaakt moeten worden. Efficiëntie is daarmee een middel geworden om uw processen (weer) te laten doen wat ze beloven.

Is het voor u ook noodzakelijk om efficiënter te werken? Vertel uw medewerkers dat dan niet, maar vertel ze wat u wilt dat uw processen echt doen. Grote kans dat efficiënter werken dan een onvermijdbaar bij-effect is.

Suiker en Melk?

021

(Let op: deze blog is, na beetje afstoffen, een herplaatsing van blog van 13 sept 2011. Wellicht dat sommige stukjes daardoor wat ouderwets overkomen)

Procesmanagement is dagelijks werk. Dat kun je goed doen of slecht doen. Maar stel dat je het serieus zou willen proberen, dan zou je kunnen stellen dat het doel van procesmanagement het besturen van uw organisatie op basis van processen is.

De gedachte daarachter is dat processen “de dingen” zijn waarmee uw organisatie de producten en diensten voor uw klanten maakt.

Lean is een methode voor continu verbeteren. Toegepast op een procesgerichte organisatie, gaat het daarbij dus om het verbeteren van processen.

Hierdoor zou het leveren van producten en diensten dus steeds beter moeten gaan. Wat daarbij als ‘beter’ wordt betiteld, verschilt natuurlijk van proces tot proces.

Lean en Procesmanagement; 2 verschillende dingen, maar samen een sterk koppel. De goede dingen steeds beter doen. Wie wil dat nou niet?

De ideetjes achter Lean zijn natuurlijk niet de enige manier om processen te verbeteren. Maar, het zal u niet ontgaan zijn, wel net zo populair als Justin Bieber   Genoeg voorbeelden dus ook van succesvolle en minder succesvolle toepassingen.

Mijn ervaring is dat de minste kans op verbetering ontstaat wanneer lean wordt ingezet als trukendoos. Met z’n allen 3 dagen op training en dan knutselen aan VSM’en, oud Japans verbeterbord-staren, werkplekken inrichten met 5 essen en vervolgens verbaasd zijn dat die 2 ton besparing maar niet wil lukken in een maand.

Lean is geen trucendoos. Dat het een levensstijl is, gaat me ook iets te ver, maar “willen verbeteren” is toch wel een minimale voorwaarde. En wanneer zou u willen verbeteren?

In ieder geval wanneer u pijn heeft. Dus, waar doen uw processen pijn?

Beter is soms gewoon slechter

010

Dit zou een mooi procesje zijn ter ondersteuning van mijn hetze tegen organisaties die als doel hebben om processen te modelleren. Of misschien nog wel meer tegen allerlei bureautjes en consultants die vertellen dat het toch echt nodig is om al je processen in kaart te brengen.

Maar, nee. Deze keer ligt de nadruk op het woord efficiëntie. Een woord dat elke manager graag hoort en hem alles laat aanschaffen wat, volgens de folder, de efficiëntie verbetert.

Efficiënter werken. Plat gezegd betekent dat dat je hetzelfde product/dienst levert met minder mensen, tijd, grondstoffen, energie etc. Al deze factoren zijn relatief eenvoudig om te rekenen naar geld, dus betekent het dezelfde producten/diensten leveren voor minder geld. Niets mis mee.

Vind ik ook. Tenminste als het zou gaan om de efficiëntie van een proces als geheel. Een proces heeft een bepaald resultaat en efficiënter betekent dus dat het proces hetzelfde resultaat voor minder geld gaat leveren.

Daarom is het jammer om te zien dat deze proceskijk vaak wordt vergeten in de zoektocht naar efficiënter opereren. Zelfs in groots opgetuigde lean-trajecten zie ik toch regelmatig het oerverschijnsel suboptimalisatie.

Eén speler in het proces bereikt een efficiëntieverbetering, kan daardoor meer tussenresultaten produceren, maar de rest kan er niets mee. Tussenvoorraden gaan omhoog, kosten ook, efficiëntie van het proces (als geheel!) omlaag.

Een verbetering is soms dus ook een verslechtering. Da’s logisch.

Waar zijn die klanten eigenlijk?

009

 

Een paar jaar geleden mocht ik op een bijeenkomst iets vertellen over mijn visie op procesgericht werken en verbeteren. Na afloop kwam er een toehoorder naar me toe met de vraag “heb je soms iets tegen Lean?”.

Ik iets tegen lean? Nee, hoezo? Zou ik dan onbewust zoveel negatieve dingen over Lean zeggen? Een soort van”Lean de la tourette”?

Nadenkend kwam ik tot de conclusie dat mijn uitingen over Lean inderdaad wel eens wat negatief zouden kunnen overkomen. En dat komt omdat Lean (eventueel in combinatie met sixsigma) zo’n makkelijke prooi is om tegen aan te schoppen. En dat komt misschien wat gek over uit mijn mond; iemand die zich inzet voor het verbeteren van processen.

Daarom wil ik benadrukken dat ik niet tegen de methode Lean ben, maar tegen de oogklep-toepassing binnen organisaties en het elkaar allemaal napraten. Iedereen op Lean cursus! Volg de Skodarijder…ik wil helemaal geen Skoda. Zo zie ik het ook met Lean.

(Ik moet overigens wel toegeven dat het elkaar napraten de afgelopen jaren wel wat minder lijkt geworden)

Terug naar de boodschap: het verbeteren van processen is vaak nodig, maar doe dat wel bewust. Het is geen leuke stafhobby ‘voor erbij’

Begin met procesidentificatie en bepaal vervolgens welke resultaten van processen niet voldoen. Bepaal vervolgens wat verbeteren betekent (sneller, goedkoper, beter, afschaffen?)

En dan kent Lean, maar ook andere methodes, fantastische hulpmiddelen om verbeteringen door te voeren.

Sorry Lean, ik zal in het vervolg beter op mijn woorden letten.

Effe wachten nog…

004

Er zijn proces-analytici die hebben geconcludeerd dat er processen bestaan waarin slechts 5% van de doorlooptijd daadwerkelijk aan een zaak (een bestelling, klacht, order, etc) wordt gewerkt.

Dat betekent dat er 95% van de tijd niets gebeurt. Dan is er dus sprake van wachtmomenten in een proces. Ik merk nog wel eens verwarring over de term wachtmoment. Zeker wanneer er vanuit een “ik-view” naar een proces wordt gekeken, wordt vaak gedacht dat medewerkers zitten te wachten. Echter, in processen gaat het niet om het “ik”, maar juist om het resultaat dat voor een klant geleverd moet worden.

Een wachtmoment houdt dus in dat de afhandeling van de onderhanden zaak stil ligt.

In Lean termen wordt er op die momenten geen waarde toegevoegd voor de klant, waardoor wachten als één van de verspillingen wordt aangemerkt.

Waarom zou een zaak stil komen te liggen tijdens de uitvoering van een proces?
Daar kunnen vele redenen voor zijn. Het kan capaciteitsgebrek (van bijvoorbeeld medewerkers) zijn. Of de zaak kan niet verder worden behandeld omdat er gewacht wordt op informatie.

Zeker wanneer informatie van extern moet komen, kan dat lastig zijn. Ook kunnen wachtmomenten (onbewust) zijn ingebouwd door batchverwerking. Zaken moeten dan wachten tot hun batch vol is. Daarom wordt er in vele verbeteraanpakken (Lean, ToC) zo gehamerd op “flow”.

Die, eerder genoemde, 95%; hoe zit dat in uw processen? Ik wacht op uw antwoord.