How to use Process Interface Properly?

Hi Weerakhan,

Let me try to ans your questions one by one:

1). Yes, multiple events can trigger a process interface as you have modeled in option 1 and 2. In that case both option 1 and 2 is logically correct, but since use of OR rule is justified (option 2), you can avoid of creating an occurence copy of Process Interface Object.

2). You can 't use Process Interface to connect process at different levels. Process Interface is simply an interface to a process, it does not have any information  that you can use to take a decision that to which level it should connect in the process. I think better we'll use function to do the same.

3). Yes, an event can triggers more than one process interfaces. The very same logic sometimes we used to implement Spin-off or Split-Join the processes.

Regards

Parveen

I believe (would ask someone with Simulation expertise to confirm) that only option 1 will work in a Simulation.  My models were a combination of both scenarios and suggestion was to go to option 1.

thanks

donald

Hi there,

I have another question. Do we have to use a logical connector to join an event to two or more processes interfaces?

Thanks

The process interface is a function object.  The rules in your method filter dictate what you should do.

Many Thanks to Parveen and Donald.

I have another question. If process interface should not be used for different process levels, it means that a process interface must not be sandwiched by two events. That is

Event --> Process Interface --> Event

Choice can only be

1) Process Interface --> Event, or

2) Event --> Process Interface.

I think its not like that.

As per my understanding a process interface can be sandwiched by two events. The only thing you should not use decision gateway (OR or XOR rule) after the process interface object.

e.g. A long business process can be splitted into small-small process. To complete the end to end scenario we are using process interface object to link up i.e. Process A (......Event----> Process Interface to process B) .....Process B(Process Interface to A----> Event.......).

hope my understanding is correct.

Regards

Parveen

Dear Parveen,

I think my question may not be so clear. Is it possible to have the following situation in a same model?

Event X --> Process Interface to Process B --> Event Y

The example you gave would be

in model of Process A ( Event --> Process Interface to process B)

in another model of Process B (Process Interface to Process A --> Event)

Many Thanks,

 Hi Weerakhan,

Since Process Interface is type of function object only, I think there is nothing wrong of using Process Interface between two Events. In a model you can very much use process interface object like Event X --> Process Interface to Process B --> Event Y.

If in a Process you want to process any operation in a sub process, you can very much use your logic. The very same thing comes out very helpful to reduce the complexities of your processes sometimes.

Hope I am making some sense here.

Regards

Parveen

Hi,

a process interface should occur at the beginning or end of a process.

It should not occur between any events.

Basically process interfaces are used to

• represent upstream or downstream processes
• Navigate to upstream or downstream processes directly from an epc (by opening the assigned model)

Following you can find an example how to properly use process interfaces. The dotted lines mean that we reuse objects (with the same or other symbols).

In our example we have a value-added chain diagram (process level n) with a sequence of three functions. Each function has an assignment to an epc (process level n+1).

Imagine one opens the assignment of 'P1'. He studies the process and wants to know how the end-to-end process is defined. Without using process interfaces you would switch back to the vacd and open the assignment of the second function.

By using a process inteface, you give the user directly the possibility to switch to the assignment of the next step defined in process level n.

Let's take it a level further:

On the next figure you can see on the left side the process assigned to the function 'P1' defined in the VACD. The function 'F1' has an assignment to a process on level n+2. And also here we can use a process interface to ease navigation.

I think process interfaces are one of the most used and most misunderstood concepts in ARIS :)

Cheers

Jens

oooooopppssssssss...!!

Thank you so much Jans, for such an important clarification.

You have very well addressed the issue. I was mistaken by the word "Interface". In a typical scenario there is no such limitation of using an interface in a process.

Once again thanks for correction.

Cheers

Parveen

 Hi,

Is it logically Correct to connect two process interfaces to each other.

Example: At a process termination, there are two process interfaces connected serially, as shown in the image below.

The idea is that in this particular process after Function B, Process1 (represented by Process interface 1) needs to be completed and then Process2 (represented by Process Interface 2) needs to be completed.

Generally, process 1 can be invoked from many other processes and its not necessary that whenever process 1 is executed, process 2 has to be executed at its end. So, process 2 interface is not modeled in Process 1. How ever in this particular process, first process1 has to be completed and then process 2 has to be completed. Considering this, is this representation correct, semantically and otherwise?

Thanks.

Hello Rahul, your example as modelled should be considered as incorrect:-

Activity B triggers Event B. You navigate to the Model represented by PI 1 to process the Event B. This is a Model in itself with Events and Functions as well as leading into the Model represented by PI2. If we took this approach to the extreme we could also model PI 3 PI 4 and so on - infact why not model the functions and events as a PI - Now think about what you have modelled - a Value Chain Representation in an epc model!!

The correct use of PI was highlighted above by Jens. I recommend that this approach is followed.

Regards

Jens, thank you for this timely comment on the art of the PI. I agree entirely with your comments here but have noticed that in some IDS publications where screen shots of models have been presented that occasionally PI are embedded within models sandwiched between Events. I'm personally of the view that this is incorrect and can only assume that this practice has slipped into common use through misunderstanding. However, I wonder what hope we mere mortals have when IDS Consultants condone this style of modelling.

Regards

However, I wonder what hope we mere mortals have when IDS Consultants condone this style of modelling.

No one said BPM is easy :)

No I am just kidding. So I think also an IDS consultant makes a mistake.

But on the other hand this is also a real strength of ARIS and the epc: Even if you misuse some objects, most people will still be able to read and understand your processes :)

Regards

Jens

Jens,

I disagree with your information about the use of process interfaces.  We successfully use embedded process interfaces in our epcs.  example: we have many processes that call the 'credit check' process (sales, purchasing, operations, etc)  these process executors do not care how the credit check is done.  We simply embed the credit check process interface in these processes (with occurrence copies of events and assignments, etc) and then we can continue with our process based on the results of the 'credit check'

thanks

dhd

Donald,

I can understand your motivation for using the process interface in the way you describe it.

But as mentioned in my post before, the semantics of the "process interface" symbol in ARIS is not the one

as you describe it. In a nutshell the process interface is a way to ease navigation.

I think you are heading more towards a service-oriented way of modelling processes.

While modeling a function you are looking for a provider which offers certain capabilities - for instance purchase operations, etc. How the provider is internally offering this service doesn't matter from a consumer perspective as long as it fullfills the defined contract.

With ARIS 7.1 the tool was extended by a complete SOA methodology. We introduces service types/business services that can support steps in an epc. These business service can have different realizations for instance a software service, but also a process is a possible realization.

Regards

Jens

Jens,

I have to dig through old presentations for proof,but I am fairly confident that Dr Scheer (2007) presented embedded process interfaces as a way of modeling.  My boss brought back the presentations and explained it like an accordion...process is same level of detail but the PIs let you compact the process and the alternative view would be to embed all of the process steps into the model.  I do not want my operations guys to know (and they do not care) how a credit check is done, they need to know the trigger and end events and that a credit check is done here and how their process will handle the different results.  If the credit check process changes, their vendor selection process does not change.

thanks

dhd

Dear Users,

I am also a little bit confused about the whole process interface thing... basically I would like to connect two seperated event-driven process chains to one large process.

As you already explained, I should proceed like this:

Process 1: Event ---> Process interface 2

Process 2: Process Interface 1 ---> Event

So far so good. But, do these process interfaces need any assignments of the other process? I think so, otherwise the process interfaces don't really know where they belong to, am I right?

Thank you very much for your help!

@Markus:

For what you describe, you don't need a process interface. Process 1 ends with an event. You use the same event as start event in Process 2. In that way, both processes are connected conceptually, because the second process is triggered when the first process ends.

@Donald:

It might be that there are presentations showing wrong usage of process interfaces. Jens just described the real definition of process interfaces. I think in your case you don't need a process interface. Just add an assignment to the business function in your parent process. In that assignment, you describe the sub-process. Process interfaces just make process models more complex by introducing yet another icon, which is, basically, redundant.

Dear Sebastian,

But what's the idea behind process interfaces then? I thought it's the right way to connect seperated processes horizontally, I think that's what I want to do. Of course I am happy to hear from you that I don't really need it ;-)

But if I would do it your way, I definitely need the same event in both event-driven process chains, is that right?

In order to simulate both processes, I simply start the first process and activate the checkbox "Models which access shared control flow objects, up to recursion depth", right? Recursion depth is "1", right?

Thank you very much for your quick reply!

Hi Markus,

I hope I haven't created more confusion ;-) Please scroll up and read what Jens has written. He also got a picture describing the "official" usage of process interfaces.

Yes, you would reuse the event in different processes to connect them. This comes in handy, because you can use the "occurences" tab in the attribute window to see in which processes the event is used.

About simulation: I'm not the simulation expert, but I would expect that it works as you described.

Thank you very much Sebastian, you saved my day :-)

Hi Donald,

I'm totally fine if you use the PI for the purpose you described. But as you mention yourself this is not the meaning of a PI. You could also just use an ordinary function with a different color to express the same thing.

I also have a question regarding PI's. In our business you often need to perform a number of work precautions before you can start the actual job. These work precautions are described in the "work execution" process and is often linked to via PI's from other processes.

I have tried  to illustrate the issue (in a simplified version) in the below picture. Process 1 and 2 has a sequense of three functions, and each function has an assignment to an epc (process level n+1). In process 1 A1 you need to visit Process 2 B1 in order to get the right work permitions etc. to perform the actual job. When these permits etc. are in place you go back to Process 1 A1 and finish the process.

Am I totally off with my modeling here or how would you model a my issue?

Kind regards

Jakob

Hi Jakob,

Good to see you bring this up -- We also have a similar scenario and our Process Owner has so far not agreed to our recommendation of breaking up "Process 1 A1" into 2 subprocesses wherein the first such process is the predecessor for "Process 2 B1" and "Process 2 B3" is the predecessor for "Process 1 A2". Have you also rejected that option?

Would like to hear more on this from Jens, Sebastian, Donald and other experts...

Thanks & Regards,

Shankar

Nice topic. I really like to jump on this one. so important.

I think Jens examples are a bit too simple and do not represent the case where an epc can have disconnected flows inside the same diagram, like Process 1 A1 represented by Jacob.  If so, then, necessarily we can have different process interfaces calling flows from different events, and calling back.  I do have a lot of processes like this, for instance "Billing" receiving events from all the different cases where billing activities are needed.  And often these cases are disconnected (not the same process instance) from the others.   What is essential is to use the process interface always with one or several events (when several, we need a logical operator). 

I don't see an issue having a PI imbedded in a sequence of activities, as long as we have events before and after. However I strongly prefer a different writing. Taking last Donald's diagram, I would really  prefer to disconnect and repeat the PI as a parrallel flow, like below: 

For PI, we should never try to save on occurence copies: it is so important to see what the interfaces are, as it is always there that we have problems.  And stay consistent: all received events should be defined in the calling process (maybe a semantic check could help here).   

@Parveen: we can represent a process interface which connects in the middle of another process by simply connecting the triggering event to the part of the process that is involved in the flow.

That was my 10 cents advice...

Here a simplified example showing how we use process interfaces. 

If you have any comments, they are welcome.

@Sebastien: although you explained that the process interface symbol would be too complicated to use in Express, we are many people to miss it a lot !!   My respect to all of you guys. 

Best regards,

We are listening, just wait and see what is coming...

Hi there

What is used in BPMN in stead of Process interface?

@Bogi, BPMN doesn't know the concept of process interfaces, so you can (and should) use occurence copies of events to have (at least) the possibility to navigate via the occurences in the properties. Please have a look elsewhere in the BPMN group, this was discussed multiple times there.

I am using Process Interface to depict a subroutine or sub-process (as in BPMN)  (i.e. where I have a common - self-contained - routine shared by more than one EPC flowchart. This subroutine may be something elaborate done at another location or outsourced, or a more simple function like a Credit Limit Check . Before this PI object came into the EPC pallet I was using two objects overlapping each other  i.e. the event over the activity; this was a tip I got from another EPC advocate site when I first looked into the EPC method (not IDS Scheer, but unfortunately I can't find the reference I am looking for) .

I use EPC for modeling processes for Quality and Environmental systems; I would like to use BPMN but it is too complex for process owners and end-users to understand. I have been using many flowchart methods over the years (since 1974) and I find EPC one of the few models which can really be used to validate processes with the participants. 

I find this thread on 'politically/semantically correct' use of Process Interface perfectly illustrates why there is so much confusion about using this symbol. For practical purposes I think I will continue to use PI objects as I have been, whether I  ever come to understand what is the correct use of these or not..

I have read this whole toppic, but I am still confused.

What if you have multiple events after a activity who trigers more then one event. Each of the further processes are, for instance, very complex, and you dont want to show these parts of the process, but just the main stream. What can you do? Can someone help me with this?

Here my example for what I tried:

I quote from the following white paper:

Transformation from EPC to BPMN

Willi Tscheschner

Hasso-Plattner-Institute, Potsdam, Germany

willi.tscheschner@student.hpi.uni-potsdam.de

"A process link in EPC is used for splitting down the process into a sub-process

or to refer to a following process. In other words, process links can be used for

specialization of one process step or to link this process to a followed or previous

process. In BPMN there is a sub-process construct which is defined as the same.

There is an embedded sub-process and an independent sub-process [1]. Embed-

ded means that the sub-process is defined in the same scope, but specializes this

process step. Independent sub-process means that this sub-process refers to a

different process within a dierent scope. With both concepts, a process link

construct in EPC can be mapped to a sub-process in BPMN."

ARIS consultants seem to only support the link process to a followed or previous process (i.e. the PI object should only appear at top or bottom of any EPC, never in the middle of one). However, I have used the PI as our friend Willi has proposed.

A sub-routine or sub-process is represented as a Function with an assignment to the lower level model. It implies that the entire sub-process is completed and control returns back to the parent. By standard use in the ARIS method a Process Interface implies control passes to another process at the same level and never returns. Technically speaking the Process Interface is not necessary, you could just as easily check the occurrences of the event, but some find the visual reminder and quick link to be helpful. It serves to remind the reader in complex models of the preceding and/or following process.

I can understand why you might want to highlight "re-usable" processes but I don't think I would use process interfaces for that. I would choose to use color or perhaps an attribute symbol instead. (Not saying I'm right and anyone else is wrong, that would just be my choice.)

Obviously there are many people who use it in a non-stadard way, which is fine if that meets your purpose. Remeber that you will lose out on some ARIS functionality if you chose to do that. For instance you will not be able to use the standard semantic check for determining whether events are balanced between processes because it assumes you are using Process Interfaces according to the ARIS method. You may also experience problems with Simulation.

Dear All,

This seems to be an interesting discussion and I can find two different trends emerging. We were also concerned about representing the following scenario:

Event 1 -> Process Interface -> Event 2

We contaced Aris Global Support and received the following response:

Use Case 01:

Use Case 02:

Anosh - the feedback from IDS supports the earlier material also from IDS, so I don't see an issue. Of couse the IDS material works in the world of theory but when you actually move to the Real World some of their material starts to break down and other approaches fill the void.

From my experience, the PI Object can be used to represent many concepts

I have difficulties when a model has a PI within its body, as in this case;

In extreme instances I have seen multiple PIs strung together in this fashion representing that you you navigate to several models and then back again. When a PI is modelled like this, it makes it very difficult to determine that the lower level interfaces are modelled correctly.

In my role as Europe ARIS Lead at SABM I have insisted that all such interfaces are removed and any exceptions that we are unable to remove are modelled in this way:

This approach ensures the integrity of our Integrations across our database. 

Darren, I was also coming to the area of practical scenarios and Process Interface's usage in modeling Real World processes.

After further discussions with ARIS and some modeling followed by Semantic Checks in ARIS, we have been able to model our process as follows:

I do not find any harm in placing the interfaces between events, provided they are linked with proper events. I also believe this provides more flexibility in re-using the processes and linking the processes across the organization.

However, your expertise and any further comments are welcome specially with respect to Simulation, as I have not yet simulated most of such processes.

Regards,

Anosh

Could anybody tell me how linking of  process interfaces in eEPKs works? I would like to link different processes with each other, so by clicking on one process interface a new process opens. Thanks for your help.

Best regards

Melanie

Dear Community,
I am designing an EPC for a particular process. Let us call it process P. From process P, I first go to process A, then to process B and finally come back to process P again. It is shown under the "scenario" section in image. Since it is not the standard practice to show two process interfaces back to back, I have decided to show process interface of A in P, but the succeeding event would be the end event of process B. Is this acceptable?

Hi Anthony. Since Process A does not throw the event "End of process B", I do not recommend the possible solution. I prefer the first scenario, with the difference that I would not show the link between Process Interface A and Process Interface B (it exists, but not in the current context).  Bgrds.

Hi Anthony,

I would suggest showing the event "End of process A" between the two interfaces, thus clarifying the interface for process B, which needs "End of process A" as its trigger. This also makes it clear for the reader, when process B will follow on process A.

Regards M. Zschuckelt