BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 06 February 2018
  5.  Subscribe via email
As automation is front and center in many companies today, what are the key mistakes to avoid when automating a process?
Max Young
Blog Writer
Accepted Answer Pending Moderation
a few come to mind.

1. You can't really be agile if you don't have nimble architecture: monolithic applications are big ships, and they can't readily turn to adjust to the currents if you don't have a plan to transition to micro-service architecture.

2. RPA is not a replacement for true integration. It's a temporary fix: critical & important & and all of that, but it's a chain that's fragile, and can be easily broken if one of the underlying systems changes it's interface. So, yes, do use RPA. But have a plan to transition to true integration.

3. Microservices and ML are here to stay. Learn them, love them, make them your own.
References
  1. http://www.capbpm.com
  2. http://www.capbpm.com/iq
Comment
While I completely agree with you, I can bet the house that no executive that greenlights an RPA project actually has a plan to transition to true integration. They only care about the quarterly results of their mandate. This is the prevailing business motivation model of the world and I'm not sure we will ever have strong enough financial crises to shake that to the ground.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Automating bad processes. Understand the process first, ensure it makes sense to automate it, fix anything that's broken then automate.
Co-founder of Skore
Comment
*mic drop
(but my above comment to Max stands here as well)
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
In automating a process, and assuming you have a good business case, don't overlook hidden process.

Also known as "tacit knowledge", most work processes are executed with the help of lots of undocumented staff knowledge and skill. This world of hidden process can be both domain-related and/or specific to a given company.

It is the skill of great business analysts to be able to tease out enough tacit process to be the basis for automation phase no. 1. (One has to know when enough is enough.) Failure to budget enough for required business analysis - including on an on-going basis usually - is to engage in magical thinking.

The mastery of hidden process is not only a technical/analytical exercise; issues of governance, dialogue, power, respect, and even compensation also come into play. Successful automation is not a Captain Picard moment ( "Make it so, No. One" ), but requires sustained commitment and trust. And even an acknowledgement that new tacit process is constantly developing!
Comment
  1. Max Young
  2. 10 months ago
  3. #5000
This is excellent: I’m using calling the “hidden Process” as “tribal knowedlge”, but it’s the same/same.
  1. John Morris
  2. 10 months ago
  3. #5001
Absolutely Max -- thanks. And "tribal knowledge" is a great description.
"Tactic knowledge" is difficult to capture in healthcare, where, in a roomful of MDs, you might not find two who agree on a starting dose for a particular patient/medication.

Whereas building a "standard" benefits training of new hires, there is no real solution to trying to force the docs to follow the standard.

A problem can arise when a handoff takes place between stages (i.e. the starting dose is off-standard, it's time to set a ramping dose, but a handoff takes place before that happens).

Now we have a ramping dose that may not provide a smooth transition from starting to ramping because the replacement doc routinely uses a much higher starting dose.

The significance for BPM is that without auto-recording of process step data to History(structured or unstructured) at Cases, plus one-click access to the Hx, it may not be easy to look up the meds History.
  1. John Morris
  2. 10 months ago
  3. #5014
Good insights Walter concerning tacit knowledge for an important domain of work, i.e. healthcare. This brings to mind Dr. Atul Gawande, the famous evangelist for checklists in surgery, and everywhere (http://atulgawande.com/book/the-checklist-manifesto/). The story of checklists is part of a broader story of readiness for BPM technology. As work processes become more systematized, then work technology such as BPM software is more easily applied.
The challenge of course is that it's very easy for checklist evangelists and other work systematizers to exaggerate how much we really understand work. Whether in Canada according to government diktat, or in private-oriented healthcare, systematizers are all too often prone to false claims about how much has actually been successfully systematized. And about how much better are outcomes per dollar.
So on one hand, checklists and BPM software are great. On the other hand, the tacit or the tribal will always be with us, I think. And every work domain has its own unique challenges.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Automation ONLY comes before simplification in the dictionary.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Key Mistakes/Omissions -

1. Assuming your Case Management platform that hosts background BPM is an island.

Without interoperability, you cannot accommodate automated process steps.(i.e. Lack of an in-place generic data exchanger to output data and import data on a need-to-know basis to/from local and remote systems and apps)

2. Not being able to accommodate any mix of structured / unstructured work, including ad hoc customer reach_in and customer reach-out

3. Not including a pre-processor at the first step of each process fragment ( i.e. is it OK to engage processing?)

4. Where necessary/useful/cost justifiable, post-processing on exit from processes steps or process fragment steps (any step, anywhere along the process or process fragment) (i.e. did we get the right outcome?)

d) KPPs (gatekeepers) - See my Wordpress article "KPPs and BPM)" at

https://wp.me/pzzpB-QB
References
  1. https://kwkeirstead.wordpress.com/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Forgetting about the iceberg of processes.

https://4.bp.blogspot.com/-nM8sA4ZG6T0/VOz7WmhmFNI/AAAAAAAAEuM/mO_-8bhmmKk/s400/Capture.PNG

Thanks,
AS
References
  1. http://improving-bpm-systems.blogspot.ch/2015/02/iceberg-of-processes-within-enterprise.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Assuming that 'automating a few steps in a predefined order' is the same as 'making processes better'
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
There are a good many of classic, yet still relevant Do's and Dont's when it comes to process automation. With no claim to be anywhere complete, things to avoid in present day automation projects that come to my mind, include:
1. Trying to find and then to automate the exception. Here, I found, the 80:20 rule applies perfectly.
2. Trying to solve all business challenges with BPMS and automation. Depending on the technologies used, "natural" limitations of what should and shouldn't be part of a process automation project will become apparent. Normally, CRM, ECM, BI and BRE initiatives shouldn't be all lumped together with a single process automation project (often different technologies, teams and methodologies are required).
3. Trying simplify or skipping altogether the process discovery, improvement and technical design phases within the process automation projects. As rightly stated above, you have to improve the process, before looking at automation. In order to do that, you and the whole project team (business, IT, analysts...) need to have a firm grip and understanding of the process as-is. Also, trying automate an improved, narrated process to-be, without having created a proper technical design document (form layouts, data dictionary. def. of WS's etc.), often proves disastrous as well during the implementation phase. Here, maybe you can summarize the point to "Not using a proper design and implementation methodology".
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
The mistake is implicit in the question: a focus on “automating processes” misses the forest for the trees. Increasing the efficiency of existing applications may certainly be a useful exercise from time to time. But true innovation lies not in wringing incremental performance improvements from existing processes, but rather in reshaping the business itself, a strategy that is reified by the process-driven applications that are the brains and sinew of the new digital business.
http://www.bplogix.com/images/icon-x-medium.png
-Scott
Comment

Are you are saying that if I am in the business of, say, manufacturing motorcycles, I can focus on improving the processes (operations efficiency) OR consider expanding (strategic and operations effectiveness) to include the manufacture of ski-doos?

In an example like this, there should be lots of room for innovation to look at sharing of resources across two lines (one with higher sales in the summer, the other with higher sales in the winter).
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Not recognising that automating a process is a process in its own creation. Vital whether a task automation or a machine one that the build is transparent with accountability. Look what happened at VW and their automated process to measure fuel pollution. Getting it wrong could be very expensive!
The fact that automated processes are only one component in the end to end process delivering the required outcome. Therefore important that there is recognition the input and output data/information needs to be effectively managed with required accountability. As the saying goes rubbish in rubbish out!
Comment

Agree... "recognition the input and output data/information needs to be effectively managed with required accountability"

This approach goes back a bit. "Telemetering information over wire had its origins in the 19th century. One of the first data-transmission circuits was developed in 1845 between the Russian Tsar's Winter Palace and army headquarters"

I wonder when the transition away from manual transaction logs took place?

There is no reason an automated task should not have a date/timestamp & performing resource with the data, same as for human tasks.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Setting Unrealistic Expectations of Capabilities: Since one size does not fit all, brands must manage their expectations for an automated system with respect to their specific application.They will need to have a realistic understanding of what automation can do for their facility and set attainable benchmarks to compare existing data to desired capabilities.

The more information you have, the better you can predict and gauge the effectiveness of the automation equipment, determine what processes can be refined, and continue to improve your overall facility.
References
  1. https://www.plasticingenuity.com/blog/automated-packaging-solutions
Kritika Pandey (Software Analyst)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
  • Page :
  • 1


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