1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 26 March 2019
  5.  Subscribe via email
What would you say are the main reasons for not automating a process today?
Accepted Answer Pending Moderation
Because is cannot be automated. i.e it is a manual process. A huge percentage of company operations cannot be automated. This may be entire processes or parts of processes that are manual. So for for regulated companies having a combination of documented and automated processes that dovetail seamlessly is critically important.
How do you determine ahead of time whether a process can be automated or not?
  1. Ian Gotts
  2. 3 weeks ago
  3. #6012
You can't. You map/document it, and then it is obvious which areas can be automated. Besides, even if you are going to automate it, you are going to map/document it.
Accepted Answer Pending Moderation
Automating a process is an investment. You need to invest time, maybe money and a period of instability until the automated process is fully adjusted, adopted and properly running. These are costs.

Of course, you expect some benefits from the automation, like greater efficiency and effectiveness, better customer service, etc.

If Costs > Benefits, then you should NOT automate.

For example: If it is a very complex process (it will take a long time to automate), and it will be executed just a few times (benefits are low), then it may be kept manual (not automated).

Of course, the hard part is measuring the costs and benefits. But it is the job that should be done to make a clever decision.

Best regards!
CEO at Flokzu Cloud BPM Suite
How do you determine ahead of time whether process automation will return the investment?
  1. Ian Gotts
  2. 3 weeks ago
  3. #6013
You can't. You map/document it, and then it is obvious which areas can be automated. Besides, even if you are going to automate it, you are going to map/document it.
Accepted Answer Pending Moderation
The concept of the business process is designed to optimize business operations. If a careful analysis of a current process concludes that it is optimized according to the intended objectives, it may not make sense to automate, since the return of this investment will be doubtful as well as other possible benefits.

Automating by automating, does not make any sense, if that does not bring benefits to the business.
How do you determine ahead of time whether a process automation will bring benefit to the company?
  1. Ian Gotts
  2. 3 weeks ago
  3. #6014
You can't. You map/document it, and then it is obvious which areas can be automated. Besides, even if you are going to automate it, you are going to map/document it.
Accepted Answer Pending Moderation
You don't automate processes where automation removes more value than it adds. These are usually processes where some human factor is critical to the value of the business transaction.

Some relevant examples from our customers:
- delivery of rare, curated food: they asked not to integrate with a delivery platform, because they wanted to meet their customers, get their direct feedback on the produce they were shipping and get suggestions on how to improve the portfolio;
- concierge services: they asked not to send automatic notifications to residents as they wanted to decide if they use this as an opportunity to gather direct feedback.
- luxury plastic surgery services: they never wanted marketing automation, because their customers never want to hear canned marketing messages.

Some personal bad automation examples out there:
- sales/support bots: I stopped ordering from Amazon because of poor customer service and poor interaction with support bots. For the same reason I avoid Google enterprise services altogether.
- answering machines: when I call telecom companies, I usually wait for the shortcut number to human operator, completely bypassing their machines, who never get a clue
CEO, Co-founder, Profluo
Accepted Answer Pending Moderation
Focus on Digital Transformation, of course! See [1] (disclaimer, the last two chapters are a commercial advert and English is not perfect yet - sorry)

  1. https://docs.google.com/document/d/1WahdvvcrHMjJcDW-JbXo1gvAMAUeq_XfEIw7DuGx4gU
Digital transformation does end up automating some processes, doesn't it?
DT converts many entities, including processes, into their digital (formal, explicit, machine-readable and machine-executable) presentation. Classic automation scripts will become integral parts of digital entities.
Accepted Answer Pending Moderation
Reasons not to automate?! Let me count the ways....

Actually @Juan and team have already listed some good reasons not to automate. @Juan says that "the hard part is measuring the costs ..." This is a "whole can of worms", as they say. Technically we are confronted with very high uncertainty. Especially, tacit and/or hidden work practices are lurking in wait. That's the micro view. We can also look at the macro view and strategy. Doing a cost/benefit or ROI on a micro work process view might give you a yes/no answer, even allowing for uncertainty. But from the macro or big picture perspective, work practices for an entire industry might be evolving due to new technologies and economics. Think so-called "disruption".

Sometimes not automating is a lot safer than blindly automating for the sake of automating. Yet uncertainty and risk await both the bold and the shy. My view is that domain knowledge is the answer. Only with deep domain knowledge -- the opposite of magical thinking -- will leaders be able to reduce both micro and macro uncertainties. With deep domain knowledge, you are in a better position to really assess whether or not to automate a given process. Or even whether you should even have that process or not.

(Interestingly, the question of domain knowledge is "contested terrain". Taylorism is very much about the acquisition and ownership of domain knowledge. Taylorism oddly enough was embraced enthusiastically by both capitalist and socialist management. It turns out however that life, work and processes are typically much, much more complex than what the Procrustean beds of most Taylorist process models would allow. The "contested" part refers to the struggle between management and labour over who will manage work. However, complexity concerns notwithstanding, we now have the example of Amazon. Perhaps Amazon warehouses are our inevitable Taylorist future. In an Amazon warehouse there seems to be little uncertainty and very good ROI.)

Returning to our original question concerning "reasons not to automate" -- as any good sales person knows, once you eliminate all the "no's" -- i.e. in this case all the reasons not to automate -- what you may be left with is a compelling reason to automate! Go Team Automate! :)
Accepted Answer Pending Moderation
"Don't Automate, Obliterate" said the late lamented Michael Hammer in 1990.

The turn of the 80s decade was an exciting time for new business thinking, I was lucky enough to be working on the MIT90s program for DEC, and participated in a lot of the discussions in and around Cambridge MA.
As some of you may have realised, I am a pragmatist not a purist when it comes to BPR. I want to be in the field structuring and moving projects forward and learning how people react to different models and methods. Finding out what people buy into, what consistently works well in a variety of circumstances and what should be thrown away. As we all know changing the process and the technology is the easy part, but if you can't change the people (from the top to the bottom) it's all going to be a waste of time and money.

So from some recent experience on process automation:

-Almost any process that is rules based has to be considered a candidate for automation.
-This ranges from minor decisions and allocations through to advanced medical diagnostics.
-Legal, insurance, banking all involve simple routine customer enquiries where the process output is a yes/no decision
-In addition some companies are also starting to use AI as a 'whisper agent' to help human call handlers process complex claims,
-Which in turn deskills their work and could result in recruiting less qualified staff and reducing training budgets.

As per one real example:

-A couple of years ago we worked on a project where a very expensive AI Chatbot had already been bought to handle on-line building planning decisions for the public
-In the UK building planning can be extremely complex and something very few citizens ever participate in, so most are unfamiliar with terminology and procedure.
-The project objective was to reduce pressure on professional Planning Officers and clear major backlogs of public enquiries
-At the beginning the AI Chatbot had the verbal and mental dexterity of a toddler.
-After nine months of intensive work by a large development team the AI Chatbot could just about handle basic on-line enquiries along the lines of: Do I need planning permission to a. convert my loft? b. extend my house c. build a shed in my garden?
-Almost any other type of enquiry prompted the response: "I need to refer you to the Planning department, which is open 9-5, Monday to Friday"
-Publishing an interactive graphic or decision tree on the website might have been a far faster and cheaper solution, but it wouldn't have been an AI solution.

Lessons learnt so far:
-We are still at the early stage of Process Automation, there is a lot more to it than replacing 25% of checkout operators jobs with self-scanning tills.
-The turning of the 10's decade has the same feel of new business discovery and learnings that happened 30 years ago.
-Putting 'AI' on the box lid is still a great business marketing tool for some yet unproven, bleeding-edge technologies.
Accepted Answer Pending Moderation
Quite simply: flexibility. Speed of change. Sometimes, it is not worth setting a process in stone if you are going to need a different one next time.

Consider the way that Hollywood makes a movie. There is a director, and a different cast and crew every time. They have no permanent organization but come together to make that one movie. There is a basic idea of what the roles are, however every film is different and asks unique things of every role.

To automate that process, would be pure lunacy. The process from the last movie would have to be heavily modified, and the benefit from automation would never be as large as the cost of writing the process down.
  1. https://social-biz.org/2019/03/16/models-and-organizations-dont-mix/
  2. https://social-biz.org/2017/09/07/business-driven-software/
Accepted Answer Pending Moderation
For me, one of the key differentiators for automating a process (or not) is intelligence.

If only the slightest amount of intelligence is needed for the execution of a business process, do not automate it.

As fancy as RPA claims to be, AI currently is at the stage of a 4 or 5 year old infant (at least, that's what I read in the book: Superminds: The Surprising Power of People and Computers Thinking Together by Thomas W Malone) and business processes are typically executed by adults (whether they act like adults is an entirely different discussion). When trying to capture intelligence in automation, the number of different possiblities very quickly becomes uncontrollable and therefore should be left to manual decision making and processing.
BPM is all about mindset first and toolset later....much later
Accepted Answer Pending Moderation
Reasons that leap to mind include:

  1. Immaturity. Your business is too small or not sophisticated enough to take advantage of automation tech.
  2. Myopia. “Everything's working fine—why change it?”
  3. Confusion. I have a lot of sympathy for organizations that decide to automate, venture into the marketplace to see what's available, and come away with a giant headache but no solution. Today, everybody is an automation vendor; everybody has a workflow solution; everybody can solve all your business problems with their slick new software.

Technology: if it were easy, anybody could do it.
Scott's opinions only. Logo provided for identification purposes only.
Accepted Answer Pending Moderation
A great question and one that hints at the complexities to be taken into account when drafting out automation and BPM implementation roadmaps. Definitively, there are either process components and also entire processes whose LoE's significantly outweigh any potential benefits which one could aspire to obtain. The 80:20 Pareto rule has also an important applicability here. A rule of thumb we found that helps when evaluating if certain features can and, more importantly, should be automated, is validating the business repeatability, rules rigidity and case volumes. If the value mapped to one of those variables seems to be off, an automation effort may not be the right path to follow.
NSI Soluciones - ABPMP PTY
Accepted Answer Pending Moderation
Accepted Answer Pending Moderation
There are none ...and there are many. It depends on your interpretation of process and how you relate it to value. For some, a single system function like entering an order into a system, is a process, and so is hire-to-retire.. Just moving a pallet of material to clear a space is a process ...but would you automate it.

A key reason to automate process - it forces out the exceptions, the ones that never come out in a mapping exercise. Exceptions cause automation to fail. They add cost and degrade quality whether or not you automate. Use Automation as an enema to bring exceptions into the light. Just use a tool that can automate processes quickly and cheaply.

We automated an electronics company's RMA process. The CEO was upset because the automated process, which captured the cost of processing the RM, showed they were better off junking the returns and shipping replacements ...so he didn't need to automate the RMA process in the first place. But in doing so he added $Ms to the bottom line. He could have called in The Consultants but they would have probably cost more than the automated process..
Accepted Answer Pending Moderation
Every business process is human driven and automating the whole process is never going to happen. Yes there will be tasks within a Process which can be automated as already discussed in RPA discussions. Many more now readily implemented such as creation on emails and letters, rules/conditions on events triggering next actions, reports created and allocated etc.

I see "AI-assisted jobs” rather than technology replacing human roles as now being an achievable objective with next generation software aided by BPM thinking
We toyed with mdbs' GURU AI software back in 1985 - the pitch seemed to focus on "reverse reasoning".

Today, qualification for AI seems to revolve, among other things, on ". . . . when presented with an unfamiliar task, a strong AI system is able to find a solution without human intervention".

We don't consider assistance at branching decision boxes along workflow pathways to be AI; we don't see predictive analytics overlays that show a "current" best practice pathway as AI. A rule set that accommodates yes/no/neither allows full automation but we don't see that as AI.

In short, we don't have any AI "solutions" at the present.
Karl you make a good point identifying differences between automation and intelligence....something that is often confused. I think where a task automation requires more than just one automated action which then triggers another relevant action then I would suggest warrants the intelligent tag? For example an intelligent questionnaire can recognise past responses then present relevant new options and ultimately present informed conclusions? A pricing configurator would have intelligence making decisions.
I tried to look for "minimal requirements" for AI.

Nothing much out there - we can probably say that the difference between non-AI and AI is that the latter can guide the processing for an eventuality the software programmer did not consider.

It's dangerous to try to give examples , , ,

Suppose we have a robot programmed to 'go down the hall and, at the end, enter the 1st door that is unlocked". Suppose further that the programmer did not include in his/her rule set a rule that says if you get to the last door and it is locked, then come back.

Non-AI would have the robot forever stuck at the last door, AI would have the robot come back.

I love the joke where a lady asks her son to go to the store and ". . . .bring back a quart of milk, but, if they have eggs, bring back six" - the son returns with six quarts of milk. The lady asks "why did you bring back 6 quarts of milk?" Response : ".. because they had eggs".
Accepted Answer Pending Moderation
- Scenarios where the front line users who interact and build a relation/rapo with the customers should not be compromised with automated bots
- Internal debate & speculation on "to automate or not to automate" is still ON or if that hurdle is already covered, "to build a wrap-&-renew RPA solution on top of legacy or rip-&-replace to build a solution encompassing process automation & advocating STPs" is ON. In either cases Process is stuck!
- Happy & content with the existing system - lets go with the flow thought process. ITTT (If this happens then we will figure out what we will do) - i.e. the urge to step out of the comfort zone & start experimenting
- Lost in discussions, PPTs/slides, meetings, conferences & research (busy calculating RoI - mostly theoretical or building a fictitious verbal fantasy digital platform) - missing the creation of a roadmap, blueprint & incremental steps to realize the same
- Budget & Costing (ending up in prioritizing & tagging the process as "NOT the bigBet" for this year)
- Taking a Top-Down approach to Digital Transformation than the Bottom-Up approach of identifying/correcting and realizing the benefits at the smallest process level that pile up to build the entire platform
- Painting an outside-in view of digital automation/transformation than an inside-out view. Contextualizing of the action for every process in the business is a key - it can be compared and observed as industry blueprints.
  • Page :
  • 1

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