Management of change

When I was asked to write a guest blog for the guys from What’s Your Baseline (who also are respected colleagues of mine) I did not have to think twice. What I did have to think about is the topic of this blog and I started reading some of the blogs of their website and then it hit me: one of the most underrated topics in business probably is the management of change and why should we consolidate the management of change processes. Before I go more into depth on this topic, allow me to define the management of change, just to make sure that we don’t confuse this with change management.

Both are, by the way, incredibly important and the way I have learned to define them is that change management deals with the human side of things, how to make sure people buy in to a change in the way of working (and much more). Management of change, on the other hand, basically deals with all things you can write down, such as processes, applications, risks, roles and much more. For me, these two topics are two sides of the same coin, or the Yin and the Yang if you want and the one mechanism that sits in between them, and that can unite them is communication. Without communication, the chances are high that initiatives on side do not trickle down to the other side (and vice versa) with all of the negative consequences as a result.

Different types of Management of Change

However, let’s focus on the management of change topic for this blog and more importantly how it relates to other very interesting topics that more often come by on this website and in these podcasts such as Enterprise Architecture and Business Process Management. First, let’s define management of change a little bit more. Every organization has to deal with changes, some of them initiated by themselves (think about lean six sigma initiatives) and some of them imposed by other parties (think about government or regulatory bodies). Sometimes, changes can even the result of incidents that take place in the operation of the organization.

Imagine that one day your ERP system is not working the same way anymore compared to the day before and all of a sudden you are no longer able to perform your daily tasks. We could call that an incident, right? Now imagine that you are the final approver for the invoices that need to be paid to your vendors, in which case you could circumvent things for a day or two, but at a certain point in time your vendors will start complaining. In order to mitigate this incident, you will probably need to make a change in your ERP system and this process can be long and cumbersome.

So, incidents can turn into changes, improvement initiatives typically result in changes as well and how do channel all of these change requests in the best possible way? Well, I will not come up with a 7 step process in this blog, because I believe that there are numerous good best practices around this topic on the internet, but what I will do is make a case for two things: consolidation and transparency.

Consolidation

Let’s start with consolidation. In my daily work I consult a lot of different large companies around the EMEA region and in most cases (and then I mean 90%+) these companies deal with changes to business processes and applications in separate ways. They typically have two different ways of working for dealing with changes, one for process changes (if these are dealt with from a central perspective to begin with) and one for application changes (that are typically dealt with by IT) and this is where the problems begin.

In order to explain myself I have to take a step back and elaborate a bit on the way things work in an organization. Every organization has (or should have) a mission, vision, and strategy and especially this strategy will be translated into an operating model, which is a collection of agreements on how the company wants to organize itself in order to be successful in achieving the strategic targets.

Now, the proof of the strategic pudding is in the execution, and to be more specific in the execution of the business processes and work instructions on the shop floor and in the management offices. Nowadays, the business processes are supported by applications. Of course, we might still print out documents and store them in a physical archive, but these documents are printed out using a printer and a print application, right? They are no longer fabricated on an old-fashioned typewriter and this just confirms that the consolidation of management of change processes is vital.

In other words, business processes and its supporting applications go hand in hand and should, as a result, also be managed hand in hand. Nevertheless, and this is my firm conviction, the business processes lead, the applications support. For example, Audi’s core business is manufacturing cars (let’s keep it simple) and not running 1500+ applications. The consequence of this is that there also is a very tight connection between the BPM practice in an organization and the EA practice and I do need to thread very carefully here because I don’t want to offend anybody but the usual order of things should be that based on the strategy of an organization and the subsequent operating model, first the way of working is defined (and this can be done based on the required capabilities of course) and after that, the supporting application landscape is determined.

However, I have to immediately add that this is not a regular consecutive relationship, but rather an iterative one between BPM and EA and this is due to the fact that some applications are so dominant (think about ERP) and omnipresent that it is a good thing to also examine what best practices they already have out of the box and based on that perhaps decide to change the way you work to match this best practice.

Why consolidate Management of Change?

However, the point I’m trying to make is that changes to processes and applications need to be processed simultaneously and through one management of change process. It’s because of this intertwined relationship between the business process and its supporting applications that change requests need to go through a consolidated impact analysis (meaning, the change request needs to be evaluated by a group of experts together and not in silos) before they are pushed on for design, build, test and delivery.

In my previous company (a global manufacturing company) we implemented this way of working for management of change and each change request was evaluated by a group of functional experts (the requester, a domain expert, a risk expert, a finance expert and an IT expert) and they needed to reach consensus on the question whether or not this change request was desirable and feasible. Plus, they needed to do this within 48 hours after the change request was submitted and it worked wonderfully. A change request was judged from different perspectives at the same time and this lead to a better argued decision.

Summarizing for consolidation: your management of change process for both processes and applications needs to be one and the same process and please make sure that whenever you make changes to either a process or an application or both you also oblige the people who process these changes to update the documentation before you deliver any changes to production.

Transparency

Now for the other topic, transparency. When you operate a management of change process, very often you will use multiple systems to do the change. Think about ERP, and SAP in particular. Mostly you would be using a ticketing system (ITSM systems) to make sure that you keep track of all of your incidents and change requests, probably one or more 3-tier SAP landscapes (consisting out of DEV, Q&A and PROD systems) and to orchestrate these landscapes you might be using SAP Solution Manager (CHARM) and finally a BPM platform for the process management side of things.

It’s not hard to understand that if you are looking for transparency across this entire management of change process, flowing through all of these applications, it can be quite difficult to tie everything together. You either need a wizard with databases, excel and some BI tools or you can resort to process mining.

Process mining is capable of taking in data from various systems, stitching it together and analyze process performance across these systems. It can discover end to end processes and find bottlenecks that otherwise might remain hidden. Going back to the example from my previous company, we applied process mining and connected all SAP systems, including Solution Manager and added the data from the ticketing system as well. What we also knew were of course the complaints from the business groups that it took too long to process changes and through process mining we found out that the two biggest bottlenecks in the end to end process actually were:

(1) the approval of the cost estimate and,

(2) the execution of the UAT and guess what, both of these activities are the responsibility of the business group itself.

Did we rub that in? Yes, we did and the complaining stopped, but more importantly also the activity cycle times went down and people started to respond quicker to their tasks, because they now understood that the total cycle time for processing a change request also depends on their own performance (and that, by the way, is also a classical technique from change management).

Concluding

Coming to some kind of conclusion here I can say that the ability to deal efficiently with changes may be one of the most important capabilities a company can have. Certainly given the incredible amount of changes and the speed with which they are coming at you. Having a single repository of your processes and applications and an efficient, consolidated management of change process on top of those is the ultimate definition of business agility, if you ask me.