A company improves their process to cut costs and/or increase revenues. If a process accomplishes neither, then it could be called a failure. However, process improvement is an ongoing activity. Even if a process succeeds in cutting costs and/or increasing revenues, companies should always be looking for further gains...
In general you could say: when a process doesn't deliver what it promises anymore. You can discuss if you call it a failure if it happens for one case, or do you call it a failure when it happens for 50 % of the cases?
That might happen so now and then, so the real failure might be the lack of flexibility to adjust the process and make it perform again.
But the biggest failure to me would be executing processes that deliver results nobody wants. So that's the lack of adaptability to changing needs. But maybe that is not failure of a process, but failure of a company.
Inherent in process automation is the ability to keep count. Processes should be monitored for usage counts, exception rates and the time between transitions should be measured and reviewed regularly.
Processes that are not used might be considered as failures, certainly a waste of time to create and automate in the first place. But is this really a process failure or an implementation, training, supervision or hiring failure?
Any automated process that takes longer than the previous (automated or manual) process it replaced should be identified as failing but not yet failed. These processes become priority targets for review and remediation. Close consultation with the users and business leader will always reveal ways to optimize and enhance the process.
But the most obvious failed process is one where the users have simply circumvented it in order to get the job done more effectively. One business leader told me recently that she had discovered a user who "still processed all the returns by hand, kept large three-ring binders under his desk and, once a week, and entered everything into the computer 'to make it happy'." This process failed the user who found life easier the old way. It isn't that users are necessarily recidivists or Luddites, though some certainly are, it is that they want to work efficiently and will find the fast course to do so.
A failed process is most likely a failure of design and implementation rather than usage.
I would echo what Kevin mentioned in that a process has failed if users circumvent it for a better way of working. Now there may be policies or legal implications that require a process to be a certain way but in many circumvention instances, it seems users have better and faster ways to get their work done.
I would expect that if we are talking automated processes, the evaluation and redesign cycle has failed and now the process itself is a hinderance rather than a value to the users. This is a big issue where firms with process automation forget to continuously improve and think they are done once in place. User feedback and needs are unanswered and so the process adjusts one way or another. The process automation becomes a source of disdain and then management/users look for the next tool/implementation to help address the previous 'failure' even though the tool wasn't the biggest problem.
"Every process is perfectly designed to deliver the results it is currently producing." So in that sense a process can just go on producing the poor results it has. And someone or something (data feedback) has to send a signal that something is not working, then a decision has to be made to improve it, and action taken.
And what is noteworthy here is that no one is noticing and taking action. This is a process that has no value ( e.g., reports that are produced and nobody uses them) and yet the organization goes on doing it. Clearly that is a process that has failed.This example really supports what Emiel said as well.
I agree with earlier observations about workarounds, but you have to be careful: not everybody circumventing a process is doing so due to the failure of that process. Change is hard for many, and often threatening. People can be pretty creative in avoiding perceived dangers to their jobs or self-esteem. If your users are working around your process, the failure may well be in the process per se—but it may be that the real deficiency is in the way you prepared them to accept and adopt the changes you are introducing through automation.
Google has just shown us the way here, today unveiling an algorithm which learns games faster than humans.
Think back to when you were a teenager. Most of us will say "crikey I didn't know much, but I thought I did".
It is the same with process. Think back to the process you designed ten years ago and you'll think "I'd do it differently now".
A Process should be considered a failure if it doesn't learn. Because the day it is installed is the best it will ever get.
The market will move on, the needs of the customers will change and the people using the process will see things they forgot to include in the originl version, new things they can now see how to do better and they'll educate the customers to modify their inputs to suit the process.
Imagine a steadily rising graph. You design a process to meet needs at a particular point. So you touch the graph.
Then the process is set in stone and doesn't move on. It flatlines, while the graph continues to rise.
Unitl suddenly someone finds that you've fallen behind. Then there is a very steep climb to get back to the curve again. Costing fortunes in both time and money - and leaving a gap for competitors to exploit for every moment you are under that curve.
This is step-change. It is the biggest single failure of process. If you don't design your processes so they learn, they fail from day one.
Considering that a good service is usually not noticeable (e.g. a good waiter is not intrusive, a good system administrator is unknown to the end-users, etc.) then a process is a failure when its participants start to talk about it.