Brodski Robotic Process Automation Viewpoint

Introduction

There is a real buzz in technology circles as organisations switch on to Robotic Process Automation (RPA). It is an enabling technology for organisations to automate the manual element of a business activity/task, from simple to more complex activities that involve human interaction with IT systems.

Abbildung in dieser Leseprobe nicht enthalten

RPA vendors often refer to automating a business process, which is misleading as there are better tools (e.g. BPM) out there to enable an organization to improve its overall end to end business processes. This is where friction often occurs with the IT department.

There are a number of opportunities that can be addressed by RPA as follows:

- Replacement of existing operations
- Supplementing existing operational resources
- Addressing activities needing to be automated

The business is best placed to introduce RPA as it is they are the ones who know where the technology can be best exploited.

It is essential that those wanting to exploit RPA understand that it is not a business process that is to be automated but an element of the process, as mentioned above, the business task. It is the "doing" aspect of a business process, enacted by human operators in the main, which is at layer 4 of most business process models to help understand business granularity.

Abbildung in dieser Leseprobe nicht enthalten

Organisations need to understand that RPA is in the business domain and not the IT domain. The IT organisation is very important and RPA will not be delivered without them, both for establishment of the infrastructure and for technical advice.

The RPA technology addresses presentation interfaces; this is distinctly different to application level interfaces which address formal application communication between applications.

RPA is best suited for structured, rule based tasks which are repetitive in nature.

The business tasks to be automated may be dependent on very old systems, some of which may have been established 30/40 years ago with hidden design aspects and minimal maintenance since, so loss of knowledge is more than likely.

Business Case

Be wary of consultancies that make proposals for RPA where often they are introducing other supporting technologies. It is more than likely that you will have these technologies (e.g. business intelligence) and it is not the RPA opportunities that are being addressed.

There many business benefits arising from implementing solutions using RPA, some which are not necessarily quantifiable:

- Removal of human operators or displacing to more productive roles or roles needing to be filled.

- Increased throughput
- Improved data input quality through consistency of business rules applied and referring to master data.
- Addressing tasks that have been put on the back burner

Architecture

The business needs to understand were the RPA technology fits into the enterprise architecture, whether it is for the whole organisation or a particular department.

The architecture also needs to identify all the supporting IT services that will be required, including any Cloud related services - an architecture design will be required and this will help identify some of the groups who will be involved in ensuring a successful delivery.

Abbildung in dieser Leseprobe nicht enthalten

A formal detailed design will be required from IT and agreement obtained on responsibilities for the RPA platform. This will be a game changer in the way the technology is managed and delivered.

Abbildung in dieser Leseprobe nicht enthalten

Key Skills

The RPA vendor often provides a methodology for developing, implementing and operating the technology which should be used as the basis of an organisations introduction of RPA. It can then be adjusted to take into account the specific approaches of the organisation.

The business need to be aware that this technology is often sold as a "configuration" only model but it still requires developer like skills and will present challenges when first implementing. In some areas full developer knowledge may be needed to get round some technical issues.

Security

Most vendor technologies have good security capabilities but these must be often specifically selected for implementation, and will often require a good architecture design to enable them.

In order to strengthen the security of RPA integration into the organisations IT security services (e.g. Active Directory) is essential. This will allow security services to be used to monitor activity and alert when unusual behaviour is detected.

Remember not to repeat bad practice which humans get away with, instead refer to the governance board for direction - it may be a case of some "real" programming or change to the process/task.

Decision Tree

RPA is a good solution for automating manual tasks but the business need to be wary that they do not overstep the capabilities of the RPA technology. There are cases were other technologies are much better suited (e.g. Bl, ETL, ESB etc.). Therefore, in partnership with IT, a decision tree, with justifications, should be created to guide the analysts in determining which business activities can be addressed by RPA and which require other technologies in order to be automated.

Governance

To ensure a successful implementation and ongoing exploitation of RPA it is essential to establish a governance board, made up of key parties impacted by the changes. This must include IT, who will often have key levers that need to be operated to get RPA implemented successfully.

The execution of RPA solutions will require the collaboration of many parties, some who maybe external to the organisation. As this is a shared delivery with IT then open governance is an enabler of success, with both parties needing to have proper representation on the governance Board.

COE

To get the best business value, an organisation with lots of opportunities for automating manual tasks, needs to take full ownership of the delivery and manage other contributors.

Establish a Centre of RPA Competency (coc) within the business to gain momentum and keep it close to the "coal face" in order to have a quick turnover of automating business activities.

The business will need to determine where the COE will be established; spanning the whole business, within each department or specific areas (e.g. Call Centre) and provide a training programme for the personnel manning the COE.

Also ensure all the knowledge is captured in a structured way for reuse etc. further down the line.

Analysis

Analysis needs to be undertaken with the rigour applied to normal IT development initiatives otherwise exceptions will be rife. Consider the environment and personnel who will be involved and the aspects to be addressed:

1. Information and knowledge consulted (written notes, authorative web sites etc.)
2. Supporting systems used within the business activity
3. Supporting automation within the "front-end"
4. Explicit and implicit business rules applied
5. Consulted persons within the team/management

Undertake a desk based walkthrough with the task SME(s) to get their sign-off that all detail has been captured.

Non-functionals

To ensure an appropriate architecture design Identify the overall non-functionals for at least:

1. Volumes/Capacity
2. Performance - will be better than human operation
3. Availability - what does the supporting platform need to consist of, including database resilience (may be addressed within 5. Below)
4. Scalability - consider how many robots will be required
5. Reliability
6. Security (see below)
7. Disaster recovery
8. Legal/Regulatory controls

These may need to be revised ongoing in response to the emerging business activities to be automated.

Service Management

The RPA tools have good facilities for managing the robots that can be used directly by the business. The business will need to manage to exceptions arising from the automation of tasks which cannot be handled by the actual automation.

The business will need to have a good interface with the IT department to handoff technical problems for them to progress.

Development

There will be challenges associated with each connection to be automated, mainly from technical detail yet to be unearthed. What is seen as a simple automation may have hidden aspects, such as pre-processing added to the front-end of the automation (e.g. Smalltalk/Java coding).

There is a need to document the best practice to be adhered to - also identify approaches etc. that are not acceptable. This will ensure consistent designs, coding and service management approach.

An exception handling framework will ensure exceptions/errors are presented to business users in a business sensitive context - this speeds up responses/actions to be taken.

Ensure appropriate test data is obtained both for development and testing purposes. This may be difficult to identify if the system has been operating without change for some time.

Implementation

As this is often a new venture for the business then the approach for the first automation taken should be one that has minimal risk that is a simple automation which allows all the parts to be tested and checked with little impact on the business if problems occur. Certainly there should be no big bang approach where several automations are implemented in parallel. Something's to consider are:

1. When to switch over
2. Parallel running for a period that inspires confidence in RPA - business confirming success
3. Ensure all know their roles and responsibilities
4. The overall implementation schedule - to ensure issues etc. can be managed for each automation to be introduced.
5. How the organisation will revert back to manual operation if there are major issues (can be trickier as time marches on).

Challenges

1. General resistance from the IT department - have that decision tree upfront.
2. To get started the business will need a partner and a formal assessment of their capabilities will be required.
3. There may be business tasks which have already been out sourced to overseas organisations and business benefits already achieved with little opportunity to get more through use of RPA.
4. The business may want to address automating a task which does not provide sufficient business benefit given the costs associated with the actual automation.
5. Identifying personnel who fully understand the activity needing to be automated; some knowledge disappears as people move on or retire. Often little documentation exists unless compliance with regulatory, standards etc. has to be complied with.
6. Finding personnel in the business that can be developed into RPA analysts and redevelopers.
7. The technologies supporting the manual process are often ancient in IT terms and no longer supported or well understood. Screen scraping these or finding presentation based APIs can be a daunting task.
8. Hidden automation at the front-end, for example predefined business rules encoded in Smalltalk.
9. Getting access to technology that eases the task automation (e.g. Microsoft Outlook rather than Google Mail).
10. Ensuring testing is undertaken with the same disciplines as applied by IT, this can seem onerous and unhelpful to the business but it ensures a high quality result.
11. Getting a third party organisation that understands RPAto undertake penetration testing.
12. Remember that just because your human operators accessed an external parties IT system you cannot just go ahead and access the system (e.g. Web site) using RPA without the owner of the IT systems specific agreement. Often they explicitly exclude robot access for fear of an adverse performance impact on their systems or are becoming similar to a denial of Service (DOS) issue.
13. Some vendors will exclude robotic access from their licence for fear of performance issues being unearthed, given the speed robots operate at and the ease with which additional robots can be introduced.

Recommendations

1. As stated above RPA is an initiative that needs to be delivered by the business with IT providing a supporting role (bringing their substantial skills in supplier negotiation, RFI/RFP processes and technology choices/set-up).
2. Issue an RFI followed by an RFP to get the appropriate technology for the business. Ensure examples of business tasks are provided and non functional identified.
3. Create a process for capturing opportunities for automating business tasks, which should include:
a) High level description
b) Ownership details
c) Current costs
d) Cost of automating
e) Priority (1 to 5)
Capture in a spreadsheet or better still a browser passed platform (e.g. Jeri)
4. Establish the COE as early as possible to reduce the reliance on a partner.
5. Implement developer level of coding discipline and guidelines.
6. Don't bend the outcome of the decision tree analysis to get around constraints of the RPA technology.
7. Look to supplement the COE with trained graduates for the analyst and developer roles.
8. Get the governance up and running with early involvement from IT.
9. The IT department provide a help desk with problem management/escalation software that should be used by the business for managing RPA related problems.
10. Prove the RPA management processes with a simple business task.
11. Parallel run the automated business with the manual business activity.
12. Ensure you have a penetration test and have an independent external party check out your implementation of RPA.
13. Create a RPA business tasks catalogue (e.g. a spreadsheet of key details) for ongoing operational management and change.
14. Even though it may seem arduous implement the security features provided by the RPA technology.
15. The RPA vendors tend to be single product companies, and although a star on the stock exchange, an organisation needs to undertake a risk assessment and determine if escrow is appropriate.