What Is RPA (Robotic Process Automation)
Note: I am not associated with any RPA vendor. All information shared in this article is based on my experience and research.
Consider the new hire onboarding process. In most organizations, an employee needs to be added to multiple systems that do not necessarily talk to each other.
A manager has to create accounts in multiple systems and send out emails to other teams in order to request office space, machine and security badge etc. These tasks are not really part of a manager's job description but have to perform these regardless.
For such repeatable tasks, RPA is a good option. The term RPA stands for Robotic Process Automation, here are a couple of definitions.
Robotic process automation (RPA) is the application of technology that allows employees in a company to configure computer software or a “robot” to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.
Source: IRPA
Robotic process automation (or RPA) is an emerging form of clerical process automation technology based on the notion of software robots or artificial intelligence (AI) workers.
Source: Wikipedia
In a nutshell, using an RPA software, you can visually create a flow of how workers accomplish a task, for example.
- Open browser
- Login to a website
- Copy data
- Open another system
- Search record
- Paste copied data
- Save the record
These clearly defined instructions ("robot") are then deployed on a machine, where they perform these defined tasks over and over again just like a human would do.
Prefixing "Process Automation" with the word "Robotic" makes it sound very fancy and cutting edge, but as of now if you explore features that various RPA software provide, it would be more appropriate to call it "Repeatable Process Automation".
RPA is great for repeatable tasks that you can clearly define as a flow along with all the rules. You can quickly automate various swivel chair activities that take useful time from a worker's day. So instead of workers spending time on doing these mundane tasks, they can focus on real value-add work.
I personally prefer the following definition.
Robotic Process Automation enables organizations to use software robots to complete repetitive, time-consuming work to significantly increase productivity, improve quality and decrease the need for re-work—also usually resulting in improved customer satisfaction.
Source: Verint
Use Cases
You can find a list of use cases for RPA from following sources.
- 25 Examples of Processes for Robotic Process Automation
- 20 More Examples of Processes for Robotic Process Automation
Example
This video from UiPath (an RPA software vendor) will give you an idea of how RPA software work.
https://youtu.be/B2CF-DLFVkQ
Republished/Cited
- Article republished on BPMLeader.com
UX Patterns For Enterprise Applications – Error Messages
Consider this scenario, you complete a form, click on submit button and the system show all sorts of errors that you made while filling out the form. As shown in the screenshot below, there are two obvious issues with displaying errors so late and in such format.
- First, it is not immediately obvious which fields are causing the error message, so you need to go through each field to investigate.
- Second, the error messages are not helpful e.g. in this case which field has an invalid format, is it the phone or email or both?
So in order to avoid such infuriating scenarios, follow the patterns listed below.
Instant Validations
Perform instant validations (upfront) on all fields instead of delaying errors and waiting until the end when the user is ready to submit. This helps users in making sure that everything is in order as they are filling the fields.
Descriptive Messages
If you are not providing inline error messages, then make sure your error messages are detailed enough to point to the correct one. This way at least users know exactly where to go in order to resolve the issues.
Both patterns help reduce time spent on resolving issues and avoid the frustration that comes with not knowing what's wrong.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.
UX Patterns For Enterprise Applications – Actions
Primary Actions as the name suggests are the main actions a user performs on a form e.g. submitting information or approving/rejecting work. This post discusses a few patterns that should be considered while designing primary actions.
Clear Labels
More often than not, you will see a button at the end of a form called Submit. Even though Submit button knows what happens next, the user clicking the button might not. So, to make it intuitive for the user, it is a good practice to clearly label the Submit button i.e. what is the button doing. For example on an expense form, instead of just labeling it Submit, Submit Expenses will make more sense.
Expose Options
Another common theme we see is that a list of options is provided in combination with a Submit button. Options (a.k.a. drop-downs, a list of values, LOVs) are a great way to list data such as names and states etc., but users need to put some effort and perform additional steps in order to find required information.
So, for set actions, it is usually a good idea to make them as Button Groups. This reduces the number of steps required to perform an action and clearly tells users what is required of them.
Destructive Buttons
If there is a primary action that is considered destructive e.g. Reject or Cancel Request etc., highlight them in a way that its destructive nature becomes clear to the user. Asking for confirmation once the destructive button is clicked is another good way to make sure user does not mistakenly perform the action.
Repetition
Actions like “Submit Request”, “Approve Request” and “Reject Request” etc. should be repeated. They should be placed on top and bottom of the screen. Repetition makes it easily accessible, the one at the top suggests what is to come and the one at the bottom is most likely the one that will be used by the users.
Another option is to make a floating bar for Primary Actions, that moves with the users so that they can take the action at any time.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.
How To Sell BPM In An Organization
BPMTips.com recently did a great post about selling BPM in an organization. They asked more than 20 BPM experts this question, "How to sell BPM in an organization?".
I found following common themes in most responses.
BPM is hard to sell
Executives are not concerned about tools and methods, they are interested in outcomes and value
Less ‘selling’, more ‘benefits’
Have an executive sponsor who is committed to BPM over the long term.
Word Cloud generated from all the responses also provides nice insights.
Read the complete article on BPMTips.com to gain valuable tips.
UX Patterns For Enterprise Applications – Search
A well thought out search functionality can greatly enhance the experience. Instead of just thinking about search as a filter criterion, think of this as an alternative and much quicker way to navigate.
Search should not be limited to a single tab or menu item e.g. if you are under the Orders tab then usually you would only be allowed to search for all orders by certain attributes. Having that capability is good, but what if the end-user wants to search for a customer from that location or any comments where a particular customer is mentioned. Think of this as the search your operating system (OS) provides, you can type anything in the search field and then the OS will look for matching filenames, text within files, emails, conversations etc. The figure below gives an example.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.
UX Patterns For Enterprise Applications – Relevant Data
Good decision making requires good data. Finding good data usually means that user has to run some report, log in to some other system or request some team to provide it. All these activities cost time and resources and often cause delays in the decision making process.
There are a couple of ways to make the decision-making process easier and quicker.
Decision-able Data
Providing data that is relevant to the decision making process is a good way to ensure that user does not have to leave the screen to find such information e.g. a manager has to approve if a new contractor can be on-boarded or not, so the system could provide how much budget there is, and to further facilitate what has been the trend of decisions for similar requests.
External System Links
For cases when you cannot bring data into your system, and as a result, users need to perform swivel chair activities (i.e. users need to manually log in to another system and get some data), it is helpful to provide them with a list of those external systems.
Ideally, these should SSO-enabled links that take users to correct screens in the external system, preferably with pre-filled data.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.
How To Monitor Multi-System Business Processes
Organizations use processes to manage their business. How each process gets implemented falls into four main categories.
- Paper-based
- Email + Spreadsheet
- Multiple Systems
- BPM Software
Organizations have invested a lot of time and money in processes that fall into category 3. Bringing all those processes into a BPMS is not an easy or quick job. I have seen a single process that goes through 20+ systems from start to end.
Let's take an example of order fulfillment, a fairly common process. The diagram below shows lifecycle of an order as it moves through various systems. Most of the times you will find core business of an organization distributed into multiple systems in a similar manner. Work, of course, gets done, but at any given time you cannot find exactly what is the current status of the process. And to generate even simple reports, data first needs to be consolidated from all the systems manually or through some sort of batch job.
So, how do you monitor a process that resides in multiple systems and ensures that it is running optimally considering it does not provide a single view. You build a shadow process.
The idea of shadow process is simple; you design the end to end process with all major milestones without actually implementing all the functionality in a BPMS.
Implementation Steps
Here are high-level steps for implementing a monitoring system using shadow processes.
- Define process with major milestones
- Level of milestone granularity is directly proportional to effort required
- Use milestones that make sense for reporting
- Find a common id that will allow you to uniquely identify an instance of the process in all systems
- Build services that either receives events from external systems or fetch data from external systems
- Build services that advance the process instance based on event data
- Log key event data e.g. instance id, business data, start time and end time etc. These can then be used by any reporting tool to generate meaningful insights
Compared to implementing all the processes in a BPMS, this type of monitoring solutions is much quicker to implement, provide end to end process view and helpful insights for future optimization.
UX Patterns For Enterprise Applications – Location Data
With Internet of Things (IoT) getting popular in all industries, it is important to have an awareness of the location of those “things”. This awareness, for example, helps in dispatching a service team when the thing shows issues.
A few simple examples of this:
- Things could mean a fleet of trucks, optimize routes, nearest job
- Oil tank, low, send for refill or repair
- Emergency help dispatch for a car, nearest service center
Once again these are just examples to help you visualize how these maps can be used in enterprise apps to actually improve the user experience.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.
UX Patterns For Enterprise Applications – Linked Data
Imagine you are case worker responsible for a fraud investigation. In order for you to find a suspect, you need to look at analyze various other cases, accounts, and data. This is extremely time consuming and at times infuriating. A great way to improve the user experience is to use connectivity maps.
The idea is that system itself analyzes the data, and then presents the case worker with a map highlighting all other cases and accounts connected to the case being investigated.
The usage of these connectivity maps is not limited to just this one use case but can be used in many other scenarios as well. A few other use cases of connectivity maps:
- Device dependencies: a connectivity map will help identify the impact on infrastructure if a device fails.
- Air traffic: connectivity map can show how delay at one airport might have an impact on overall air traffic.
Want to learn more about UX Patterns? Download your copy of "UX Patterns for Enterprise Applications" here.
The Case For Agile Methodology
Almost everyone (in the US) is familiar with the Healthcare.gov website and the drama that surrounded its launch. Interestingly enough the front-end was developed in 3 months using the Agile methodology, but back-end that had to connect multiple systems to IRS and Insurance companies used Waterfall methodology, the problem? Well, everyone decided to test all these systems close to the end, because that’s when you test them, at the end when there was not enough time, so they cut short testing and launch the website. As one can only imagine, the back-end systems simply did not work.
People who fixed that mess used Agile.
Rigid Plans vs. Incremental
Planning is important for combat, but the moment first bullet is fired, your plan goes up in smoke
Source: President Eisenhower
Waterfall relies on such “color-coded” and “detailed” plans that are good to look at but lack reality.
The idea that 100% of project requirements need to be captured and signed-off before analysis stage can be completed and design started, and that there will be no changes until the project is deployed is simply flawed.
Agile on the other hand is a time boxed, iterative approach that simply says instead of doing everything at once, build your software in 2-4 week iterations. Small bangs instead of a big bang. You still go through all stages that a waterfall project goes through, but in smaller chunks, so there is no compromise on design, quality or documentation.
Everything vs. High Priority
Waterfall processes require to implement 100% of requirements otherwise it is not accepted, so essentially all requirements are equal.
He who defends everything defends nothing.
Source: Frederick the Great
Time-boxed nature of Agile forces customers to prioritize, which means the most important stuff gets done first, and the least important is saved for last.
Delayed Feedback vs. Early Feedback
I worked on a project for a client where the waterfall was part of their DNA. After 6 months of analysis we took requirements to stakeholders for sign-off, and the very first comment, due to recent audit findings we need to add new requirements in scope.
Due to recent audit findings we need to add new requirements in scope
Back to the drawing board, after another 4 months we request sign-off, and once again due to org changes, we need to redo the whole analysis phase.
Let’s assume you successfully complete the development, and during the testing phase, your users interact with the software for the first time in months or even years. Usual customer response, you have developed what was in the requirements document but well this is not what and how we had imagined the system.
Not just users, this is the first time development team gets to test their architecture and design.
So Agile recommends to test and get feedback from users earlier and regularly, it welcomes the change.
Wasted Effort vs. Continuously Improve
Another issue that stems from waterfall methodology is that the expectation is 100% of requirements need to be implemented before software can be deployed. Study of hundreds of software systems show that users only use 20 % of the features, yet we deliver 100% of features, which means that the effort both money and cost spent on that 80 % of features might not have been necessary.
How do the iterative nature and requirements prioritization help? Agile recommends shipping early when you have completed 20% of the features that will deliver 80% of the value then deploy the software in production. And based on real feedback, re-prioritize remaining requirements, and then deliver 20% of those features. Within 2-3 releases you would have delivered more than 150% of the value. And you may or may not even need to deliver rest of the requirements and focus the effort on something else.
You only need to deliver what is needed, e.g. during the Iraq War, U.S. spent huge sums of money to build a chicken processing plant that did not get used, so finally, they asked villagers what they wanted? Villagers wanted a simple, foot bridge so that they don’t have to go all the way around to get supplies. It might not be as impressive but that was exactly what added value and was the need.
Poor Visibility vs. Improved Visibility
In waterfall being half way through the project does not necessarily mean you have implemented half the feature, but with Agile you always know how much work has been completed and how much is left.
You are also going to hear a lot of negative feedback about Agile, in my opinion, it is mostly propagated by people who do not do Agile the right way.