Resolved What Are the Key Questions to Ask Before Automating a Process?
What would you say are the most important questions to have answered before automating a process?
1. Cost, 2. Payback period.
Don't forget when doing the math to deduct the cost of not automating.
And, do an SROI, not an ROI, if appropriate.
"Who gets it next?" ad nauseum, ad infinitum.
Question #1 - Supposing I can deliver the information to you in any form you desire, what will you do with it? (What are the actions and decisions to be made from it?).
From my experience as an enterprise architect, I would consider any "process automation" as a new solution to be implemented. A "normal" description of a solution is a document with 100+ questions which are all important although the level of important depends on the solution life cycle.
If the same solution is to be delivered with an ideal BPM-tool suite/platform which is an integral part of a Corporate Unified Business Execution platform then number of questions will less than 10 (guess).
So, the key question to ask before automating a process is when will we start implementing our Corporate Unified Business Execution platform?
In other words, are we automating the past (imagine cows meandering along the side of a hill in the way that cows have always meandered along the same path)? The implication is that we should have in the mind desired outcome of our business process. And alternative ways of getting there. Once we start thinking "meta", all bets are off. Do we stay in the zone of operations? Or consider strategic implications of different or better processes? And what about process technology, i.e. work processes are defined by the technologies that are available to us. Insurance business processes changed dramatically with the arrival of IBM 360/370 series computers. To pick a more modern example, field service and maintenance processes are evolving rapidly due to the introduction of IoT-related sensors and predictive maintenance.
Geoffrey ( "Mr. Crossing The Chasm" ) Moore's new book (available very affordably as an eBook, and with lots of chapters published on LinkedIn), Zone To Win, is terrific on the strategic context within which operational processes exist. Mr. Moore is very focused on time horizons; business processes and business process automation and the construction of business process automation artefacts are always time-defined and time-sensitive.
I guess it would be: why are we automating one business process? That's like trying to convert your city from right-hand-side driving to left-hand-side one block at a time. Good luck with that.
In this piece, Jason Bloomberg ponders the end of the business process as the core organizing principle of digital business. I'm not a theory guy, as you've probably all figured out by now , but I tend to agree that we have to start thinking bigger than business processes if we want folks to get as much out of this technology as we know to be possible.
Looking at the viability of process automation as suggested by Amit, is a very good point to start. There are additional items we suggest our customers to look at, such as the impact of a process in the principal value stream of a company, the preparedness for the different involved departments to cope with a process automation (e.g. automated, policy driven approvals vs. approval committees that insist on physically meeting and approving) and so on. We then consolidate this information into a Process Readiness and Priorization Matrix in order to gain numerical, weighted input of process candidates to be "automated". We also try to create a visual blueprint of the most important and impacting business processes of the company, assuring to take into account the process hand-offs and the weight a determined process result may have on subsequent processes.
What has changed during the last couple of years, though (in my opinion at least), is instead of using such an analysis to determine whether to automate a given process or not, companies are mainly using it to identify the order of automation. The process automation itself is rarely a matter of debate anymore.
Managers; will this project disrupt day to day operations and how am I going to understand the status of my departmental processes and interrogate when things go wrong? ...Answer the build based upon direct input from you and your team with quick prototypes for feedback in an environment separate from existing systems. Implementation once all happy very quick to minimise any disruption with users all involved. Once up and running you can see state of any Process and any delays or problems you will be automatically notified for any needed action. Such an environment support ready change for continuous improvement based on input from you and your team.
Compliance audit folk; So how do we know rules are not being breached in both the build and subsequent operation running of the process? Answer the build is completely transparent and your input is welcome and readily available for detailed inspection at any time. There will be a complete audit trail of activity and you can specify any report needed to satisfy internal or external needs.
IT department; What no code....so what's our role? Whilst build in hands of business analyst skills you have important job to ensure reliable secure infrastructure delivery. There will be inevitable need to link to systems needing your input and having you best coders available should there be a need for any complex manipulation of data such as algorithms. There maybe the opportunity for your business oriented coders to quickly pick a new skill as we roll out more process automation across the business.
CEO -will it disrupt my golf game?
IT department – we will implement the rules and provide connectivity with local and remote systems and apps.
- Do we need this process at all (does the result solve a problem?)?
- What are the needed characteristics to make the process perform?
- Is automation one of the missing characteristics?
Oh wait....that just sounds like good old process (re) design.
1. Key questions similar to process redesign as duly noted above.
2. Questions around the RPA pitch, as posted by Amit.
It has been well explained already what questions must be asked prior to process automation. Perhaps, it would be relevant to mention, which practical steps should be also taken to answer these questions.
Before any process is automated, there must be done careful process mapping. Although the idea looks trivial and self evident, it is often ignored in vast majority of automation initiatives. As a result, true mapping reveals itself already after implementation. Surprisingly, it often has nothing in common with original automation plan. This careless attitude to preliminary process study is one of the most common reasons for faults in process automation.
As a next step, it is useful to do an exploratory process mining to reveal true variability of the existing process. If process is volatile, it might be very laborious or even impossible to automate. It is wrong to think that mining is suitable only for processes, which are already automated. Simple mining can be done even for a purely manual process by just recording its steps by hand and comparing them with previously prepared process map.
Put together, these simple rules can ensure smooth implementation and good effect from automation.
+1 "process mining" and "process mapping" as practical steps; practicality and uncovering as much as possible within budget are the opposite of magical thinking. This should be a positive exercise -- seeking a better understanding the processes which are the basis of our business. the better to conduct our business even better.
Thank you, @John. Simplest things are missed far too often.
Good point about planning and reality. One of our early adopters was a bank where the manager explained how the process handling foreign cheque clearance worked. We returned the next week to show his requirement working and he said right let's show the team. Guess what the team said that's not how it works! So we sat down with team and said no problem and with them made the required changes. When they realised they could maybe do it in a better way and readily implemented new ideas emerged. All this created in the graphical process designer readily understood by all. Having that transparency in the resultant application reflected in the process map and supporting easy change with no coding really does delivery that better understanding of the process direct from users.