Implementation of Service Operation Tutorial

7.1 Implementation Considerations

Learning Unit 7: Implementation considerations. This lesson covers Implementation considerations which should be addressed by the time processes and functions and service cum operations.

7.2 Implementation Considerations

There are a number of processes and functions described in this module, and it is therefore important to address the implementation considerations which should have been addressed by the time they come into operation. A number of these have been covered in the previous modules; this Module will focus on some generic implementation guidance for Service Operation as a whole. At the end of this module you will be able to understand and describe implementation considerations for: • Managing Change in Service Operation. • Service Operation and Project Management. • Assessing and Managing Risk in Service Operation. • You will also be able to understand and describe the importance of Operational Staff in Service Design and Transition. • lastly Implementation considerations required for Planning and Implementing Service Management Technologies. Let us learn about each of the above points in detail. In the next slide we will look at managing change in Service Operation.

7.3 Managing Change In Service Operation

Let us start with the considerations for managing change in Service Operation. Service Operation should strive to achieve stability – but not stagnation! There are many valid and advantageous reasons why ‘change is a good thing’ – but Service Operation staff must ensure that any changes are absorbed without adverse impact upon the stability of the IT services being offered. There are many things that may trigger a change in the Service Operation environment. These include: • New or upgraded hardware or network components or Process enhancements • Changes of management or personnel (ranging from loss or transfer of individuals right through to major take-over’s or acquisitions) • Service Operation staff must be involved in the assessment of all changes to ensure that operational issues are fully taken into account. It is important that Service Operation staff is involved in these latter stages as they may be involved in the actual implementation and they would want to ensure that careful scheduling takes place to avoid potential disputes or particularly sensitive periods. Upon completion, change should be measured as successful or unsuccessful. The ultimate measure of success in respect of changes made to Service Operation is that customers and users do not experience any variation or outage of the service. So far as possible, the effects of changes should be invisible, apart from any enhanced functionality, quality or financial savings resulting from the change. Let us now move on to our next slide and look at the considerations for Service Operation and Project Management.

7.4 Service Operation And Project Management

In our last slide we understood the considerations for managing change in Service Operation. This slide explains the considerations for Service Operation and Project Management Because Service Operation is generally viewed as ‘business as usual’ and often focused on executing defined procedures in a standard way, there is a tendency not to use Project Management processes when they would in fact be appropriate. For example, major infrastructure upgrades, or the deployment of new or changed procedures, are significant tasks where formal Project Management can be used to improve control and manage costs/resources. Using Project Management to manage these types of activity would have benefits like clearly stated and agreed project benefits, more visibility of what is being done and how it is being managed, which makes it easier for other IT groups and the business to quantify the contributions made by operational teams This in turn makes it easier to obtain funding for projects that have traditionally been difficult to justify the cost., Greater consistency and improved quality and Achievement of objective results in higher credibility for operational groups. In the next slide we will learn about the considerations for Assessing and Managing risks in service Operation.

7.5 Assessing And Managing Risks In Service Operation

In our last slide we understood the considerations for Service Operation and Project Management. This slide explains the considerations for Assessing and Managing Risks in Service Operation Let us agree that there will be a number of occasions where it is vital that a risk assessment of Service Operation is quickly undertaken and acted upon. The most obvious area is in assessing the risk of potential changes or Known Errors but in addition Service Operation staff may need to be involved in assessing the risk and impact of Failures, or potential failures – either reported by Event Management or Incident or Problem Management, or warnings raised by manufacturers, suppliers or contractors. New projects will result in the live environment deployment. Environmental risk surrounding IT service Continuity-type risks to the physical environment and locale as well as political, commercial or industrial-relations related risks. New customers and Suppliers, particularly where new suppliers are involved or where key service components are under the control of third parties. Security risks – either theoretical or actual arising from security related incidents or events have to be assessed. Let us now move on to the next slide on service operations staff involvement in Service design and transition.

7.6 Operational Staff In Service Design And Transition

In our last slide we understood the considerations for Assessing and Managing Risks in Service Operation. This slide explains the importance of service operations staff involvement in Service Design and Service Transition. Service Operation staff must be involved during the early stages of Service Design and Service Transition to ensure that when new services reach the live environment they are fit for purpose, from a Service Operation perspective, and are ‘supportable’ in the future. In this context, ‘supportable’ means: Capable of being supported from a technical and operational viewpoint from within existing, or pre-agreed additional resources and skill levels. Staff should work- Without adverse impact on other existing technical or operational working practices, processes or schedules, Without any unexpected operational costs or ongoing or escalating support expenditure, Without any unexpected contractual or legal complications and No complex support paths between multiple support departments of third-party organizations. A point to note here is that Change is not just about technology. It also requires training, awareness, cultural change, motivational issues and a lot more. Further details regarding the wider management of change are covered in the Service Transition publication Moving on let’s look at the considerations for Planning and Implementing Service Management Technologies.

7.7 Planning And Implementing Service Management Technologies

In our last slide we understood the importance of service operations involvement in Service Design and Service Transition. This slide explains the considerations for Planning and Implementing Service Management Technologies There are a number of factors that organizations need to plan during deployment and implementation of, ITSM support tools. These include Licenses- The overall cost of ITSM tools, particularly the integrated tool that will form the heart of the required toolset, is usually determined by the number and type of user licenses that the organization needs. Licenses are often available in the following types Dedicated licenses are for the use by those staff that requires frequent and continued use of the module example: Service Design staff need dedicated license to use Incident management module. Shared licenses are for staff who use the module, but with significant intervals, so can usually manage with a shared license (e.g. Third-line support staff may need regular access to an Incident Management module – but only at times when they are actively updating an incident record) Web licenses are Usually for allowing some form of ‘light interface’ via web access to the tool’s capabilities, this is usually suitable for staff requiring occasional remote access, or use of just a small subset of the functionality for example engineering staff wishing to log details of actions taken on incidents or users just wanting to log an Incident directly. The next important point is at the stage of Deployment- Many ITSM tools, particularly Discovery and Event Monitoring tools will require some clientor agent software deploying to all target locations before they can be used. This will need careful planning and execution – and should be handled through formal Release and Deployment Management. It also needs to be considered that Capacity checks may be necessary in advance to ensure that all of the target locations have sufficient storage and processing capacity to host and run the new software. The capacity of the network should also be checked to establish whether it can handle the transmission of management information, the transmission of log files and the distribution of clients, and also possibly software and configuration files. The third point to be considered is the Timing of technology deployment If tools are deployed too soon, they may be seen as an immediate panacea and any necessary action to change processes, working practices or attitudes may be hindered or overlooked. Similarly, care is needed to ensure that training in any tools is provided at the correct point – not too early or knowledge will diminish or be lost. A tool alone is usually not enough to make things work better. There is an old adage: ‘A fool with a tool is still a fool!’ Lastly A decision is needed on what type of introduction is needed – whether to go for a ‘Big Bang’ introduction or some sort of phased approach. As most organizations will not start from a ‘green field’ situation, and will have live services to keep running during the introduction, a phased approach is more likely to be necessary. In many cases a new tool will be replacing an older, probably less sophisticated, tools and the switchover between the two is another factor to be planned. This will often involve deciding what data needs to be carried forward from the old tool to the new one – and this may require significant reformatting to achieve the required results. Ideally this transfer should be done electronically – but in some cases a small amount of rekeying of live data may be inevitable and should be factored into the plans. This summarizes our implementation considerations module. Now let us move to the last module on challenges, critical success factors and risks of Service Operation.

7.8 Summary

As we have come to the end of learning unit 7, let us summarize. In unit we discussed about implementation considerations during: Managing Change in Service Operation Service Operation and Project Management Assessing and Managing Risks in Service Operation Operational staff in Service Design and Transition Planning and Implementing Service Management Next is the quiz section, complete it before you proceed to learning unit 8 on Challenges, CSFs and risks of service operation.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*