De meeste projecten die DI Blue doet, hebben te maken met het in staat stellen van onze klanten om slimmer, sneller en beter te werken. Daarom speelt automatisering van bedrijfsprocessen een zeer belangrijke rol in bijna alles wat we doen. We gebruiken low-code platforms zoals Netcall Liberty Create als een van de belangrijkste enablers om, wat wij “speed companies” noemen, te bouwen. Echter hebben we vaak te maken met veel verschillende uitdagingen, die niet allemaal kunnen worden aangepakt door 'het platform'.
Een real-life use case
Stel je een B2B-use case voor waarbij, binnen een groot productie bedrijf, materiaalreserveringen en fullfilment verbeterd moeten worden. Momenteel is er een team dat zich bezig houdt met invoer van orders die voornamelijk via e-mail en telefoon binnenkomen. Dit wordt handmatig gedaan in de ERP-backend en vanaf dat moment gaat het proces van deze afhandeling semi-"automatisch" lopen.
Er is echter weinig transparantie in de keten voor zowel de klanten als het interne team en het niveau van procescontrole en kwaliteitsmanagement is erg laag. Er is weinig feedback beschikbaar betreffende voorraad cijfers en levertijden. In het verleden werden er enkele proof of concepts gedaan om het bedrijfsproces opnieuw te ontwerpen, maar de integratie met het ERP-systeem kwam herhaaldelijk naar voren als het belangrijkste knelpunt, waardoor veel onzekerheden en continuïteitsrisico's voor de organisatie ontstonden, wat resulteerde in een laag vertrouwen om deze projecten verder uit te rollen. Maar dan komt low-code om de hoek kijken.
Digitale transformatie aanwakkeren
Een bedrijfsproces als deze is een goed voorbeeld voor kandidaat processes (zogenaamde "seed processen") voor low-code om tractie te krijgen als een snelle digitale transformatietool. Stel je voor dat je een model ontwerpt dat kan worden omgezet in een werkende applicatie, en dat je dit op elk moment kunt aanpassen.
Zolang de low-code kandidaat impact heeft ‘op de business’, zoals efficiëntieverbeteringen, hogere klanttevredenheid, en bijvoorbeeld verbeterde CX, kan een "olievlek" -effect ontstaan.
Het concept van automatisering dat zich vervolgens over de hele organisatie verspreidt, afdelingen verbindt, de product- en servicekwaliteit verbetert en uiteindelijk meer ruimte en middelen voor innovatie over laat.
Maar dit is de theorie: in grotere bedrijven met een IT-geschiedenis, is de realiteit echter heel anders. Laten we eens kijken naar het volledige ecosysteem waarmee low-code verbinding moet maken om een echte impact te maken.
De uitdagingen bij het implementeren van low-code
Allereerst richten low-code systemen zich over het algemeen niet primair op de UX en gebruikerservaring. Ze helpen om bedrijfsprocessen te automatiseren. Dat betekent dat het misschien geen goed idee is om een standaard low-code portal open te stellen voor je directe klanten, maar u hebt ze wel nodig omdat zij de belangrijkste input van voor uw bedrijfsproces leveren.
Het gevolg is meestal dat de onderliggende logica wordt vastgelegd in een bestaande toolset of platform (zoals een intranet portal pagina) of dat specifieke applicaties voor dat doel worden gebouwd. In ons voorbeeld werd een speciale B2B-applicatie gemaakt, die in feite dient als de klantgerichte productcatalogus en het bestelsysteem, die met behulp van de API's bestellingen verzend en orderstatussen ontvangt. Dit soort oplossingen, hoewel zeer logisch en handig, voegen een extra laag aan complexiteit toe.
Vanaf dat moment gaat alles goed binnen het BPMS. Met behulp van het casemanagementconcept loopt het proces, rekening houdend met bedrijfsregels, de organisatie dienend met workflows, sensoren, analyses en nog veel meer automatiseringen. De processtromen verlopen supersnel, tijdens de runtime van het bedrijfsproces.
Zodra gegevens echter moeten worden bewaard, loop je tegen problemen aan. Hoewel het zeker mogelijk is, zou het doel van de BPMS nooit kunnen zijn om master- of transactionele gegevens zelf te bewaren (op basis van het sleutelprincipe van "separation of concerns" dat de schaalbaarheid van het IT-landschap garandeert) - daarom wil je de gegevens opslaan in de bronsystemen. In ons geval is dit een ERP-systeem.
Integratie is de belangrijkste bottleneck
Dus daar ga je, je eindigt met dezelfde reeks problemen als eerder vermeld: integratie is moeilijk, duur en helaas het grootste obstakel voor verandering. Dit komt niet door de BPMS zelf, maar door het feit dat je nieuwe integratiemogelijkheden moet bouwen tussen de BPMS en het bronsysteem(en).
En ja, natuurlijk hebben veel bedrijven middleware-lagen of zelfs volledige enterprise-servicebussen - maar heb je ooit gezien dat ze langdurig worden gebruikt zonder grote problemen en hoge kosten? Dat is precies wat je wilde vermijden met de invoering van BPMS.
En het wordt nog erger wanneer je verbinding moet maken met legacy-systemen die de basis -integratiemogelijkheden missen of gewoon zo verouderd zijn dat het erg onverstandig is om er nieuwe functies aan toe te voegen. Dit soort situaties zullen je BPMS ambities onmiddellijk doen verdampen en het probleem is dat je het niet echt uit kan leggen, omdat je belangrijkste publiek hoogstwaarschijnlijk non-technici zullen zijn die misschien de technische vaardigheden missen om het probleem te begrijpen ("Hoe moeilijk kan dit zijn?"). Je project sneuvelt zonder de kans op een volgende poging.
Robotic Process Automation en zijn magie
Stel je voor dat je geen technische integratie hoeft te bouwen, en dat je dezelfde schermen kunt gebruiken die nu gebruikt worden voor handmatige orderinvoer in het ERP-systeem. Je voegt een virtuele werknemer toe aan je team.
In plaats van "menselijk werk te vervangen door robots" (wat min of meer de belangrijkste propositie is die momenteel wordt gebruikt voor het gebruik van RPA en, naar onze mening, een zeer negatieve), ook wel "Digital Labour" genoemd, versterk je de oplossing om het legacy-knelpunt te overwinnen, waardoor je teams zich kunnen concentreren op echt belangrijke dingen. Je hoeft geen technische integratiescenario's of complexe data mapping te doorlopen: script het scenario in de softwarerobot en verbind het met uw BPMS API.
Kortom, dit is hoe het zou kunnen werken:
De belangrijkste bezwaren tegen dit concept bevinden zich in de categorie "Dit is een work-around, je lost het echte probleem niet op" of in de categorie "Screen-scraping is er al heel lang en heeft zich niet echt bewezen in end-to-end bedrijfsscenario's, dus waarom zou dit werken?".
Je lost echter wel het belangrijkste probleem op, namelijk dat IT niet in staat is om snel waarde te leveren, of dat legacy-technologieën de snelheid van verandering niet kunnen volgen, wat resulteert in eindeloze en dure integratieprojecten.
Voor het screen-scraping argument is RPA echter beter dan het lijkt. Met moderne RPA-tools kun je zeer complexe scenario's bouwen, waaronder intelligente feedbacklussen met gegevens uit de bronsystemen en geavanceerde orkestratie, net zoals je dat doet met het BPMS-gedeelte van je oplossing. In feite kan RPA worden gezien als "screen level"-procesbeheer, dat zeer goed dient als een krachtige uitbreiding van een oplossing voor het automatiseren van bedrijfsprocessen.
Bij DI Blue gebruiken we Netcall om deze use cases te realiseren.