AU
Hi,
We were using Organization Library, Document Library and Application System library. But now we realised that our process model's activities (functions) are not standard. As we have so many Designers (63 person), they wrote various verbs into functions. Does anyone use function library for this reason? Also object library is reasonable for a systematic modeling? For example: Function : ''Change customer order'' we want to make two library . One of them include the verbs for example 'change' . and one of them include the object for example ''customer order'' . And we will merge this two parts and make a sentence.
Do you think this is possible to define every object and function on ARIS? and if it is possible in which way we will merge this two object while modeling?
Hello Ayca,
I have no objections to an activity "Change customer order". That is good practice. As for the "objects". Model them as satellites. So for the "customer order" you would use a Cluster symbol (Cluster/data model object). We call these "business objects" in colloquial terms. You would model the satellite with the relations "customer order" "is input for" "Change customer order" and "Change customer order" "has as output" "customer order". As you can see, the business object "customer order" is input and output of "change customer order". This is all the detail I would want to see in the EPC. "Customer order" bears the value creation.
The business objects should be governed in a library of their own. Resist the temptation to model the states of the business objects in the EPC. So don't use "received customer order", "validated customer order", "changed customer order" etc.
If you want to have a model of the states of the business objects, create a custom symbol based on the Cluster/data model object type and assemble the state objects in a separate model per object (maybe box-in-box modelling?), which would be governed in the library as well. In order to indicate the change of state of the business object, assign the states to the activity in a function allocation diagram of the activity as input and output, if you desire so.
You can use dedicated models for the business objects (eERM) also to collect attributes of these business objects, while you design your process. Use the symbol d-Attribute (ERM attribute object type) for this. This way you get a clear idea, what information you are dealing with in your process. Please note, that business objects do not adhere to any normalized form of data modelling. Merely they are collections of attributes and other business objects that you need in the context of a particular process. Having said that, you may even consider governing the business objects in the vicinity of each particular process the business objects occur in - instead of a central library.
If you model the d-Attributes for the business objects, you get the "raw material" for an object modelling effort. But that is another intensive discussion how to do that well and I got carried away...
So last thing is the question of function/activity libraries: A big NO!
Never reuse functions in multiple EPCs. They are not the same, even if you don't find different names for them. The thing to be done in a particular activity differs in different processes, otherwise you wouldn't have different processes. Activities are the meeting point of predecessors, successors, events raised, objects used and acted upon (value creation), roles performing, IT systems used, skills or capabilities required and whatever you may choose to model according to your meta model. If you want to write a description for the presumably equal activities in different processes you are very likely to discover that you want to describe different things in each process. So that is the final blow for the reuse of activities.
Regards, M. Zschuckelt
Hello M. Zschuckelt,
Thanks for the nice post. I had a question on the change of state of a BO being depicted on a EPC. I agree with your comments above, but is it ok if we model the CRUD relationship between the process/activity and the BO on the EPC.
Regards, Bharat Bajaj
Hello Bharat,
yes it is a good idea to enrich your modelling with create and delete relationships, beyond the "is input for" and "has as output", that I mentioned.
Here is another idea: You might use matrix models and put on one axis the functions of your process and the business objects (or even ERM attributes in hierarchy with the business objects) on the other. If you arrange the functions in the order of occurrence you may get a good overview, if you created the object before you read it. If you work on attribute level and an attribute occurs in multiple business objects, place the identical ERM attribute multiple times on the object axis to each business object. Since it is the same attribute definition, connections you make on one occurrence will immediately show also on the other.
There is a feature to work with more than two types of relationships in matrix models: When you open the "Contents" pane, select the tab "Connection types" you can add an abbreviation letter in the "Ab..." column on the right. You could choose c, r, u, d for the connection types you use for that and these letters will show in the matrix cells, where such connections exist. Even multiple connections will all be shown that way.
Regards, M. Zschuckelt
