Published in:

Open Access 2013 | OriginalPaper | Chapter

3. The Solution – Part I

Authors : Albert Fleischmann, Stefan Raß, Robert Singer

Published in: S-BPM Illustrated

Publisher: Springer Berlin Heidelberg

Activate our intelligent search to find suitable subject content or patents.

search-config

AI-assisted search

Patentsearch

Off

Abstract

This chapter sums up the story of the last chapter, so you could probably start reading this book here. The first scenario depicts a problem between an operations manager and a person from the logistics department; this means that in this case there are two actors. The operations manager is responsible for his team to meet certain production schedules and to cope with any problem that may occur.

Speed is the essence of war. Sun Tzu

3.1 Summary of the Problem

The first scenario depicts a problem between an operations manager and a person from the logistics department; this means that in this case there are two actors. The operations manager is responsible for his team meeting certain production schedules and coping with any problems that may occur.

The logistics department is responsible for delivering production material in time so the production schedule can be met.

A problem arises when there is an exceptional process situation that may endanger on-schedule performance of production operations. In this case the operations manager has to reschedule production and inform the logistics department so production material is delivered when needed.

The challenge, which will be addressed in this scenario, is the communication between the operations manager and the logistics department, because there is a lot of room for error in communication, which could lead to massive production problems.

After reading this scenario, it should be clear how to create a new process group with the Metasonic Suite which is able to support solutions for the problems described.

3.2 Solution – Step by Step ∣ Scenario I

3.2.1 Creating a Project

Open the Metasonic Suite by double-clicking on the desktop symbol.

After starting the application, the dialog window Workspace Launcher eventually pops up. There you can define the location in which your project files will be stored. Activate the check box Use this as the default and do not ask again, if you do not want to see this dialog again. Press the button OK, when finished. If you start the application for the first time a welcome window is shown. Close this window; if you wish to see this window again simply choose Welcome in the Help menu.

To start a new project, choose the menu entry File/New/Process Group. In the opened dialog window Metasonic Build Process group enter a name in the field Process group name. For our purposes please enter “Teaching Factory goes S-BPM” and click on the button Finish. By default the standard work space location – as defined during application start-up – of the Metasonic Suite is used. After having created a process group, it is displayed on the left-hand side in the Navigator window (see Fig. 3.1).

3.2.2 Creating a Process

Now, that a process group has been defined, it is necessary to create a new process within this group. A process group is able to store several processes. Right-click on src in the Navigator window on the corresponding process group “Teaching Factory goes S-BPM” and select New/Process from the context menu, as shown in Fig. 3.2.

You should always give the processes meaningful names. In this case the name is “Scenario 1 – Operations Manager and Logistics”, as shown in Fig. 3.3. Press the button Finish, when done.

The application window automatically displays the modeling space for the newly created process. All processes of a process group can be chosen in the Navigator window (see Fig. 3.4) for modeling. Mark a process group and click on the small triangle to the left of the group to expand or collapse it. Double-click on a process to start working with it.

3.2.3 Modeling the Process – Subject Communication

Now that a process group and a process exist, we can start to model the process.

Subjects

The first question you should answer is the number of subjects in the process. In this case there are two subjects: the operations manager and the logistics department. So the first step is to create these two subjects in the process. This is simply done by dragging and dropping the object named Internal Subject from the Palette (on the right-hand side by default) onto the opened process modeling space, as shown in Fig. 3.5. In the dialog window Create a new subject enter a reasonable name for the created subject. Leave the check box Multiple subject unchecked.

The subject’s name is either “Operations Manager” or “Logistics”. After having added the first subject, repeat this step for the second subject. After adding both, the Operations Manager and the Logistics subject, the process should look like that shown in Fig. 3.6. Feel free to move the subjects around on the working space – or canvas, if you prefer to think of it from a design point of view.

Communication

After having defined all necessary subjects, the next step is to identify the communication between them.

The next step includes some brain work: the goal is to identify the communication behavior between the two subjects. Analyzing the problem, the question should be: what kind of messages do the subjects exchange and what are the contents?

In the example, there are four possibilities to structure the communication:

Starting point:

The operations manager sends a message to the logistics department to inform them about an irregular process state: an order cannot be completed because a specified problem occurred which forces the production date of that item to be postponed. The operations manager also specifies the production order number, a response time by which a response from logistics is needed and an alternative, which is executed when there is no timely solution.

Possibility 1:

The logistics department receives, reads, and accepts the message. As a matter of acknowledgment a confirmation is sent back, with an optional comment.

Possibility 2:

The logistics department does not respond in time, but an alternative exists – the alternative is then executed.

Possibility 3:

The logistics department does not respond in time and no alternative exists. In that case the operations manager tries to reach an agreement with the logistics department to solve the problem. This can be done via different communication channels, for example calling the logistics department, a personal chat with a responsible member of the logistics department, escalating the matter to a superior etc. After both sides have agreed on a solution, the logistics department sends a message back to the operations manager in which the agreed changes are specified (and documented).

Possibility 4:

The logistics department receives, reads but does not accept the message. An informal solution is then agreed on via an arbitrary communication channel, as specified above. After both sides have agreed on a solution, the logistics department sends a message back to the operations manager in which the agreed changes are specified.

When looking at the four different possibilities it is clear that there are three different types of messages which are exchanged between the subjects:

A “Request for Change” (RFC), sent by the operations manager to the logistics department which includes the following fields:
- Production order number
- Old starting date and time
- New starting date and time
- Explanation of reason for change
- Answer needed by (date and time)
- Alternative, if not accepted
An “Approval”, sent by the logistics department to the operations manager if the RFC is accepted including the additional field:
- Comment
An “Agreed upon Change” message, which is sent after both sides have agreed on a solution with the following fields:
- Production order number
- New starting date and time
- Comment

After you have identified all necessary information for further modeling, the next step is to implement the communication flow in the Metasonic Suite.

The first action is to model the communication flow from the operations manager to the logistics department subject. To do so, you left-click on the previously created subject Operations Manager and click on the envelope symbol labeled Create new message, as shown in Fig. 3.7.

Now move the mouse pointer to the target subject Logistics (an arrow representing the message flow appears) and left-click on the target subject. A dialog window labeled Create new message appears. In that window click on the link Create a new message type, as highlighted with a red box in Fig. 3.8.

In the Name field enter the text “Request for Change”, which is the first message to be created (see Fig. 3.9).

After you have named the message, the parameters of that message have to be specified. This is done in the tab Parameters by simply clicking New and adding the name of the parameter to be created. The parameters correspond to the different message types mentioned in the text above. Figure 3.10 shows an example of the parameter Production Order Number.

The parameters are added one by one by entering the name in the dialogue Create parameter and clicking the OK button afterwards.

After you have added all necessary parameters, the window should look like that shown in Fig. 3.11.

After you hit the OK button, the message is created and again the Message Overview window, which now shows all available messages, is shown, with Request for Change (local) being the sole available message. Now we can use all the created message parameters during the modeling of the process.

After you click the OK button again, the message created beforehand is linked from the Operations Manager subject to the Logistics subject and the whole process model should look as shown in Fig. 3.12.

Then the other two messages, which are directed from the Logistics subject to the Operations Manager subject, are created. Use the same procedure as before: click the Logistics subject and use the envelope icon to connect the message arrow with the Operations Manager subject. In the opened dialog window now create a new message type by clicking on the link Create a new Message Type.

Name this message “Approval” with the only parameter “Comment”. After confirming to close the dialogue window, the window Create new message now displays two messages – the previously created “Request for Change” and the newly created “Approval”.

Persevere and add the third message by clicking the link Create a new message type again. This message is named “Agreed upon Change”. Here all needed parameters already exist because you already created them previously. So you can add them by clicking the Add button and checking the needed parameters: “New Plan Date”, “Comment”, and “Order Number”. After confirming the selection, the window Create message type should look as shown in Fig. 3.13.

Now, after you have confirmed closing the current and the following window, create the communication link between the logistics department and the operations manager subject as you did before. The two subjects should now look as displayed in Fig. 3.14.

The overall communication between the two subjects is now defined.

3.2.4 Modeling the Process – Internal Behavior

Now we have to define the internal behavior of the two subjects; this means that we now want to define how the subjects will deal with the previously defined messages. To be exact, each subject represents a process, which is defined as the internal behavior of the subject; these processes are synchronized, i. e., coordinate their execution, via the exchange of messages.

Behavior of the Operations Manager

First, we have to define which of our subjects in the model initiates the process. In our example this is the operations manager, which means that the first step is to model the internal behavior of that subject. The modeling of the internal behavior is initiated by double-clicking the related subject, which in this case is the Operations Manager.

This opens another canvas labeled with the name of the subject, in our case Operations Manager. The communication structure was discussed above; this structure now has to be modeled in the S-BPM notation. The first element needed is the start element – this element is unique within a process and starts the whole process choreography.

To start modeling, select a Function state element from the Palette on the right-hand side of the application window and drag it onto the canvas Operations Manager, as shown in Fig. 3.15.

For a better view, it is suggested that you place it on the top center of the actual canvas. You have to assign a name to the element to indicate its function. In this example, label the new state “Problem description” (see Fig. 3.16). The chosen name and other configuration possibilities are shown in the Properties tab below the canvas. There you can also see the text Is start state. The first created function state will be assumed to be a start state.

The “play” icon in the top right corner of the created Problem description function state visually indicates that this is the starting state of the subject (see Fig. 3.17). This means that the first action the subject should do, when the process starts, is to describe the problem which occurred; in our case this is a problem in the execution of the planned production schedule.

After you have successfully created the first function state, it is necessary to add the previously created parameters. To do so, select the function state Problem description and then, at the bottom of the screen, select the menu entry Parameters in the tab Properties (see Fig. 3.18). Practically, we make the messages and parameters available to the model. The idea behind this is the so-called paradigm of information hiding. We should always carefully select, who should be able to see what information. So here we can decide whether a specific piece of information is only visible (read only) to a subject, or if it can be edited by that subject (read and write).

Since the Operations Manager is the one who sends a notification about a problem, the parameters need to be editable. All existing parameters are added as editable by clicking the Add… button.

After you have added all parameters, the window should look as shown in Fig. 3.18. The parameters are inherited throughout the process model, which means that subsequently created elements also have access to the specified parameters.

After formulating the problem, the operations manager sends the Request for Change message to the logistics department. To model this, choose the element Send state from the Palette.

The simplest way to do so, is to select the Problem description state and then use the leftmost symbol in the context menu, to directly create a new send state. Move the mouse pointer to the position at which you want to place the new send state and release with a mouse click – the new state is created and the Create transition window pops up; enter “Send Change Request” in the text field Send state name to name it. The action that occurs between the two states is already defined as “Problem description done” by the application, which in this case exactly describes what should happen (Fig. 3.19). After that, the internal behavior should look similar to that shown in Fig. 3.20.

After having sent the change request, the operations manager is waiting for an answer. To model this, a so-called receive state is used. This state also specifies from whom we expect which message. The approach is similar to the one described before, except that the icon used in the Palette is the second one.

Now, create a new Receive state below the send state. A dialog window, labeled Create transition, pops up; there we have to define the Transition, i. e., the Receiving Subject and the Messagetype. In this case the Receiving Subject is Logistics and the Messagetype is Request for Change (local) – use the drop-down menus for proper selection. Before closing the dialog window, name the created Receive state “Waiting for answer” and press OK. After that, the internal behavior should look as displayed in Fig. 3.21.

From the point of view of the operations manager, there are now three possible cases: either the Approval, the Agreed upon a Change, or no message at all (a timeout) is received. We suggest to first model the “positive” or “happy” path, where an Approval is received, which is also the desired output of the process from the operations manager’s point of view.

To do so, create another function state below the Waiting for answer state with the approach already used twice. The function state is the second symbol from the left in the small pop-up menu. Creating this state will make the Create transition window appear. Here you have to specify which message is to be expected and from whom. In this example the sender is the logistics department and the received message is the Approval, as shown in Fig. 3.22. Name the new function state “End”, because after having received the approval, there is nothing more to do for the operations manager and the process ends.

After the function state End has been created, it has to be marked as an end state so the process can terminate after the state is reached. To do so, click the state and check the Is end state check box in the Properties window at the bottom of the screen. If you can’t see the check box, make sure that the General tab is selected. The end state is visualized by a stop icon in the top right corner of the function state. The whole modeled internal behavior should now look as in Fig. 3.23.

The next possibility which has to be modeled is the one where the request for change is not acceptable for the Logistics subject, but where the two subjects (representing the involved actors) agree on an informal solution. The informal solution is then sent from the logistics department to the operations manager as a documented confirmation. This situation represents scenarios where communication occurs beyond the process management system; this could be via personal negotiations on the phone, by email, or face-to-face. But, at the end we want the process instance to reflect the real path and to terminate with a predefined state.

Of course we could modify the process in any thinkable direction; for example the operations manager sends a confirmation to reflect a mutual agreement. This means that in this case the operations manager receives an Agreed upon a change message. After that message, the operations manager only needs to check the agreed message parameters (representing, e. g., the new time schedule) and after that the process is finished.

So, this is another possibility of what can happen after the Waiting for answer state. Another function state, Realize approved changes, has to be created and connected to the function state Waiting for answer using a transition labeled Agreed upon a change.

Now, select the Waiting for answer state and create a new function state (use the small context menu) at the right-hand side of the Waiting for answer state. Again, in the dialog window Create transition, select from the drop-down menu Sending Subject the entry Logistics and from the drop-down menu Messagetype the entry Agreed upon Change (local). Name the newly created state “Realize approved changes” (Fig. 3.24).

After that, the internal behavior should look as shown in Fig. 3.25.

You can change the appearance of connectors with your mouse; click on the connector to see the connection points with states (red) and the “moving” points (black). So move it around as you like. The state transition description box can also be moved to a different position; if you move it away from the transition, a thin line will still show the connection to the corresponding transition.

As the activity Realize approved changes is the last one in this process path, the process should then end. So we have to connect this state with the previously created End state. Select the Realize approved changes state and then choose the first icon in the context menu on the right, which is a connector, to connect it to the End state. The default name for the transition (“Realize approved changes done”) can either be left as is or changed to something like “Realized approved changes”. This should make the internal behavior look as shown in Fig. 3.26.

The next step to model is the possibility that there will be no answer on time. This case will be modeled in a slightly different way, because function states created via the small pop-up menu when selecting a state do not cover the use of timeouts.

The first thing to do, when there is no answer on time, is to check whether an alternative path exists or not. So drag a new Function state from the Palette on the right to the left-hand side of the Waiting for answer state. Label this state “Alternative exists?” (Fig. 3.27).

Contrary to the previous approach, the transition between these two states has to be created manually. To do so, select the Manual timeout from the Palette with a left click. Click on the Waiting for answer state and then on the Alternative exists? state (in exactly this order) to create a transition from the former to the latter state. Label the transition “No answer on time” (Fig. 3.28).

Now, again, there are two possibilities. Either there exists an alternative, in which case the alternative is executed and the process ends, or there is no alternative, which means that the two subjects have to agree on an informal solution.

To model the case of an existing alternative, create a new Function state labeled “Realize alternative” below the Alternative exists? state, again with the help of the small pop-up menu. Label the transition “Alternative exists” instead of “Alternative exists? done”. After you have created the new function state, the only step left is to connect it to the End state in exactly the same way as described before when connecting the Realize approved changes to the End state. Again, the transition can be relabeled; otherwise, the default label can be used.

A view of the bottom of the resulting internal behavior model is shown in Fig. 3.29.

The last step in modeling the internal behavior of the operations manager is to model the case in which no alternative exists and there is no answer on time. Following this case, there has to be an informal solution that the two subjects agree upon – using any possible communication channel.

So, create a function state labeled “Informal solution”. Create this function state above the Alternative exists? state and name the transition “No alternative exists”.

If there is an informal solution, the logistics department sends an Agreed upon Change message, which means that after agreeing on an informal solution, the operations manager has to go back into the Waiting for answer state.

To make this happen, connect the newly created Informal solution state to the Waiting for answer state with the transition Agreed on informal solution – and the modeling of the internal behavior of that subject is now finished. Now all possibilities have been taken into account and modeled as internal behavior.

Figure 3.30 shows the newly created parts of the internal behavior. Figure 3.31 provides an overview of the complete internal behavior of the operations manager.

Behavior of the Logistics Department

We will now model the internal behavior of the Logistics subject.

The possible behavior from the logistics’ point of view is quite simple: whenever a change request is received, it is either accepted, which results in sending back an Approval message, it is not accepted, which leads to the Agreed upon change message – or it is simply ignored.

In all cases the first step is to receive the Request for change message. To start modeling, double-click the Logistics subject in the overview window. Then drag a Receive state element from the Palette onto the canvas (Fig. 3.32) and label it “Receive change request”.

Placed in the top center of the canvas, it now marks the starting point of the internal behavior of the Logistics subject, which is again visualized by a small “play” icon within the element, as shown in Fig. 3.33.

The next step in the behavior, after having received the change request, is to evaluate whether it is acceptable or not. This means, that the next state will be a function state, which also creates the transition between the two elements. To create it, select the already created Receive change request state and then click Create new function state from the pop-up menu as described previously.

Create this state beneath and label it “Change request acceptable?”. The transition consists of Operations Manager as the Sending Subject and Request for Change (local) as the Messagetype (Fig. 3.34).

Afterwards, the behavior of the logistics subject should look similar to the one shown in Fig. 3.35.

After that, similar to the operations manager’s internal behavior, the parameters have to be specified so the received message can be read correctly. To do this, select the Change request acceptable? state and choose the parameters tab. This time the parameters are not editable but for display only. Therefore, on the right-hand side, in the Parameters for display only section, add all parameters as display parameters by using the Add… button followed by the Select all button (Fig. 3.36).

If the Parameters for display only section looks as shown in Fig. 3.37, the step was performed correctly.

Again, the simplest path is modeled first. The “happy” result of this process is, that the logistics department immediately accepts the operations manager’s request for change.

After coming to the conclusion that the Request for change is acceptable, the logistics department sends back the Approval message, and after that, the process ends.

So the next step is to model the sending of the Approval message by creating a send state, using the already known pop-up menu approach, below the Change request acceptable state, which also creates the transition between the two elements. The send state is the first element on the left in the pop-up menu.

Name the transition Change request acceptable and the newly created send state “Agree on change request”. The internal behavior of the Logistics subject will then look like that shown in Fig. 3.38.

If you want the logistics department to be able to add a comment to the Approval message, you will have to add the Comment parameter to the editable parameters section of the Change request acceptable? state. To do so, simply right-click the Change request acceptable? state and select Properties from the context menu. Afterwards click the Parameters tab. Here, click the Comment parameter in the Parameters for display only section and click the Remove button. After that, click the Add… button in the Editable parameters section. In the following window, select the only available parameter (which should be Comment) and add it by checking the check box and clicking the OK button.

The only thing left to do for the logistics subject, after having agreed on the change request, is to end the process, which leads to the transition which actually sends the message.

To finalize the so-called happy path (sometimes also called sunshine path), simply add a function state labeled “End” beneath the Agree on change request state using the pop-up menu. For the transition, the Receiving Subject is of course Operations Manager and the Messagetype is Approval (local). To formally specify that the process terminates at the End state, check the Is end state check box in the General tab when selecting the element. Figure 3.39 shows an overview of the internal behavior of the logistics subject modeled so far.

The next step is to model the possibility that the change request is not acceptable. If that is the case, the logistics subject is required to simply find a solution by using a freely chosen communication channel. The outcome should be that a solution is negotiated with the operations manager. After a solution has been agreed upon – via informal communication and natural language –, the agreed solution is sent from the logistics subject to the operations manager subject as a confirmation. After that the process ends.

Create a function state called “Find solution” on the right-hand side of the Change request acceptable? state via the pop-up menu. Label the transition “Change request not acceptable”, which makes the internal behavior look similar to that shown in Fig. 3.40.

The next step is to send an Agreed upon change message to the operations manager. There are only two editable parameters which the logistics subject may have to change: the New Plan Date parameter and the Comment parameter.

After selecting the Parameters tab of the Find solution state, add these two parameters to the Editable parameters section by using the Add… button. Afterwards add all remaining parameters to the Parameters for display only section by again using the Add… button and the Select All button. This should lead the Parameters tab of the Find solution state to look similar to that shown in Fig. 3.41.

As said before, the next step after a solution has been found is to send the agreed solution to the operations manager as a confirmation. Therefore, create a Send state below the Find solution state using the pop-up menu. Label the transition “Found solution” and the new send state Send agreement. Afterwards the Change request not acceptable branch should look similar to the one shown in Fig. 3.42.

The last step is to simply connect the Send agreement state to the End state and thus end the process. You can also do this via the pop-up menu using the last element on the right. The transition requires you to set the Operations Manager as the Receiving subject and Agreed upon change (local) as the Messagetype. The whole internal behavior, which now includes two possible branches, should look similar to that shown in Fig. 3.43.

The last possibility is the case where the Logistics subject either does not read the received message (which causes the operations manager to execute the alternative) or the Logistics subject is processing the received message while the timer runs out. If the timer runs out and the operations manager executes an alternative, the process must also be terminated for the logistics subject – no matter what state it is in.

The simplest way to achieve this is to turn every single state within the logistics subject into an End state. This means that the process may terminate within that state but isn’t necessarily doing so. In this case the process is only terminated if it reaches the End state within the operations manager’s internal behavior.

In practice, this means selecting each created state and checking the Is end state check box, even of the Receive change request state – it is then a start and end state at the same time.

After you turned all six states into end states, the complete behavior of the logistics subject should look similar to Fig. 3.44.

3.2.5 Enacting and Executing the Process

After you have created the whole process model consisting of two subjects, their communication and internal behavior, the next step is to enact and then execute this model. An executed model has the advantage that all existing possibilities can be validated. It is also possible to check whether there exist possibilities which were not taken into account during the design phase.

Validation Environment

The previously created process can be executed directly within the Metasonic Suite. It can also be played through (step by step) using actually existing user accounts, which are assigned to a subject.

Prior to executing the process, these accounts have to be created by mapping the business organization onto the process. They are stored in a separate database within the validation environment provided by the Metasonic Suite.

The first step is to start the validation environment by choosing File/Start Validation Environment from the menu (Fig. 3.45).

After you clicked on this menu item, the validation environment is being started which can take a while, depending on your hardware. After the environment is started, the whole window should look exactly as shown in Fig. 3.46.

This window will be used for validation/execution purposes.

Users, Roles, and Groups

In this section we have to define who is doing what. We have defined subjects including their internal behavior. Now we map the organization onto these subjects (or processes, if you like). This includes the definition of roles as an abstract representation of responsibilities within an organization. At the end, we then map groups and real users onto those roles, which again are linked with subjects. This is the most flexible way to design the enactment of business processes.

The Metasonic Suite uses a typical three-level scheme to organize user accounts and to connect them with the subjects created in the process model (Fig. 3.47).

On the first level are the user accounts, which can be assigned real names and which represent actual humans in the real world. The second level consists of user groups, which users can be assigned to and which can represent, for example, departments. The third level consists of roles which link the user groups to the created subjects.

For our company, the following organizational structure exists (for a visual aid, see Fig. 3.48):

Within the operations management department there are two employees:

John Doe
Joe Bloggs

Within the logistics department there are also two employees:

Norma Roe
John Stiles

This structure has to be created within the Metasonic Suite so John Doe and his colleagues can login and start working with the Metasonic Suite.

The first step is to create the necessary roles. To do so, open the Usermanager from the (previously started) validation environment window with a left-click. The Usermanager is the second link from the bottom on the Metasonic Suite’s validation environment window (in full-screen mode) as shown in Fig. 3.46.

The Usermanager opens a new page in a web browser and offers a selection of three functionalities: User-, Group-, and Role administration. The easiest approach is to start creating the groups because this results in the least amount of clicks needed for this scenario.

To create groups, select the menu item Group administration from the menu on the left-hand side. The groups in our scenario represent the departments in which the users work; therefore, in this case, they are named “Operations Manager” and “Logistics”.

Create a new group by selecting the Create new group link after having selected Group administration from the menu on the left-hand side as shown in Fig. 3.49.

As shown in Fig. 3.50, the first group you create is named “Operations Manager”. All user accounts which represent operations managers will later be added to this group.

Enter the name of the group and hit the submit button. Use the same approach for the second group named “Logistics”.

The creation of both groups can further be validated by using the Search button with an empty input field – this displays all existing groups. Within all displayed groups there should also be the two groups you just created.

The next step is the creation of the four user accounts, which is done via the User administration link from the menu. The User administration browser window looks very similar to the Group administration browser window. Create a new user account by clicking the Create new user link.

Create the first user called John Doe with the login name of “jdoe” and the password “topsecret”. To link the account with the group “Operations Manager”, click the Search button within the user creation form and add the element “Operations Manager” to the Associated tab with the \(\boxed{\rightarrow}\) button. After you have filled out all necessary information, the Create new user form should look like the one in Fig. 3.51.

Repeat this step for the user account of “Joe Bloggs” with the username “jbloggs”, the password “topsecret” and the group “Operations Manager”.

Use the same approach to create “Norma Roe”, “nroe”, “topsecret”, group “Logistics” and “John Stiles”, “jstiles”, “topsecret”, group “Logistics”.

After the creation of all users, they should all be listed when using the Search button on an empty form in the User administration section as shown in Fig. 3.52.

The last step is to create the necessary roles. To do so, select the Role administration item from the menu.

As previously mentioned, roles link the groups to the subjects in the process model. Therefore, it makes sense to name the roles according to the subjects.

The first role to create is the “Operations Manager”. Do so by selecting Create new role, as previously described.

Name the first role “Operations Manager” and link it to the group Operations Manager. The group can be selected by using the Search button with an empty input field and choosing the previously created Operations Manager group. Add the group to the Associated tab by using the \(\boxed{\rightarrow}\) button. The resulting form should look like the one in Fig. 3.53.

Submit this form and use the same approach for the role Logistics, i. e., you create a role with the name “Logistics” and the group association “Logistics”.

Afterwards, the two created roles should be displayed when using the Search button with the empty input field in the Role administration browser window, as shown in Fig. 3.54.

After you created all necessary groups, roles, and users connect the roles with the subjects in the process model. Close the browser window and open the Metasonic Suite again. A double-click on the Metasonic Suite tab minimizes the validation environment and brings back the process overview.

The first step is to bring up the Roles for process group window. To do so, right-click the process group named “Teaching factory goes S-BPM”. Then select Metasonic Build – process group specific settings/Roles.

This step opens the Role repository window (Fig. 3.55).

As the next step click load after selecting Standard role repository from the drop down menu in the center of the screen. Select Usermanager in the following Roles match window as shown in Fig. 3.56.

After you clicked the OK button, all existing roles should be displayed within the Role repository window, which includes the Operations Manager and the Logistics roles. Click the Synchronize button and again select the Usermanager in the Roles match window to synchronize the current process group with the previously created roles. After you saved the whole file (e. g., by using the shortcut \(\boxed{\text{Ctrl}}+\boxed{\text{S}}\)), the roles are ready to be linked with their respective subjects.

Return to the process group overview window which shows the two existing subjects and their communication (Fig. 3.14).

Here, select the “Operations Manager” with a right-click. In the following context menu, click Properties.

In the General tab of the Properties window there is a drop-down menu labeled Role. Set this option to “Operations Manager”, which should be selectable (Fig. 3.57).

Use the same approach to select the Logistics subject and set its role to Logistics (Fig. 3.58).

This finalizes the links between the process model and the users, roles, and groups. Save the file again, and now it is ready to be uploaded and executed.

Metasonic Flow

In this section we discuss how to upload a concrete S-BPM model (the one you created) into a repository where it can be executed by the process execution engine. In the repository you can store different versions of a process for example for documentation purposes. The upload step can also be seen as a formal release step, so that only completely designed processes are enacted.

Do so by clicking the Modelmanager link in the Metasonic Suite’s validation environment overview window.

After the Modelmanager has opened in a web browser, the overview window is displayed. The next step is to create a new Process Repository. Create a new repository by entering “Teaching Factory goes S-BPM” in the only available text input field and clicking the Create button.

After you created the repository, create a folder within that repository which is called “Scenario 1”. Create a folder by using the form available on the right-hand side of the screen after you selected the previously created Process Repository (Fig. 3.59).

After you created the folder, the process model is ready to be uploaded. Select the newly created folder and click the Search button to search for the process file, which contains the modeled process, on your hard drive. In this case the file you are searching for is the file

“Scenario_1_-_Operations_Manager_and_Logistics.jpp”, which should be located in a folder labeled src, typically placed within the project folder. The project folder in our case is called Teaching Factory goes S-BPM. This is also the work space location, which was selected at the very beginning when you first started the Metasonic Suite.

After you selected the desired process file, it can be uploaded by clicking the Upload button as shown in Fig. 3.60.

The uploaded process file is automatically selected after uploading. The only thing left to do before you can start with the execution is to check the Metasonic Flow start check box and, afterwards, click the play button next to it (Fig. 3.61). If you encounter an error, please check if all roles contain users and each subject has been assigned a role.

The process is now ready for execution, and a login window, which is shown in Fig. 3.62, pops up.

It is now possible to login here with the previously created credentials and execute actions depending on their linked subject’s behavior.

The login window is actually the start page of Metasonic Flow, which can also be opened by selecting the second link from the top at the Metasonic Suite’s validation environment overview window. After uploading the process file and activating it for execution via the check box, there is no further need to use the Modelmanager. To execute this process, only the Metasonic Flow window is needed.

In the next step all possible process variations can be played through for validation purposes (or just for fun). In this case you will only try out the sunshine (or happy) path: an error occurs in the manufacturing process, which causes the operations manager to send a Request for Change message to the logistics subject; a certain schedule cannot be met which is then accepted and confirmed via an Approval message by the logistics department.

You will play this process through by only using one physical machine, therefore always logging out and in again with the corresponding subjects. In a real world environment, of course, every subject has their own machine.

So the first step is to login with an operations manager user account such as John Doe.

Log in with username “jdoe” and password “topsecret”. Afterwards, the Metasonic Flow home screen is displayed (shown in Fig. 3.63.)

The next step is to start a new process instance as John Doe, operations manager. Do so by selecting Task from the menu bar and then New Task from the drop-down menu located at the top left of the screen.

The next window asks which process to start. Here the only possible choice is the previously uploaded process. The window should at least include the folder structure shown in Fig. 3.64.

After selecting the “Scenario 1” process a form appears where several settings can be adjusted. It is recommended to change the Title of the process instance to explicitly describe the purpose of that instance. In this case, rename the Title to something like the current date and time followed by “– Scenario 1 – Sunshine Path” (example shown in Fig. 3.65).

After that, click the Start button – a new process instance for this process is started and the whole browser window should look like Fig. 3.66.

At the top right of the screen the currently active task “Problem description” is displayed.

You, enacting the process instance as John Doe, can perform this task by using the Parameters tab from the previously shown Fig. 3.67. The Parameters tab shows all available parameters which can be used to describe the production problem in more detail (Fig. 3.67).

Open the parameter editing window by double-clicking one of the parameters shown. Use this window to further describe the problem. An example is shown in Fig. 3.68. In this case the parameters are not arranged in a specific order.

Please note that the parameters are only used as an easy-to-use and easy-to-explain solution. For a more advanced and visually more attractive solution, there is the possibility of using business objects. We do not concern ourselves with business objects because in this book we want to focus on the communication aspects of processes and we do not want to show how to define forms.

Click the Save button to save all entered parameters. Afterwards, check the Problem description done check box (see Fig. 3.66) and enter the next stage of the process by pressing the Next button at the upper right of the screen.

The next window is similar to the previous one, except that an image indicates that the process is now in a send state of the internal behavior, as highlighted in Fig. 3.69.

Send the specified parameters as a message by clicking the To button (marked in red in Fig. 3.70). Here it is possible to send the message to a single person or to a whole department. In this case, send the message to the whole department, because you do not care who in the logistics department takes care of the problem (Fig. 3.71).

Save the selection and click the Send button to send the message. John Doe now waits for an answer to arrive or the timer to run out.

For the next step, logout as John Doe by using the logout link at the top right of the screen, and login as one of the members of the logistics department. After you logged in as a logistics user, the currently running process is displayed within the Active Tasks area of the browser window.

Double-click to open the task. In the opened window select the only available instance by double-clicking it.

A browser window opens and indicates that the internal behavior of the Logistics subject is currently in a receiving state.

Click the check box to activate and click the Receive button to receive the message from the inbox. In the next window, read the received parameters in the Parameters tab as shown in Fig. 3.72.

After reading the parameters, you can decide whether they are acceptable or not. In this case we assume that the change request is perfectly acceptable and therefore activate the Change request acceptable check box. Then click the Next button and the Approval message is prepared to be sent. Afterwards, in the Parameters tab, you can also edit a comment parameter if you like. In this case it is assumed that everything is perfectly fine without the need for any further comments. Therefore, select “John Doe” as the recipient of the message in the To form (which opens after you click the To button), as shown in Fig. 3.73 and save the selection. Finally, send the message by clicking the Send button.

Following this action, the process is finished for the Logistics subject and there is nothing more to do, which is indicated by the End state image in the next window.

Logout of the current user account and login as John Doe once more to receive the approval message.

Open the only active Task on the left-hand side with a double-click and afterwards the only instance available, also with a double-click.

Receive the message, in this case sent by Norma Roe (Fig. 3.74), by checking the check box and clicking the Receive button.

After that, the process has ended for John Doe and is terminated. Now that the sunshine path has been validated, all other paths could be validated as well, before using the process in a real production environment.

As already mentioned, the message parameters are neither restricted (e. g., it is possible to enter plain text into a date field) nor arranged in a particular order. To avoid these flaws and to create nice-looking messages, the Metasonic Suite offers a feature called business objects. Business objects do not alter the behavior of the process in any way, but affect the visual appearance of the message forms (business objects will not be handled in this book).

3.3 Accomplishments

After you modeled the whole process and enacted it for execution, the process is principally ready to be used in a productive environment.

By handing over the login details to the participating subjects, the process addresses the communication problems outlined at the beginning of chapter 2.

After some time and several process executions, which of the possibilities occurs most often can be evaluated: the “sunshine path” or any other variation? This could lead to a possible process improvement.

The most important accomplishment of the new process should be that employees solve unexpected problems in a structured and well-documented way by using the Metasonic Suite and other forms of communication. All processes started in Metasonic Flow are logged and can be analyzed for various purposes. For example, one can analyze how often a process is finished with the best possible outcome. Nevertheless, the modeled processes are for demonstration purposes and we hope you can see the power of S-BPM.

3.4 Lessons Learned

After you worked through this chapter, the following concepts of S-BPM and the Metasonic Suite as a supporting system should be clear:

Creating a new Process Group
Creating a new Process within a Process Group
Creating Subjects
Creating Messages, including parameters
Creating communication flows between subjects
Modeling the internal behavior of subjects
The concept of users, groups and roles
Creating users
Uploading processes
Executing uploaded processes using Metasonic Flow

Open Access This chapter is licensed under the terms of the Creative Commons Attribution-NonCommercial 2.5 International License (http://creativecommons.org/licenses/by-nc/2.5/), which permits any noncommercial use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Springer Professional