CJ
Hi,
I am new to EPC and am struggling with a few of the basics. One thing I would like to represent is the artefacts produced by a function. I have managed to do this with a 'Document' object, but an unsure if this is correct syntax (especially as a number of the artefacts are not actually documents). A specific problem I have with the document object is that I need to create a hierarchy of them and ARIS doesn't seem to let me do that.
For example, I would like a function (produce test strategy) which produces an artefact (test suite) and a function (test planning) which produces an artefact (test case). I would then like test suite to aggregate test case, so that test cases are children of test suites. Neither of these are acutally documents, but ignoring that schemantic the 'document' type works ok for this. The problem is that ARIS won't let me create aggregation/composition relationships between these documents.
Please could someone point me in the right direction here?
On a related note, one thing which would help is the language specification for EPC. ArchiMate, UML, BPMN, etc... all have published language specifications, but I cannot find anything for EPC. Does a specification exist for the language anywhere?
Many thanks!
Hello,
There is no language specification for EPCs. There are basically 2 well established variants how to model the control flow of an EPC ("strict" with trivial events and "casual" without them) and how to link EPCs through process interfaces, which are supported by the tool. Furthermore each step should be "carried out" (connection type) by some entity from the organization view of the ARIS house (most common is "role", but also "position" or "org. unit" and some others are used occasionally). That is usually considered as the core of EPC.
Beyond that each organization defines for itself, which extensions are useful to model to reach the goals of the modelling effort and deliver value to the stakeholders (whoever they are). With those extensions you call it an "extended EPC" or eEPC. You can link virtually any resource from the ARIS house to the process, because the process is the business. Because the goals of the modelling effort are different at every organization, it would not make sense to prescribe a specification. There are "good practices". If they are "best practices" depends on your point of view.
So yes, first thing is analyzing who the stakeholders are and what their needs are. Derive what is to be modelled from that and get a good grip on your terminology. Then find a "good mapping" to the ARIS terminology. For example most ARIS consultants have a clear idea what a "capability" object should be used for, but in the real world that term is sometimes also used for some other concepts which map to different object types in ARIS. This is just one example of many. Only with a "good mapping" you will be successful in linking other views of the ARIS house sensibly. The ARIS method help makes a lot of suggestions.
So here are some suggestions coming to my mind when I read your description:
You are looking for an object showing what is being "produced" by a process step. One obvious candidate is "Product/Service". In fact each state of your generated value can be understood as an intermediate product or service. There is a symbol "Object state" for the "Product/Service" object type, which could be useful here, because you probably want to reserve the term "Product" for your final products at the end of the process.
If you document every object state this becomes very tedious to manage, because there may be quite a lot of them. For example in a car manufacturing shop floor there may be more than sixty stations after each of which the car is in a new object state. If that is useful to you, you can do that. If it is sufficient for you to know that you are working on a car I suggest a stateless object to be used on every step: Cluster/data model. You can assign that object with an IE data model and model your (stateless) aggregation there. This way you collect the pieces being assembled - for the test suite in your case - in the IE data model. And you don't do it more than sixty times, but once. So your "test suite" object (of type Cluster/data model) to be produced by your process would be both input and output to every process step. This sounds a bit boring to model and read, but I am sure you will come to points in your process, where you decide that something else is happening at the same time, which you don't consider part of your "test suite" product.
IE data models are your entry point to the Information view of the ARIS house. Clusters are stateless, aggregated, non-normalized, generally process-specific objects, but as you detail them, you will get the raw material for sorting things into normalized data modelling which in turn will be a starting point for your data architects. With some governance considerations you may come to the conclusion, that your aggregation details stay with you, but should be mapped to the artefacts in the data architects' domain. You will select or create suitable models to do that mapping.
Document objects: Use them for actual "documentation" in some medial form. They might be used as representatives of actual documents in your ARIS Document Storage or Sharepoint(TM) repository. Link them to those documents and your readers find additional documentation, work instructions etc. linked to the processes where you need them, accessible with a mouse-click.
