This is the second part in a series of articles, that are going to look at business transformation from several angles, pointing out, where modelling your business may be able to help.
In most of the cases IT changes are rather minor and they are handled, as part of the business as usual routines. ITIL change management processes typically cover these, with examples such as opening a port on a firewall, or putting an old, unused server out of its misery and moving the services provided by it to a new virtual server.
By definition ITIL considers change, as something, that – among other things – is implemented with a minimized and accepted risk to existing IT infrastructure and results in a new status of one or more configuration items (CIs).
In order to understand the extent of change and identify the affected Configuration Items, the traditional Configuration Management Database (CMDB) is a very useful tool, however, it might not be sufficient in itself.
What does this change mean to my business?
Most organizations that use ITIL based processes, have developed a CMDB to support audit readiness, but these lack features, that would enable sufficient visualization and data analysis capabilities in order to help identify the possible extent and implications of the change.
In the above example, moving the services from one computer to another might be a simple enough task and one might even discover, using the CMDB, which business units are actually affected by the change.
It will not contain, however, what the business unit actually uses the technology service for. Nor to what extent this change impacts each unit separately. For instance, bringing down a JAVA application server might be a critical issue for the sales department, who uses the CRM application running on it. However, the same server might have marginal importance to the people in logistics, who only have a test barcoding system on it.
Therefore, asking change approvals from the business unit leaders, might not be relevant, as these managers would not even now what the technical service in question does. Since it is completely meaningless to them, their approval will become a formality in the entire process.
Would it not be great to know exactly who is using the resources and services and for what purpose? What a professional IT operation it was, if change managers could contacted business managers individually, with the impact information relevant to them!
Their feedback and approval would then make much more sense. Thus, you had the chance to perform the appropriate level of preparation to ensure the business continuity of the important stuff.
If the assessment is done using a model that shows which business processes are using which service, and for what purpose, you can actually demonstrate how business processes will be impacted during the migration. Business managers can evaluate what this change means from a business perspective and then ask that the IT to do the migration at another time window, so that the customers remain unaffected.
To sum it up, even day-to-day changes can and should be supported with a proper and meaningful impact analysis on the business. Running an impact analysis on an existing model as a preparation to the change, can save many working hours, mitigating the negative effects of the rush and uncertainty.
It is always better to be safe, than sorry!
About the authors
Gergely is an IT Consultant and an Enterprise Software Architect. He ran his consulting company for seven years, now he’s working as an IT consultant. His main interests are IT Strategic planning, high-level architecture design. He’s hobby projects involve household electronics, Linux, Android, web development.
Peter develops business and products in Atoll. He has a special interest in agile architecture control practices and therefore likes to get his hands dirty in projects with our tool, SAMU.