BPM as Anti-Pattern

An organisation's "Services" come in two basic types, firstly end-to-end processes that co-ordinate lots of individual steps, and secondly a large set of fine grained services that represent individual steps. Any hierarchy or structure is solely from the basis of process. The fine grained services proliferate and become difficult to manage while the large business process elements become difficult or impossible to change.
The cause of this sad situation? Steve explains it this way:
The organisation has decided to map the processes and end to end and in detail; the work has created a series of grand "end to end" process models that are categorised by their large number of steps and the lack of sub-processes that they use... The problem is that the valid business services have not been identified and thus the process maps have been created without a proper service structure...
The challenge here is that the organisation has not started with clarity on its services and hence has created a Process Oriented Architecture. Retrofitting services into such an environment creates a sub-optimal system that is liable to have all the issues of other process based systems, such as COBOL.
I've never heard the BPMS approach described in quite this way before. The beef seems to be that integrating systems top-down from the process perspective, using BPMS's point-click introspect-and-catalog paradigm, leads to unwieldy COBOL-like monstrosities. If the business would just wait until the architects properly factored the universe into right-sized reusable chunks, life would be much better. I think Steve has unwittingly discovered the business-IT non-alignment anti-pattern.

Update: Phil Ayres, whose blog Improving New Account Opening suggests he is a serious been-there-done-that guy in BPM, presents a positive take on the BPM anti-pattern. He maps it to his own real or imagined past experience in a way that I can best sum up in one sentence: The business guys doing the process modeling were idiots (led by the infamous 'consultant'). OK, I'm sure that's not such a rare occurrence, but what I still don't get is Steve Jones's anti-anti-pattern, which is to have IT figure out the "services architecture" before you put the idiots in the room. I'd like to offer a different anti-anti-pattern, coming from a BPM perspective, which is to provide a methodology behind the modeling - and train the business guys how to use it - that helps define "coarse-grained units of reuse" as determined by the business. Hey Steve, how'd you like to become a "consultant"?