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.
Hinweise
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.
Anzeige
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.
Anzeige
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.