1 The Challenge

During our initial meeting with our client, the later project manager described to us the challenges confronting his company because of the severe competition on the market and the growing demands of its customers:

“We see ourselves as a broker between our customers and the service providers . Our customers expect us to coordinate the contract execution completely, but they also want us to be faster and more flexible in our service performance. Even if the contract award and execution become highly dynamic through flexible design, we cannot really allow ourselves any mistakes in the billing , and the billing cannot become too complicated from the customers’ standpoint. If we do not meet our customers’ expectations, they can also go straight to our service providers to make their purchases”.

“Our customers can place their orders on a customer portal, on the phone, or by email. For example, we receive orders from new customers via email or by phone when we have a contract with them, but their account has not yet been created for administration on the portal. We utilize a large ERP system to coordinate the orders. We have attached a service portal to the ERP system and use it to pass the orders on to our service providers. Billing of customers on behalf of the service providers is handled by the ERP system. A file for internal offset of services and reconciliation of balances is generated from this system. Customers can see the progress of the orders on the customer portal, but not completely. The service providers can report progress for order execution via their service performance portal, but not completely. The progress reports from the service providers are synchronized only in part with the progress reports we place on the customer portal”.

“We always have a problem when a customer wants to make changes after placing an order and the order has already been sent to our service providers. Things really become complicated when our service provider bills a customer for a change in services agreed upon with the customer, but we don’t know anything about it. We cannot make the changes directly in the order in either of these cases. We must take the long way around of working with cancellations, new orders, and unstructured order references. There are similar complications when something changes in the customer’s master data during the performance and billing of the service and the master data are not maintained properly.”

This was how our client expressed its requirements for a consistent and complete digitalization of its service performance and billing process. Taking the description of requirements, we distilled the following approaches as the starting points for optimization and concentrated especially on finding solutions to them during the course of the complete and consistent process digitalization:

  • The data about the customer, contract, service provider, and invoice are located in separate systems.

  • The lifecycle of an order is not consistently defined and implemented from the customer order to the contracting of the service provider to the accomplishment and billing.

  • The central IT system for service performance and billing is the ERP system.

  • The ERP system supports a standardized process for service performance and billing which does not completely cover the client’s requirements. When there are changes in the order, the rigidity of the standardized process causes additional expenditures of time and effort in processing.

  • Information used for service performance and billing is not available when it is needed.

2 The Solution

During the first two steps, we did some work on the architecture aimed at complete and consistent digitalization of the process and the exploitation of optimization potential. The first step was to analyze the processes from an end-to-end (E-t-E) view; afterwards, we designed a three-layer architecture for the implementation. We did not commence design, automation, and integration of the process until the work on the architecture had been completed. For the process work, we used subject-oriented business process management (S-BPM) and a suite of tools which supports S-BPM in modeling and implementing processes.

End-to-end (E-t-E) view in the process

To begin with, we incorporated the end-to-end view into our client’s architecture as a means of structuring and reducing process complexity. This enabled us to decompose a process monolith into six separate processes. The functional scope was defined for each process and clearly distinguished from the others. The E-t-E view is moreover an approach for the complete and consistent identification of the required business objects and their lifecycles. Using the E-t-E view provides a dedicated trigger for the launch of each process. At the same time, the E-t-E view is used to identify the business object which is the necessary input for the process. It also identifies the business object which is handled within the process and which becomes available as the output when the process has been executed. From the E-t-E view, it is possible at a later time to derive important business statuses for the specification of the lifecycle of a business object and consequently to identify flag stops for process measurement and process management. The E-t-E view of the process results in the following clear structure (Fig. 6.1).

Fig. 6.1
figure 1

E-t-E process view

Full size image

The E-t-E view of the process revealed the following business objects (along with others), including the appropriate, relevant business definitions.

The service order is received on the customer portal, by email, by fax, or on the phone.

A service provider order to a suitable and available service provider is generated for every service order item.

The service providers enter a service report for every service order item (service provider order).

The customer invoice showing all of the reported service order items for a time period for a specific customer is issued.

The service provider credit note showing all of the reported service order items for a time period for a specific service provider is issued.

The change is related to one service order and can affect one or more service order items and consequently one or more service provider orders.

Architecture structure for process digitalization

In the next step, we supplemented the process architecture by the addition of another layer based on the clearly structured E-t-E view. The result was an architecture comprising three layers. The process logic was capsulated in its own layer for the consistent and complete process digitalization. This approach made it possible to decouple the process for the complete and consistent process digitalization from the restrictions imposed by existing interfaces in the legacy systems.

The process with the business process functions and process logic is located in the process layer. The process is characterized by its subject-oriented nature. This means that the business process functions are executed as the internal behavior of a subject (process worker), and the subjects are synchronized during process execution via their communication relationship, the exchange of messages. The process logic is implemented in a workflow engine. Each process function is implemented either as a manual activity or automatically by a Web service call or automatically by a number of Web service calls within a business context. So the services required for a complete and consistent digitalization are orchestrated according to business procedures along the process logic and brought together with the manual activities in the process layer.

The services for the automation of the process and integration of the data-carrying systems and legacy systems are located in the integration layer. The services are integrated into the process by means of service calls from the process layer. The file structure of the services is aligned with the business capabilities required to execute the process or to be able to carry out our client’s business. We defined these business capabilities in consultation with the client independently of the IT system landscape currently in operation and the implemented processes. The file structure aligned with business capabilities is what makes it possible to differentiate clearly, retrieve, and thereby achieve the greatest possible reusability of the services. Figure 6.2 shows a part of the service repository created in this way. We decided against the integration of an enterprise service bus (ESB) for the realization of the integration layer because the highly standardized services available from the ESB do not, from the business perspective, satisfy the process requirements.

Fig. 6.2
figure 2

Architecture structure for process digitalization

Full size image

The data objects are located in the data layer. The data objects are differentiated along business lines and allocated without overlap to the business capabilities required to execute the process or to carry out our client’s business. Simultaneously with the differentiation along business lines of the data objects and the allocation without any overlap, a system which takes over create, update, and delete functions for the data object was allocated to every data object. This approach clearly defined responsibility for data maintenance without any overlap. In this way, the redundant maintenance of the data and the required validation and consolidation of the data within the framework of process execution could be reduced to a minimum. The ERP system was retained as the central data-carrying system, a step which secured the investments in the ERP system. In the future, a far greater share of the necessary changes can be covered using the standards in the ERP system. It became possible to reduce significantly the expenditures for any client-specific changes in the ERP system because their implementation had been shifted to the process layer.

Subject-oriented design of the processes

We used the S-BPM approach for modeling the processes in the process layer and a workflow engine which made it possible to generate 1-to-1 the process application for implementation of the process logic from the process models. I would like to emphasize this especially: no more programming is required for the implementation of the process logic because the application is generated from the models. This means that changes in our client’s process logic now lead solely to modeling expenditures. Changes in the process involve development expenditures only if and when the Web services for process automation and process integration must be modified, supplemented, or newly developed. Thanks to the creation of a process layer characterized by subject orientation, our client is able to reduce significantly the change cycles and change expenditures. This process layer gave our client the ability to implement changes in the process flexibly and quickly. Even before the project was completed, our client had discovered that it now had at its disposal an instrument for the design of agile processes which could be used for differentiation from the competition.

The question still remains whether the business users, the process agents, are capable of working with these flexible and quick changes and of adapting their daily work to them.

Our client was able to answer this question with a clear YES. The justification for this YES was just as simple as the method we used for the design of the processes in the process layer. The business users designed and modeled their processes and any necessary changes themselves. The process logic they had designed themselves and the collaboration in the process could be experienced and tangibly handled immediately after being modeled in a process application (Fig. 6.3).

Fig. 6.3
figure 3

Democratization of the process transformation

Full size image

It is not necessary for me to give a comprehensive explanation of the method in a book on S-BPM in the Wild. My co-authors have certainly done a fine job of this. At this point, I want to address only a couple of critical success factors for process digitalization which we were able to influence to the benefit of our client by using the S-BPM approach.

Utilization and acceptance of the modeling language among business users

Five symbols in combination with natural language generate unambiguous statements. The business users immediately grasped how the modeling works. It was a particular moment of revelation for us when the business users realized that the description of process functions and their explanations could be seen 1-to-1 in their process applications as well and not only in the models. In this way, the process models served not only to describe the process, but were also usable as operating procedures in the process application.

Willingness of the business users to contribute during the modeling workshops

During the first workshop, we spoke “only” about the communication relationship among the process subjects and determined what information would have to be shared. This led straight to addressing critical points in the collaboration model among the process subjects. The business users found out in the very first workshop that tasks were in reality not distributed in the way provided for in the company’s governance model. We did not sweep these critical points under the rug. We conducted an exhaustive discussion of these topics so that we could achieve an improved, yet feasible, process sequence in our client’s organization. The constructive criticism from this head-on confrontation with current issues and the easily understandable presentation of a solution using only two symbols (the subject and the message) caused any initial reservations on the part of the business users to evaporate.

Lasting acceptance of the workshop results and interaction with IT

Right from the beginning, we had representatives from the IT department sitting alongside the representatives from the business side in the workshops. This was initially only of symbolic importance. We wanted to demonstrate that the business side and IT sit down together and collaborate on a model. During a later project phase, when Web services for the automation and integration were implemented for the refinement of the process, we showed that we did not intend this to be a purely symbolic gesture. We were able to prove that business users and IT speak one language and are talking about the same model. As mentioned above, the same designations and descriptions found in the process model we had drawn up along with the business users in the workshops were used in the process application. Using these designations, the business users communicated their requests for changes in the process application to IT. Here at the latest, the business users noticed that we had not just conducted yet another workshop on process modeling. The business users had the tangible experience of seeing their business models being used by IT and realized 1-to-1. The business users accepted their workshop results as models which were established at the working level sustainable and as their own processes and applications.

Management support

When it came to bringing management on board, we observed that the use of S-BPM gave rise to a phenomenon which made it substantially easier to gain the unqualified support of management. The business users regarded themselves as the owners of the designed processes and saw how these processes were implemented 1-to-1 in process applications. This proprietary sense prompted the business users to make their own attempts to convince management of the correctness and necessity of the process implementation. Our client’s business users assumed the role of project marketing. During the meetings for presentation of the interim results, the business users themselves took the floor and presented the process application and its benefits. Management’s response was only logical: If our own employees are convinced of the value and have been given a lever for achieving our goals in the form of the process application, then we will give our support. At the first presentation of interim results, the project was no longer our project that we, the consultants, were conducting for our client. The project was now our client’s project and belonged to the employees from the business side and IT; we, the consultants, were merely guides.

3 The Project Work

We organized the project on the basis of the Scrum rhythm so that we could get a handle on the complexity. Our basis for the conduct of the modeling workshops was a participation-acceptance model which would maintain the highest possible level of motivation among the workshop participants throughout all of the workshops in the series. We proactively designed the communication of the project results to match the rise in the business users’ understanding of their process.

3.1 Agile Procedure in Scrum Rhythm

We aligned the process releases to the E-t-E processes and differentiated them in accordance with the growing process automation and integration. At the end of every sprint, a process application was presented as a process increment in the sprint review. The process application became more refined with each successive sprint, i.e., the degree of automation and integration grew from one sprint to the next. In discussing the process backlog items, we spoke about communications model, internal behavior, business object specification, business object mapping, rules, forms, interfaces, and Web services. The chart outlines how all of the process backlog items always contributed to the creation and modification of a process application as a process increment (Fig. 6.4).

Fig. 6.4
figure 4

Adaptation of Scrum for subject-oriented process digitalization

Full size image

3.2 Participation-Acceptance Model (PAM)

The conduct of a workshop, and the conduct of an entire series of workshops in particular, demands tremendous concentration, discipline, and stamina from facilitator and participants. The paradigm of a subject-oriented approach for process digitalization which shifts the focus of the approach to the process subjects can be transferred to the design and conduct of workshops as well by using the PAM. Speaking concretely, this means putting yourself in the shoes of the workshop participants and orienting the workshop to their fundamental motivation and willingness to participate actively. We have observed that the participants’ motivation to participate in and contribute actively to the workshop results in changes over the course of a workshop or of a series of workshops. By becoming aware of these changes, facilitators can adjust and adapt the style of the workshops to take advantage of these differences (Fig. 6.5).

Fig. 6.5
figure 5

Participation-acceptance model (PAM)

Full size image

Motivation Phase (1) Skepticism

At the beginning, most of the workshop participants were skeptical and did not yet know what the project’s goal would be or how it would be achieved. The motivation level was not especially high.

We attempted to keep this phase of skepticism as short as possible. We began by asking participants about their expectations and writing their responses on a flip chart. This was followed by our concretization of the workshop’s objectives so that all of the participants entered into the discussions on an equal footing.

Motivation Phase (2) Yes, we can!

During the second motivation phase of “Yes, we can!”, there was a significant rise in the motivation level. It was important that we were able to point to the most concrete results possible at the end of every workshop so that the “Yes, we can!” phase was established as firmly as possible in the participants’ minds.

During this phase, we were able to lay the groundwork which would prevent the collapse of motivation during the phase of disillusionment from becoming too great.

Motivation Phase (3) Disillusionment

The motivation curve took a downward dip during the phase of disillusionment in this project as well. We were unable to make any precise predictions about this phase because we could not foresee when the light would go on for which participants. Disillusionment may occur, for instance, from a change in the conference room used for workshops if the general conditions in the new conference room are not as optimal. But disillusionment may also result from major insights gained by a workshop participant from the business side about his/her process, the processed data, and his/her workplace. During the section “spectrum of process transformation”, possible insights are described and our workshop facilitators are sensitized to them, making it possible to deal proactively with the issues.

We sought to minimize the drop in motivation levels right from the previous “Yes, we can!” phase. At the end of each workshop, we made the results transparent and asked a workshop participant to present them.

Motivation Phase (4) Routine

The group dynamics which had been generated ran their course during the routine phase of this project as well. Now it was important to do the practical work conscientiously. We communicated all of the results, we spoke frankly about impediments, and we collaborated in the drafting of strategies to remove impediments. During the routine phase, we regularly recalled the project objectives and communicated the progress that had been made in reaching these objectives.

Here is another highly practical tip for fostering motivation. We went to the creative laboratory for the modeling during the first sprints. This is a room with a sofa, various chairs—some comfortable, some uncomfortable—toys and, above all, large-area walls offering plenty of space for modeling—writing down ideas and suggestions, then erasing them again. This unusual environment surprised the workshop participants and opened a door to their collaboration during the workshop.

3.3 Spectrum of Process Transformation

Management of expectations is especially significant during projects for subject-oriented process digitalization. As a consequence of the subject-oriented process digitalization, there may be substantial changes in the working environment of the process workers, who have expectations concerning these changes. It was important to become highly aware of these expectations and to channel them in communication with the business users and management for two reasons: one, to avoid disappointment of these expectations, and second, to prevent the changes from overwhelming the process subjects. Over the course of our projects, we have identified six major areas for change. These areas should be actively guided in the communication with the client so that the success of the project is not jeopardized.

Another aspect of these changes is that every change is related to insights about the process gained by the business users. Every change is related to a project result and can lead to a fundamental reassessment of the process and the collaboration in the business department. This fundamental reassessment can precipitate a crisis in the project if it changes people’s understanding of the way work is done in the business and IT departments. But mastering the crisis also leads to change in behavior, lasting improvement, and even innovations. Findings can also lead to revamping of communications, internal behavior, and distribution of tasks. In such a case, it is highly valuable to have a system for concretization of the changes available for execution at any time so that the changes can be made tangible (Fig. 6.6).

Fig. 6.6
figure 6

Spectrum of process transformation

Full size image

Processes

The participating project members see and recognize who is involved in the process, how communication proceeds (content), and what tasks must be completed at every step of the process.

The starting prerequisites for the process and the process objectives are clear to all of the involved parties.

Data

The required data (input and output) are modeled. There is an exact definition of what data in the process are processed/required by what subject at what point in time and who will make these data available.

Workplace

The computer workplace is designed. The great revelation: “This is how I work?! This is how tasks are shared?!” A “new” workplace is created for the employees on the business side. It is important to point out to them the advantages of the new workplace and to guide them into the new processes.

The project employees recognize that the type of process and data modeling leads directly to a certain way of working at the computer monitor.

Automation

By this time at the latest, the project employees accept the present, process-oriented IT application.

The project employees recognize that the quality and user friendliness at the workplace can be substantially improved through various steps of automation. Process acceleration and improvements are also realized here.

The automation of statuses simplifies the users’ workplaces.

Transparency

Information in the form of data which can be assessed using IT is now available for every step of the process and can be taken as a basis for analysis and improvement of the process.

Even if supervisors do not play an active role in the process, the enhanced transparency results in the recognition and demand for new management mechanisms/management processes.

This serves as a basis for the generation of qualified KPIs for evaluating, planning, and managing the process in real time.

Optimization

Cross-department opportunities for optimization are recognized. Operating procedures for the users are derived from the process description. The clarity of the operating procedures is reviewed.

At this point, all of the users from the business side join in as input sources and contribute what they have noticed and experienced as improvements.

4 Summary and Outlook

Subject-oriented digitalization of processes will do more than promote the establishment of BPM as a management discipline in companies. The design, implementation, and practicability of processes are raised to a previously unknown level of quality. We will see this happening when we have a full-area market for tools which can generate 1-to-1 the process applications for executing the process logic from the business models and simultaneously utilize these business models to orchestrate the IT functions for process automation and integration. Like us, many others will also discover the advantages which arise when the business side and IT really speak one and the same language and navigate through the process in the same model (Fig. 6.7).

Fig. 6.7
figure 7

Process digitalization with S-BPM at a glance

Full size image

I am looking forward to working on more projects for complete and consistent process digitalization using S-BPM, and I would like to see the market for the appropriate tools grow over the coming years and the method become the standard. When this happens, BPM will finally be able to keep all of its promises from recent years.