We who work in IT know that all businesses can now be considered technology companies to some extent or another from the large financial firms to the smallest home town bank, networking companies, manufacturing, utilities and energy, retail, insurance, health care, government agencies to the local law firm and mom and pop retail shops around the corner. This is due to the overwhelming reliance each and every second, or 24/7, on technology. If any of these companies were to lose their technology at any given time they could stand to lose money (in some circumstances millions of dollars or more).
It is estimated that 70 percent of all problems related to IT can be traced back to some type of change that occurred within the infrastructure or application. Many firms take their change practices very seriously or that is what you hear from the IT and executive management within a company or those who takes part in any given change process (CP). From technicians responsible for server OS changes or even a simple patch to the OS to developers who make changes to functionality of the applications used by their company or their user community. From engineers tweaking links to the network infrastructure or the customer engineers and vendors responsible for hardware changes to the systems themselves. All of these highly critical aspects of supporting an IT environment and more, “yes there are many groups I missed”, have a stake in making sure that their changes never, “OK, never is next to impossible, so I will say decrease” impacts to the systems and products they support.
Now because of these changes to their small piece of the IT world “which in reality could impact the big picture of a complex, interdependent, big and scary world” even the smallest changes to IT can break a functioning product that a firm provides or whoever uses their products. Many firms say that managing changes successfully to their IT environments is the number priority. But even those small changes many times do not get the attention they require desperately because the true impacts are not documented or defined within a process or tool. We all know the big changes (ZOS upgrade, major server OS changes) gets some diligence just for the fact that they are big and well known impacts, but they too are the cause of many failures even though they are known risks.
Analysts and engineers or those responsible for Software Configuration Management (SCM) know all too well that many of the critical “business related” changes flow from their repositories making SCM what I consider the “foundation” of the change process. These SCM engineers also understand more than many that change is a dangerous business and that diligence to verify impacts and other possible risks is a never ending task. Hopefully the tools they have chosen can provide the right dependency reporting for each and every component or artifact that is being altered. This is not to lessen the criticality that other groups of analyst or business process engineers supporting a higher function of the change event management (CEM) process. They attempt to manage cross functional impacts, change collisions, risks or scheduling and managing approvals and running weekly “nea even daily” change meetings for each and every event taking place throughout the enterprise.
Where does it all begin? While I’ve said that SCM is the foundation for change, how a firm manages or tracks their assets is the “floor” of that foundation. Many times I have seen, or heard, from managers that they believe their asset inventory is at best 80 percent