Big size corporate companies that opt for Business Process Management (BPM) adoption invest a lot in BPM initiatives with the primary focus on the identi cation and standardization of best practices in the di erent phases of the BPM lifecycle. The business processes designed are usually seen as the standard way of executing the processes and tend not be adapted to speci c customers' need or changing conditions. Furthermore, the acceptance of a paradigm shift by the end users is an added challenge. This case introduces a success story on BPM adoption in complex environments where di erent organizational units with di erent needs are involved. The projects executed in di erent units respond to speci c customers' requirements, which a ects the set of processes to be designed and executed within them. We developed a novel approach inspired by the Cyne n framework and used it to de ne process architectures and the respective business process models for a subset of the units. To ensure the applicability and acceptance of the new paradigm we followed a number of well-known methodologies and practices (e.g. SCRUM and gami cation). As a result, we managed to move from the traditional function orientation to BPM orientation taking into consideration the exibility needs, and we received very positive feedback from our end users.
Big size corporate companies that opt for Business Process Management (BPM)
adoption invest a lot in BPM initiatives with the primary focus on the
identi cation and standardization of best practices in the di erent phases of the
BPM lifecycle [
However, in many business elds (e.g. project business of plant
engineering), exibility is strictly required and it is wrong to always want to simplify
and impose standardization with existing BPM frameworks and tools [
This case introduces a success story of a pragmatic approach to adopt BPM
in complex environments with a clear focus on exibility of processes
regarding customer requirements and paradigm shift in the mindset of people. From a
priorly created process map, a blueprint process architecture and its respective
process models were de ned and progressively adapted to more speci c cases
according to the customers' requirements of the projects executed in di erent
organizational units. The approach is inspired by the classi cations and concepts
introduced in the Cyne n framework [
The description of the case is structured as follows. Section 2 describes the context and the speci c challenges that had to be faced. Section 3 explains the solution developed for a smooth BPM adoption. Section 4 summarizes the results achieved. Section 5 re ects on the lessons learned along this work. Finally, Section 6 outlines the conclusions drawn from the work and the future steps. 2
Bil nger1 is a leading international industrial services provider that o ers industrial plants maintenance services, modi cations and plant units (the latter often on a turnkey basis) in two service lines: Technologies, and Engineering & Maintenance. The group consists of numerous mid-sized companies mostly covering the areas of Continental Europe, Northwest Europe, North America and the Middle East, which often execute projects jointly making vast use of synergy e ects. With its 36,000 employees, Bil nger upholds the highest standards
of safety and quality and generated a revenue of e4.153 billion in the nancial year 2018.
Due to historical reasons, the group companies are in their majority highly specialized and maintain discipline-oriented procedures as internal standards for their operative processes. A Bil nger project consists of di erent scope modules that can be executed by di erent units within Bil nger (e.g. Engineering Electrical is performed by Company A, the Engineering process by Company B, and Construction by Company C). Such scope modules are often modi ed by client-speci c requirements. Speci cally, Bil nger prepares for projects during the tender phase from a baseline mainly consisting of the project execution plan, the schedule and the budget. Changes to this baseline are only allowed for good reasons { usually because the client changes the scope or external circumstances require changing the execution sequence. Therefore, the process model for the project must be frozen at project start. It is a copy of the universal enterprise process model stripped down to the relevant processes and altered and amended in accordance to the project speci c needs. Improvements to the universal enterprise business processes are not automatically transferred. They are manually introduced if necessary. A change of the project baseline requires a review of the respective project process model. During execution, Quality Assurance (QA) is enforced using the project process model as a basis for the audits.
As a rst e ort towards BPM adoption, the Bil nger Process and System
Harmonization program was launched in 2017. The rst focus was put on the
commercial processes. The process map [
A second phase of the program would target the operation processes, which comprise the most value-adding functionalities for the business and must be adapted for speci c projects. As aforementioned, projects have speci c requirements that need to be considered in project processes by modifying standard company processes. Without such an adaptation, there would be no chance to check how far project requirements are ful lled by processes and hence, e ective management of quality control and assurance could not be realized.
Due to the large casuistry and the adaptation needs, the extension to the operation processes in engineering, manufacturing and construction turned out to be much more challenging. Although the advantages of process orientation (based on process models) over the traditional function orientation (with disciplineoriented procedures) had been recognized from the results achieved with the commercial processes, reservations in application for engineering purposes prevailed. Speci cally, the engineers identi ed two key requirements for a proper support of the operation processes: Industrial E2E process overview
In short, exibility was necessary in order to satisfy the customer needs for di erent projects. The actions taken to consider these requirements for the definition and implementation of the operative processes are described next.
Bilfinger Process House Industrial E2E process overview BilfngerSE (Idea-tIo2-MMarket) PSH Process Map 1.M2O(Market-o-Order)
2.O2C(Order-to-Cash) 3.R2S(Request-o-Service) 7.R2P(Request-o-Project) 5.S2D(Stock-to-Disposal) 4.P2P(urchase-to-Pay) H2R (Hire-to-Retire) D2O (Demand-to-Operation) The Corporate Project Management O ce and one of the largest engineering units at Bil nger decided to jointly tackle the challenge to set up a BPM system with all advantages but ample exibility to accommodate engineering needs. The extension of the Bil nger Process and System Harmonization program was carried out in 2018 and took place in two dimensions.
On the one hand, a horizontal development was performed towards a full
process map [
On the other hand, a vertical (top-down) development was conducted towards
a process architecture [
The de nition of the detailed process models as part of the vertical development was the most cumbersome task. Based on our personal experience of unsuccessful huge BPM initiatives in the industry for standardization of the whole business in complex project environments, the plant engineering business of Bil nger decided to increase the reliability of the operation business processes that can be grouped as simple/best practice processes as well as to provide an adaptable backbone for achieving the best quality results. The hypothesis was that individual views (quick starter maps) for individual businesses or entities would increase user acceptance. Bilfinger Proces House SOOMuppapeenBrrBaaouguOttreBiistoospmiuSinnnHenusPeeriuSPeprnansPoemrstetorclsovayjeDeDinncscCceeSeethRstvlssvraePaiesln(tloosHeonu(pg2PprymR2cmin)e&ege)nntt AMcQaounTPuaernlgnMiotetPdycTiamreeesoMgstnrcea&ned(ernMsesCDPr2(ogarBOsenot2mtc)Rreoe)slnietnsg
Bolb oli et
al.
Therefore, we avoided establishing a huge BPM initiative at corp orate level
and selected two pilot units in our pro ject business sector and prioritized
end-toend pro cesses into three waves with di erent typ es of pro cesses. The rst wave
targeted Pro ject Management and Engineering, the second one Pro curement,
Sales and Business Development, and the third and last one Construction and
Commissioning. We exp erimented a novel BPM approach based on the Cyne n
framework [
Cyne n is a so-called sense-making framework, which means that its value is not so much in logical arguments or empirical veri cations as in its e ect on the sense-making and decision-making capabilities of those who use it. It gives decision makers p owerful new constructs that they can use to make sense of a wide range of unsp eci ed problems and is particularly useful in collective sensemaking b ecause it is designed to allow shared understandings to emerge. Key in Cyne n is the notion of un-order (which in pro cess-oriented vo cabulary could be interpreted as exibility ), not as a lack of order but as a di erent kind of order where the whole is never the sum of the parts, every intervention is also a diagnostic and every diagnostic an intervention, and any act changes the nature of the system. Based on this, the Cyne n framework has ve domains, four of which are named, and a fth central area, which is the domain of disorder, as depicted in Fig. 4. The right-hand domains are those of order, the left-hand domains those of un-order, and none of the domains we will describe here is more desirable than any other; there are no implied value axes. In short: { The Simple domain has known causes and e ects whose relationships are generally linear, empirical in nature, and not open to dispute. The objectivity is such that any reasonable person would accept the constraints of best practice. This is the domain of process reengineering, { The Complicated domain has knowable causes and e ects whose relationships may be stable but they may not be fully known, or they may be known only by a limited group of people (experts). Everything in this domain is capable of movement to the known domain. The only issue is whether we can a ord the time and resources to move from the knowable to the known. This is the domain of systems thinking, the learning organization, and the adaptive enterprise, all of which are too often confused with complexity theory. The decision model here is to sense incoming data, analyze that data, and then respond in accordance with expert advice or interpretation of that analysis. { The Complex domain has complex cause-e ect relationships. Patterns may repeat for a time but we cannot be sure that they will continue to repeat because the underlying sources of the patterns are not open to inspection (and the observation of the system may itself disrupt the patterns). Thus, relying on expert opinions based on historically stable patterns of meaning will insu ciently prepare us to recognize and act upon unexpected patterns. The decision model in this space is to create probes to make the patterns or potential patterns more visible beforehand, then sense those patterns and respond by stabilizing the patterns that we nd desirable, by destabilizing those we do not want, and by seeding the space so that patterns we want are more likely to emerge. This requires gaininig multiple perspectives on the nature of the system. { The Chaotic domain has chaos, which means that there are no perceivable relationships between cause and e ect, and the system is turbulent, which implies that we do not have the response time to investigate change. Applying best practice is probably what precipitated chaos in the rst place; there is nothing to analyze; and waiting for patterns to emerge is a waste of time. The decision model in this space is to act, quickly and decisively, to reduce the turbulence; and then to sense immediately the reaction to that intervention so that we can respond accordingly.
When using the Cyne n framework, the way of thinking about moving between domains is as important as the way of thinking about the domain we are in, because a move across boundaries requires a shift to a di erent model of
Bilfinger master process house Include latest version of best practices identified by units
Adapted view for Bilfinger unit 1 (blue print for selected processes)
Adapted view for Bilfinger unit 2
Adapted view for
Bilfinger unit XX understanding and interpretation as well as a di erent leadership style. As we had to face a situation in which the information about the processes could be knowable and complex because the project-adapted processes were tailored to customer's needs, we used the Cyne n framework to design business processes (and de ne the respective BPMN models) lying in the Simple, Complicated and Complex domains as well as to build an adaptable blueprint as a frame for the execution of the adapted processes. We did this as follows.
First, we created a blueprint with the most developed Bil nger unit focusing on the rst-wave processes in the form of a process map and the respective process model de nitions. This blueprint was o ered as a reference model to other units. For every project, a copy of the model(s) was done and later adapted according to the customer's needs (cf. Fig. 5). The units encompassed process belonging to the three aforementioned domain, and they thus had to be treated di erently.
Those processes classi ed in the Cyne n's Simple domain were considered well-known due to the large amount of data and knowledge available about them. In designing these processes, potential risks that typically bring projects from the Simple to the Chaotic category were evaluated (e.g. an unexpected situation in which the project manager has an accident and is unable to ful ll his role for an unlimited period of time). In this way, process-based risk management was forced and mitigation measures were de ned.
In order to handle the Complicated and Complex domains, we had to recognize exible as a valid state in plant engineering. Consequently, we created one frame that covered exible socio-technical systems (for complicated scenarios) as
processes
Step 1 Step 2 Step 3 Company Processes
Pick and/or modify processes
processes
Step 1 XStep 2 Project manual
Step 3 Modified
Addiotional step Steps 4 well as ecosystems (for more complex ones). In the Complicated domain, variants of good practices were o ered to the end users with a company-speci c approach for the adaption of processes according to the business case (cf. Fig. 6). The Complex domain included intricate components and complex interconnections, and they had to be adapted to rapid change. A probe-sense-respond approach with fast reality check and the evaluation of the probes was needed, and the learnings were captured for potential future needs. In general, the most challenging processes (with highest potential of innovation regarding customer needs) at Bil nger are often in the Complex domain.
Along the execution of theses actions we had to make a number of decisions
and considerations to face several challenges that emerged. These decisions and
the methods used could be of help for other organizations that have to address
similar problems and thus could be seen as guidelines for BPM adoption in
complex settings from a real-life experience. They have been classi ed according
to two di erent goals, as summarized next:
1. One of our main concerns was to ensure the applicability of the BPM
approach. Several actions were taken in this regard, speci cally:
(a) Rather than a big corporate project, we executed small BPM projects
with a clear focus on a speci c set of processes that are prioritized. In
this line, we sought the harmonization and standardization of operative
processes only in the areas in which it was reasonable. For us, the
harmonization of processes had a di erent target than establishing process
orientation with a particular scope in each unit.
(b) We established a blueprint for BPM governance and adapted it to the
speci c requirements of the selected pilot units.
(c) We used a strong modeling tool to enable fast process development and
an easy application for our end users.
(d) In line with the previous point, we designed everything around the end
users (end-to-end processes) and aligned all our execution activities to
the particular customers' needs (internal and external). We prioritized
our customers and employees in all BPM decisions rather than any
standardized principles (e.g. BPMN language, ISO 9001 norm [
At the beginning of this initiative we su ered an initial reluctance and sceptical opinions to the paradigm shift from most of our stakeholders. However, after the development of our novel approach for the progressive de nition of process architectures for di erent organizational units, we received positive feedback from our internal (e.g. employees) and external (e.g. customers) stakeholders.
The paradigm shift with the adoption of BPM was a great experience and it became obvious in the pilot groups we worked with. In addition, exibility in the way how business processes can be applied could be achieved. Using the guiding principles described above, we looked at BPM from a completely di erent angle. It was an important step towards increasing the BPM impact and overcoming the complex environment of our business.
In addition, the advantages acknowledged by the engineering community were a reduction of interface risks, a more reliable process execution, a much quicker integration of temporary sta and hence, the opportunity to foster resource leveling between the companies. 5
We believe one of our key success factors was to design a blueprint as a universal enterprise process architecture and create a copy of if (and its process models) at the project start (for every project). Such initial model was then stripped down to the relevant processes and altered and amended in accordance to the project speci c needs. We would follow a similar approach if we had to face a similar problem in the future.
In our opinion, another key success factor was the application of gami cation to ease the paradigm shift and help the end users to understand the end-toend processes. We could spend weeks and months, or even years, laboring with process models trying to change our results and not even begin to approach the phenomenon of change that occurred spontaneously when our employees saw things di erent and understood why. With games and playing videos we managed to make them understand and believe in the advantages of BPM adoption.
In this journey, we also noticed that simply deploying process models in a process modeling tool does not necessarily lead to their desired comprehension and use. All employees have to be trained and be taught that process models are a means of communication and that they are never nalized, as improvement is an iterative and continuous task. 6
From the work performed we can conclude that establishing BPM at big size corporate companies is a complex task that needs to be done progressively and giving the same importance to the implementation of the BPM practices as to the e orts required to change the mindset of the end users towards process orientation. The approach must be exible in order to accommodate di erent customers' needs and should be applied to several distinct scenarios in order to evaluate its validity. In case of success, the positive feedback creates intrinsic motivation for other organizational units within the corporate and can be rolled out easier.
Given the good results achieved, we are planning to continue to use our approach and practices within the remaining Bil nger units tackling the requirements of other types of processes. Applying the approach to other pilots will help us to improve the blueprint. In addition, we aim to give visibility to our approach beyond our company's boundaries so that other organizations can gain knowledge on our experience with BPM adoption and apply it in their own settings. Getting informed about the bene ts achieved in previous cases would help to move from a top-down approach (in which the top management of the company pushes the adoption of BPM to the units by a harmonized approach, and units tend to show resistance) to a bottom-up approach (in which the units themselves are interested in adopting BPM so a blueprint can be more easily created).