It is a trend to offer tooling that supports BPMN modeling together with model syntax checking and model simulation. For example see BPMN simulation and syntax checking in ARIS.

Model syntax checking can make sure, that modeling rules, that are statically checkable are kept. It is definitely a help. Especially beginners do not know all of the syntax rules and are guided by the checks. Also experts might find this feature helpful.

Model simulation can be distiguished into

1. Interactive simulation of a single process instance and
2. Cumulative simulation, where many process instances are created and throughput and latency are determined

Especially the ineractive simulation of a single process instance can also be a great help in understanding the model and even the modeling elements and it’s semantics.

The cumulative modeling itself is more like a determination, if the underlying business process is optimal or not.

Another category is thinkable: The verification. While cumulative simulation or single model instance simulation can not ensure, that certain attributes for a process hold, like the absence of deadlocks, verification can. Here it is decisive to find the right attributes of a process that shall be tested.

All of this are technical means to achieve better model quality, and all of these are useful. But none of these is so useful as a governance process. Just because humans can without all of these means do the same thing and they can do even more. They find problems, that even the most sophisticated syntax checker, simulator or verification routine will never find. Also what all of these methods can only find is the consistency of the model in itself (or with another model), but never can test the correspondence of the model with the real world process. This will still be left for humans for all times.

Therefore while all of these means of checking and testing are useful, because they are comfortable, they can or should never substitute a governance process.

This may happen: The right means are used for the wrong purpose, and the result is a disaster.

I have already discussed, that the modeling purpose does determine the outcome of a modeling exercise.

So what happens, if you use the right modeling language for the wrong purpose? It ends up in spaghetti models.

If you try to use a BPMN model for the purpose of model driven development – as mentioned in the blog (i.e. to generate coding) – for a business process with many special cases, then the result can be a spaghetti model. But this is not because BPMN is not good, it is because the right means for the wrong purpose has been used.

What is the level of detail that should be modeled? By which modeling technique it should be modeled? These difficult questions are best solved within the scope of a model governance process. As soon as a model become a subsitute for coding only – i.e. it is not human readable any more – it misses it’s purpose. Then it would be better to code. A governance process makes sure, that it is still human readable.

Furthermore it needs to be considered, that BPMN is not the only modeling language in the world and should not be used for purposes, where other means are better. I will elaborate on this later.

In itself this is not sufficient to achieve a consistent model quality in designing BPMN models. More is needed. The missing element is a governance process.

What is a governance process in this context?

What you need to design high quality (BPMN) models is experience. It is always possible to solve a certain modeling problem is different ways. Which is the best way for which kind of modeling problem? Unter which circumstances is which solution better? Is a certain solution consistently applied across a large set of models, if the underlying modeling problem is the same? What are the modeling rules, what are the patterns?

Theoretically it is possible, that a single person has all the experience needed. But still then this single persons approach differs from an approach of another single person. Also it is not clear if this single person is always available. Furthermore we are humans and we err.

So the elements of a governance process, that produces consistently high quality in modeling are these:

1. A defined number of modeling experts with different background, which collaborate over a long period of time with some, but little fluctuation.
2. A defined review process with enought time to study a model for all reviewers (experts) and the possibility to accept or reject a model.
3. The possibility to raise issues, discuss pros and cons and find solutions.
4. A list of quality criteria, patterns and modeling guidelines which each model needs to fulfill. This grows over time by common action of the experts.

Each expert that takes part in such a governance expert council will learn from each new model review and the common expertise will rise. The quality level of models can be held consistently high. Futhermore is the feedback of such an governance expert council to the standard – in this case BPMN – invaluable, because they are those who find out even the subtle weaknesses of the standard over time. Each modeler, that commits to the governance process learns more than any theoretical class can ever teach him.

What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance [...] Kiran Garimella

from http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
That is an concise list of what is important within BPM, although I to not share the view of the author, that BPM is a kind of proces operating system. ImhO it is a design principle and a management paradigm. It must be supported by system design, to become effective, but it is not an operating system, upon which higher level solutions will be developed. Yes, it is an architecture – and the Business Process Platform architecture that I already mentioned is one important part of it. But it is not merely a separate software layer.
Now let us look a little more into detail of these elements:

Ad 1) Business Semantics.
It is obvious, that it is inevitable to take into accound the process, that is realized by Business Objects (Ordering, Selling, Payment, Stockkeeping, Billing, …) if the process semantics is important. Each of the Business Object types have a business semantics. Each of their states has and the actions, that can be performed with them (like release). It is not possible to ignore them, if an holistic view on the process semantics is necessary. The other way round said: It is often necessary to realize the process semantics by means of implementing Business Objects, because it is so sophisticated business semantics – if I mention prices calcuation for example.
Ad 2) It is impossible to do process design and not take into account the process, that has been implemented in Business Objects already – if it is not a very simple case like a very simple workflow. But even with a simple worflow, there often is a Business Object (Invoice, Project, Order, …) behind it. So the process can not be designed completely free, but within the limitations of the Business Objects, that are going to be used. Or the other was round: if the Process is Designed completely free, then Business Objects need to be implemented or extended to realize such a behavior.
Ad 3) Process Metrics.
Is it possible to think of process metrics and not take into account the state of Business Objects? Plainly said: No. It is relevant, if orderes are Released or not, if Invoices are posted or not and how long it takes from ordering an Order (i.e. reaching the state ordered of the Order) and posting an invoice (i.e. reaching the state posted of the Invoice). So process metrics need a tighter integration with Applications – in the form of a Business Process Platform BPP.
Ad 4) Process Goverance
Process governance can only be realized, if the necessary process metrics is provided. As a result of process governance, the process needs to be adapted. This can – in certain limits – be done by changing some modeled workflows. But often it is needed to utilize different functionality which is implemented in Business Objects or to adapt Business Object functionality. This can only be done, if the application has been built in a way, which makes this possible cost effectively – i.e. by conforming to a BPP architecture.
So the different elements of BPM can better be reached, if BPM is tighter integrated into applications – i.e. if applications are BPM enabled – and if a Business Process Platform (BPP) programming model is followed.