Case for ACM using BPMN?

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.

Cloud demands a new way to run Business Processes

My invoices / purchase orders / quotes / leads are stuck!

Does any of these sound familiar? Have your ever had a situation when you are working with a cloud service and another application and you realize that your business is stuck somewhere in between because of an IT issue either on your IT or the cloud providers IT? How many times you have been interrupted because xForce upgraded their API or your ERP was undergoing maintenance or the DB went down over the weekend towards the end of the quarter – just when you needed it the most and you could not provide that crucial analysis or report.

If any of these scenarios strike a chord then you are looking at the new way of doing your IT business.  Where services will go down or will  do an upgrade with or without notice and you have to redo some steps while not redoing others – sounds familiar? I want to push all my quotes again to SalesForce, but I don’t want to submit all the invoices again into my SAP. Welcome to a world where when you define a business process, it may not work exactly as expected because of a myriad of reasons – some you can control some you cant. How do we get around these? We have seen the argument of on-premise vs on-cloud play out and currently the answer lies somewhere in between. And that is going to be the reality of our world for at-least the next decade.  How do we prepare ourselves for this reality and ensure that we are not sitting in conference calls between Friday and Sunday AM.

What you need is a solution that lets you make these various applications talk to each other and be prepared to hold the line when one of the parties is not reachable. Also it must allow for reconnection when the call drops – almost all of the things that you expect from … common sense!

I remember talking to a tire selling company last year when they had put a system in place which was holding a few hundred  of invoices in flight but there was no way to move them forward. Engineers on both sides spent hours trying to “fix it”, understand how we got there in the first place but it was a tedious task. Those invoices were critical for the sales team to hit their monthly target but there was little respite from the “system” issues.

When we started building out the next generation business process platform, we were acutely aware of these requirements. Our belief was confirmed when talking to our early adopter customers that they have this pain and it is a recurring pain. Therefore, we built a very agile business process engine which can react to such events as and when they occur. Earlier research around BPMN execution semantics came in handy for our design. And the result was Roubroo – a light weight, cloud based graph enabled business process platform which could execute structured and unstructured processes, accommodate ad-hoc process definition and instance state changes with a WYSIWYG control – much like the control panels in more evolved machines like Hydroelectric plants – more on this another time.