1. Peter Schooff
  2. BPM Discussions
  3. Thursday, 15 June 2017
  4.  Subscribe via email
What is a clear sign that it's time to automate a business process?
Brian French Accepted Answer Pending Moderation
The question seems too simple to me. In order to even get to the point of "automating" a process, one needs to have determined whether that process is core to the company and you can justify spending money on it. Assuming that decision has been made, "automation" of the process seems to be an oversimplification. The process would need to be analyzed (let's not get stuck on whether that analysis would be automagically done or done using AS-IS/TO-BE analysis) to determine what the process needs to do in order to satisfy the end customer. The analysis of satisfying the end customer should be done at the activity level as well. With this analysis, we can determine at the activity level of the newly designed process, based on the desired customer outcome, which activities can be automated (I think people would call it digitized these days). Some activities may not be able to be automated.

As far as when it is time to automate a process, if the process is a core one to a company, that company should always be analyzing how to make the process better. This definition of "better" should be focused on customer outcomes. If the feedback loop for the process ends up indicating a portion of a process should be automated, and the cost can be justified, then it is time to automate that portion of the process.
To automate a process is to turn over the work of that process to a computer. That also means taking the work away from people. Two basic issues arise. One is feasibility, that is, can it indeed be automated? The other issue pertain to costs: (1) the costs of automating the process and (2) the cost savings resulting from eliminating people. It is entirely possible that enough of a process can be automated that the cost savings justify doing so even though the entire process might not be automated. I have undertaken more than one "clean up" project, which entails figuring out how to automate the rest of a process that was once only partially automated. Many people will recognize that as largely automated forms processing work that also had a suspense stream for manual processing. Getting the suspense stream into the computer is what I am referring to as "clean up" automation.
  1. Fred Nickols
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Peter Hilton Accepted Answer Pending Moderation
It’s time to automate a process when you’ve stopped learning anything from performing it.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
John Morris Accepted Answer Pending Moderation
It's NEVER "time to automate a process" -- for it's own sake.

As long as an organization is satisfying the requirements of stakeholders, then investment dollars should be conserved.

The investment decision to automate a process will be driven (in a competitive for-profit environment) by a business case triggered by competitive necessity only. (Kodak probably had the best silver nitrate film production processes; further investment in process improvement was not going to be helpful.)

The statement above is (admittedly) attention-grabbing; it's also just a statement of normative business practice under conditions of perfect information.

We need to be careful however because decisions concerning investment in business processes are among the most important decisions that can be made concerning any business. We need to be careful because there are risks to getting thinking about business process investments wrong. Specifically, I am going to call out two specific risks, both risks associated with management ideology as applied to business process investment decisions: And then finally I am going to relax the unrealistic assumption of "perfect information".


1) DANGER OF CYNICISM: ( a.k.a. "process is for suckers", or risk of process under-investment ) -- American car manufacturers are accused of having religiously adhered to the above business logic until they were out-competed by Japanese competitors. One could say that the "never-for-its-own-sake" approach is cynical, without any love for "just doing a good job, or the best job". But to ascribe investment-driven business decisions to cynicism alone would be a mistake. Failure to invest in process improvement might be cynical, but insofar as it results in failure, such failure to invest is also stupid and lazy. American auto executives missed the competitive signals that it was time to invest in better manufacturing processes.

2) DANGER OF PRODUCTIVISM: ( a.k.a. "process is the only thing", or risk of process over-investment) -- "Productivism" is an entertaining concept, the opposite of "consumerism". It is a focus on production-for-production's-sake (or in this case, "process-for-its-own-sake" ). The idea that we should improve our process just because we want to be better at it is "productivist". Productivism is a relatively modern idea; before modernity, people just did things they way they'd always been done. The Soviets were especially enamoured of production for its own sake, even if it was ostensibly for the greater purpose of strengthening "socialism in one country". The Eiffel Tower is an example perhaps of production-for-its-own-sake. The current rise of "craft businesses", often by unemployed MBAs, is another example of productivism. There's certainly a pleasure in work and craft which is satisfying in and of themselves, beyond any business viability. And yet in the end, the business viability of any production project is a necessary justification for those who want to stay in business.

Here's an interesting article that touches of productivism versus consumerism by French writer Pascal-Emmanuel Gobry:

This Is The Fundamental Thing That Most People, Including Paul Krugman, Don't Get About Economics


A process investment decision is no different than any investment decision. And good investment decisioning is not a theoretical abstraction, but reflects the specifics of the business domain. So for our business process investment decision, let's acknowledge imperfect information and uncertainty especially about domain-specific process competition. Specifically, we'd like to hedge the risk of being locked in to an uncompetitive process.

So what are the factors to consider which should guide our business process investment decision?

1) UNCERTAINTY -- It's sometimes difficult to correctly read market signals until its too late; this uncertainty can be reduced by competitive intelligence and by being better informed about market trends. (This increase in knowledge is not free; information has a cost.)

2) CAPABILITY -- One cannot just turn process improvement on or off at will; process improvement capability itself is a corporate asset. (Maintenance of process design capability is not free; it requires a sponsor.)

3) DECISIONING -- Business process project lead times and payoffs can be lengthy; the cost of time-to-value can be high. (Just the ability to make process investment decisions is a capability; process governance has a cost and needs a sponsor.)

For these reasons, we arrive at an interesting conclusion, one that we had previously rejected! Specifically we should act as a productivist, and improve processes for their own sake, and for the love of the work! This approach is a hedge or, under the assumption of a competitive marketplace, a long bet (an option) that competitors are doing the same thing. With such an approach we can limit the existential risk of competitive surprise
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Dr Alexander Samarin Accepted Answer Pending Moderation
There are, minimum, two types of “automate a business process” – 1) automate the coordination of human activities and 2) reduce the amount of human activities.

The first type of automation must be done ASAP for all critical processes (consider impact x frequency metric). The second type of automation requires a slightly different approach – when the users found a good way to do their work then automate it, even a very simple file transfer or an update. Of course, your BPM must be very agile.

+! Alexander -

Re #1 (automate the coordination of human activities) the more decentralized an organization, the more important. I suspect the cost of this type of automation varies widely i.e. a few thousand dollars versus a few hundred thousand dollars or more. Accordingly, it pays organizations to carry out due diligence when shopping for tools/when making decisions re mapping and operating environments. Some of the "solutions" promoted to corporations border on scandalous. Any initiative by IT where the starting position is "what is BPM and should we adopt this?" has a predictable negative outcome. An experienced consultant with a good track record is the obvious path to take.

I really don't see how a BPM implementation that is not agile can become agile. It is somewhat like trying to convert a submarine into an airplane. The foundation has to be right to achieve "agile".

The only advice corporations need is "Caveat Emptor" - if a corporation is going to spend a lot of money and fail in their implementation, the corporation ends up in a delicate strategic position relative to its competitors.

As for #2 (reducing the amount of human activity) - if a corporation does not put a focus on this, the completion wins. The notion that staff whose jobs have been eliminated can be 'easily' retrained/re-deployed, to me, is nonsense. The problems are resistance to change and inability to change to take on different work.

@Karl, RE "I really don't see how a BPM implementation that is not agile can become agile". Sure. Let us ask (or propose to Peter) an opposite question "how agile BPM can become not agile".
@Alexander .. I think that would make for a good question.

  1. more than a month ago
  2. BPM Discussions
  3. # 4
Kay Winkler Accepted Answer Pending Moderation
As pointed out by the contributors above, applying a sensible cost/benefit check, before engaging in anything BPM, is the right thing to do. Sounds like common sense but it is still a crucial step, many users fail to take. Not only allows such a quick check to validate if a given operation merits the implementation of BPM but also helps with scoping out the type of suite. Having a unified BPM discipline in place, its perfectly possible to have an open source or low cost BPMS for back office processes, while mission critical is backed by an iBPMS, for example.
Having said that, not everything in BPM has to lead to automation, automatically :). In fact, there are several goals BPM stakeholders can pursue, on different levels. Process documentation, flow charting, mining, analysis or just as-is compliance control in order to establish a starting point, may be things of interest. BPTrends, in their semi yearly "State of BPM", publish a nice list of top goals for IT stakeholders in correlation with BPM, and automation itself is actually not the leader of that list. If I recall correctly, the top things to achieve with BPM are usually around gaining better insights and process controls.
NSI Soluciones - ABPMP PTY
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Bogdan Nafornita Accepted Answer Pending Moderation
When you have stopped thinking about the work you're doing, while doing it.
CEO, Co-founder, profluo.com
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Peter Hilton Accepted Answer Pending Moderation
When to automate? ‘When you find yourself avoiding doing something the right way because of how hard it is to do.’ - Jessica Kerr aka @jessitron at #ndcoslo
  1. https://twitter.com/damovisa/status/875351064920432640
  1. more than a month ago
  2. BPM Discussions
  3. # 7
David Chassels Accepted Answer Pending Moderation
I do not think that automation is the initial driver...? This would be a consequence of recognition that current processes need reviewed and digitised to allow feed back on actual activity. As this exercise moves forward with a Digital Business Platform there all be obvious activities which can be ready automated. And so that journey can begin where with deeper knowledge of the processes and the capabilities with in the software so more sophisticated automation could be implemented.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.