Can ITIL help to reduce pain out of failed change? Are outages happening in organizations are real outage or they are cause of poor change management? Can we imagine impact of poor change management process or failed change? Some one implemented change to production server (responsible for managing application which decide compositions for medicines) in Medicine manufacturing unit? Although it was small activity of 10-15 mins to reboot production server but are we justifying business impact due to this? How much exactly does change hurt an organisation? Well, 70-80% of service interruptions are caused by poor quality changes being made... this is my experience & also voice of other participants who attended change management sessions from me… Perhaps you will know this story: Wrong output getting produced out of manufacturing unit (may be Medicine manufacturing or Car manufacturing unit..), Key business system generating the wrong numbers; someone thinks a tiny change was made over the weekend within a database. No-one knows who, no-one knows what. The company is losing $ every second.., entire production unit is down due to server reboot made during business hours… Within the IT world, change is inevitable. We have the constant release of security patches, hot fixes, service packs, new versions, changes to code, hardware replacements, configuration changes, modifications to reference data – the list goes on. So change equates to risk, and risk is not something that any business likes to encourage. ITIL saw was various organizations (both public and private sector) experiencing essentially the same service management pains, but independently dreaming up and implementing their own best practices as a result.. The best practices were named ITIL– the Information Technology Infrastructure Library. Among these practices was a heap of good advice for systematically managing change, and thereby crucially minimising its associated risk. So what does ITIL tell us about managing change? Proposed changes are formally detailed as requests within a change management system for consideration. Change requests are reviewed at a change advisory board (CAB) – a group of interested parties who meet regularly to assess all upcoming scheduled changes. The CAB is chaired by the change manager (CM); and present will be service owners, IT workers from various disciplines, representatives from the business, and the person making the change request in the first place. The CAB is not concerned with getting into the technical nitty-gritty of the changes; it is about mitigating risk by asking sensible questions such as: • Has the change been fully tested? • Is this change getting implemented in business hours? • Is another change happening at the same time which is incompatible? • Is RACI defined for all activities part of change & release? • What post-implementation checks will take place to ensure the change was successful? • Is there an adequate back-out plan if change fails? • Is sufficient staffing in place if everything goes horribly wrong? But in order to get all this done… important point is “Change Request should be Raised in System”………….
Topics
