Posted by Harald van der Weel on Sunday, January 16, 2011 - 08:13
EPC is widely used in Business Process Modelling tools of German vendors like SAP and ARIS.
BPMN is more and more adopted by the bigger BPM tools like Tibco, Oracle, Cordys and recently by SAP. Will BPMN standard completely wipe-out EPC, or will there always be applications for EPC left, that are left uncovered by BPMN?
Dear All, I can not miss the fact that the discussion is based on the assumption of 'stand-alone' process modelling, which is quite usual, but is not right. The point of modelling purpose was already made in the discussion. Putting communication aspects aside, the task of modelling business architecture calls for EPC. For example, the simple task of indicating measurement points in a process and assigning them to KPIs seems quite complicated in BPMN notation and trivial in EPC. It is not the only example of that sort. BPMN was created to be visual representation of executable process and thus transforms into executable code naturally. Full EPC method, on the other hand, should be restricted to achieve the same result. Some examples of using 'trivial' events (Harald) or mixing Event and States (Igor) are just examples of bad practices. In properly set project these semantic issues should be clearly described and aligned to the modelling purpose. My experience of using BPMN was as follows. BPMN was selected for its "popularity" (thanks to OMG) and the subset of notation we used was a replica of EPC. In a background we used extra FAD models to link processes with other necessary elements - data, KPIs, roles, capabilities etc. Nikolai
Dear Harald, I share your position about EPC. Even a small Freudian slip only proves your main message – EPC practitioners usually mix Events and States. Luck of formalism allows them use elements of notation as they like it. This is one of the reasons why EPC model is hard to translate in to executable format. Igor
Earlier contributions to this discussion have provided a number of arguments why EPC cannot be easely replaced by BMPN on the short term. Some are perfectly legitimate, like utilizing prior investments in buying EPC related tooling or documenting processes in EPC. Other arguments mentioned I find less convincing. The argument that EPC is semantically richer may be true on first sight, but is this actually an issue? Let's have a closer look at EPC and BPMN: The common aspects of both EPC and BPMN are that both represent a "flow" (or "process"). A flow consists of "activities" (or "steps"), "connectors" and (optionally) "conditions" ("gateways"). All these objects are similar in both EPC and BPMN (boxes, lines and squares), and hence it is possible to define similar (almost identical) basic flows in both modeltypes. Obviously there are a number of differences too. For example: EPC supports "states". I have seen several EPC-s in my past. Seldom I saw any additional value in the states used. In most diagrams they just reflected the result of the preceeding activity (E.g. If the activity was "submit order" the resulting state was "Order is submitted"). I would say that most business users are pretty capable of making up such a resulting state themselves. (The use of states may even blurr the process). And if really required, BPMN allows to use a dummy activity to reflect a state. (Most BPMN tools even allow you to assign a separate color to make a visual distinction). Another difference is that EPC provides a number of special symbols (stereotypes), e.g. User, Location, Entity, Risk or Document. These symbols may be linked to activities or states to provide additional semantical information, and represented with a specific look (symbol/colour). In BPMN it is perfectly possible to link "annotations" (or even dummy activities if you like) that have no specific semantical meaning but in analytical models definitly could be used as such. (In the required colour!) Besides that, I consider BPMN swimlanes way more more informative than the User-symbol in EPC. Hence, I believe it is possible to define a similar models in BPMN as the ones in EPC with comparible semantical value and understanding of the business, without real restrictions and without significant additional effort. Another argument mentioned is that BPMN is too strict: I believe that EPC (if not used for defining formal models) indeed has a more free format. There are two defenses in favor of BPMN First: when using BPMN for analytical purposes the complex constructs of BPMN should not be used in the first place! It just takes activities and connectors (and optionally gateways) to define a high/level analytical model. The only syntax restrictions of BPMN are that all symbols are connected, exactly one starting event exists (and some gateway-types may have some restrictions on incoming/outgoing connectors). If these limitations are too "strict" for certain modelers, than I would suggest a free format drawing tool. Secondly: In analysis phase syntax errors are imho not a real issue: Most BPMS-s supporting BPMN allow to freely define and distribute designs even with BPMN "syntax errors". Just as long as you not try to validate, build or deploy the model there is no issue It is clear that I speak from an BPMN background. So I am very interested to hear what I may have forgotten to take into account when defending BPMN.
Let me first say that neither EPC nor BPMN can be called a Process Model in a wide meaning of this term. As we know Process Model consists of several perspectives. A Behavioral perspective answers a question “how a company perform operations?” EPC is not intended to model a behavior, it does not include all necessary information: like time and some more. Moreover, EPC usually includes only the most likely routes and skip non standard paths and exceptions. It describes a use case. Let us recall the original scenario of EPC usage. We move along process route marking functions encountered on the way. Then we analyze all processes, extract functions in order to build a function catalog. No need to go all ways, but must pass all the functions. So EPC is a tool for Functional Modeling, used for composition, when we build a model bottom up. Please compare EPC with a FFBD. They are similar despite all EPC extensions. FFBD is a functional diagram, why should we call EPC a process one? EPC is extremely flexible and some people decided to use it for workflow diagrams. I also use it, but only for sketching, because EPC do not guaranty a result. Have you ever transform EPC diagram in to executable form? Technically it works fine, we did it 5 years ago fist exporting to XPDL then importing in BPM. Transformation works but processes not. All EPC processes that we transformed could not be started without drastic redesign. In some cases it was easier to redraw them from scratch. It happens so because EPC is extremely flexible and allows many diagramming techniques. Flexibility should be limited by methodology. Some people mix SADT and IDEF0. Both are necessary. You cannot model IDEF0 without SADT. But where is a methodology for process modeling. Neither ARIS nor BPMN have modeling methodology? As a result we model workflow based on possibilities provided by the notation. BPMN does not have a methodology as well, but you immediately see that your process can not be executed. With EPC you find it too late. Summing up. EPC is a tool for functional diagramming that is adapted to be used for workflow sketching, but author take all risks that a final model can look and behave in a different way. You should decide: take a risk or not. There is a need for methodology of process modeling. As process model includes several perspectives. Methodology should cover all of them not limiting to behavioral component. Best regards, Igor
That's it. This is our common space of mutual understanding. Event though I am not a big fan of mixing modeling conventions in the course of a project, your "EPC-is-a-toy-for-boys" view makes mi think you are completely right. I couldn't agree more with you.
Well, to be honest, I prefer BPMN. For me EPC symbols are something like toys for boys. But I must to admit that EPC diagrams are better for publishing purpouses, because of possibility of mixing EPC with FAD, PCD and so on. More relaxed rules means more unconstrained communication. And sometimes it's better to have more communicative notation (EPC, Aris "house" and so on) for business people, and another notation (BPMN) for development./deployment purpouses.
I still can't get your point, however I do thank you for your attempt to elucidate your view on this particular semantic difference between semantics and syntax that almost every customer is constantly asking about...OK, let me be more serious. What is the use of having a language that is allegedly a semantically rich (you said that), but at the same time is incapable of constructing complex workflow patterns? Imagine you are having hundreds of available words, and aren’t able to express more than just a few sentences with these words. Last thing. I wouldn’t be so sure to equal the great number of EPC symbols with a richness of meaning. [Updated on 3/6/2011 9:09 AM]
Mike, there are two words: the syntax and the semantic. A rich semantic means a lot of "symbols/words" like in EPC, and a rich "syntax" means a lot of grammar constuctions like in BPMN.
Correct me if I am wrong, but I am afraid I can't join a club of those members of BPM world who claim EPC are semantically much richer than BPMN. Never before have I heard nor seen such a misstatement. Show me please any sort of EPC-like roll-back, interruption of running tasks or race-condition, not to mention all-or-nothing performance. If that's too hard to make it out in EPC, maybe you try to figure out how to show an ordinary DELAY - a process just stoppped and it's doing nothing but waiting.
We find that our business users are happier with BPMN and are, therefore, much more likely to use our modeling tool. Feedback received from our end users regarding EPC notation led us to our hybrid approach. We are using a limited set of BPMN-like notation in ARIS, changing the appearance of EPC objects. With this blend, we are getting better traction with the business. That said, we are still in very early days, so this may evolve further.
Most important difference between EPC and BPMN is the "motivation". EPC was created to model and analysis of business processes. BPMN was created to model, analysis and __deploy__ processes. So, if you are going to create an executable process, the BPMN notation is better choice, because you are using one notation for analytical and deploy models. It is true that EPC diagrams are semantically much richer than BPMN. But EPC diagrams also are less strict. On the other hand, the information systems are very strict... In other words, it's easier to model business reality with EPC (because of it's relaxed grammar), but it's easier to model executable processes with BPMN (because of it's strict grammar). Especially with BPMN __2.0__.
I second both previous opinions. We also produced good results by capturing requirements and defining TO-BE processes using EPCs (ARIS platform), equipping them with BPMN attributes (had to use custom attributes) and deploying them on EMC Documentum platform using third party solution (deployment was done in one day after process definition workshop with users).
I do not believe an either/or situation is relevant. When talking about solutioning, the truth is that one needs the ability to capture "required capabilities" that drive business processes, and require the capturing of requirements (business, technical, operational) in order to produce solutions that meet those needs. Until we have tools that fully embrace the multiple facets of Requirements Management (Capability, Process, Requirements) our best approach has been to use EPC at the higher levels where the discussion is predominantly a business one, through to the lower executable levels where the discussion is predominantly IT-centric and BPMN is currently more appropriate (even switching to runtime BPEL, although perhaps that won't be necessary much longer). Our corporation is implementing solutions that allow us to physically associate knowledge from these various perspectives with actual runtime solutions - believing this approach is the best way to ensure enterprise level solution governance, that practically transcends discussion around Business/IT alignment. Stop the talk, help make it practical. In our case this requires three different vendor products, and some homegrown magic - but it is quite doable. To the question whether BPMN will replace EPC - I think that is the wrong question - perhaps the right question is which is more appropriate where. In my opinion, the ideal is a notation(s) that accounts for the information that is required, at all levels from concept to implementation.
My two cents: I believe EPC and BPMN are largely complementary to each other because they serve different purposes. EPC diagrams are semantically much richer than BPMN and allow many different viewpoints and concerns to be explicitly modeled, rather than just added as comments (e.g., Process Controls, PPI's). Also EPC diagrams are much better in discussion with business people. The rigour and general formal "wordiness" of BPMN at level 2 modeling makes it less effective as a communication tool. SAP is indeed moving their detailed process modeling to BPMN, ao we can expect a sharp increase in the use of BPMN modeling in SAP projects, especially if the upcoming Business Process Library in Solution Manager delivers on its intentions. In the (NetWeaver) BPM projects we have done as a company the experience is that BPMN remains at this time primarily a graphical developer programming language, with the use as a business modeling tool coming second on all counts. cheers Hans
|
||
|
