It is easy in principle and it has been made difficult by process management methodology.
While I agree widely with the Theo's general perspective I think this discussion goes astray in multiple ways. The term 'BAD PROCESS' comes from the world of predefined, predictable process models. A process has to be defined to be 'bad'. If there is no process the customer might be unhappy but there is no process that is at fault. In the general concept of a process the main goal still is cost cutting so a process is bad if it is expensive. Process quality is measured how well people adhere to process metrics such as how much time is spent. Quality in terms of customer satisfaction is not measured inside the process.
Therefore there is no'easy way' identify a bad process, mostly because creating and maintaining a process today does not include explicit goals so the much vaunted process metrics have not means to identify is something isn't right. Even if the people involved realize through a conversation with a customer that something is amiss, there is not much that they can do unless they go through the whole improvement cycle. Just knowing that a process is bad does not yet include an understanding what process would be good. Each performer can identify how to improve his work if he understands his goals. That has btw nothing to do with the number of sub-processes ...
And then there is the whole nonsense about iBPMS that supposedly enables the business my merging multiple technology sets (analytics, rules, event recognition, pattern matching) to automatically tune processes. No such thing will happen because first you need explicity goal definitions as well AND you need an explicit data model AND you need a well-defined state-space of varaibles that make up the process environment AND somehow the customers and performers goal assessements have to be mapped into it. Truly, I have seen nothing of the kind in iBPMS proposals including recent books on the subject. It is a hype ... no more.
I did discuss the subject from the perspective of goal orientation in this post a couple of years ago:
Quote: "For business, goals can represent strategic objectives (often quite intangible), customer outcomes (pure perception), operational targets (must be measurable) or process goals (ideally tangible). While process goals should in principle be tangible, that does not mean that the actions needed to arrive at that goal are equally tangible or predictable. That is the whole point. A process flowchart assumes all-out predictability, while goal-orientation is about guidance under uncertainty. As certainty is not achievable because any event can happen at any time in any process context, goal-orientation is the only real world approach to process management. The ‘outcome’ (can be output, handover or result) of a process is achieving goals that are causally connected to business strategy and capability."
You should finally realize that virtually all processes that involve human interaction and are predefined and rigid are bad processes!