.JPG)
In my last three episodes I shared my thoughts on the topic of Management of Change, or MoC in short and I argued that this is one of the most underrated business processes out there. It’s almost regarded as necessary evil, while in fact, it is one of those processes that actually enhances your business agility. Do you want to effectively implement a new business model / product / service? You can rest assured that changes will be needed to your processes, applications and more. If your MoC process then takes very long and is not first time right, you’ll loose valuable time to market for your new business model / product / service. It’s that simple.
Anyway, the MoC process is not a stand alone process, it is the central hub in an ecosystem that has links to many aspects of any organization. Let’s see what we explore together!
First of all, there is a link to the Incident Management process and supporting application. Every organization experiences hick ups and incidents. Failed security patch updates, missing implementations for new mandatory legal requirements, spooky application behavior, we’ve all seen it happen. These events often trigger an incident management process (often supported by tools such as Remedy, Jira or ServiceNow) and this process is also often run by the IT department. You can imagine that at the moment such an incident is being handled it is likely that there will be consequences in more ways than just the application that is acting up and the proposed solution to the incident may have an impact on the related procedures, processes or even on other applications. This interdependency between the various components of your organization, in the event of a change (the solution to an incident can come in the form and shape of a change request), can cause some havoc if not handled appropriately.
Another example I particularly like is the act of setting up a shared service center. This should always go hand in hand with some rigorous standardization, harmonization and, centralization. New roles will be created, new business processes are developed, other existing ones are discontinued and all of this is having a profound impact on the documented business processes. A new role means new authorization profiles, new SOP’s or work instructions, new interaction with other roles and much more. All of this has to be integrated with your existing process documentation to make sure that whatever technically needs to happen to set up your shared service department is in line with the way of working as described above.
A third and final example for this week is the link between the MoC process and the so-called development groups in the organization (the ones that make the application changes, DevOps, development streets, whatever you want to call them). During the MoC process, after you have successfully managed the impact analysis, high level design and approval for it, there will come a moment that the detailed solution design will have to be actually built. This typically is a handover moment between a process oriented group and the IT application experts group. Now imagine that this development group is located somewhere far away (let’s say India, just randomly). This physical separation leads to the consequence that the specification of the solution design (as fabricated during the MoC process) needs to be first time right and unambiguous. This also is the reason why the different levels of testing in the MoC process (unit testing, integration testing and user acceptance testing) is really, really important.
Summarizing, I can argue that the MoC process is the glue to connects the business world (with ever changing environments and requirements), the IT world (with the continuous stream of incidents, changes and patches) and the process management world (trying to consolidate it all) and if this process is not functioning optimally, you will pay the proverbial penalty in a reduction of business agility.
So much on the MoC process for now (I can talk about this for days if needed), as of next week I will sharing my thoughts on business continuity management and it’s link to BPM.
Ciao, Caspar
