RP
Good morning,
We are considering the possibility to migrating our business-focused modelling to BPMN, in order to satisfy a number of requirements surrounding clarity and ease of use, as well as to model some of our more complex scenarios (exception flows and timed events, which are a key pain point today).
Our business users are quite familiar with similar (visually) process diagrams (in Visio, unfortunately), and are quite uncomfortable with the EPC notation; the modeling we have done in EPC is not very complete at this point, and most of the work to model the business remains to be done. Those models which are complete are often "converted" into Visio diagrams (non-EPC; Flow Chart) before being used for our operations and training.
As part of our assessment, we are looking for the experience of other companies in making this change. The initial option that we have identified is to use BPMN for the process, and to enrich it by attaching the application, role, and kpi objects in a Matrix model.
Any experiences regarding the transition, or challenges faced after making it, would be appreciated.
Rob Potter
Loblaw Companies Limited
-- Follow Up --
Can anyone help me clarify how ARIS uses Data Object vs. Data Store? It appears that Business Information Object in EPC is being converted to Data Object; this doesn't seem to line up with the spec (it should be a Data Store, I think). Any clarification?
Hi,
Here is what I can share.
First of all the difference between a Data Object and a Data Store is a problem of lifespan. A Data Object exists only during the execution of the process like local data in a program. A Data Store represents permanent data available before the process started or after the process terminated, like data stored in a database.
Recently during a large project, we had to translate about 120 EPC's into BPMN models. Here are two or three lessons learned:
First the way of thinking between EPC and BPMN is slightly different. For instance, we have found many unneccessary intermediate events in the BPMN models which were the equivalent (i.e. direct translation) of the events in the EPC. But they did not make any sense in the BPMN models. It's something business modelers have to learn: an other way of thinking.
The BPMN models focus more on the sequence logic. Even though you have the lane to represent who's doing what, the data objects and data stores, it's a bit more focused than EPC. As a consequence, you have a more detailed process in BPMN but you need another model on the side such an Function Allocation Diagram to represent all surrounding items related to tasks. EPC offered a little bit more capabilities ina single model. And by experience, I know that users like to have everything on a single page.
In general BPMN is more compex than EPC. But do not trust consultants saying that BPMN is for IT while EPC if or business. BPMN is rather a bridge between business and IT. A common notation to express general views or retailed views. Unfortunately, if EPC can be learned on the job, it's better to have a real training before starting BPMN. I am in favor of internal trainings so you can present both BPMN theory and your own company guidelines and recommendation in the same class.
Hope it helped.
Patrick
Hi Patrick,
Thanks for the info; a few follow ups, if that's ok:
1) Our business users aren't comfortable with EPC at all - BPMN is visually and conceptually quite similar to what they've done in past (mapped processes in Visio).
I've definitely found that EPC events are often non-sensical in BPMN, so for the models completed in EPC there is some work to convert; that said, our business (with some exceptions) don't understand the EPC way of thinking.
Would you expect the same learning curve, if the business users were not EPC users?
2) Our expectation was to use a "matrix" if we go to BPMN. Currently, we use RACI and other matrix-type representations. One of the key issues our community has is the "clutter" in EPC.
Which elements have you found to be challenging on a second page? My current thought is to use Collaboration diagrams, with Pools mapped to user roles and Lanes mapped to systems.
3) Interesting that you would suggest the BPMN was for IT; EPC (in this context) has been fairly solidly rejected by the Business, and they've shown a significant preference for the BPMN modelling examples.
EPC, here, has not been able to be learned on the job; most users learned the "traditional" process flows on the job, which translate to BPMN quite easily (less restrictive, but still similar).
Any other thoughts or clarifications would be appreciated. Thanks again.
Hi Rob,
You made a good point here referring to business not adoptiong EPC notation and easily understanding the BPMN notation. My experience is that BPMN provides a traditional workflow modelling view hence easier to understnad and ease of acceptance. The root problem here is the modelling vs creating a picture which I called mapping. I don't think people get this difference and hance difficulty in understanding and accepting the logical modelling construct.
I am also in the same journey as you where we are working through implementing BPMN as a modelling standard slowly diverging from our legacy EPC notation. Some of the challanges I am working through are conversion, represenation of data in two different models (EPC vs BPMN), selection of models types available for BPMN in ARIS and learning.
Lets keep posting.
Regards,
Rupesh
Thanks Rupesh - sounds like a bit of a different journey, since we have a very limited scope to our EPC.
The challenge between "Model" and "Picture" is huge - it is a bit abstract, but once it lands I think people will see a huge value in it.
In terms of diverging, have you had any issues with integrating the EPC and BPMN?
My initial experience is that the two are fairly compatible in ARIS (BPMN 2.0 only); events and roles can be interchanged. The only challenge I've had is Data Object vs. Data Store.
Strategically, I am thinking that the easiest solution is a soft transition - start doing BPMN going forward, and update the EPCs to BPMN next time we change them. Once we are on 7.2, we might decide to mass-convert, assuming it works smoothly.
Regarding BPMN model types, I was intending to begin with only "BPMN Collaboration", as it seems to capture all of the BPMN Process elements, and includes better support for the Pool / Lane (we are big on integration here); that way, users don't need to worry about selecting the model type.
How are you lining users up to model types?
Rob,
I can also fully agree with your point of view. Like you, we do have some processes modelled in Visio using a classical flowchart notation. Migrating these processes to BPMN is quite natural. I meant that for users with no process modeling experience at all, the EPC approach is more affordable. Now for the others, using BPMN correctly (which is something ARIS fortunately helps you to do) is relatively more difficult than gentle flow charting in Visio. The BPMN grammar is far more precise and it will require extra thinking. But that also means creating value...
Here, we use the Function allocation diagram to connect various artifacts to task and processes, mainly: persons, organizational unit, groups, input documents, output documents, documented knowledge, skills, application system types, KPI instances,... But all other approach is acceptable. My advise is that you just pick the easiest and fastest one. In my view, matrix migh be quick for capture but lack necessary clarity for maintenance. At the moment, my users find that FAD is a bit "heavy", especially when you have to make one per task.
About pools and lanes. Indeed, pools and lanes already indicate who is executing a task. And application systems can very well be modelled as a pool or a lane. But when to use a pool or a lane? I have to recognize that it's the very first question that BPMN beginners are raising. And there are logical rules to answer that questions. I encourage you to read the book "BPMN Method & Style" written by Bruce Silver.
Should we model all application systems as lanes? In my view, no. When an application system simply "supports" a task, it's better to define the link in a FAD, a matrix, or whatever. This is usually sufficient. But when an application system plays an active role in a process like a workflow engine, an automated set of activities, then use a pool or lane. The semantic difference between the 2 situations described here is the following: if the application supports only the task themselves link them in a separate model. It the application supports the tasks AND the sequencing between the tasks (including forks and joins), model that application system as a pool or a lane.
Of course, all that are just advises. I am no guru...
Patrick
Thanks Patrick. We are struggling to balance the needs of our training, IT, and Process teams - it is challenging to get a view that is clear for execution, and also provides for the needs of our users in training.
The other challenge is to ensure standardization - I think your idea makes sense, but it is a bit subjective for us (we have more than 100 people who will need to work with the rules, so it needs to be a pretty easy test).
Have you tried using the "depicts" relationship in ARIS for the pool and lane?
I was thinking that we would use the Pool for the organizational entity, and lanes within the pool for the systems - my primary concern is whether the "Belongs to" relationship between the user and application ill impact reporting.
My concern with FAD is as you described - heavy to do for each task. I think Matrix will probably capture what I need, or possible using FAD for the higher level process if it is not cross-functional (i.e. "Send Order" might have multiple steps, but is entirely owned by Role A, in Application B.; so I could use a FAD for "Send Order", and not each atomic task.).
For Automation, I was intending to use the "Automation User" as a pool; that way, we can see all of the automation together, across systems, and see that hand off between users and system processes.
