In de laatste blog kon je over de vele aspecten – inclusief de critische succesfactoren – lezen voor succesvolle procesimplementaties. Deze blog is gericht op de voornaamste bedrijfsproces implementatie technologieën die er bestaan en die je toelaten om vlot en duurzaam de processen te implementeren die je (her)ontworpen hebt.
Mogelijks nog belangrijker: je leest er aanbevelingen – of op zijn minst duiding – over wanneer je welke technologie best gebruikt.
1. Organisatie brede software
Wat is bedrijfsbrede of organisatie brede software?
Dit zijn zogenaamde software pakketten, ook Commerial Off-The-Shelf software genoemd :
- ERP of Enterprise Resource Planning – zoals SAP, Microsoft dynamics AX of NAV, open source ERP zoals Odoo of Compiere, enz.
- CRM of Customer Relationship Management – zoals Salesforce, Siebel (destijds overgenomen door Oracle), open source CRM, enz.
- SCM of Supply Chain Management software
- MES of Manufacturing Execution System software – zoals bv. BrightEye, Siemens, Apriso, enz.
Of andere, die ofwel onderdeel kunnen zijn van een grotere bedrijfssoftware suite, ofwel niche software voor een specifiek (sub)functioneel domein.
Eigenschappen van organisatie brede software
Off-the-Shelf
Typerend voor die software applicaties is dat ze “off-the-shelf” zijn, wat betekent dat je – althans in theorie – de software niet hoeft te ontwikkelen of programmeren, maar in plaats daarvan moet “integreren” in jouw organisatie.
In werkelijkheid is er meestal enige ontwikkeling nodig bovenop de standaardsoftware om aan specifieke functionele noden te voldoen.
Afhankelijkheid van software adviseurs
Deze applicaties zijn dikwijls zo complex dat u moet vertrouwen op specifieke softwareadviseurs die over de (software) expertise beschikken om ze te implementeren. Zoals SAP-consultants of Dynamics AX / NAV-consultants, enz.
Cross-functioneel
De eerste ERP-softwarepakketten werden snel zeer populair dankzij hun cross-functioneel karakter. Een verkooporder (een verkoopafdeling) bijvoorbeeld wordt gestroomlijnd naar collega’s van de plannings, productie of magazijn, enz.
Waarschijnlijk de reden waarom ERP een typische enabler – of zelfs driver – was voor procesherontwerp gedurende het laatste decennium van de vorige eeuw.
Geïntegreerde database
Een ander groot voordeel is dat bijna alle processen – althans degene die door de software ondersteund worden – één en dezelfde database gebruiken, waardoor mensen van verschillende afdelingen dezelfde, unieke gegevens en een gemeenschappelijke taal gebruiken.
Deze “monolithische” karakteristiek heeft echter ook enkele nadelen, zoals je verderop zal lezen.
Modules – een risico voor functionele silo’s
Helaas, wat ik ook heb ervaren, is dat dit soort software nog te dikwijls functionele silo’s kan veroorzaken. Consultants zijn vaak gespecialiseerd in delen van de software – modules genaamd en vaak geassocieerd met functionele domeinen, bv. financiën, inkoop, productie, enz. Een consultant kan moeilijk – lees onmogelijk – alle modules kennen, en kent dus niet alle mogelijkheden van andere modules. Dat kan een obstakel zijn voor end-to-end bedrijfsprocessen.
Advies voor een wendbare, procesgedreven implementatie
In 2011 heb ik een Master-scriptie geschreven over hoe zo’n organisatiebrede software op “Agile” wijze te implementeren. Het basisprincipe is om de software proces per proces te implementeren – waarbij bedrijfsprocessen worden beschouwd als “sprints” – in plaats van pure functionele implementaties, zijnde module per module. Dit vereist uiteraard multidisciplinaire (teams van) consultants in plaats van modulespecialisten (alleen).
Wanneer organisatie brede software inzetten?
Gezien hun aard lijkt het voor de hand te liggen dat dergelijke breed spectrum software waardevol is wanneer er een noodzaak is om de meeste van de bedrijfsprocessen te verbeteren. Meer in het bijzonder wanneer het landschap van informatiesystemen erg gefragmenteerd lijkt, en dit silo’s veroorzaakt die goed werkende bedrijfsprocessen duidelijk in de weg staan.
Een typisch voorbeeld is wanneer jouw organisatie behoorlijk goed groeide, hoewel interne processen niet erg efficiënt zijn omdat dezelfde gegevens twee – of zelfs meerdere keren – moeten heringevoerd worden. Wanneer je bv. verkoopordergegevens invoert, maar dezelfde gegevens opnieuw in een (losstaande) facturatie- en boekhoudsoftware moet invoeren ; en nog eens in een planning applicatie.
2. Process Engines of BPMS software
Ik heb heel vaak kritiek gehoord over organisatie brede software. Niet alleen omdat het om grote implementatieprojecten ging, die al te vaak niet op tijd noch binnen budget werden opgeleverd, of zelfs met vele tekortkomingen tegenover de oorspronkelijke project scope.
Ook met betrekking tot het unieke karakter van organisaties kan dit soort software beperkend zijn. Inderdaad, om competitief te zijn en te blijven, moet elke organisatie uniek zijn – door een strategische focus. Maar hoe rijmt COTS-software – dat ook bij jouw concurrenten kan geïmplementeerd zijn – met het uniciteitsprincipe? Kan jouw organisatie zich nog steeds van haar concurrenten onderscheiden, met behulp van dezelfde software die de bedrijfsprocessen op quasi dezelfde manier ondersteunt?
Dit is waar proces engines of BPMS kunnen helpen…
Wat zijn ‘Process Engines’ of BPMS?
Process engines of Business Process Management Systemen (BPMS) zijn platformen die het mogelijk maken om bedrijfsprocessen uit te voeren en te bewaken, net zoals je ze ontworpen hebt aan de hand van een procesmodel. Inderdaad, dankzij BPMN 2.0 – tegenwoordig de dé facto standaard in procesmodellering – kan men met een dergelijke process engine een uitvoerbaar bedrijfsproces genereren vanuit een (geldig) BPMN-procesmodel.
Hoe werken Process Engines?
Hoewel het kan verschillen naargelang welk Process Engine je gebruikt, zijn dit de stappen die je gewoonlijk volgt:
- Procesontwerp – voor moderne engines is dit met BPMN 2.0
- Definitie van data (model) voor het proces dat je ontworpen hebt. Dit omvat gegevensuitwisseling tussen het proces en andere gegevensbronnen waarmee het proces in wisselwerking staat, b.v. een ERP, CRM of welke database ook die al aanwezig is.
- Ontwerp van user interface via welke de procesactoren zullen werken.
- Bepalen van bedrijfsregels binnen het proces.
- Toewijzen van procestaken aan resources (mensen) – nl. de procesactoren zoals bepaald door de ‘swim lanes‘ in het BPMN diagram.
- Optioneel, de integratie van het proces met andere applicaties – bijv. met een bestaande ERP of welke software ook die al aanwezig is.
Hoewel deze video van 1 specifieke BPMS-leverancier is, illustreert deze duidelijk wat de process engine doet en welke stappen je moet uitvoeren van ontwerp tot uitvoering – of zelfs tot bewaking. Vooral vanaf het moment 1:10 kan je een per een de stappen bekijken om een bedrijfsproces te ontwerpen en te implementeren.
Voorbeeld van een typisch gebruik van een Process Engine
Een (middelgroot) bedrijf had net een ERP- én een CRM-software geïmplementeerd. Het offerteproces voor op maat gemaakte diensten was echter zo specifiek en bevatte zoveel – en bovendien heel uitdagende – bedrijfsregels. Het ontwikkelen van deze logica in de CRM-software zou niet alleen erg duur zijn geweest; de afhankelijkheid t.o.v. de CRM-integrator zou het dienstenbedrijf hebben verlamd wanneer het regels of logica moest aanpassen.
Het ontwerp en de implementatie van het proces via een dergelijke process engine stelde ons in staat om relatief snel te implementeren, maar ook om een hoge mate van flexibiliteit te behouden. Inderdaad, enkel de uitwisseling van sommige gegevens creëerde op de een of andere manier een afhankelijkheid – zeg maar een relatie – met de CRM. Maar voor de rest was het hele proces en de logica ervan onafhankelijk van de CRM, waardoor eenvoudige aanpassingen in taken, gebruikersinterfaces, bedrijfsregels, acteurs, enz. heel vlot konden plaats vinden.
Bovendien kon de proceseigenaar het proces zeer effectief beheren, dankzij een eenvoudige procesmonitoring, aangezien alle procesgegevens – zoals event logs – werden verkregen uit één en dezelfde gegevensbron (die van de process engine).
BPMS vendors
Hoewel deze lijst niet volledig is (en moeilijk up-to-date te houden), kan het helpen om jouw zoektocht te versnellen: Activiti, AgilePoint, Appian, Bizagi, Bizflow, Camunda, Kissflow, Kofax, Newgen, PNM soft, Signavio,…
Merk ook dat naast deze nichespelers, grote leveranciers zoals ERP-leveranciers – bijvoorbeeld SAP, Oracle, enz. – ook vaak een Process Engine bieden in hun softwarepakket.
3. RPA – Robotic Process Automation
Wat is RPA?
Robotic Process Automation-software zijn tools die eerder aan de gebruikerskant van andere computersystemen werken, dus om repetitieve, eenvoudige taken te automatiseren die voordien door gebruikers werden uitgevoerd. Met de toenemende AI (Artificial Intelligence) en ML (Machine Learning) -mogelijkheden kan RPA ook omgaan met complexere taken.
RPA wordt gekenmerkt als een “outside in“-aanpak van automatisering, omdat het de “binnenkant”, dwz de bestaande informatiesystemen – die bedrijfslogica, bedrijfsregels, gegevens enz. omvatten -, niet wijzigt noch verbetert. Dankzij RPA verhoog je eerder de efficiëntie door taken te automatiseren die voorheen – tijdrovende – gebruikerstaken waren. En mensen die dergelijke gebruikerstaken moesten uitvoeren, zijn vaak blij om van het saaie en repetitieve werk af te zijn.
Voordelen van RPA
- Waardecreatie verbeteren: door repetitieve taken te automatiseren, kunnen werknemers nieuwe, meer waardetoevoegende taken uitoefenen.
- Hogere medewerkerstevredenheid: dankzij deze meer waardetoevoegende taken zullen werknemers gemotiveerder zijn, gezien de hogere zingeving van hun werk.
- RPA-projecten zijn meestal projecten met een lager risico dan bijvoorbeeld ERP-projecten, omdat het meer aan de (gebruikers)oppervlakte werkt. Kortom, het verandert niets aan de proces- of bedrijfslogica.
- Verbeterde gegevenskwaliteit: onder andere minder gegevens (invoer) fouten. Vooral omdat RPA zeer geschikt is voor repetitieve taken, waar mensen dikwijls de aandacht verliezen na een zeker tijd.
- Snellere en betrouwbaardere diensten: in tegenstelling tot mensen, kunnen (ro)bots 24/7 werken en worden zelden ziek.
Hoe werkt RPA?
RPA-tools werken door een proces – in de taal eigen aan de RPA tool – in kaart te brengen, die de softwarerobot vervolgens uitvoert zoals gedefinieerd. RPA bootst dus gebruikerstaken na die nogal repetitief en programmeerbaar zijn. Hou er dus rekening mee dat – net zoals voor process engines – je de bedrijfsprocessen ook moet in kaart brengen voordat RPA je zal kunnen helpen…
Enkele typische RPA waardescenario’s (toepassingsvoorbeelden)
Verwerking van klantorders
Stel je voor dat je een ERP-software hebt voor het beheren van klantbestellingen, maar het is – om welke reden dan ook, bijvoorbeeld om veiligheidsredenen – niet geïntegreerd met uw webshop die klantorders genereert. Deze orders worden daarom handmatig door een gebruiker in de ERP-toepassing gecodeerd; een weinig benijdenswaardige gebruikerstaak. Zoiets kan vrij eenvoudig worden geautomatiseerd via RPA-software, in plaats van het handmatig opnieuw coderen van de gegevens.
Gegevens uit verschillende applicaties groeperen
Stel dat uw callcenter – of uw interne verkoopmedewerkers – informatie over een en dezelfde klant verzamelen uit verschillende systemen: verkooporders van uw ERP, correspondentie (bijv. E-mails) van uw e-mailtoepassing, ongestructureerde gegevens uit uw documentbeheersysteem, enz.
RPA kan u helpen om alle relevante gegevens van deze verschillende bronnen in één scherm te bekijken. Het kan tevens helpen om websites te ‘scrapen‘ (d.m.v. web scraping) met belangrijke informatie over deze klant.
Op deze pagina vind je andere typische voorbeelden (scenario’s) waarvoor RPA heel nuttig kan zijn.
RPA-software vendors
Nogmaals, dit is zeker geen volledige lijst, maar het kan jouw selectie inspanningen vereenvoudigen: Automation anywhere, Blueprism, Kofax, Pega, Redwood software, UiPath, Verint, etc.
Conclusie – wanneer welke technologie gebruiken?
Voordat u beslist welke van de hierboven beschreven proces implementatie technologieën in te zetten, kan je best volgende aspecten beschouwen:
De mate van bedrijfs(proces)innovatie en procesherontwerp
Als je veel van jouw organisatie’s bedrijfsprocessen behoorlijk grondig moet herzien, bijvoorbeeld door een nieuw – of zelfs disruptief – bedrijfsmodel, is er een grotere kans dat ERP (of soortgelijke) software nuttig zal zijn. Vanzelfsprekend na een grondig herontwerp van veel – zo niet de meeste – van die bedrijfsprocessen.
Process engines kunnen helpen bij het aanpassen – of van nu implementeren – van processen die nogal ‘ongebruikelijk’ zijn, dus deze die afwijken van de meer standaard processen die worden ondersteund door Off-The-Shelf software. Of wanneer het herontwerp van het proces inderdaad diepgaand is, maar slechts voor enkele bedrijfsprocessen, terwijl investeren in software voor de hele organisatie te veel van het goede – zeg maar overkill – zou zijn.
Er is weinig kans dat RPA nuttig zal zijn voor vrij diepgaande bedrijfs(proces)innovatie, omdat jou procesherontwerp dan op een meer fundamenteel niveau zal zijn eerder dan aan de (gebruikers)oppervlakte.
Business agility / flexibiliteit
Gezien het nogal ‘monolithische’ kenmerk van organisatiebrede software, kan je die moeilijk flexibel en snel inzetbaar noemen. Een wijziging aan dergelijke software (en hun vele lijnen aan programmacode) vereist heel dikwijls een grondige analyse van de veranderingseffecten. En dit is op zich al erg tijdrovend.
Process engines daarentegen zijn veel flexibeler en maken een grondige procesherontwerp gemakkelijker.
RPA is zeker ook heel snel toe te passen, hoewel het minder geschikt is voor een grondiger procesherontwerp, zoals bv. een verandering in de bedrijfs(proces)logica, omdat het meer aan de (gebruikers)oppervlakte werkt.
Snelle ROI en laag projectrisico
Als je naar snelle procesverbeteringen uitkijkt, zonder (veel) structurele verandering aan de proceslogica – zeg maar zonder diepgaand procesherontwerp -, dan is RPA absoluut de meest geschikte technologie.
Zoals je wellicht weet, zijn ERP-achtige projecten zeker niet bekend om snelle procesverbeteringen. Implementaties van minimaal een half jaar, tot vele jaren zijn geen uitzonderingen; als ze zelfs al (op tijd) live gaan…
Beheer van “monumenten”
Een andere typische toepassing van RPA is het beheren van “monumenten”. In Lean, betekenen monumenten grote, vaste delen van apparatuur die moeilijk te verplaatsen of moeilijk te vervangen zijn. En dit is ongetwijfeld ook van toepassing voor minder fysieke systemen zoals IT-systemen.
Mainframe-applicaties zijn typische voorbeelden van grote systemen die moeilijk te vervangen zijn. Bovendien hebben steeds minder mensen de vaardigheden om dergelijke applicaties – dikwijls in een oude programmeertaal geschreven – aan te passen aan nieuwe zakelijke behoeften; hoewel deze monumenten nog steeds belangrijk kunnen zijn en mogelijk in leven moeten worden gehouden.
In dergelijke gevallen is RPA vaak dé oplossing om het monument levend te houden, doch de (vaak onvriendelijke, repetitieve) gebruikerstaken in deze systemen te laten uitvoeren door (ro)bots – zoals RPA.
Deel jouw mening (of jouw ervaring) met een van deze proces implementatie technologieën via onderstaand vakje Reacties en ontvang een inspirerend artikel over robotica en intelligente automatisering.
P.S.: Als je deze informatie nuttig vond, aarzel dan niet om ze te delen met je Facebookvrienden en –fans, LinkedIn contacten, Twitter volgers en Google+ circles via de share knoppen hieronder. Bedankt!