Peter Lacken er vår Senior Automation Architect. Han er en særdeles kompetent konsulent med mange års erfaring fra store internasjonale prosjekt innen RPA. Peter har stor tro på et helhetlig, langsiktig og strategisk arbeid med robotisering for virksomheter, og mener suksess er et resultat av gode mellommenneskelige relasjoner og søkelys på detaljer.
Hans unike metodikk innen RPA tar utgangspunkt i «best practice» fra systemutvikling, og flere av hans artikler er svært godt mottatt i fagmiljøet.
Denne artikkelen skrev Peter Lacken i desember 2016. Siden den gang har mye skjedd innen RPA-teknologi, men artikkelen er muligens enda mer aktuell i dag.
Peter Lacken sammen med daglig leder i Ren Røros Intelligent Automation as Arild Solibakke.
RPA: A Developers Perspective
RPA as a transformation for business operations at a strategic level is generating articles, papers, research, conventions and consultancies all over to have their say on this hot topic. It is exciting times to be involved in this field; however, as a techy I can only get so hyped by it. I am a developer at heart who wants to scratch beneath the spin and understand more about what it takes to be successful in this field. This short article will share my thoughts on a developers’ perspective for success.
Blue Prism is marketed as a filler between the needed IT assistance in the Back Office areas and the lacking commitment to solve it within a company’s existing IT development budget. Timescales plays a big part and choosing a product such as Blue Prism can get you operational relatively quickly. Moreover, the projects can be business led and business solved! So who needs an IT department anyway?
The thought leaders in RPA are praising the merits of a close collaboration with your friendly IT department for a successful project. Rightly so, there is an important infrastructure and security layer to overcome in the initial phases that must be maintained thereafter. Sandwiched somewhere between strategy and hardware is a layer that I have not read much about in the world of RPA: The technical solution. The design and development components should be built to model a process that promotes re-use and maintainability. This is an area that can be easily overlooked, yet should be considered early in your adoption of RPA and the culture of your Team. Key to success in this area is an architectural mind-set that is well versed in transaction handling. Analysing a process with a service oriented outlook and a strong integration background will give you a final solution that will scale well and robustly handle your exception cases. Dive a little deeper and we unpeel another layer that is equally important when developing RPA. The development building blocks.
Blue Prism is an incredibly open and flexible development tool that gives the developer many avenues to choose from when faced with a system to interact with or a business rule to model. Take these steps carefully. Poorly thought through choices will cost you later, hopefully in the test phase, but maybe in production. The fixes required at this late stage more than likely have a sticky back and rhyme with disaster. I believe strong developers with an object oriented background and an API mind-set will deliver much neater solutions.
Let me rattle off some practical examples:
- Look at Blue Prisms web service support as your integration layer if at all possible.
- Know when to build an API business object (multi-process accessible) versus a self-contained service business object (one queue, one process, one business object).
- Understand clearly what should be defined at the process level versus business object level.
- Organise the process sides logically and clearly, aiming for every single side to be visible start to end without scrolling.
- Consider your business objects as “classes” and look for opportunities to abstract your process data items to stand-alone, non-system interaction business objects.
- Create sensible system interaction business object actions that are in touch with the system it is interacting with and not necessarily the process step you are solving.
- Use collections where possible and nest them if necessary. I could go on and on but will spare you anymore for now.
To conclude, do not underestimate the attention to detail required from your technical team when building a solid RPA solution. Choose a partner that can bring this experience to the table and get you off to a flying start. It is possible to automate a process that satisfies the requirement and at the same time is a weak implementation. Having key technical personal leading and steering the direction of the development aspects will mitigate the risks of many post production pitfalls. Requirements always change or are misunderstood, Networks can be unstable, Systems must be upgraded, Windows needs patching. Be ready for this “less sexy” type of challenge while your strategy guy is in a meeting talking AI and cognitive computing!