Like
Gertrude Stein's famous rose, process is a process is a... We all know what a process is, I think; the definition isn't in dispute. Not so for process
approach, which is a rather murky idea that's related to the concept of "systems thinking." The consultant and author Allan Sayle claims credit for the idea, saying that he developed it in the 1970s. I have no evidence to dispute his claim, but I think the genesis goes back even further, and perhaps Sayle was the first to elucidate the idea in a general business setting and gave the idea the name we're talking about today.
The idea, as I see it, is not necessarily antithetical to an element-by-element ISO 9001 documentation system, as has been contended. Instead, I think the purpose is to overcome the "silo" effect, wherein departments and their disparate priorities have a negative effect on having smooth, uninterrupted processes.
As an example from my own experience with an OEM (product is irrelevant), when a design was transferred to manufacturing and found to have bugs, it was often difficult to get the design authority's attention in addressing the problems because as soon as the design was released, he had a new set of priorities for a new design effort. As the familiar biblical adage goes, no man can serve two masters, and if the design engineer were faced with a choice of honoring the priorities set by his own managers or dropping everything in honor of the manufacturing engineer's needs, the outcome would be predictable. The idea of conflicting priorities travels along the entire "product realization" path--at the end, for example, we might have a shipping guy who's been told, in no uncertain terms, that he cannot ship a product until some sort of special packaging is available, while he's simultaneously being dunned by a customer service person who says the product MUST SHIP TODAY!!!
This sort of thing, which happens every day in manufacturing, is clearly the result of poor (or nonexistent) leadership. If the "top management" in a company allows the coexistence of clearly conflicting priorities among her department managers, no one below that level will be able to do anything about it. It follows that if such a scheme of conflicting priorities is in place, "systems thinking" goes out the window, never to be heard from again.
In order to implement a process approach, all of the disparate elements that combine to produce a product or service must be coordinated such that a smooth continuum of effort exists
across department boundaries. This is what the standard refers to when it talks about processes
and their interactions. If such a continuum
does exist, it does so irrespective of documentation, the standard and CB auditors who want to "promote" things but don't understand what they want to promote.
I don't know of a way to completely mitigate against incompetence at the top level of management, and the standard shouldn't be expected to perform miracles. No one below the top level can successfully implement a process approach (or anything else for that matter) unless given responsibility and authority to do so. Good luck with that, as they say.