As a business person, you usually hear these two modelling notations tossed around in meetings and conversations around ‘process’, or from your process-oriented colleagues on the other side of the ‘fence’. Unless you are a business process management (BPM) professional, or have done modelling in the past, the difference or similarity of either one is not apparent. At the risk of being on the receiving end of a detailed discussions on the merits of each, you may just choose to smile and nod your head politely while appearing to vaguely understand the ‘lingo’ of conditional flows, logic operators, events, and FADs, etc.

However, it would be good to have some knowledge of both to understand how either could capture the set of requirements you have – the artefacts may add value to your business far beyond their cost of development.

If only we lived in a unified world – all driving on the right side of the road and using only 240V; no choices between ‘soccer’ or ‘football’, Coke or Pepsi, and so on. It can be pretty frustrating when we travel to discover we have brought the wrong adapter, or find out that our favourite beverage is not available in a restaurant. However, the market dictates that familiarity, applicability and experience demands personal choice.

The same can be said for process modelling.

The Event Driven Process Chain (EPC) is one popular  modelling notation and the Business Process Modelling Notation (BPMN) is another. People are sometimes confused which of the two provides a better fit or utility for visualising and communicating business processes.

Choosing one or the other, without realising whether the modelling notation actually addresses our concerns, is an exasperating exercise. While there is a full spectrum of alternative notations, we limit our discussion to EPCs and BPMN, since they appear to compete the most with each other’s functionality. Hopefully, a peak under the hood will not only give an appreciation to the merits of both notations, but also lead you to explore these issues in more detail.

Before selecting a notation to use, the first and most important task must be to determine the purpose of modelling.

This should be done before every project, no matter how big or small. However, defining and understanding the goals of the organisation would help to determine the overarching purpose and, therefore, provide direction on choice. It is difficult to decide the relevance and use of process modelling notations if you are not clear on this direction.

I would suggest asking:

1. Why do we need to model?

2. Whom are you modelling for and communicating with, business, IT, or management?

3. What systems will be affected by your modelling choice?

These are some of the questions whose answers will help you to define the environment in which the modelling will be done. Other considerations may include educational background or function. On the whole, business people prefer EPCs, while IT people may look to a more formal notation. Also, are the requirements simple or complex (tactical process improvement, versus model driven integration)? Unless you are quite clear about most of these, then deciding on one or the other notation becomes ambiguous, and the selection exercise futile.

Once you defined the scope and the context, write it down in summary or table form. Having these requirements handy will make it easier to decide which modelling notation to choose.

The EPC is most often used to model higher-level business processes. However, there are cases where these have been used for executable modelling. BPMN would be most often better for lower-level process modelling, having been designed to be convertible to Business Process Execution Language (BPEL). So if your company has web services or SOA implemented – or you are in the IT, technology or telecommunications industries – BPMN would be more suited, since it has process automation as a primary focus.

The EPC is more detailed in looking at sequences or chains of events, and is very expressive in capturing other elements of a process (process outcome, risks, issues, KPIs, etc.). While possible, BPMN does not contain models/objects that allow the visualisation of a company's strategy (like a Balanced Scorecard model or an Objective Tree), nor is it meant to model business rules. If your top management requires the measurement of such metrics, then it would be a safer bet to go with EPC.

The EPC strikes a good balance between strict adherence to rules (or ‘rigour’) in modelling and conveying the process in simple terms. It has only five basic elements and rules, and uses the extended EPC to capture and express all other required information, either in objects or their attributes. The EPC, however, is graphically less efficient than BPMN, since you tend to have much larger diagrams with more objects in them (i.e. Events should be used after each split). This can be improved by using sophisticated modelling tools to improve the ease of navigation between the models. The EPC cannot be used to express all patterns will not all be necessary or apply to the task at hand.

While both notations support ‘looping’ equally well, BPMN supports non-interrupting events that trigger an exception while the process continues – you can show this in EPC with rules (AND rule) and events, but the solution in BPMN is more elegant.

The use of BPMN for business process modelling has to be complemented with additional elements (matrix or FAD). BPMN models are also meant to be ‘flat’, although some tools allow for a hierarchical breakdown. BPMN does not support the assignment of multiple resources to one activity. EPCs do not support semi-structured processes, whereas ad-hoc sub-processes can be implemented in BPMN. EPC cannot be easily used to describe executable processes.

(Image courtesy of http://www.ariscommunity.com/users/sstein/2010-04-15-epc-vs-bpmn-perfect-flamewar )

The chart above shows the comparative positioning of EPC and BPMN for easier reference.

Should an organisation consider using both?

If you belong to an organisation that can devote resources to training and getting expertise on both modelling notations, that would be a good alternative to consider. Having expertise in both conventions would allow your organisation to use EPC to model high-level diagrams, which give general impressions of processes, and switch to BPMN on an execution level to have all the important details about a particular process.

This would provide an organisation with a detailed and comprehensive view of the inner workings of the company, and more easily allow for  process improvements.

However, like any selected language or method in an organisation, it is imperative that clear standards are set, communicated, and adhered to. Normally, IT and engineering professionals prefer BPMN, since it can track tasks against application (lane) and domain (pool). Business people, on the other hand, normally model with EPCs, since these makes it  easier to identify task/function against responsible individuals and KPIs/metrics.

Whatever your final choice may be regarding the points discussed in this article, it is always safer to get a second opinion, or recommendations from other people in your industry or those with similar requirements. To become an expert in either or both notations will involve a lot of study and time.

This article is not meant to be a comprehensive analysis of the two notations; however, it does provide some idea into their workings and will allow you to hold a conversation on this topic.

References
1 http://de.bpmn-community.org/best_practices/31/, accessed 22 June 2011.
2 http://www.ariscommunity.com/users/sstein/2010-04-15-epc-vs-bpmn-perfect-flamewar,accessed 22 June 2011.
3 Recker, Jan, BPMN Modeling – Who, Where, How and Why, BPTrends, March, 2008.
4 Recker, Jan, et al., An Exploratory Study of Process Modeling Practice with BPMN, 2008.
5 http://wiki.sdn.sap.com/wiki/display/ModHandbook/Process+Modeling+Notations, accessed 22July 2011.
6 Leonardo Consulting.