Example: confidence

White Paper - itsmcampus.com

White PaperChange Management:A CA IT Service ManagementProcess MapPeter Doherty Senior Consultant, Technical Service, CA, Waterhouse Director, Business Service Optimization, CA 2006 Table of ContentsIntroduction ..3 Change Management .. 4 Request for Change (RFC) ..5 RFC Analysis ..5 Change Prioritization ..5 Categorize ..5 Change Advisory Board ..6 Change Schedule ..6 Build & Test Change .. a Successful Change Management Journey ..7 About the Authors ..823 IntroductionCA s IT Service Management (ITSM) Process Maps providea clear representation of the itil best practice use the analogy of subway or underground systemtransport maps to illustrate how best to navigate a journeyof continuous IT service improvement. Each map detailseach itil process (track), the itil process activities (stations)that must be navigated to achieve itil process goals (yourdestination), and the integration points (junctions) thatmust be considered for process has developed two maps (Service Support Figure A;and Service Delivery Figure B), since most ITSM discussions are focused around these two critical Service Support journey represents a journey ofimproving day-to-day IT service support processes thatlay the operational foundation needed upon which to buildbusiness value.

3 Introduction CA’s IT Service Management (ITSM) Process Maps provide a clear representation of the ITIL best practice framework. We use the analogy of subway or underground system

Tags:

  Introduction, Paper, White, White paper, Itil

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of White Paper - itsmcampus.com

1 White PaperChange Management:A CA IT Service ManagementProcess MapPeter Doherty Senior Consultant, Technical Service, CA, Waterhouse Director, Business Service Optimization, CA 2006 Table of ContentsIntroduction ..3 Change Management .. 4 Request for Change (RFC) ..5 RFC Analysis ..5 Change Prioritization ..5 Categorize ..5 Change Advisory Board ..6 Change Schedule ..6 Build & Test Change .. a Successful Change Management Journey ..7 About the Authors ..823 IntroductionCA s IT Service Management (ITSM) Process Maps providea clear representation of the itil best practice use the analogy of subway or underground systemtransport maps to illustrate how best to navigate a journeyof continuous IT service improvement. Each map detailseach itil process (track), the itil process activities (stations)that must be navigated to achieve itil process goals (yourdestination), and the integration points (junctions) thatmust be considered for process has developed two maps (Service Support Figure A;and Service Delivery Figure B), since most ITSM discussions are focused around these two critical Service Support journey represents a journey ofimproving day-to-day IT service support processes thatlay the operational foundation needed upon which to buildbusiness value.

2 The Service Delivery journey is moretransformational in nature and shows the processes thatare needed to deliver quality IT examination of the maps shows how a continuousimprovement cycle has become a circle or central line,with each Plan-Do-Check-Act (P-D-C-A) improvementstep becoming a process integration point or junction .These junctions serve as reference points when assessingprocess maturity, and as a means to consider the impli-cations of implementing a process in isolation. Each of theITIL processes are shown as tracks , and are located in aposition most appropriate to how they support the goalof continuous improvement. Notice too, how major itil process activities become the stations en-route towardsa process destination or Paper is part of a series of 10 ITSM Process Mapwhite papers. Each Paper discusses how to navigate aparticular itil process journey, reviewing each processactivity that must be addressed in order to achieve processobjectives.

3 Along each journey careful attention is given tohow technology plays a critical role in both integrating itil processes and automating itil process A. Service B. Service ManagementChange is an intrinsic aspect of every business especially healthy businesses that innovate and readilyadapt to shifts in the market. So, for a business to remainhealthy, its IT organization must be capable of effectivelyand efficiently handling change. It must be able toexecute change with minimal cost and minimal risk ofbusiness disruption. IT must also be able to keep itselfwell-aligned with changing business goals and today s fast-moving markets, this ability to easily andappropriately handle change is even more s why IT organizations need to implement andautomate best practices for the entire end-to-end changemanagement lifecycle, from planning through doing (see Figure 1). Only IT organizations that embrace thiskind of disciplined approach to change management willbe able to deliver the operational agility essential forbusiness Incident and Problem Management represent the heart of Service Support, then Change Management isthe process to control the heart rate.

4 Optimized ChangeManagement results in fewer incidents and problems, andhelps ensure that strategic improvement requests arequickly processed and implemented. That is why theprocess must be well documented, especially duringcategorization activities, since decisions made here willaffect how resources and costs will be s review the Change Management process journey(see Figure 1), assessing each critical process activity (orstation), and examine how technology can be applied tooptimize every stage of the journey. While technology willgreatly enable the automation of the change process, itcannot improve a process that is fundamentally 1. Change Management Process journey of Change Management starts with a Requestfor Change (RFC). What is the difference between aservice request and a change? At a basic level, a servicerequest may involve making a change to the environmentbut generally that change is operational and doesn timpact business services.

5 A number of related servicerequests could generate a change if they require impactanalysis or touch the production environment. A Request for Change (RFC) could be triggered by suchactivities as a customer request via the Service Desk, theintroduction or removal of a Configuration Item, or theoutput of a development project. It could also be triggeredby Problem Management. To prevent too many entrypoints, the process should document who can createRFC s, what they are intended to do and what informationis required. Technology can help, ensuring that, requestorsdon t need to know the entire process and have a simpleway of submitting RFC s. The tool should drive themthrough the important steps and ensure that the correctlevel of detail is captured. It is also important tounderstand the business importance of the change. Remember, the goal of Change Management is to facilitateall change requests by using clear procedures, automationand easy checks and balances.

6 itil suggests that anymember of the organization should be able to submit anRFC. If not managed properly, this could lead to ungateddemand and possible misuse of the Change Managementsystem. A more appropriate approach would be to useservice requests for routine standardized demands thatneed not be controlled by Change Management, and touse IT or business relationship managers to submit activity of RFC Analysis is designed to perform aninitial evaluation of the information provided for complete-ness and feasibility. An automated system can significantlyshorten this phase by allowing the tool to apply businessrules to determine what information is required. A keyrequirement is ensuring adequate change lead times arein place, and in-line with performing the initial analysis, the next station isprioritizing the change. This occurs by analyzing theimpact of the problem and the urgency of the fix (if thechange was generated from a problem) or the importanceto the organization of what the change is implementing.

7 Ifthis can t be agreed upon, the Change Advisory Board(CAB) may need to intervene. When the change priority isdetermined it is used to determine resource requirementsand change scheduling windows. In a resource-constrainedenvironment, business units can use it to internallyprioritise demand. Risk assessment should also be determined at thisstage. Measuring risk can be defined as the actual riskassociated with implementing the change versus the riskof possible failures if changes are not implemented. Bothtypes of risks should be evaluated and costed. Anotherportion of determining risk is based on the impact of thechange on other components of the environment. Today,in a highly shared environment, an individual cannot trackall of the touch points between technology and businessservices. For example, if a change requires a clustered webserver to be rebooted, what business services are affectedand what is the impact on Service Level Agreements?

8 Integration with Configuration Management can help byallowing you to work through what if scenarios to determinethe impact of a technology change on business next station is actually a major hub for a number ofactivities. Categorization involves evaluating the size ofthe change from a resource requirements perspective, therisk associated with the change, as well as the priority,and then deciding on the process steps to be is an extremely important activity, since itis assigned according to business impact, and thereforedetermines the level of change authorizations andfinancial and resource requirements. During this stage, ITmust collaborate with the business to ensure the correctcategorization of changes and avoid problems furtherdown the bulk of Change Management work is done at thisstation, with many checks and balances to ensure thatchange approval becomes relatively straightforward.

9 Here,organizations can realize the major benefits of ChangeManagement, for example, by utilizing technologies tohelp determine change categories (based on criteria5 REQUEST FORCHANGE (RFC)RFC ANALYSISCHANGEPRIORITIZATIONCATEGORIZE example, by giving CAB members electronic access toRFCs for electronic the CAB approves the change, the doing phases ofscheduling, building, testing and implementation CAB has to be financially responsible and strike abalance between managing risk and controlling all approvals are given, it is now appropriate toschedule the change. More activities need to happenbefore a change window can be selected. In cases of majorreleases, an organization may be restricted to certainmaintenance windows and needs to have a place holderin the Forward Schedule of Changes (FSC) calendar. Thesekey activities are best controlled by using best practiceproject management.)

10 This is one of the key steps in increas-ing the value and taking advantage of the proactive natureof Change Management. Scheduling should be worked out with the key stake-holders to ensure that all the implementation stepsrequired to institute the change are achievable. Automatedtechnology helps keep everyone informed of what needsto be done and when it is visibility into when changes are to be imple-mented is critical. In this scheduling phase, a ForwardSchedule of Change (FSC) should be updated. This shouldbe a generally available calendar view of when all changewindows are scheduled. It should be clearly stated withineach window any (business) services or technologiesthat will be impacted, along with the start and end timeof the implementation. This is important for a number ofreasons. First, it allows changes to be implementedtogether where there is an opportunity to do so (forexample where there is common infrastructure beingaffected).


Related search queries