Hi ARIS community,
I'm a bit wondering how you model timelines resp. timer events in EPCs.
Like in the follwoing use cases where you have a sequence of activities and in the middle of your process you are dependant on a "timer event", like:
1. you can only proceed after a wait time of X days/weeks/months/etc.
2. a specific task must be completed in x days/weeks/months/etc.
3. a specific task can only be executed in a specific time frame (e.g.: from 10pm to 3am)
Looking forward to your feedback.
Best,
Veronika
Hello Veronika,
ad 1.) in EPC there is no such thing as the timer event in BPMN. An event is always a point in time. So here you would have to model an activity "Wait 3 weeks".
ad 2.) This is an XOR decision:
- Event "Activity X completed" (or some sensible description of the positive outcome),
- Event "due date for X passed".
ad 3.) Normally you would not care about such time frames, unless you want to model this for simulations.
EDIT: I think in simulations you would model such a timeframe as availability of the resource executing the step.
Hi M. Zschuckelt,
Thanks for your feedback :)
Bug, I disagree with your first point as there is a dedicated symbol available (see below).
To your suggestion under 1: I would also argue that you can put an event and say: "3 weeks waiting time completed" and connect it to the subsequent function with an AND connector.
to 2: why not using risks for that purpose?
to 3: I disagree with that- because, if I want to train people on the process, they also need to know about such dependencies. For some processes these time events are crucial and putting them into a description only, is, to my understanding insuffcient.
Does that help? So, any suggestion or pro and con overview is appreciated.
Best,
Veronika
Unfortunately your image was not attached. Anyway, it's up to you to add it to your method and interpret it that way. If it is useful for you, then do it.
ad 2: The question is, what happens, if the desired schedule is violated: Is there a consequence for the process? If it is merely an escalation, you might also put a Control there (which is a function and can describe the escalation procedure, this would keep the main process lean). If it has other consequences for your process to miss the deadline at that point (e. g. the RFP deadline is over and you need not continue), I'd say it is a decision not to have performed. Risks are always good, but do not answer the question on the EPC flow. They are only satellites.
ad 3: How about documenting the needed time window on the preceding event? Like "Preceding activity completed and it's between 11h and 14h". This way it's very illustrative for your trainees. Or you maintain this time window on a dedicated attribute of the Activity and show that in the model graphic with an attribute occurrence?
Hi,
Thanks for the info with the picture- it should now be visible to you.
No. 2: I was also thinking about controls, but since there is no real process behind it, I have a hard time to argue (with myself) that it is a control. And in fact, I don't really like the risks as well, because the timer event is no real risk- the result of not having it completed in due time would be a risk...
No. 3: That is mainly what we currently do: we have a separate event that is connected with an AND- so, only if the previsous activity passed and the event took place, then the next process step can continue.
Maintaining such information in a separately placed attribute is also an option (we just have quite a number of placements around it, so I need to be careful with that- but a good idea!).
Best,
Veronika
You should make a good guess, how many people in your organization actually look at the models. If you present your process nicely on the steps view with some nicely configured fact sheets it may not be so important, if you find a spot for yet another attribute occurrence in the model.
EDIT: another thought on the time window: If the schedule is imposed externally (e. g. trading hours of a stock market), the time would be a property of the activity. If the schedule is internal, e. g. the resource performing the step is working part-time, I would see this as an attribute of the performing resource. However, that is difficult to attribute to the process at all, assuming you are modelling roles and the people (or positions) performing in roles might work part-time. So considering all that it would be a process decision again to provide a service (performing certain activities) only during certain hours in order to enable part-time work. -> that brings me to yet another thought: Services. They are a composite object of utility (function) and warranty (QoS). The availability schedule of the service would be part of the QoS. You could use the Service as a resource for performing in the process. But now I'm introducing yet another object type, for which you need a Service Architect to own it.
Risks are for the risk manager. If she is your stakeholder, involve her, what she sees as risks. Having documented processes is an excellent opportunity for the risk manager to identify and own many risks. If the risk manager is not your stakeholder (yet), there is not much point modelling risks. You need a well-defined owner for every single item that is modelled. You might take a look at ARIS Risk and Compliance Manager component in order to become more attractive for the risk manager.
As you can see, there is always potential to introduce more abstractions in order to accomodate more stakeholders with their views in an Enterprise Management System. They all come together on the process in the end. So the art is to find the compromise that suits your organisation. If you do not think in services and don't have a service architecture discipline, don't start modelling services (unless you are founding that discipline). If you do not have a risk manager you can involve, there is no point modelling risks (unless you want to make a point about the importance of risk management). Document the bare necessities on the process artefacts. And if that becomes too complex, or the process owners do not want to own everything you document there, you need to expand your method with the new owner's objects.
