Overcoming the Innovator’s Dilemma in Disruptive Process Innovation Through Subject Orientation

Abstract

Once digital technologies trigger business process management and change, organizations are challenged to (re)position their products and services. Thereby, creating disruptions could help overcoming the threat of being blindsided by novel developments. We consider Subject-oriented Business Process Management being capable to create socially acceptable organizational disruption through process modelling and explorative execution. S-BPM capabilities adjust changes in customer, product and organizational management through its unifying communication perspective. In this contribution, we report on creating disruptive innovation starting with subject-oriented re-design of work and production processes. The presented case, a large transformation process of an automotive company reveals that this type of disruptiveness enables an integrative perspective on existing work procedure in an aligned, since synchronized way. Hence, we can conclude that a starting point for innovation is grasping the collaborative nature of existing processes rather re-establishing functional positions and procedures.

1 Introduction

New digital technologies start changing business and production processes substantially. In ‘The Innovator’s Dilemma’ Clayton Christensen [1] has analysed how companies can be blindsided by low-end products from competing organizations. In ‘The Innovator’s Solution’ Christensen et al. [2] reveal how organizations can create disruptions themselves rather than being blindsided by them. Subject-oriented Business Process Management [3] has not only been successfully introduced into various fields [4], including digital production [5], but is rather capable to create socially acceptable organizational disruption through process modelling and explorative execution [6]. The major reason for that are the S-BPM capabilities allowing to adjust changes in customer, product and organizational management through a unifying communication pattern.

In line with Christensen, in this contribution, we discuss creating disruptive innovations through subject-oriented re-design of work and production processes. We present a case from automotive industry undergoing a large transformation process. The subject-oriented intervention reveals that this type of disruptiveness enables an integrative perspective on existing work procedure for the first time. The behavior of stakeholders and systems can be aligned through synchronizing their specification, in particular their communication patterns. To achieve such integration, we can conclude, the collaborative nature of existing processes should serve as a starting point for innovation. As such, focusing and finally re-establishing functional positions and procedures should move to the background in the course of organizational interventions.

The contribution is structured as follows. After this introduction, we reflect on the major reasons Christensen identified for enterprises being blindsided by disruptors. The recommendations how to avoid this and how to drive disruptive innovation successfully are also subject of Sect. 2. In Sect. 3 we present Subject-oriented Business Process Management (S-BPM) as an approach for mastering organizational disruption. Section 4 exemplifies a corresponding use case stemming from automotive industry. We conclude the contribution sketching the objective, achievements, and further research.

2 The Innovator’s Dilemma and Solution

When analyzing the Innovator’s Dilemma Christensen distinguishes between sustaining and disruptive innovation [1]. Sustaining innovation is characterized by performance improvement of existing products along attributes being valued by major customers in the mainstream market.

To profitably satisfy the needs of their customers, enterprises work in a certain value network with channel partners and suppliers. The value network determines the operating processes and the cost structure (indirect, direct cost), with the latter also impacting the need for size, margin and growth.

The value network determines the cost structure (indirect, direct cost), and depending on that, the need for size, margin and growth. It also shapes the organizational capabilities, according to Christensen becoming manifest in the Resources-Processes-Values Framework (RPV). Resources like people, equipment, technology, product designs, brands, information, cash, relationships with partners (customers, suppliers, distributors etc.) are the most tangible, visible and measurable factors. They are quite flexible and can relatively easy be exchanged, transferred across organizational boundaries etc. Processes are patterns of interaction, coordination, communication, and decision-making through which organizations transform inputs into outputs. They can be formal or informal and are always used to perform specific tasks efficiently. Well-performing organization have their processes optimally aligned to the tasks, assuring that employees perform recurrent tasks in a consistent way. Changes are not intended, and if, however, needed, must follow tightly controlled procedures. Hence, the value creation processes tend to be very solid. Values include the criteria managers and employees on every level of the organization use when making prioritization decisions. They usually reflect the cost structure and business model, mainly gross margin and size of a business to be accepted. As resources can be exchanged easier, organizational capabilities primarily reside in processes and values.

Based on these facts, Christensen observed that established competitors are very good in marketing sustaining innovation within their existing value network and with their given cost structure. The market is well known and the customers are well understood and are offered improved products at the high end of the market. This gives the incumbents the opportunity to strive for high margin and high growth. They have well-defined processes in place, optimally adjusted to the tasks to be accomplished.

However, this quite comfortable position makes enterprises prone to be blindsided by newcomers with disruptive innovations. Here the value proposition brought to market is different. With products, which are simpler, smaller, cheaper and more convenient to use disruptors aim for the low end of a market or a completely new market. Surprisingly this is also true in many cases, where established enterprises for example were the first to develop innovative technology. The reasons presented by Christensen are manifold. Rather than finding and shaping a new market, the incumbents try to sell the innovation in the existing market, where customers currently do not show need for the new product or service. They have no practiced processes to handle disruption which comes too fast, and disruption is inconsistent with the existing values. As a consequence, they often try to use the processes which work well for their established business also for marketing the disruptive innovation (one-size-fits-all processes). But capabilities are shaped within value networks and thus very specialized and different for launching sustaining innovation on existing markets and bringing disruptive innovation to new markets.

Taking these observations into account, Christensen and Raynor suggest several principles to solve the Innovator’s dilemma [2]. Following them should facilitate incumbents to successfully launch disruptive innovation and not leave space for newcomers to jump in. Selected principles are:

• 1. Grant autonomy: disruptive business needs the freedom to create a new organization, in particular new processes, and to build a unique cost structure in order to be profitable.

• 2. Avoid one-process/one-organization-fits-all policy for all types of innovation: disruptive change requires the creation of new resources, new processes and new values.

• 3. Create new processes and align every critical process and decision to fit the disruptive circumstance: radically different processes are not created by drawing flow charts but by ‘heavyweight’ teams which are confronted with problems the organization never faced before [7].

• 4. Follow emergent strategy making approach: particularly in early stages of disruption, where it is not clear, what the right strategy would be, strategy comes up from day-to-day decisions.

• 5. Develop an understanding of technology, customers and markets: try, fail, learn quickly and try again.

• 6. Assign managers with the right ‘school of experience’: a person in charge for a disruptive business should have experience in managing disruptive innovation, no matter if successful or not, as long as he or she went through a learning process.

3 Tackling the Innovator’s Dilemma with Subject-Oriented Business Process Management (S-BPM)

In this section, we firstly introduce S-BPM as an approach managing business processes before applying its concept to handle disruptive interventions for innovating the structure of work organizations.

3.1 Subject-Oriented Business Process Management in a Nutshell

S-BPM Fundamentals.

Subject-oriented BPM (S-BPM) is a stakeholder- and communication-oriented paradigm [3]. It focuses on subjects as the acting parties in processes (people, systems) who represent abstract behavior descriptions and exchange messages in order to coordinate their mutual work. Activities in a behavior are denoted by predicates and objects are the targets of the activities. Subject representatives can specify their behaviors independently as long as they do not touch the messages (interfaces) or agree upon changes with their communication partners. This behavior encapsulation allows highly flexible self-organization, with the communication structure assuring overall coordination. Subject-orientation has been inspired by various process algebras, the basic structure of nearly all natural languages (Subject, Predicate, Object) [3], and the systemic sociology developed by Luhmann [8]. An easy-to-use graphical notation with only a few symbols allows non-method expert to model the subjects’ interaction and behaviors. Figure 1 summarizes the various inspirations, the resulting development phases of S-BPM and enhancements.

Fig. 1.

S-BPM foundation

S-BPM notation.

The easy-to-use graphical notation needs only five symbols to build the two diagrams necessary to describe a process. In the so-called subject interaction diagram (SID), the subjects as process-specific roles and their message exchange are documented. Payloads of messages are complex business objects or simple parameters. Figure 2 shows the two language elements needed to model an SID for a simple process, where employees send business trip requests to a manager, who decides on the request, informs the applicant respectively, and, in case of approval, passes the request on to a travel agent for further processing.

Fig. 2.

Subject interaction diagram (BT = Business Trip)

In a refinement step, the subject behavior diagrams (SBD) are created. Subject representatives as modelers specify the activities and interactions their roles have to perform when executing the process. They also define data structures for business objects to be created, manipulated and exchanged in the subject behavior. Figure 3 depicts the subject behaviors of the employee (left) and the manager (right). With only three different notation elements each diagram shows the sequence of executing internal actions (functions) as well as sending and receiving operations. The state transitions ‘To: Manager; BT Request’ in the employee behavior and ‘From: Employee; BT Request’ in the manager behavior are examples for how the subjects synchronize their communication via messages during process execution. The transition ‘To: Travel agent; BT Request approved’ links to the behavior of the subject travel agent, which in its behavior (not included in the figure) receives the message and processes the data before it comes to an end.

Fig. 3.

SBD ‘employee’ (left) and SBD ‘manager’ (right)

S-BPM roles [14].

S-BPM lifecycle activities are driven and performed by persons acting in certain roles triggering, guiding, implementing and reflecting process management projects: Governors care about the constraints under which BPM activities are performed by focusing on influential factors of change processes. They also set up S-BPM structures by addressing relevant BPM stakeholders. Actors execute business procedures, and interact mutually, to deliver products and services. They are supported by experts and facilitators with respect to S-BPM activities. Experts are IT architects, organizational developers, or specific domain specialists, and support S-BPM activities on demand. Finally, facilitators are required for guiding development processes, as they take care about the social acceptability of change proposals on the organizational level.

S-BPM lifecycle activities [14].

Each of the introduced roles might get involved in each of the following bundles of S-BPM activities:

In the course of analysis models are set up reflecting a situation of an organization ‘as it is’. Facilitators, governors, and actors collaborate to scope a certain universe of discourse (Analyzing). While modeling, envisioned processes are specified (Modeling). They need to be validated to ensure their effectiveness (Validating). It is checked whether a process produces expected results. In this bundle of activities mostly the actors and method specialists are involved, as they need to validate communication and functional procedures with respect to the quality of work results. Once a process has been validated, it can be optimized to certain criteria, checking the efficiency of a modeled process (Optimizing). Resource-specific aspects such as time and material consumption are investigated, and might lead to significant changes. To feed the results back to the running business, the process models must become operational on the organizational and technology level (Embodying). Governors and facilitators guide this alignment to existing structures, infrastructure, and strategy of an organization. Once in operation, business processes need to be monitored and analyzed again (Running and Monitoring). The sketched lifecycle activities are in line with existing BPM approaches and can be performed in linear sequence or non-linear order (see Fig. 4).

Fig. 4.

Flexible S-BPM life cycle

3.2 S-BPM Featuring Disruptive Innovation

In the following we review the key characteristics of S-BPM in the context of triggering disruptive interventions and guiding constructive exploration of stakeholder and system behavior. We start out with detailing today’s intervention scenarios and proceed with structuring the organizational development process along the Innovator’s solution principles.

Starting either with low- or high-end disruption, processes and all related (re-) engineering tasks are affected. It is not only the management per se that has become crucial for operating a business [2], but the way of organizing them and the quality that can be achieved by that organization: ‘Processes are defined or evolve to address specific tasks, and the efficiency of a given process is determined by how well these tasks are performed. Processes that define capabilities in executing certain tasks concurrently define disabilities in executing others. Consistency is key - processes are not as flexible as resources, and must be applied in a consistent manner, time after time.’ ([9], p. 7).

Given the current trend in digitalization, individual stakeholders design business operation, so that changes directly propagate from specification to operation. Adaptation of business processes at an early stage, including introducing automated behaviour through digital systems, seems to be the key [10]. Thereby, customers, network partners, management, and workers are involved, as processes concern all stakeholders. S-BPM involves them not only according to their mutually interacting functional roles or in terms of networked organisational units, but also as designers, and more particularly, engineers. The engineering part is required since ad-hoc dynamics of change are becoming common due to concepts like demand-driven excellence [11].

As such concepts shift organizational change management to the level of business operation, S-BPM actors require a proper support reaching beyond traditional domains skills. Any notation and change management needs to consider collaboration, thus, challenging means of communication rather than domain expertise. With respect to process design and engineering activities, both the notation, and modelling process including stakeholder validation, need to be supported in a human-centred way. Otherwise, stakeholder participation is likely to lead to re-specifying existing patterns and behaviour rather than letting emerge novel designs (cf. [12]).

Setting the stage for disruptive, stakeholder-driven work re-design and process engineering, S-BPM implements all principles of Christensen’s solution:

• Utilizing S-BPM modeling and execution capabilities actors can create a completely new organization, and thus system and role behaviors. As parallelism is key, the cost structure for each behavior can be considered separately without lacking general profitability.

• Behavior particularities can be kept as long as communication interfaces between subjects are included in design considerations. Rather than standardized behaviors, a variety of ways to accomplish tasks can be expected.

• Innovation is actively run by concerned actors by means of S-BPM due its simple notation, role concept, and development procedure. Facilitators guide the S-BPM process, whereas governors take care of organizational particularities. Finally, experts could jump into development processes to clarify S-BPM or domain issues.

• Strategy can emerge in a coherent (not on day-to-day basis) from the bottom to the top, since S-BPM needs the operational basis through its models, however representing the entire organization – since each stakeholder or system becomes a subject, their interaction pattern finally represents an organization’s behavior (albeit asynchronous behavior encapsulation representing parallelism as in real life).

• S-BPM considers technology, customers, and markets at the same time, and in a dynamic way: Customers and market representatives are modeled as subjects, and thus, their behavior is captured the same way. Once processes are validated they can be implemented technically through model execution. The cycle ‘try, fail, learn quickly and try again’ is supported for each stakeholder or system represented as subject.

• S-BPM’s facilitators and governors are in charge for managing disruptive innovation, both from the domain, and social process perspective. However, they do not interfere in actors’ individual behavior modeling.

Consequently, each disruptive innovation through S-BPM is a two-staged procedure, driven by the specifying self-contained operation entities (subjects) and then, executing those specifications to evaluate whether business objectives can be achieved running the operation in the novel way.

Autonomous self-organization.

The actor-based, decentral specification of work behavior as a characteristic of S-BPM is a cornerstone of autonomously creating new processes for the disruptive business. The approach and the easy-to-use notation facilitate comprehensive stakeholder inclusion. This allows to form a heavyweight team of people from various functional units, who are involved in the process to be developed. Each member represents a subject, describes the respective behavior and altogether they coordinate their interaction and thus build the process.

Explorative process execution.

The graphical notation of the S-BPM modeling language is based on a process algebra with a clear formal semantic allowing automated code generation. This makes subject-oriented processes built by the participant’s executable on the fly. It empowers them to instantly validate their work design without having IT specialists involved (‘what you model is what you execute’). Issues identified during validation can be changed in the model and the result be tested again right away. Same is valid for weaknesses or other needs of changes which actors observe when they execute implemented processes in daily operation. The S-BPM lifecycle allows for non-linear sequences of BPM activities, depending on the particular situation. Hence, stakeholders can easily and quickly align new and existing processes to disruptive circumstances. Organizational development based on the S-BPM approach facilitates the development and maintenance of adequate business processes for various types of business. It thus helps overcoming the one-process/one-organization-fits-all policy and the disadvantages related to it. This individual, situational fit of processes and the agility with respect to adapting them to changing circumstances form the basis for emergent strategy making and learning as recommended by Christensen and Raynor.

4 Use Case

In this section, we only outline a very complex use case. We show a process system of process systems. This means the complete system consists of several layers of subsystems. These subsystems are connected via messages. According to the subject oriented paradigm these messages are asynchronously exchanged. In this paper, we only show the network hierarchy of the process system. Due to the limited space, we do not show all the message types exchanged between the various systems and components.

4.1 Background and Requirements

Automotive industry will dramatically change during the next couple of years. Digitization will have significant impacts on the physical product car and related services. Services around the automobile “that are sold and delivered digitally are disrupting today’s business processes and models and providing entirely new capabilities.” [16] From a business point of view the major difference between services and classical products is that producing and delivering a service is the same process. In the business with physical products you have production processes, sales processes and service processes around your product.

Digitization will change the car business manifold. There will be new types of cars with alternative drives and fuels, new marketing and sales methods and new mobility related services e.g., multimodal travel services, commerce services, alternatives to ownership, vehicle health diagnostics.

A car will become something like an internet of things. Sensors and physical actors communicate with software actors. Together they build a complex system called car. Cars itself are connected with other cars and various support systems. Cars are a subsystem in a system of systems. Mobility related service processes are also systems in a system of systems.

Car manufacturers will cooperate with respective partners to offer and to produce these new types of cars and the related services. According to [16], about 75% of executives expect highly intense collaboration with other industries to be a growth driver. However, issues at play in the automotive industry are interrelated. Digitization will be shaped by emerging economies and widespread urbanization. Regulations will continue to compel innovation in automobile technology and related service processes [15]. Services that are sold and delivered digitally are disrupting today’s business processes or models and providing entirely new capabilities [16].

The trends outlined above has some significant implications on the design of mobility related products and services. Products and services must be easily adaptable to regulations and preferences of markets. Since these regulations and preferences can change very fast, a mobility system of systems must be adapted to new requirements. These adaptions must be done fast and efficiently. In the best case. this can be done by the related business people.

One system design approach to overcome these problems is reactive programming [17]. Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. Reactive systems are responsive, reactive elastic and message-driven. The S-BPM philosophy meets these requirements. Therefore, this philosophy has been used to design a process system capturing future developments. In addition, reactive process designs can be easily transformed into software systems which support these processes.

4.2 Process Architecture

In this section, we will outline the structure of the aftersales process system. Currently this system covers the subsystem “Accident support” (AS) and “Web service management” (WSM). Basically, these two systems are connected with the messages “Announcement car arrival” and “Confirmation car arrival”. Figure 5 shows the top-level structure of the considered process system.

Fig. 5.

Process system overview

The messages transport the data required in the receiving system. There is no common data access for these two systems. If a message is sent from one system to the other system, a subject in one system sends the message and another subject in the receiving system accepts its. These subjects are called interface subjects.

Each system can be divided into smaller systems which are also connected with messages. Figure 6 shows the internal structure of the process system “Accident support” This process system consists of four other process systems connected with messages.

Fig. 6.

Details of accident support

In this more detailed description the message “Announcement car arrival” is sent from a subject in the process system “Organize measurement”.

Like the process system “Accident support”, the process system “Workshop service management” can be subdivided in process systems. Figure 7 shows that the process system ‘‘Workshop service management” is structured by seven process systems. In this structure the message “Announcement car arrival” sent from inside “Accident support” will be received inside the process system “Agree appointment”.

Fig. 7.

Details of workshop service management

This hierarchy of networks of process systems can have any number of levels depending on the complexity of the considered process system.

The lowest level ends up in a Subject Interaction Diagram (SID). Figure 8 shows the internal structure of the process system “Accident Helpdesk” which is contained in the system “Accident support”. The system “Accident Helpdesk” consists of the subjects “Customer”, “Helpdesk”, “Car data management” and “Ticket system”. In this SID, the subject “Helpdesk” sends the message “Accident data” to the subject “Organize measurement”. In the SID, it is not defined how the subject will be implemented. The subjects “Customer” and “Helpdesk” can be implemented through a combination of human and IT or even completely by IT, if a car is equipped with an automatic accident call. In this case, all the required data will be sent like location, damages, car type, owner, etc. The IT-subject “Helpdesk” receives them and creates an accident ticket automatically. The subjects “Car data management” and “Ticket system” represent data systems anyway and will be completely implemented by IT. Hence, independently from the implementation technology, the communication structure need not be changed, and there will be no impact on the other subjects.

Fig. 8.

Details of accident help desk

For each subject the Subject Behavior Diagram (SID) defines the allowed sequences in which messages are received, sent and internal activities are executed. Figure 9 shows part of the behavior diagram of subject “Helpdesk”. In the start state the message “Accident call” is expected. Most messages transport data as payload. A copy of these payload is stored in the internal data of a subject. This corresponds to the concept of micro-services. Each micro-service has its own data and do not share data directly also subjects do. Each subject has only its private data, thus, data required by a subject from another subject must be transferred by messages from on subject to the other.

Fig. 9.

Behavior of accident help desk

This means additional to the behavior diagram, the specification of a subject also contains its local data, and for each message sent or received the data transported with that data need to be defined. The specification also describes which message parameters are stored in which local data in the case of receiving messages. If a message is sent, then it is defined from which local data the values for the message parameters are copied.

So far, we have outlined the process system “Accident helpdesk” down to the SID-level and a cutout of the SBD of subject “Helpdesk’’. The system “Organize measurement” is more complex. It has several more layers and systems because in this system several partners like workshops, towing companies etc. are involved. It does not matter that these are external organizations. They are also represented by corresponding subjects. A subject-oriented process specification is nearly independent from organizational structures. In particular, services delivered by external parties, can easily be attached to existing internal process systems. Messages are a simple way to connect organizations loosely.

4.3 Tools for Describing Processes

For describing the process system for the two aftersales processes the corresponding standards of the company must be applied. According to play the project management, BPMN must be used as model notation and the tool must be ARIS. For specifying process systems according, the subject-oriented paradigm while utilizing BPMN, a corresponding BPMN subset must be defined. We call it S-BPMN [18]. Figure 10 shows a simple process described in S-BPMN.

Fig. 10.

Behavior in S-BPMN

Subjects are represented by pools, internal activities by tasks, send states by send events and receive messages by receive events. To describe alternative receive messages in BPMN, event-based gateways must be applied and for case distinction the exor gateway is used. To describe the data objects of subjects (pool) and the data payload of messages we use Entity Relationship Diagrams (ERM). BPMN and ERM are supported in ARIS and we connect the various information with each other by links.

For describing the systems hierarchy, we took some other symbols and mechanisms available in ARIS. In general, ARIS was used as a process repository.

ARIS allows exporting BPMN process models in BPMN-XML format. BPMN-XML is a standard for the XML representation of BPMN models. It turns out that ARIS supports event-based gateway symbols, but it does not export it in BPMN-XML. Therefore, we used a normal exor gateway followed by the corresponding receive events.

Data models are not supported by the BPMN-XML export. There is no appropriate direct export available. Here some further investigations are required.

Due to the restricted number of BPMN symbols, we could use the TIBCO (www.tibco.com) workflow engines to execute the process behaviour, however without data. The problem has been that TIBCO does not support BPMN-XML. TIBCO uses XPDL as an internal format. Therefore it was necessary to transform BPMN-XML to XPDL. In the trial, the transformation was done manually. We modelled the test process again by using the TIBCO Studio.

4.4 Experience and Status

The first process-system version has focused on the German market. When propagating into other markets it turns out that it is easy to adapt processes to other markets. Process systems can be removed if they are not required, e.g., as insurance processes are different in the various markets. This shows that the process systems down to subjects can be easily adapted to new situations.

It shows that most business and IT people are not trained in choreography-based BPM approaches like S-BPM. Most people think in control flows. Control flow-oriented BPM concepts like EPC create strongly related activities. Monolithic systems are created which can be changed only with significant effort. There are no building blocks which can be removed, replaced or adapted without impact on other parts of a system. Systems loosely coupled with each other can be easily deployed because a system can be replaced without impact to the other systems if the communication interface is not changed.

One drawback was the migration into a workflow system. Processes should be supported by IT with less programming. To reach best agility process models need to be imported into a workflow engine directly. Our tests showed that this is partially possible, but modelling tools and execution platforms need to be harmonized to that respect.

5 Conclusion

In line with Adam Smith [13] who was looking for a balance of opposing forces, S-BPM provides capabilities of digital process techniques and technologies to recognize and account for human needs when innovating organisations. Striving for a balance means to look beyond ‘training the troops’ [9] as part of the innovator’s solution), since today’s innovation can only sustain through actively engaged stakeholders supported by concepts and tools beyond their domain, focusing on reflective engineering for disruptive socio-technical design.

Hard coded processes prevent progress. New products with different complementary services, marketing and sales strategies must be supported by appropriate processes which can be implemented fast and with less effort. Otherwise innovations can be killed by “hard coded” processes.