Reading through Adam  Deane’s post and comments I realized its important to understand where the industry is headed without the three letter acronym jargon. And more importantly, how can folks leverage the work done to build existing specifications. I very much appreciate the real world examples Adam listed. I saw the commentators telling what ACM is not – I want to hear what it is. Thanks to Max for giving such a good list of what to expect from an ACM:
And my comments follow the “-“
A) business performers can create the processes to meet well defined goals.
– Well who can argue with that – and that is true for any process; the process owner should “OWN” the process. WYDIWYE is critical must have. Dont shoe horn the process to fit what the tool can do.

B) processes are signed off by the process owner and rated by customers.
– Absolutely – it means other folks that consume the process must agree with the definition of the process.

C) They can follow a flow but do not have to.
– When they dont follow a flow what do they do? My point is whether we like it or not, there is a flow.

D) They can be modified during execution where allowed.
– Absolutely. I am assuming the question here is whether you allow state changes or also allow definition changes.

E) Goal completion can have very strict criteria.
– It should have a measurable criteria.

F) Modified processes can be saved as new templates. (adapted)
– Absolutely – in CS corridors  the word is versions.

G) each process instance can be audited.
– Absolutely true. If an instance cannot be audited then we are generating code and reverse engineering audit info from code to tie back to the process initially created.

H) linked objectives and targets allow business perfomance monitoring.
– The key performance indicators should be linked with business performance.

Well a product can do all of these, it can use BPMN as a notation to track what is happening?  Would we call it BPMS, Dynamic BPM, Intelligent BPM or ACM …? Check out Bruce Silver’s review of Roubroo.