Process analysis is a central bundle of activities of the S-BPM process model. Once an S-BPM project is started, analysis is paramount. It denotes a purposeful collection and evaluation of relevant process information in preparation for the next steps of the process model. Such process information includes existing descriptions of business processes, current process specifications (e.g., ARIS diagrams), measurements, and analyses of key performance indicators, or other documentation for quality assurance.
4.1 To Go
×
Process analysis is a central bundle of activities of the S-BPM process model. Once an S-BPM project is started, analysis is paramount. It denotes a purposeful collection and evaluation of relevant process information in preparation for the next steps of the process model. Such process information includes existing descriptions of business processes, current process specifications (e.g., ARIS diagrams), measurements, and analyses of key performance indicators, or other documentation for quality assurance. Process definitions describe specific business processes to achieve organizational goals. We have already presented the major components of process definitions in Sect. 3.2 while introducing the concept of processes in S-BPM.
Anzeige
In case in the analysis for these elements no significant data could be collected or important information is missing, other activity bundles of the integrated S-BPM approach may be affected. In such cases, the analysis has to be repeated for refinement. The unique characteristic of the subject-oriented analysis is its focus on subjects and thus on the process actors. It implements system thinking by using acquired information about business processes to identify roles or actors that serve as reference points for further specification. Therefore, S-BPM differs from conventional BPM. For instance, in ARIS-based BPM, analysis can be performed using a context-free function tree representation (Scheer 1998). In doing so, important questions remain open, e.g., the communication relationships between Actors required for task accomplishment. The respective information needs to be added later on, which causes an increased amount of effort.
The key benefit for organizations when analyzing according to S-BPM is that work performers (Actors) and responsible managers (Governors) can be directly involved in the acquisition and analysis process. They need no special training, since they are assumed to have already mastered the natural language semantics of natural language sentences. Therefore, we can start introducing the tasks the various S-BPM stakeholders need to perform in the course of analysis.
In the following, we detail the various points of reference of subject-oriented process analysis. They represent the context for the analysis methodology explained subsequently.
4.2 S-BPM Stakeholders Involved in Process Analysis
The analysis process can be viewed from the perspective of the four specific S-BPM roles. Each of the four roles deals with different tasks.
Anzeige
The guidelines for the individual work performers resulting from process analysis should trigger the adaptation of work processes to human needs and capabilities.
4.2.1 Actors
In a process, usually multiple Actors (work performers) are involved. They analyze which parts of the process are already known and how their interaction can best be represented. The central questions of the Actors are oriented toward standard sentences semantics of natural language. They deal with roles and systems (subjects), actions (predicates), business objects, and the communication between subjects for accomplishing tasks. The Actors of a process also usually know best where deficiencies occur, and how these might be resolved.
4.2.2 Facilitators
A Facilitator analyzes the best possible process to follow in BPM projects. He supports Actors in finding relevant contacts or consulting experts. He handles the communication between the involved parties in the project. In particular, he ensures that the objectives associated with adjusting a process are sufficiently communicated by the Governor, and that their relationship to the objectives of an organization is explained to Actors and Experts.
Actors should come to a constructive dialog with each other through the Facilitator. Experts can help to bring an external perspective to existing processes, which enables Governors to completely focus on organization-specific developments.
4.2.3 Governors
A Governor ensures that the constraints of an organization are complied to. He takes care that the objectives of a process at hand or a process to be defined are in accordance with the overall goals of an organization. In particular, he influences the performance indicators of a process, how they should be measured, and what targets should be pursued.
Scoping is always required—in particular for organization-wide S-BPM. By limiting the initial scope to an area that Governors can handle in a transparent way, such as the production unit of an organization, explicit interfaces can be identified which can then be subsequently addressed in their own specific context, such as that of product development.
4.2.4 Experts
Experts are specialists who are either directly or indirectly involved in a process. They have background information that is crucial for the process design. When needed, Experts contribute data, information, and knowledge about the process, reference process models, etc. for analysis. For instance, if within the scope of an analysis the efficiency of a current process is to be measured, appropriate specialists could be brought in. As a general rule, it makes sense to involve external Experts in order to efficiently encounter the tunnel vision often associated with daily routine work.
4.3 Reference Points
After describing the tasks of the S-BPM stakeholders throughout analysis, we are going to highlight the frame of reference for performing process analysis. It includes the following conditions, which we will then describe in more detail:
Process analysis is a form of system analysis.
Process analysis is a kind of knowledge management.
Process analysis includes the analysis of an organization.
Process analysis requires stringent procedures.
4.3.1 Systems Theory
The roots of systems theory can be found in biology. In addition, it is now used in many other areas, such as physics, chemistry, sociology, etc. (von Bertalanffy 1969). Systems theory is an interdisciplinary model of knowledge, in which systems are used to describe and explain phenomena of various complexities. A system consists of elements, which refer to each other and interact in such a way that they can be considered a single unit with regard to a specific task, purpose, or meaning. They can be distinguished in this respect from their surrounding environment. As an interdisciplinary field, systems analysis has also found use in many other sciences, including organizational theory (cf. Häfele 1990, Morgan 2002).
In system thinking, causal relationships are replaced by associative ones and, where appropriate, also by circular explanations, and isolated elements become tightly coupled system elements. By systems analysis, the elements of a system with their most important causal relationships can be identified and described. There are not only linear “if-then” chains, but also feedback loops (Krallmann et al. 1999, Simon 2011). The integrated S-BPM process model considers not only fundamental system contexts, such as the implementation of compliance rules in business processes but also dedicated opportunities for feedback. The subject with its outward bound communication relationships stands in the foreground.
Therefore, process analysis is a special form of systems analysis applied to business processes. Elements and relationships can be applied to process management through the interpretation of a process as a set of actors, activities, subprocesses, etc. As discussed in Sect. 3.2, activities or tasks, work performers, materials, and information are essential components of processes. These elements can be related causally. Usually, tasks are linked through successor or predecessor relationships. An activity can be related to a resource through a “used” relation. The relation “executes” defines which actor is responsible for the execution of a certain task. Depending on the type and depth of the process analysis, elements and causal relationships can be designed in different levels of detail. A structuring of the analysis results is required in order to be able to implement them later in a process model.
For instance, if we consider the basic requirements of a modeling language according to Mielke, the element “activity” with its relationships (e.g., the sequence) stands at the center of attention (Mielke and Balzert 2002). They are only secondarily linked to objects, relations, and roles. This is consistent with most traditional BPM approaches. In subject-oriented process analysis, however, the element “subject” including its relations with other subjects is at the center of interest. This allows transparent stakeholder orientation and role-oriented communication flows as opposed to function-oriented sequence specification.
Another aspect of systems analysis is to define a system boundary and the system environment (scoping). Thus, the focus of analysis represents a certain universe of discourse. Process analysis, as a special form of systems analysis, reveals a special feature, since the scope of a process and thus the system boundary is not necessarily identical with the boundary of an organizational structure. Processes can represent cross-organizational work or information flows (Fischer et al. 2006, p. 3f).
Consequently, people (work performers) and IT systems (resources) could be part of processes, even though they are not part of the organization at hand—the system boundary for process management can be a dynamic gray zone (Rosenkranz 2006). For this reason, a process analysis should always include the organizational environment. This means: Stakeholders who are not part of the organizational structure, which is initiating and held responsible for BPM, may be involved in the analysis process. For instance, the paradigm shift in strategic process management of CRM (customer relationship management) includes customers. Customers in fact are not part of the internal organization; however, all the processes need to be aligned to them. In CRM, their knowledge determines the development of products.
Therefore, Actors need a context-sensitive understanding of their duties to successfully accomplish their tasks. This allows structuring the various elements and relations in such a way that subjects of a process can work with them to accomplish their tasks.
4.3.2 Knowledge Management
When performing a process analysis, knowledge of an organization is acquired in a targeted way, namely, by obtaining relevant information about a process (Gronau et al. 2004). In doing so, we have to differentiate between explicit and tacit knowledge (Krallmann et al. 1999).
Explicit knowledge is already documented information about a process and an organization. The analysis should filter out the information that is relevant for the considered process.
The counterpart of explicit knowledge is tacit knowledge. The latter is not available in documented form. Tacit knowledge is (still) in the minds of work performers. Questions not immediately obvious to outsiders and questions which possibly are even impossible to document in their detailed complexity are: How is a task accomplished in a certain way? Why does it only work in that way? The collection of tacit knowledge and its transformation to explicit knowledge starts with stakeholders directly involved and affected. Surveys in this regard lead to detailed requirements for processes or parts of processes, and to dependencies and communication structures between the involved stakeholders that have previously not been documented. Subject-oriented analysis is focused on the subject, i.e., role-relevant application of tacit knowledge and its documentation.
Knowledge management in S-BPM means first and foremost to identify and localize the knowledge about the processes of an organization (Riempp 2004). An essential factor is the role of Experts acting as knowledge carriers. In addition, the other stakeholders of the S-BPM process model are also knowledge carriers. The identification of Actors through subjects facilitates the documentation of knowledge, since along with the function or activity relationships, actors and responsible stakeholders become transparent in the course of acquiring process-relevant information. When a process is designed from scratch, then usually no stakeholders with appropriate experience, who could be consulted or involved, are available. In this case, it is the task of the Actors to conceive this role and design a communicable behavior specification emphasizing the necessity of its existence.
4.3.3 Organization
To better cope with complex relationships, the traditional concept of “organization” comprises a distinction between structural elements and process elements. This dates back to Nordsieck (1934), Seidel (1972), and Kosiol (1976, p. 32f) and describes two sides of the same object. The organizational structure statically places organizational units at the center of attention, and subtasks, representing the respective objects of process design, are only considered secondarily.
Job descriptions define which tasks are performed by which parts of an organization. Today, IT systems are regarded as part of the organizational structure (Fischermann 2006). They are considered not only as detached material resources, but also as media to convey information “at the right time at the right place.” Meanwhile, they are of crucial importance for the accomplishment of tasks.
An organizational structure also represents an identity creating structure of an organization. Each employee can identify himself with his responsibilities and a particular unit (Fischer et al. 2006, Vahr 2009). For many organizations, org charts are still their “business cards” to external partners and their main structural elements to organize their work internally. The business cards of most employees of an organization include their position within the structural organization.
Once the focus is placed on the performance-relevant processes, running in space and time, among the work force, we speak of a flow-oriented or process organization. This constitutes the dynamic view of an organization (Picot et al. 2005). In such organizations, the tasks are at the center of attention, and most importantly, how these tasks are arranged. An essential question is how organizational units are mutually related to accomplish a correct temporal order when executing tasks. Processes are the actual implementation of organizing workflows in practice (Fischer et al. 2006). “The sum of all processes composes the process organization” (Fischermann 2006). Processes can be mapped to workflows by IT support and at least partially automated.
Both points of view of an organization contain valuable information. Hence, always both organizational dimensions should be considered in the context of subject-oriented process analysis. In organization theory, a paradigm shift has occurred in recent years. This is also reflected in organizational research. While in the past organizational charts, job descriptions, etc. have been put to the foreground, today we speak of the “primacy of the process organization” (Gaitanides 1983). It is not an organization’s structure that stands in the foreground, but rather processes, also known as “structure follows process” (Fischermann 2006).
The primacy of process organization is emphasized by the rapidly growing need for interdivisional and cross-company collaboration. The generation of organizational value creation through isolated services is decreasing more and more. The division of labor for generating services and products has been extended over the entire globe in many cases (Hirzel et al. 2008). Collaboration can be effectively described through processes and efficiently supported by IT.
However, if the orientation toward the flow of work tasks is predominately one sided, several issues are likely to have to be addressed:
The responsibility for employees, tasks, goals, and budget is still primarily held by people in the line of the organizational hierarchy. This can lead to conflicting process and organizational goals.
Stakeholders are identified in an organization primarily by their position in the structural hierarchy, not by processes. In the scope of a process, even employees holding positions in higher levels of the hierarchy are traditionally handling simple tasks, such as approvals. When running processes, the focus is on collaboration and less on the hierarchy. It is difficult for many managers to accept this shift.
Thinking in terms of processes is generally more difficult than thinking in terms of a familiar static organizational structure (Fischermann 2006).
Process analysis therefore is a special form of organizational analysis. This means, conversely, that it should also take into account the organizational structure in an appropriate way. The processes have to be aligned to the corresponding organization and embedded in existing hierarchical structures. In other words: “In the practical organization of work, the organizational structure is often a requirement, so that the flow follows the limits of the organizational structure, which cannot be changed” (Steinbuch et al. 1997). For these reasons, both organizational views have to converge. Fischermann recommends a process-oriented organizational hierarchy (Fischermann 2006).
In subject-oriented process management, the process can be guided by the organizational hierarchy. Therefore, we also refer to S-BPM as process management oriented toward the static structure of an organization. The S-BPM role of the Governor represents the driver (e.g., management, organization development) for integrating business processes within an organization.
4.4 Choice of Approach
In traditional process analysis, basically two approaches can be followed: top-down and bottom-up (cf. Österle, 1995):
The predominant pattern of thinking of an organization guides process analysis, either toward a top-down, bottom-up, or middle-out approach (combination of the first two).
The top-down approach focuses on the corporate strategy and vision of an organization for the analysis. The so-called FAU-process model (F for “Fuehrung” or Management/A for “Ausfuehrung” or Execution/U for “Unterstuetzung” or Support) identifies three distinct types of processes (Fischermann 2006):
Management processes are processes for creating a strategy, planning, and control. They may also be referred to as meta-processes for process management, which as such affect other processes, in particular execution and support processes.
Execution processes (core processes and value-adding processes) describe the actual operational processes. Traditionally, they are aligned to the production or supply of services. Modern CRM strategies recommend the alignment to the customer. Each process should lead to a measurable value for customers. According to Hammer and Champy (1996), there should be no more than ten core processes in any organization.
Support processes (auxiliary processes) are required to provide the resources needed for the management and execution processes. These include for instance staff management, financial management, or IT management.
Representatives of each type of process at the top level are progressively detailed and structured in the top-down approach. Process analysis is correspondingly understood as a stepwise refinement of the processes of a coarse representation to a more detailed description level (Gaitanides 1983). This step can be iterated any number of times, right down to the description of individual actions. In associated literature, several recommendations for decomposing business processes can be found. For instance, Buchner et al. (1999) distinguish between corporate processes, business processes, subprocesses, workflows, partial workflow, subworkflows, and activities.
A simpler variant (Fischermann 2006) decomposes business processes into subprocesses and tasks of different degrees. Both of the above-mentioned approaches to detailing a process leave open at what level of detail processes need to be initially specified before starting refinements, and how to design the interface between different levels of detail. Different stakeholders will approach this issue in different ways. In practice, therefore, systematic guidelines seem difficult. The analyst and the stakeholders involved in the collection and evaluation of data may interpret differently for each case at what level of abstraction a process needs to be positioned. Certification, software development, or process cost accounting, etc. have different objectives and subjective assessments with regard to the process level. Taking their respective perspectives may lead to specific abstraction levels. It is the duty of the Governor to establish a common view among those involved in the process development.
The advantage of top-down analysis is that the process goals are easy to anchor in the organization’s objectives, as they represent the starting point of analysis.
In the bottom-up approach, however, the process is constructed from the “base” upwards. The starting point is the individual actions that are linked together to form processes and procedures. The survey could start by identifying elementary actions involved in task accomplishment followed by composing those actions to a process specification. The disadvantage of the bottom-up approach is the assumption that each action is also required on its own. Only in case of an optimization, individual steps can be combined or omitted. Moreover, in this approach to analysis, the objective of a process could get lost in the details. The advantage still, however, is that the process is successively constructed from detailed factual steps.
The advantage of a bottom-up approach when involving operative stakeholders concerns the initial selection of an abstraction level, which corresponds to their perception. Analysis will consequently lead to collecting and describing only those processes that match the perceived reality. Another advantage of this approach is that participative organizational learning is triggered, once individual perspectives on events can be communicated effectively (cf. Stary and Fleischmann et al. 2011).
The subject-oriented analysis combines the advantages of the top-down and bottom-up approach. It starts with analyzing the active subject. According to the particular objective, either a top-down analysis is required, namely when identifying how subjects communicate with each other, or a bottom-up analysis is more appropriate, when considering certain operations in detail. Both approaches are not contradictory and can even be combined. In case it is required to represent certain aspects in detail, the respective subject is detailed accordingly, while other subjects such as the customer can remain abstract.
4.5 Determine the Context of a Process
Before a process can be described in detail, the goal of process analysis needs to be formulated. In order to do so, fundamental information about the process context needs to be obtained, including, e.g., a unique process name and internal and external conditions influencing process execution. These are detailed in the following.
4.5.1 Target of Analysis
An important prerequisite for a successful survey and evaluation of processes is to determine the objective to be achieved when performing the analysis. It is not sufficient to collect just any type of information about the process, especially if the analysis phase is the result of previous step of the S-BPM process model. In this case, the analysis has a very concrete target. For instance, a need for optimization has been identified and needs to be detailed. This could require obtaining additional information, since previously collected information from existing analysis may not be sufficient.
4.5.2 Initial Information
In order to describe a process, the following fundamental information needs to be acquired:
Process name. The process needs to have a unique name in the organization. The analysis should determine whether the same process is used in another context with a different name. If so, the “twin process” needs to be included in the analysis.
Example: The accompanying sample process handling a business trip request is termed “business trip application.”
Type of process. In Sect. 4.4, fundamental process types have been described. For each process, it has to be determined whether it is a management, execution, or support process.
Example: The process “business trip application” is a support process of an organization; it usually does not contribute to the value creation of the organization.
Process objective. Each process has one or more targets that should be achieved for the organization as a result of its implementation. These targets play an important role in determining appropriate metrics and approaches to optimization.
Example: The process “business trip application” should allow carrying out a coordinated and unified travel preparation for all employees.
Objective of the S-BPM project. The client (Governor) has different requirements on an S-BPM project. In general, participants or managers expect either improvement in the efficiency or effectiveness of processes.
Example: The Governor mainly expects from the process “business trip application” an improvement in effectiveness, because the error rate so far has been quite high.
Process metrics. Metrics of a process usually are defined very early—in this context, they are termed KPIs (key performance indicators) (see Sect. 11.4.2).
Example: In the process “business trip application,” a KPI is the processing time. If it is too high, no short-term travels can be approved.
Process owner. The Governor assigns the responsibility for a process to a specific person (termed process owner). The process owner himself usually has a Governor role. He is responsible for accepting the process model and is in charge of its implementation. During operation, process change requests must be approved by the process owner. He takes care of regular monitoring of the process and its optimization, if necessary.
Example: For the process “business trip application,” the department head of HR (human resources) takes the role of process owner and Governor.
Existing process models. It needs to be checked whether the process has already been (partly) modeled with a tool (e.g., ARIS), as this may influence the modeling path—existing process descriptions might possibly be reused.
Example: The process “business trip application” has not yet been modeled.
Supporting IT systems. It needs to be documented whether IT tools for process execution are already in use.
Example: For the process “business trip application,” an Excel spreadsheet was developed in which the personnel department documented all business trips so far.
Super/subordinate process. Does the process need to be considered in context with other processes?
Example: The process “business trip application” is closely related to the processes “booking” and “absence management.”
Process map. In a process map, a rough overview of the relationships of the process to other processes and the organization is represented. According to Schmelzer et al. (2010), relationships with customers and partners need to be included.
Example: Figure 4.1 shows how the “business trip application” is embodied into the process map of an organization.
Fig. 4.1
Example of a process map including the “business trip application”
×
Maturity. In a first estimate, the maturity of the process can be determined. Well-known approaches are the Object Management Group’s Business Process Maturity Model (BPMM) and the Process Assessment Models for Business Processes (PAB) and Enterprises (PAE), which are based on the model of the European Foundation for Quality Management (EFQM) (cf. Hogrebe and Nüttgens 2009; OMG 2008; Schmelzer et al. 2010, pp. 288ff). Figure 4.2 exemplifies the maturity levels of BPMM.
Example: The process of handling business trip requests is already implemented in most companies. The employees largely follow the same principles when applying for business trips. They can find instructions for submitting a request for business trips in the organization’s intranet. However, these are not obligatory and leave many options open. According to OMG’s level model, the process can be assigned to level 2 (managed).
4.5.3 Internal Constraints
Internal constraints of the analysis are internal organizational factors, which influence the course of survey and evaluation (see Sect. 3.6).
S-BPM strategy. An S-BPM strategy, which is derived from the business strategy, is a set of concepts and standards provided by top management which describe how processes are managed in the organization (see Sect. 3.6.3.2).
Example: All standard administrative processes have to be unified and supported with a common tool. This requirement also forces the examination of the “business trip application” process within the scope of an S-BPM project.
S-BPM culture. This reflects how an organization informally handles process orientation (see Sect. 3.6.3.3).
Example: It is common practice to assign the management of processes to external consultants. The resulting costs can be justified since the development of a common solution usually takes a long time. The employees are accustomed to participate actively in changes. Hence, targets cannot always be achieved in a timely manner. The process “business trip application” is therefore initially investigated by a neutral party.
S-BPM Governance. This is understood as a control of how processes are to be implemented in an organization (see Sect. 3.6.3.4).
Example: The design of the process “business trip application” follows the process model of S-BPM.
Budget/Household. An assessment of the current financial situation is crucial. In times of scarce financial and human resources, a complete reengineering of many processes may not be appropriate. In this case, emphasis is likely to be put on a cost-effective optimization.
Example: In the budget plan, a budget of 25,000 Euros was allocated to the process “business trip application.”
Projects. As part of multiproject management, it needs to be checked whether other projects are in progress which may affect the S-BPM project directly or indirectly. The process is possibly already under investigation in another project. In this case, synergy effects could be used.
Example: The company is currently introducing an ERP system. However, this has no functionality to implement the “business trip application” process.
4.5.4 External Constraints
The procedure to follow for process analysis concerns the context of the subject matter at hand (Sect. 4.3.1). In order to recognize this context, the external conditions of the process have to be considered.
Market situation. There may be the need to clarify in how far the described process is influenced by the situation on the market.
Example: Due to the strong market growth in Eastern Europe, the sales department is intensifying its activities in this region. For this purpose, the travel budget has been increased by 50 %. It can be assumed that this will lead to a respective increase in applications for business travels.
Competitors. Especially for customer processes, the competitors’ process should be investigated as far as possible in order to check whether possible business advantages and disadvantages can be derived. A typical competitive advantage would be offering a faster, more transparent, and more customer-oriented process than competitors.
Example: The travel expenses of the consultants of the organization are added to the customer rates. It is known that one of the competitors handles this in a failure-prone way, as the billings are apparently arbitrary and not comparable. Setting up the “business trip application” process should ensure that business trip requests are handled in a uniform way. This could be a competitive advantage.
Learn from the best! Do you know why your competitors outperform you? Do you know what constitutes the competition in your market segment? If not, you should reflect the frame of reference for your market segment!
4.6 Process Descriptions in Natural Language
As mentioned in Chap. 2, a process can be described using major elements of natural language—subject, predicate, and object. The objective of analysis is to work out this set of elements from available information (Buchner et al. 1999, p. 84f). Analogous to the questions on the sentence building blocks ("Who or what?"), there are three fundamental questions, as shown in Fig. 4.3.
Fig. 4.3
Elements of sentences
×
Below, we describe the procedure to follow for subject-oriented process analysis based on these questions.
4.6.1 Identification of Subjects
Point of origin and center of interest of subject-oriented analysis is the subject with the question: “Who is acting?” In a process, subjects are abstract actors, and they represent specific roles. In this way, a subject is independent of actual people.
Essential questions:
Who (or actually, what role) is active in the process?
Who is passively involved in the process (e.g., as a source of information)?
Who has to communicate, and with whom?
Which organizational units are involved?
Result. The names of the identified subjects are documented together with a brief description. The subject name should be a unique and generally accepted name of a role in the organization. In case the name has been used multiple times or exists in several variations, a naming convention needs to be determined.
Example: The subject “travel office” is used in several contexts. There is a unit for domestic travel and another for foreign travel.
The reluctance of stakeholders to model processes can be eliminated by teaching them to reflect their assertions within the framework of communication processes by using complete natural language sentences. This could even lead to the establishment of a novel communication culture.
4.6.2 Identification of Activities
After identifying the subjects, their activities need to be determined. In the context of subject orientation, an activity is defined as behavior. This stresses the fact that an activity never occurs by itself; there is always an actor: the subject. Hereby, two types of behavior are distinguished: Either the subject communicates with other subjects, or it performs its own tasks, possibly with the help of Business Objects, which are specified in the third step.
Essential questions:
With whom does the subject communicate?
From whom does the subject receive information?
To whom does the subject send information?
Which activities does the subject perform by himself?
What tasks does the job description of the subject contain?
In which sequence are these tasks being accomplished?
Do these tasks depend on other events?
Are there specific waiting periods?
What other prerequisites for running the activities must be met?
Again, the natural language serves as a guideline for the analysis. The dative is usually used to describe communication partners (“the subject x passes the document to subject y”), and the accusative to describe one’s own actions (“the subject x works on the task”).
Result. The subject descriptions are supplemented by the respective behavior descriptions.
Quantitative and qualitative assessment: There may be a demand to measure the behavior. In this case, in the analysis certain key figures need to be defined (see Sect. 11.4):
Process execution metrics (performance parameters): In view of later process calculations, it can be useful to determine performance parameters early. As such, a minimum or maximum duration can be determined for an action.
Qualitative requirements for an activity: Instructions need to be specified, such as “compliance to quality standards according to ISO 9000 has to be assured,” or “requirements according to process manual must be adhered to,” etc.
4.6.3 Identification of Business Objects
Once the subjects and their behavior have been identified, in the third step, the tools, objects, or also products that are handled by the subject, used, or passed on to others have to be specified. Business objects are all objects or tools a subject needs to execute a process. They can be both: tangible or intangible (Allee 2002). They usually refer to actions for communication and the subject’s own individual activities.
Essential questions:
Are physical or electronic documents or forms created, processed, or forwarded in the process?
How are these structured?
Which elements do they contain, and what is their structure and format?
Are there physical or electronic documents being used for completing the process?
What IT support, such as through a content management system or transactions of an ERP system, is provided?
What input masks are used in the process?
What data is used hereby, in terms of reading or writing information?
What role does information from the Internet play for handling the process?
Result. The result is a collection of materials, such as a list of documents, electronic forms, data entry screens of applications being used, as well as data record and data element descriptions, etc.
Who performs what, using what, and when? W-questions can help to attain complete natural language sentences.
4.6.4 Example
As a result of the analysis, a first documentation in natural language of the “business trip application” process is given in Fig. 4.4.
Fig. 4.4
Working out the elements of sentences in the analysis using the example of the “business trip application”
×
4.6.5 Documentation Guidelines
When documenting requirements in natural language, the following guidelines may help to describe these more accurately (cf. Pohl et al. 2009, Dori 2004):
Do not use passive voice. Processes are often described using passive voice. In these cases, the subject is missing; it is no longer known who is actually responsible for an action. Instead, sentences should be written in active form, or passive sentences should be extended with adverbial enhancements.
Example: “Then, the data is entered into the system.” Better: “The clerk then enters the data using the “personal data” form of the human resource management system.”
Do not nominalize predicates. Predicates used as nouns often conceal relevant information. An associated resolution and a more detailed explanation are often helpful.
Example: “(…) Then the forwarding of the “business trip application” is done.” Better: “The employee forwards his “business trip application” as an e-mail attachment to his manager.”
Do not use universal quantifiers. Universal quantifiers do not reflect requirements accurately. It is better to provide concrete details.
Example: “In general, the application is completed by doing so.” Better: “By filing the application form, the process enters the state “temporarily closed.” There, it remains until the end of the 4-week objection period. In case an objection comes up during this period, the status is set to “in progress,” otherwise to “completed.””
Fully specify conditions. Conditions that are relevant for decision making must be clearly formulated.
Example: “If all the necessary inputs are provided, the process can be completed.”
Better: “The process can be completed once the travel office has entered the following data:
First name and last name
A syntactically correct personal identification number which was verified using the last name
A start date and end date for the travel in which the end date is later than or equal to the start date, and taking into consideration that the travel data entry may not occur earlier than three months prior to departure”
4.6.6 Elicitation and Documentation of Implicit Knowledge
The above-detailed procedure is applicable to the collection of explicit knowledge, which is available in existing process manuals, forms, reports, software manuals, and other documents. Tacit knowledge is not documented; however, it is in the minds of the knowledge holders, who should therefore participate in the documentation process. Organizational developers design approaches for the transformation of implicit knowledge into explicit knowledge. Some conventional methods for transformation are given below:
Questioning techniques. A standardized questionnaire, a survey on knowledge, or interviews with predefined questions allows the collection of a variety of information in the same form. The advantage here is the target specific data collection. Stakeholders are no longer tempted to provide irrelevant information. The disadvantage of this approach is the fact that because of the specific formulation of the questions, certain results are predetermined, or respectively, certain aspects are excluded. This can be partially overcome through the inclusion of open questions.
Creativity techniques. Various methods, such as the well-known brainstorming, allow accumulating valuable knowledge in the course of analysis. An interesting approach is the so-called six-hat-thinking (de Bono 2006). Each stakeholder has to play six different roles and should try to describe these roles from their individual perspectives. This allows the widening of potentially limited subjective views. Other well-known creativity techniques, which can be used for analysis, are mind-mapping, the 6-3-5 method, the morphological box, the stimulus word analysis, or the Osborne checklist (cf. Backerra et al. 2007).
Observation techniques. In cases in which collaboration with stakeholders is difficult due to cost or time constraints, the analyzer can himself observe. However, this should be done using an appropriate technique; otherwise, the analysis runs the risk of delivering an individual target concept without a sound absorbing of relevant knowledge. An effective method for the latter is “apprenticing”. The analyzer learns the tasks of a stakeholder involved in the process, runs these tasks himself, and captures his associated experience. This technique however will only work with manageable units of work, which do not require additional training, as needed for expert activities.
The results are usually documented in natural language.
Do not collect data for the sake of collecting. A strategy aimed at the target reflection should guide the collection of data for analysis.
4.7 Evaluate and Decide
At the end of an analysis, a preliminary assessment has to be done. An analysis is not a mere collection of data, but rather clearly reveals the following:
Which results are well structured, and which are confusing and require clarification?
Which subjects have a clearly described field of operation, and which subject descriptions lead to the impression that not everything was documented, although this would be a requirement for achieving the objectives (e.g., workflow definition)?
Which phases of the process most likely need support, and which do not?
These observations have to be documented conclusively, in addition to the process constraints and the language-oriented analysis.
Finally, the Facilitator needs to clarify how to proceed. The determination of the maturity level can help to identify further steps along the path of the S-BPM process model.
The analysis is considered complete as soon as sufficient material could be collected, structured, and evaluated according to the original objective, so that further S-BPM bundles of activities can be processed.
Open Access. This chapter is distributed under the terms of the Creative Commons Attribution Non-commercial License, which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.
