First of all, welcome back from the holiday season. As you may have noticed I too took a little break from work (and also from blogging) to recharge not just the batteries of my EV, but also of myself and last week marked the restart of my professional activities, much to my delight. In my last blog (and the first one on Management of Change) I mentioned once or twice that the MoC process perhaps is the most underrated process in organizations. Everyone knows it’s important, nobody wants to put a lot of effort into it and we all know by now that this is a recipe for failure.
This week I would like to make an argument for consolidation in the MoC landscape and that this consolidation will unleash unparalleled levels of business agility. This may sound a little bit over the top, but in essence I believe it does.
First of all, what kind of consolidation are we talking about? Many companies around the world (I could even say: the majority) are executing parallel management of change processes: one for their IT application changes, one or more for the process changes, another for the corporate requirements changes and yet another one for legal or compliance changes. As you can imagine, when you start making changes to for example applications, there is quite a high likelihood that these changes also have an impact on business processes, just to name one, and vice versa. This is, of course, not always the case. You can think of numerous changes that you can make to applications that have no effect on anything else, right?
Read that last sentence again a little bit slower…. if a change has no effect whatsoever on anything else…. why are you changing it then? Nowadays, organizations are so heavily intertwined from an IT and way of working point of view, that virtually everything is connected to everything else. Let’s put that to the test, shall we?
Have you ever been involved in or heard of a situation where a company made changes to one part of their ERP system and right after the go live of that change, all of a sudden other people start complaining about things not working anymore? [prediction mode on] you’re now going like: hmmm, right, yes, how could I have forgotten that [prediction mode off]…
Seriously, business processes, applications, compliance requirements and risks are becoming more and more intertwined and interdependent and this results in a requirement for the management of change process to become more consolidated and more central. No, this does not mean that the execution of the various changes need to be consolidated too, but it does mean that before you start developing the solutions to the change requests, you need to perform a consolidated / central impact analysis on all of the various parts that make up your organization.
I’ve had the pleasure of restructuring and optimizing the MoC process of the company I worked for about 5-6 years ago. The IT changes were done by Corporate ICT, the process changes were done all over the place (but later in a centralized BPM team) and the average time it took from inception to production was about 9 months, which is a long time and does not help your ability to respond to external changes quickly (and this happens to be a core part of the definition of agility). One of the first things we did was to draft a MoC process that would treat all types of changes the same, it didn’t matter if it was an IT change (with an emphasis on SAP changes at first) or a process related change. At the moment the change request was delivered in the ticketing system we already used for that, the change was categorized and assigned to the proper central subject matter expert (SME). This SME subsequently had 48 hours to get together a cross-functional team to perform an Impact Analysis. In this cross functional team you would always find at least the following roles:
- The Change requester
- The Relevant SME
- A Finance SME (almost everything you do in a business process results in a financial transaction in some shape or form)
- A risk & control SME
- The relevant application SME
This way, during the impact analysis, the change request was assessed based on all the possible angles and requirements and if it was approved, we were reasonable certain that the further design, build, test and deliver to production would not result in any unexpected effects. This was also, by far, the most difficult step to implement, after all, the build, test & deliver steps were already in place from some time in the various departments.
This new way of working resulted in less interruptions and more effective roll outs of changes. It also reduced the cycle time for a change request but not yet spectacularly, however, based on the new normal for the MoC process the organization grew more confident and after about 8-12 months it was decided to switch from a fixed interval of change delivery to the SAP systems to continuous delivery. The change could not have been done with the central and consolidated start of the MoC process, the main reason being that we were now able to gauge the change requests on their potential cross-functional impact before we started developing. The result in the end was that our average cycle time for processing a change request dropped from 9 months to 3 weeks.
The food for thought I would like to leave you with for this week is to evaluate the way your process change requests for business processes, applications, requirements etc and try to consolidate at least the first steps of the MoC process into a single way of working. Your business stakeholders will thank you for that.
Talk to you all next week.
Ciao, Caspar
