Download this post (PDF)

Many organizations undergo process development efforts to improve organizational performance, but fail in the first attempts

It is startling, how many ERP implementation failures there are in the world. Examples range from Vodafone, to Nike and HP (CIO.com, 2017). The surprising thing is that a solid methodology has yet to be defined, given the fundamental role of ERP, and it being the basic way to improve business. Most of these failures are not tracked to software problems, meaning that ERPs are inherently flawed – the failures can be tracked to process development, where the companies are mapped out and managed in a structured manner. Even before adopting ERPs, companies often aim to create process structure to solve their difficulties in alignment, governance, monitoring and overcoming inertia. This is done through a regime called process development, where the goal is to reach a certain level of “process maturity”. If implemented right, it increases the control of a firm’s results and forecasting the goals, costs, and performance. It also improves management’s ability to propose better targets for performance and improves effectiveness in reaching defined goals.

Many organizations start this journey, but may not understand that the development is not seen as a binary improvement, but rather as a continuous growth cycle. The better you can adopt best practices, the bigger the benefits become. To illustrate this development, a model for process maturity (figure 1) is utilized to understand the ongoing growth of the organization and intermediate steps to aim for in the short term (Röglinger et al, 2012).

The starting point is an ad-hoc state, where the organization’s practices have been formed through time by a set of individual experts and the alignment has been done on “as needed” basis. In the first phase, organizations enter the “opportunistic” phase, which includes the first two steps of the model. This phase is named “opportunistic” because it tries to change the existing organizational structures and responsibilities. In larger organizations, the required change is especially large, because practical level change is opposed by larger inertia. While maturity models can be useful to understand the change better, they usually have one key shortcoming – they lack the practical tools to succeed in the change effort (Röglinger et al, 2012).

To reach a more mature level in practice, organizations usually set up large-scale change projects. Change projects usually have a goal of reaching the maturity of a level 2-type organization, in which the goals in the opportunistic stage are met (figure 1). The key turning point in organizational practices, before reaching a higher maturity level is when there are common process language and related practices used in documentation as well as in operative work and continuous alignment in operative teams and strategy. The common process language means that there is a defined way to model the processes in flow charts and same methods are used throughout the organization. Common processes related practices mean defining documentation update practices and knowledge interfaces. Finally, the continuous alignment means that organization is a process oriented rather than structure oriented and the alignment is based on data and requirements of the process.

A large-scale change project sounds like a solid approach - there is a clear need, proven benchmarks can be found, and the change project itself can be planned beforehand in a solid manner. However, the often overlooked, critical part is that this project aims to restructure the legacy practices of the company. Often in the initial ad-hoc stage, the operative daily work is unstructured and not systematically aligned with other stakeholders. Change projects can start on a good track, but soon it is noticed, for example by inconsistent documentation or missed milestones, that projects are not scoped in the right scale. This results in unplanned delays and even failures in the development, which can be seen from the failed ERP adoptions – in fact up to 55-75% of ERP projects can be classified as failures (Deloitte study). In some research contexts, starting a process maturity development project is compared to mountain climbing to reflect the kind of leadership and willingness it requires (McCormack et al, 2009). To succeed in the grassroots level change, operative personnel needs to show clear buy-in. It is not solely a question of process development team capabilities or convincing management - it is a question of getting the change done throughout the organization.

An often-overlooked root cause: employees not understanding or agreeing with the change

In the ad-hoc stage, the organization is largely defined through individual “heroes”, who have been leading the practical level in the past and have grown to be the focal point of information and ad-hoc structure. The difficulties have root causes in the mindset of these “heroes” as they are the ones that need to carry the organization through the change. The framework in figure 2 structures the most common issues, which includes two high level issues: the “heroes” do not agree with the goals of the change, or they are not willing to change their daily routines for the change to stick.

Figure 2: The core issues in getting the personnel buy-in

The case of individual heroes not agreeing with the selected direction is tied into a poorly communicated business case for the change. Overlooking this issue can result in lack of mental buy-in, meaning that individual heroes and key personnel do not want to be part of the change. The individual heroes may see that the development threatens their competences of selected tools or approaches or in general causes them to feel insecure. The problem lies in that their responsibilities or competencies are not considered part of the change project or that their incentives are too tied to the existing approach.

Another root cause for this is that individual heroes do not accept the business case for the change. This happens when that the overall approach is not discussed with the individual heroes enough or when it is presented in an overly top-down manner without enough feedback iterations with the personnel. Lastly, perhaps the most critical issue is that the experts see negative consequences of the change, which should be identified quite fast. In this case, the overall approach seems negative for the whole company or a segment and understanding the logic behind these fears is a critical part of fixing these problems as soon as they arrive. In environments that lack an open culture, this can be an especially critical problem.

Even when mental buy-in is reached, it may still be the case that the individual heroes do not bother to be the part of the change. In this case, the individual heroes resist change by not being involved enough. This so-called lack of physical buy-in occurs because employees do not understand the approach, its practical benefits and the value it can create. One reason is that the employees feel the collected information for the processes is too tacit or complex to be modeled in a simple manner, which leads to disengagement. The key problem is that not enough focus is put on how the knowledge is gathered or not enough time is put on finding the common path between process development team and people who have operative responsibility. Another key reason is that the individual heroes do not understand the structural approach, which usually is “given” by the change project team, but they are not capable or do not have the resources to pivot it themselves. Finally, it may be that while these individual heroes agree with the overall direction, they do not see it worthwhile to change their work routines because they feel that it cannot help them specifically. In this case, the benefits of the process development must be expanded to a practical level to enable the operative people to see the benefits as well. In a sense, this part can be seen as an acid test to see whether the approach is too top-to-bottom driven.

Lastly, the lack of methodology and proper skills in the organization or its process development team can also contribute to the problem. However, the quality of them does not matter, if other issues are present. There are multiple guides for methods, such as SixSigma’s guide.

If any of these signs can be seen within the organization, the approach should be focused on gaining the buy-in of the personnel. In practice, this means that the focus should be put on communicating the purpose of the change with a concrete vision. This often has to do with efficiency improvements, which in turn has wide-reaching benefits for the organization and its employees. Secondly, the communication should also be two-way, which gives the people a chance to provide feedback, and possibility interact with the idea of change is also crucial for cultivating a sense of buy-in. While this seems like a large task, it should not be overlooked or otherwise the carelessness results in problems at a later stage.

However, the nature of process development itself is quite hard. Successful implementation is dependent on getting three core pillars of process development to work in practice, which is depicted in figure 3. These pillars are usually introduced in a top-down manner with very heavy structure and then employees are expected to follow the new guidelines to the best of their ability on top of their ordinary duties. In this kind of context, communication and reassurance does not happen, leading to delays.

Figure 3: The three pillars of process development

A powerful approach to solve the inertia is to utilize an agile approach to introduce structure

Based on our experience, a powerful approach to find out and solve the personnel related issues is to create a light version of each of these pillars and to develop the overall structure in an agile manner with short iterations and checkpoints. The goal of this “light” approach is to enable the process owners and the individual heroes of the organization to start realizing the benefits of the process approach in a practical level and to give them the possibility to influence the change process. Other benefits of an agile regime include reduced workload spikes, continuous development, less ambiguity, and more flexibility in building the process approach.

The idea is to turn the process owners into change champions, who are critical when pushing for change from ad-hoc practices. The approach aims for operational quick wins and learnings that increase the buy-in at a concrete level but also starts building structured practices that are more relevant for the organization. This improvement in documentation, metrics and structure should be done multiple times for it to be agile practice, which is followed up in governance meetings. Each loop can focus on developing documentation and approach further, which in time will teach the process approach to the organization. It also creates practices that can be used organization-wide. One iterative loop is depicted in figure 4.

The loop usually starts with creating a version of the structured approach. In the initial stages, this approach can be quite light and start just defining the core processes and their owners. For each of the first steps, concrete early level examples are shown in figure 5.

At first, the change can start by mapping out a high-level version of the processes representing key linkages such as data interfaces between processes. While this approach may seem basic, it usually provides understanding on ownership structures between processes and provides the organization with tools to pinpoint responsibility in processes and their interfaces. Quick wins for operative work can be found in these linkages and this kind of documentation can act as good communication material to show how the organization looks like through a process lens. The idea here is to start creating a taxonomy, the first core pillar, from bottom-up to adjust it based on the organization.

The next step is to define processes further, which starts through embracing process ownership by creating clear goals for each of the processes. This forces the process owners to think through how they are contributing to the organization and to whom they are providing input or decision-making material. The goals can be tied to KPIs, which can first consist of indicators that already exist, but introduces measuring as a structured practice. Analyzing the operations through KPIs and process lens can provide understanding of the bottle necks in operations. Finally, the key part of every process is to map development areas in which the process is developed further to understand how the practices are being changed in practice.

Next, we create a clear governance structure for process owners’ tasks. At first, the governance consists of only monthly or fortnightly meetings and reviews with the overall process owner. In addition to the meetings, it should always be agreed and communicated what is the level of detail that is being followed. At later stages, the governance can also include meetings with the centralized process development team. Without clear governance and methods to be followed, the development may not advance, since organization may not start the change if it is not followed in any way.

Part of the governance structure should also be establishing a platform, one of the core pillars of the process development, which can be in its rawest form just defining where people communicate and what is the common file storage and system. A powerful approach is to introduce centralized dashboards of existing data to provide a way to follow the metrics easily within the platform. In addition, most ad-hoc organizations lack a good way to develop themselves through shared learnings, which can be started as part of the platform effort. Initially it can be a blogpost or communication platform (such as Slack, Yammer, or Google Sites) group, where stakeholders can share key learnings. The key here is to have some interesting content within the platform to encourage using it.

A critical part of this approach is to give the personnel a chance to affect the methods and overall approach. By giving an opportunity to influence whether this is the right approach to embrace process approach, it is much easier for the individual to accept and adjust their views. It is not likely that the approach will change that much, but even giving the opportunity to do this creates much more buy-in than giving templates and approaching top-down with little to no view on the overall process. As part of the feedback step, it is also critical to collect learnings and success cases of what has been be improved through the structured approach. These learnings and quick wins should then be spread out to the organization through weekly meetings for others to join the excitement as well.

In a practical level, the process depiction in figure 5 and the template in figure 6 can act as the first phases fill a follow-up tool with each of the process owners, which includes mapping the process learnings, goals, KPIs and development items. The tool itself is aimed to be iteratively filled with the early stage governance model. In addition, to enable the creation of centralized data and the wider use of follow up, an agile dashboard can be setup. Especially for companies using Google product family, the Sites feature is quite handy to provide easy data sharing. This increases alignment within the organization and creates demand for more structured measuring that may not be a standard practice in ad-hoc organizations.

Implementing a “one size fits all” approach in an ad-hoc organization can create resistance. The agility of the approach does not come only from the fact that this create less pressure on the organization in terms of workload, but that it provides an opportunity to start building the process approach in a much earlier phase. It also means that the approach starts building the process documentation as well as thinking from the ground-up – this enables considering all the aspects of the business to avoid large scale problems.

The end goal of these concrete actions is to reach enough buy-in to overcome ad-hoc practices

The quick wins are important because they can impact the business, especially through communication purposes, centralizing the documentation to provide a cohesive view and to give clear responsibilities and tasks to the process owners. But above all, these quick wins motivate and reward the process owners and individual heroes. They also encourage the process owners to start discussions by themselves on operative responsibilities and decision-making to move towards more effective and valuable operations.

Setting this scheme up, of course, relies highly on the involvement of the overall process owner. However, by utilizing an iterative approach to creating a structure where key personnel is able to be part of the change should not increase the overall workload too much. The management attention, bottom-to-top approach and a solid business case for change should provide the push to be successful and engage the process owner level. This may increase the overall change design phase by few months, but as most agile practices, it can be started at a much earlier phase and the risk of delays is reduced greatly. In some cases, it is the core enabler for the change - without taking this into account, the organization can be stuck in the change phase for a long time and may even fail in the whole effort. This in turn will increase the mental resistance and make a proper approach at a later stage much more difficult.

In a nutshell, developing process maturity starts with nurturing a process ownership mindset that requires an iterative approach to define an ownership and governance model, where goals, KPIs, and other process attributes are defined and managed by each owner. To facilitate the transition to new practices, a common platform is created for central governance and better transparency. This is done to find out potential problems in the mindset of operative personnel and to take them as part of the change from early on. An easy way to get started is to set up a forward-looking plan to agree on governance, iteration schedule and level of detail of each iteration with the process owners. Strong links to the overall change project need to be formed to reiterate business case and approaches organization-wide.

The early evidence of these practices is that this will lead to creating relevant process mappings and models, which in turn will create the common language needed to move forward culturally. There has also been support from our client work for this more practical approach to push through ad-hoc practices. Without adopting this critical middle step, delays are more likely and the organization may not be ready to develop itself.

References

CIO.com, (2017): Enterprise Resrouce Planning – 10 famous ERP disasters, dustups and disappointments https://www.cio.com/article/2429865/enterprise-resource-planning/enterprise-resource-planning-10-famous-erp-disasters-dustups-and-disappointments.html

Deloitte study: https://www2.deloitte.com/content/dam/Deloitte/mx/Documents/human-capital/01_ERP_Top10_Challenges.pdf

ISixSigma: https://www.isixsigma.com/methodology/business-process-management-bpm/improving-low-maturity-processes-takes-special-approach/

McCormack et al, (2007): A global investigation in key turning points in business process maturity http://www.drkresearch.org/resources/turning_points_published_version.pdf

Roeglinger et al, (2012): Maturity models in business process management

Tags
Process development, Process maturity, Transformation, Personnel buy-in, ERP, ERP implementation, Article