Subject-Oriented Validation of Processes and Process Models

Abstract

Once a process has been modeled (see Chap. 5), it is advisable to validate and optimize the process and its model, before the model is implemented in the organization and IT. In this chapter, we discuss the validation.

7.1 To Go

7.2 Nature of Validation

Once a process has been modeled (see Chap. 5), it is advisable to validate and optimize the process and its model, before the model is implemented in the organization and IT. In this chapter, we discuss the validation.

In process management, a validation is understood as a review of whether a business process is effective, i.e., whether it delivers the expected results, either in the form of a product or service. This is equivalent to the verification required by ISO 9001:2008, Sect. 7.5.2 (processes of production and service provision) as proof that a process is capable of meeting the required specifications and quality characteristics (cf. Schmelzer and Sesselmann 2010, p. 330). As outcome of a process, we do not only consider the process result from the view of customers but also its contribution to the implementation of corporate strategy, i.e., its value proposition (see Sect. 3.6.3.2).

The validation should ensure that a process meets its requirements (“doing the right things”) and that the specification of process outcomes and procedures as acquired in the course of analysis and modeling, enables an organization to achieve its objectives with the process at hand. Validation is distinguished from optimization, where the goal is to improve the efficiency of a model through simulation (“doing things right”, see Chap. 8). Otherwise, validation and optimization may coincide. Thus, in practice, in a validation workshop, recognized optimization approaches are usually also considered for implementation.

Practical experience, particularly in the new conceptual design of business processes, reveals that it is not usually possible to ensure a priori that the designed process model actually produces the intended output quality, from a customer and process owner perspective. During the review of process models, it is again observed in practice that a significant proportion of these models have formal and logical errors, insufficient descriptions, and inadequate focus on customer needs.

An accurate description is a prerequisite for validation. Moreover, it facilitates self-contained maintenance and control.

Therefore, we need to validate both the considered business process itself, including its characteristics and requirements as outlined in analysis, as well as its content and formal aspects as mapped to the specification in the course of modeling.

The concrete objects for validation are therefore the main results of analysis and modeling. They are usually more or less structured text documents, which contain process descriptions from a strategic perspective, as well as graphically presented process models with associated database records that describe model components in the form of attributes in more detail.

We subsequently introduce both the validation of acquired processes (see Sect. 7.4), as well as their mapping to a corresponding model (see Sect. 7.5), since the former is a prerequisite for coherent mapping to a business process model. Before doing so, we show, according to the basic idea of the subject orientation, how the various S-BPM stakeholders are involved in the validation (see Sect. 7.3). With this, subject-oriented validation justifies that a process typically is a highly complex structure with many implicit requirements, the fulfillment of which is best evaluated by involving all concerned parties (stakeholders).

7.3 S-BPM Stakeholders Involved in Validation

In Sect. 3.3, four groups of relevant stakeholders have been identified for Subject-oriented Business Process Management. In the following, we consider them in the context of validation.

7.3.1 Governors

In the course of validation, different Governors act at different levels. The review of the strategic aspects of a process requires knowledge of corporate strategy, critical success factors for the company, and the core processes. As Governors, members of top management (CEOs) therefore evaluate the process documentation, e.g., along the following questions:

• Does the process support the policy and strategy of the organization?

• Is the process approach aligned to the stakeholders (e.g., customers)?

• Are the process objectives clearly defined?

• What are the risks of the process?

• Has a process manager (process owner) been nominated?

The process owner is also usually involved as a Governor in the validation of the process and the process model. Because of his responsibility for the performance of the process, he pays particular attention to the coherence of the appropriate measurement system. A selection of questions he uses to address these issues, under consultation of key performance indicator (KPI) experts from controlling when appropriate, are:

• Are there meaningful metrics to evaluate the extent of target achievements?

• Are the methods of measurement of the KPIs clearly defined?

• Are the target values for the performance metrics systematically determined?

• Are the metrics documented with their attributes in the metrics sheets?

• Are there numerical data defined (e.g., frequency of occurrence of the process per unit of time, breakdown of the numbers with respect to existing process variants)?

When reviewing the process model, process owners take a superordinate perspective, however, in coordination with the Actors involved in its respective steps, while essentially pursuing the following questions:

• Is the process flow in the model clearly defined (sequence of substeps and activities within the substeps)?

• Are the responsibilities (organizational units, roles, and people) clearly defined for each substep?

• Are the relations of the process to other processes and the thereby necessary interfaces adequately described?

A specific task of the Governor in validating process models is to check whether the given conventions of modeling and description have been followed. This is usually carried out by the authority which has adopted the conventions, such as the Organization Department (see Sect. 3.6.3.4).

7.3.2 Actors

Actors (work performers) are the central element in S-BPM and as such are crucial for the validation of process models. They focus on the accuracy of contents, and thus, on the coherent mapping of process analysis data to the process information of the model. The Actors, e.g., responsible people in a respective process, typically have fundamental knowledge and experience with respect to the accomplishment of their tasks while executing the process. They dry run the process in the course of subject-oriented validation in their specific roles as involved Actors (subjects), as modeled, and thereby are able to identify any errors, inconsistencies, and shortcomings. The lessons learned are used to answer the following selected questions, which have been arranged according to key aspects of subject-oriented modeling:

Question about the subjects:

• Are the subjects described in sufficient detail, and do they correspond to the desired roles?

Questions about the interaction of subjects and the message s or business object s exchanged, respectively:

• Are the required inputs, especially information, and the suppliers of such (organizational units, roles, and people) sufficiently detailed and correctly described, i.e., as perceived in reality (see also the principle of accuracy of modeling in Sect. 3.6.3.4)?

• Are the produced results (outputs) and their recipients (organizational units, roles, and people) sufficiently detailed and correctly described, i.e., as perceived in reality (see also the principle of accuracy of the modeling in Sect. 3.6.3.4)?

Questions about the behavior of subjects:

• Are the sequences of actions to be performed in a subject clearly defined?

• Do work instructions (e.g., checklists and guidelines) for the execution of activities in each substep exist, and, if so, are they part of the context of the model?

• Are they sufficiently detailed and intelligible, so that concerned Actors can work accordingly?

Questions about business object s:

• Are the business objects and their structures clearly defined?

• Has it been clearly defined for the business objects, in which process steps which views are required?

• Are operations defined on each business object?

With the answers to such questions, the Actors are able to assess whether they can work according to the model description in a satisfactory way, or whether some simplification or loss of context has occurred in the course of modeling.

7.3.3 Experts

Experts in the role of internal or external consultants may support management on demand when validating the strategy (i.e., the compliance of its respective processes). Experts from controlling could help in assessing the performance figures of the process documentation. When testing models, Actors or the Facilitator could consult methods specialists and tool specialists. In a certain sense, especially the Actors are experts for validation, as they operate the business. They know the process best and can therefore assess its suitability very well.

7.3.4 Facilitators

A facilitator role in the activity bundle of validation is mostly taken by representatives of middle management who are leading an S-BPM project. They coordinate the execution of tasks occurring during the validation. Specifically, they ensure, e.g., that process documentations and models resulting from analysis are reviewed by the other stakeholders (Governors, Experts, and Actors). Depending on the results of the validation, the Facilitator initiates the transition to other activity bundles. This can be, e.g., the analysis, if a need for improvement with respect to the definition of relevant process indicators and target values is identified.

If the validation, however, has confirmed the effectiveness of the process, the Facilitator triggers optimization, while possibly consulting a simulation Expert. The latter tests different resource allocations in the model, in order to specify requirements for the organization-specific implementation (see Chap. 9). The Facilitator may also decide that optimization will not be performed due to a lack of sufficient data for simulation. Then, the activity bundle concerning the organizational implementation of the process can be immediately initiated.

7.4 Validation of Processes

The basis of the validation process is usually an informal, textual description of a process from a strategic perspective. This results from analysis and includes statements regarding goals, strategy contribution, customer orientation, risks, etc. of the process.

A possible path leading to a review of this kind of process description is the largely linear sequence of the activity bundles analysis and modeling, as is the case when designing a new, not yet existent process. Here, as Facilitator, the responsible person for the organizational development project can pass on the questions for assessing the process, structured in the form of checklists, to the responsible Governors (CEO and process owner), together with the results from analysis, and along with the process model. The selected people perform their review individually and independently, and rate, possibly involving consultants (Experts), the items of the checklist.

In the next step, the Facilitator consolidates the results and attempts to resolve contradictions. Serious deviations of estimates are discussed and clarified in a workshop or in bilateral talks with the involved parties. Finally, once there is consensus about the need for action, the Actors eliminate in the bundle analysis and modeling the recognized deficiencies in an iterative loop. Then, the Facilitator distributes the revised documentation to the Governors for reevaluation of the originally recognized deficiencies.

If thereafter no more contradictions exist, the validation of the process is considered to have been successfully completed, and the Facilitator proceeds with content validation of the process model. Figure 7.1 summarizes the described multistage procedure.

Fig. 7.1

Steps of process validation

A valid model requires a correct representation of the current state of affairs. It characterizes semantic correctness. This results from the consensus of domain experts and method experts once they consider a model to be accurate. Semantic correctness needs to be differentiated from syntactic validity, as the latter refers to the compliance with specified rules for documentation.

In S-BPM, other, less linear paths may lead to the validation of a process. In particular, in case of preexisting and already running daily business processes, validation (or at least validation of specific aspects) can be triggered by an actor. If for instance, a salesperson recognizes in the sales process that an increasing number of customers no longer wants to receive sale documents on paper, but rather in digital form, he may ask the process owner as Governor to modify the process accordingly. The Governor, in turn, depending on his authorities and skills, will either check by himself whether the process design should be adapted to meet this customer need, or he will trigger validation through the superordinate Governors (e.g., management). In case of a positive decision, the process owner can subsequently, by involving a Facilitator (managing the project), analyze change options in detail and initiate their implementation.

S-BPM strives to provide long-term support for the Actors (work performers) by improving their individual situations in daily work. This is why we focus on subject behavior. The subject’s inclusion in the interactive behavior, as well as the objective-oriented accomplishment of tasks, determines the conclusiveness of S-BPM Models.

7.5 Validation of Process Models

7.5.1 Formal Validation

Formal validation determines whether the means of describing a process model for its representation are used properly. This type of review requires that a formal syntax exists for the description language. The latter defines the allowed usage of description constructs. This precondition for accurate modeling is met with subject orientation, so that here the formal validation of process models is not a separate step, but rather an implicit part of the activity bundle “modeling”.

In contrast to other modeling languages, subject-oriented modeling follows a clear formal syntax and semantics with subject, predicate, and object (see Chap. 12) and only uses a very limited number of symbols (see Chap. 5). An initial positive consequence is that modelers generally have less chance to generate formally incorrect models. However, its main advantage lies in the fact that a suitably designed subject-oriented modeling tool, based on the formally correct use of the notation, can help to entirely avoid formal modeling errors.

Other notations, such as EPCs or BPMN, as well as their corresponding software tools, usually provide users with a high degree of freedom when modeling, and thus increase the potential for errors. This applies to the use of language elements for task settings (e.g., what symbol represents information exchanged by e-mail) and to the arrangement of language elements for representing a specific business logic, input, output, etc. Possible consequences are ambiguities and inconsistencies in the presentation and the violation of rules with respect to the notation’s use (syntax errors). The first-mentioned defects can ultimately only be avoided by a comprehensive specification of conventions and a manual or visual verification of syntax compliance.

Some errors regarding notation can be detected automatically if a tool provides the appropriate functionality. Well-known functions of modeling tools in this respect range from preventing incorrect inputs and indicating flaws to the automatic improvement of models. For example, one of these tools (ARIS) produces an error message when an event-driven process chain (EPC) does not, as provided by the syntax definition, start or end with an event or a process interface. Another tool supporting modeling according to the Business Process Model and Notation (BPMN) detects violations of fundamental notational rules, i.e., when modelers incorrectly combine activities in different pools with a sequential flow, the tool replaces it automatically with a message flow.

Despite the implied functions of these tools for supporting established modeling languages, formal model deficiencies remain undetected when using the corresponding methods such as incorrect logical connections in ARIS or BPMN. This leads, e.g., at the latest, in the course of IT implementation to problems. Measures taken by IT to eliminate the deficiencies are often not reflected back into the model. Hence, IT implementation and functional modeling are inconsistent in terms of seamless round-trip engineering (see Sect. 15.1).

In contrast, S-BPM models, which have been described using the appropriate modeling tools, are formally correct and can, after successfully validating their content (see Sect. 7.5.2), be easily implemented or transferred automatically into code (see Chap. 10). Moreover, for subject-oriented modeling, there is no need for comprehensive convention guidelines (e.g., in contrast to ARIS), in order to ensure an intelligible, consistent, and comparable model representation.

7.5.2 Content Validation

Since S-BPM differs from other major BPM approaches, due to its primary reference to subjects and their interaction relationships, it is recommended that this unique feature also be used when validating models for the sake of increased consistency and coherency. In this section, we therefore introduce a subject-specific approach aligned to semantic coherence. The core of this innovative method is its ability to dry run a process, while involving the actual participating process stakeholders to which subjects are assigned. This provides them with a script of how they should perform along a specific process.

According to this script, the process can be executed as a role play. Thus, the participants actively experience the process and get an idea of how the process works in daily business. From their respective subjective points of view, the Actors are able to assess, e.g., whether substeps assigned to their role in the model description, the associated sequence of actions, the thereby required documents, IT systems, and especially their interactions comply with the requirements for the successful completion of a process. The Facilitator organizes and moderates the interactive execution of a process.

For this comprehensive experience of a subject-oriented process, the subjects, their behavior, and the communication structure, which means the interactions of subjects with the thereby exchanged messages and business objects, in accordance with the modeling methodology already introduced in previous chapters, need to be specified. The following variations show how this can be accomplished both with a conventionally designed, as well as with an IT-based role play.

The formal part of validation captures the usage of the modeling language, while the content part represents a task-relevant test procedure. Both evaluations are required for successful validation in S-BPM.

7.5.2.1 Content Validation Using Conventional Role Plays

Conventionally, the implementation of a model in a (role) playing environment can be done as detailed in the following:

Representation of subjects:

• Actual involved stakeholders of the process (subjects) are seated at a large table in a meeting room.

• Name tags identify their roles.

• The input and output trays are represented through storage boxes.

Representation of the behavior of a subject:

• Standard-sized sheets of paper contain the steps required by each subject (sending, receiving, and other activity) according to the process model.

Representation of the subject’s interaction including exchanged message s and business object s:

• Index cards (single messages) for labeling with parameters

• Forms describing the business objects used, which can be attached to messages

• Photocopy machine, for making copies of business objects.

• Before beginning, each subject obtains a sufficient number of messages and business objects for the execution of multiple instances.

Figure 7.2 shows part of a possible role playing environment.

Fig. 7.2

Conventional interactive process role play (photo: Alexandra Gerrard)

The Facilitator of the game starts the game by asking the first subject to become active, according to the process model, and to create an instance, e.g., to fill in a business trip request as an employee. The game Facilitator then monitors the further course of the game until the end of the play by checking off the activities performed by the subjects, such as sending and receiving messages or filling out a form, on a corresponding model diagram.

Both the subjects and observers not involved in the process, articulate and document their perceptions, e.g., on the following topics:

• Have Subjects been forgotten? If yes, which ones?

• Have Messages been forgotten? If yes, which ones?

• Have Business objects been forgotten? If yes, which ones?

• Are the business objects structured correctly, or are data elements missing or redundant?

• Where are redundant work tasks?

• Where are any unnecessary communication steps?

• Which subjects are not required for accomplishing tasks?

The immediate discussion and evaluation of the interaction allow the rapid identification of problems with respect to process effectiveness and efficiency and also facilitate developing possible solutions with respect to subject behavior, interactions between subjects, and the exchanged information. Identified weaknesses can be handled on the spot, i.e., by directly editing the model. An improved model can then immediately be interactively played once again.

The key advantage of the described approach is that the Actors validate the model by themselves, from their individual perspectives, by actively playing the respective roles. Using conventional methods, such as the walkthrough, originally stemming from software testing, the model is checked step by step, however, only “on paper”. To do so, usually in a workshop, large-format plotted graphical models are pinned to moderation walls (see Fig. 7.3). Instead of printouts, also large beamer presentations are used, possibly supported by animation capabilities of modeling tools, which facilitate following the flow by visualizing pointer movements.

Fig. 7.3

Typical walkthrough situation (Source: binner IMS GmbH)

The workshop participants scan the process step by step using concrete examples of the mapping of the perceived reality and review it with regard to its effectiveness, as well as with respect to formal deficiencies. The detection of errors in the process or of improper process output is much more difficult with this theoretical approach than with actual “doing”. This disadvantage of the conventional walkthrough is reinforced by the fact that the work performers of the process rarely participate as Actors. The walkthrough team consists mostly of process owners, and when appropriate, various consultants as content specialists, and method and tool experts with respect to formal aspects of the model. These people are not really familiar enough with the operational details of the process for them to recognize obscure deficiencies of the model on paper.

7.5.2.2 Content Validation Using IT-Supported Role Playing

Conventional role playing as described in the previous section is very useful; however, especially when used for more complex processes, it may become very costly. The materials (e.g., cards and sheets) need to be prepared, the participants need to gather simultaneously in a convenient place, the process needs to be manually recorded and analyzed, etc. It therefore obviously makes sense to support the described procedure with an IT solution.

The principle corresponds to the conventionally designed game. The difference is that the gaming environment is mapped onto an IT landscape so that a kind of distributed prototyping is enabled (cf. Schmidt and Fleischmann et al. 2009, p. 56; Fischer and Fleischmann et al. 2006, pp. 93 ff.). Consequently, executable software is generated from each subject-oriented model description, including user masks for each subject. For subject-oriented models, this is relatively easy, since the graphical notation presented in Chap. 5 is based on a formally distinct semantics, which provides a machine-interpretable representation including subject, predicate, and object (see Chap. 12).

The generated program also represents the communication relationships between subjects, and therefore, the interactions along the process flow. The stakeholders can collaborate along the process using spatially distributed computer systems, and exchange messages via an appropriate Internet server (see Fig. 7.4). They can immediately check and evaluate its associated forms, entry fields, and dialogs in the respective steps of the process flow.

Fig. 7.4

IT-based interactive process role play

At this time, such an evaluation can be performed, independent of the IT implementation later on. For instance, when an SAP form is used in a subject behavior description, the SAP system does not have to be available with the appropriate transaction. For role playing, it is sufficient that the Actor can check at this point the behavior of the SAP system in terms of an interface, e.g., can verify whether the input data which the SAP system requires are available.

While validating, the system can automatically record all activities of the subjects and the resulting changes to objects (e.g., completed forms). In turn, the process participants capture their comments on the validation in provided masks. The analysis of the generated data can largely be performed IT based.

Regarding our example of handling business trips, a validation scenario could encompass the following subjects: employee, manager, and travel office, as part of the internal organization (e.g., a company); and the travel agent as an external subject (interface subject). The employee starts an instance of the process by completing and sending the request to the manager. After the other necessary work and communication steps have been completed, the process instance ends with the employee’s (as applicant) receipt of an approval from the manager in positive cases and a rejection in negative cases.

For validation purposes, the representatives of specific subjects can be given access to the application which is automatically generated from the model. Each of them can then run at their PC workstations within a defined period of time their relevant work steps and communication procedures. If concentrated in a single location, at least the people who represent the internal subjects could come together in a room and validate the process, e.g., using mobile computers. Then, in addition to the communication provided by the process model within the validation application, the participants can also reflect personally on the process. In this way, they can especially review their interactions, which represent their interfaces for collaboration and, where applicable, adapt them accordingly.

In the case of a spatial distribution of the subject representatives, e.g., the external travel agent in our example, telephone or video conferencing can be used as additional communication channels for validation.

We will briefly explain in Sect. 13.4, how such an IT-based validation environment can be achieved.