The cutoff between under-automating and over-automating is very abstract. While business rules and IFTT allows automation teams to provide significant value to their users, they sometimes struggle in deciding when they are over-engineering a process. As complexity rises, so does the Total Cost of Ownership, including development, maintenance and support, whereas marginal derived value decreases. Moreover, these rules may also sacrifice flexibility for repeatability, which is something that we do not always want.
This begs the question “How can we better define the automation cutoff and how to best involve end users in this kind of decision making?
Marked as spam
Some of the determinants for automation could be a) requires fast turnaround (may be in minutes) b) human centric/ manual activity can be eliminated completely c) highly or completely manual / human centric d) has multiple decision points (branching) While points a & b does not require much justification, c & d may require deeper analysis and may call for improvement/redesign/reengineering before jumping into the decision for automation. The inclusive way of arriving at the decision to automate or not will be best provided in discussion with the end users when setting up the threshold limits for the criteria. The end users have the experience, business knowledge and even may have deep knowledge from peers in same industry to be able to provide the insight necessary to arrive at a decision. However, technology, cost, etc will also have an important role to play in the decision to automate along with the strategic objectives of the organization.
I really like this question. I wish I had a better answer. Unfortunately, I think we tend to automate everything, and then only later realize we maybe overdid it. It's difficult to know what is worth automating without taking the time to understand what it would take to automate, but by then, you have everything you'd need to automate it--so why not just do it? On the other hand, once you've automated something, it's really hard to go back to a manual process. I try to keep the 80% approach in mind and focus on automating scenarios that happen 80% of the time and leave the last 20% manual. The "80%" may shift depending on the goal of the automation and the nature of the process (risk, efficiency, cost, etc.). So if the goal is reducing risk or the process is inherently high risk, then I'd lean more heavily towards automation where possible.