ITIL Intermediate OSA - Technology Implementation Considerations Tutorial

Welcome to lesson 9 ‘Technology and Implementation Considerations’ of the ITIL Intermediate OSA Tutorial, which is a part of the ITIL Intermediate OSA Certification Course.

In this lesson, we will have an understanding of how technology and process go hand in hand. This lesson also speaks about basic knowledge of ITSM tool requirement on the Service Operation process perspective.

Let us begin with the objectives of this lesson.

Objectives

By the end of this ‘Technology and Implementation Considerations’ lesson, you will be able to:

  • Understand the Generic requirements, evaluation criteria for process implementation, projects, risks, staffing practices, Service design, transition, and operation

  • Explain the technology requirements for service management tools and where and how they would be used within OSA for process implementation

  • Describe the best practices that need to adapt to overcome challenges and risks when implementing service management technologies.

Moving ahead, let us learn about the generic requirements in the next two sections.

Want to check the course preview of ITIL Intermediate OSA? Watch the course content here!

Generic Requirements (Toolsets)

By generic requirement, we mean standard requirement found in the ITSM tools. Let us go through some of the concepts which are considered as generic requirements from the technology and tool perspective.

Self-Help

Many organizations find it beneficial to offer ‘Self-Help’ capabilities to their users. The technology should, therefore, support this capability with some form of web front-end allowing web pages to be defined offering a menu-driven range of Self-Help and Service Requests

Workflow or process engine

A workflow or process control engine is needed to allow the pre-definition and control of defined processes such as an Incident Lifecycle, Request Fulfillment Lifecycle, Problem Lifecycle, Change Model, etc.

Integrated CMS

The tool should have an integrated CMS to allow the organization’s IT infrastructure assets, components, services and any ancillary CIs (such as contracts, locations, licenses, suppliers etc.)

Discovery/Deployment/Licensing Technology

In order to populate or verify the CMS data and to assist in License Management, discovery or automated audit tools will be required. Such tools should be capable of being run from any location on the network and allow interrogation and recovery of information relating to all components that make up, or are connected to, the IT Infrastructure.

Remote control

It is often helpful for the Service Desk Analysts and other support groups to be able to take control of the user’s desktop (under properly controlled security conditions) so as to allow them to conduct investigations or correct settings, etc. Facilities to allow this level of remote control will be needed.

Diagnostic utilities

It could be extremely useful for the Service Desk and other support groups if the technology incorporated the capability to create and use diagnostic scripts and other diagnostic utilities ( for example, case-based reasoning tools) to assist with earlier diagnosis of incidents.

Reporting

There is no use in storing data unless it can be easily retrieved and used to meet the organization’s purposes. The technology should, therefore, incorporate good reporting capabilities, as well as allow standard interfaces which can be used to input data to industry-standard reporting packages, dashboards, etc.

Dashboards

Dashboard-type technology is used to allow ‘see at a glance’ visibility of overall IT service performance and availability levels. Such displays can be included in management-level reports to users and customers – but can also give real-time information for inclusion in IT web pages to give dynamic reporting, and can be used for support and investigation purposes.

Capabilities to support customized views of information to meet specific levels of interest can be particularly useful.

Integration with Business Service Management

There is a trend within the IT industry to try to bring together business-related IT with the processes and disciplines of IT Service Management – some call this Business Service Management. To facilitate this, business applications and tools need to be interfaced with ITSM support tools to give the required functionality.

We have learned about the generic requirements found in ITSM tools. Now we will proceed to learn about the evaluation criteria for process implementation in Event Management, Incident Management, Request Fulfillment, Problem and Access Management, Service desk and Service design in the next few sections.

Evaluation Criteria for Process Implementation

In the following sections, we will focus on the requirements for the tool from the Service Operation processes perspective.

Let us start with Event Management.

Event Management

From the perspective of Event Management process, the tool should:

  • be multi-environmental, should have an open interface to allow monitoring and alerting

  • be easy to deploy

  • have Standard agents to monitor the most common environment

  • have Open Interfaces to accept any standard

  • have Centralized routing facility of all events to a single location.

  • have Configurable and programmable functionality

  • have the Capability to manipulate events

  • have the Capability to suppress or flag events and ability to allow an operator to acknowledge an alert

  • support for design or test stages and it should have good reporting functionality.

Incident Management

From the perspective of Incident Management process, the tool should have:

  • Incident logging capabilities, an integral CMS, a process flow engine

  • Automated Alerting facility, integral KEDB, and Automated Escalation

  • Open interface to event management tools, a web interface for self-help

  • Diagnostic tools and reporting capabilities as well as Easy to use

Request Fulfillment

From Request Fulfillment perspective, the tool should:

  • be able to link service request to incidents or events.

  • have Front-end self-help capabilities for users to submit requests

  • have Proper access controls and Integration to Service Catalogue will benefit the tool from the process perspective.

Problem Management

From Problem Management perspective, the tool should have the facility where:

  • Problem records can be linked to the related incidents

  • Integration with change management and KEDB is necessary

  • Integration of CMS to link the problem records with specific CI will obviously benefit the product from the process perspective

Access Management

From the Access Management viewpoint, the tool should be integrated with human resource management process and it should have Directory Services Technology.

Service Desk

From the viewpoint of Service Desk, the tool should have:

  • Integrated KEDB

  • Diagnostic Scripts

  • Self –help Web Interface

  • Remote Control

Service Design Evaluation Criteria

The use of tools will enable the centralization of key processes and the automation and integration of core Service Management processes. The raw data collected by the tools can be analyzed, resulting in the identification of ‘trends.’

Preventative measures can then be implemented, again improving the quality of the IT service provision. Some points that organizations should consider when evaluating Service Management tools include:

  • Data structure, data handling, and integration

  • Integration of multi-vendor infrastructure components and the need to absorb new components in the future – these will place particular demands on the data-handling and modeling capabilities of the tool

  • Conformity to international open standards

  • Flexibility in implementation, usage and data sharing

  • Usability – the ease of use permitted by the user interface

  • Support for monitoring service levels

  • Distributed clients with a centralized shared database (e.g. client-server)

  • Conversion requirements for previously tracked data

  • Data backup, control, and security

  • Support options provided by the tool vendor

  • Scalability at increasing of capacity (the number of users, volume of data and so on)

Service Design Evaluation Criteria

The figure given above shows the standard approach of identifying requirements before identifying products, but pragmatically there may be some element of overlap where exploration of tools on the market opens one’s eyes to new options that change the requirements.

These stages are targeted primarily at the evaluation of packaged software products, but a similar approach could also be used when evaluating custom-built software. Produce a clear Statement of Requirements (SoR) that identifies the business requirements together with the mandatory facilities and those features that it would be ‘nice to have’.

Also, identify the site policies and standards to which the product must conform. Such standards may include it running under particular system software, or on specific hardware. It is essential to have a Statement of Requirements for use during the selection process – this statement can be used as a ‘tick list’.

The tool requirements should be categorized using the MoSCoW analysis where:

  • M stands for MUST have this

  • S stands for SHOULD have this if at all possible

  • C stands for COULD have this if it does not affect anything else

  • W stands for WON’T have this time but WOULD like in the future.

Let us look at the risks and staffing practices by service operation in the next couple of sections.

Projects, Risks and Staffing Practices

The risks and staffing practices by service operation are discussed as follows:

Service Operation and Project Management

Service operation is the phase where the actual value gets realized. So we can say that effective and efficient management of service operation processes will help in delivering the effective and efficient value to the customers.

Using Project Management to manage these types of activities, we could have clearly stated and agreed benefits. Implementation of project management will provide 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 its cost. Greater consistency, improved quality, and achievement of objectives results in higher credibility for operational groups and these are the other benefits of project management implementation.

Operational Staff in Service Design and Transition

All IT groups will be involved during Service Design and Service transition to ensure that new components or service are designed, tested and implemented to provide the correct levels of functionality, usability, availability, capacity, etc.

Additionally, 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 skills levels

  • 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

  • No complex support paths between multiple support departments of third-party organizations.

In the next section, we will learn about assessing and managing risk in service operation.

Preparing to become an expert in ITIL Intermediate OSA? Enroll in our ITIL OSA Course today!

Implementing Service Operation - Managing Risk in Service Operation

Assessing and Managing Risk in Service Operation There will be a number of occasions where it is imperative that risk assessment to Service Operation is quickly undertaken and acted upon. The most obvious area is in assessing the risk of potential changes or Known Errors.

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/Problem Management or warnings raised by manufacturers, suppliers or contractors

  • New projects that will ultimately result in delivery into the live environment

  • Environmental risk (encompassing IT Service Continuity-type risks to the physical environment and locale as well as political, commercial or industrial relations related risks)

  • Suppliers, particularly where new suppliers are involved or where key service components are under the control of third parties

  • Security risks – both theoretical or actual arising from security-related incidents or events

  • New customers (or) services to be supported.

So far we have looked at assessing and managing risk in service operation. Next, we will learn about managing change in service operation.

Implementing Service Operation - Managing Change in Service Operation

Service Operation staff must ensure that any changes are absorbed without adverse impact on 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

  • New or upgraded applications software

  • New or upgraded system software (operating systems, utilities, middleware etc. including patches and bug fixes

  • Legislative, conformance or governance changes

  • Obsolescence – some components may become obsolete and require replacement or cease to be supported by the supplier/maintainer

  • Business imperative – you have to be flexible to work in ITSM, particularly during Service Operation, and there will be many occasions when the business needs IT changes to meet dynamic business requirements

  • Enhancements to processes, procedures and/or underpinning tools to improve IT delivery or reduce financial costs

  • Changes of management or personnel (ranging from loss or transfer of individuals right through to major takeovers or acquisitions)

  • Change of service levels or in service provision – outsourcing, in-sourcing, partnerships, etc.

Service Operation staff must be involved in the assessment of all changes to ensure that operational issues are fully taken into account. This involvement should be there at all stages of the change lifecycle. The Change Manager should inform all affected parties of the change being assessed so input can be prepared and available prior to CAB meetings.

However, it is important that Service Operation staff are involved at these latter stages as they may be involved in the actual implementation and they will wish to ensure that careful scheduling takes place to avoid potential contentions or particularly sensitive periods.

Measurement of successful change 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 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.

In the next couple of sections, we will learn about challenges and risks faced by Service Design and Transition.

Service Design - Challenges

With every undertaking, there will be challenges or difficulties to face and to overcome. This will be especially true when attempting to design new services and processes that meet the requirements of all stakeholders within the business.

Experience has shown that the following will help to overcome the challenges:

  • Understanding the business requirements and the business priorities and ensuring that these are uppermost in mind when designing the processes and the services.

  • Communications will be vitally important both in explaining what is happening and how individuals will be affected and in listening to the requirements and needs of the individuals. It’s vitally important to communicate with people about concerns that relate to their daily job.

  • Involve as many people as possible in the design. Setting up focus groups or steering groups can be very effective in getting the right solution as well as gaining wider support.

  • Gaining commitment from senior management as well as from all levels of staff.

Service Design - Risks

There are a number of risks directly associated with the Service Design phase of the Service Lifecycle. These risks need to be identified to ensure that they are not realized. They include the following:

  • If any of the PFSs for Service Design is not met, then the Service Design or Service Management process will not be successful.

  • If maturity levels of one process are low, it will be impossible to achieve full maturity in other processes.

  • Business requirements are not clear to IT staff.

  • Business timescales are such that insufficient time is given for proper Service Design.

  • Insufficient testing, resulting in the poor design and therefore poor implementation.

  • An incorrect balance is struck between innovation, risk, and cost while seeking a competitive edge, where desired by the business.

  • The fit between infrastructures, customers, and partners is not sufficient to meet the overall business requirements.

  • A coordinated interface is not provided between IT planners and business planners.

  • The policies and strategies, especially the Service Management strategy, are not available from Service Strategy, or its content is not clearly understood.

  • There are insufficient resources and budget available for Service Design activities.

  • The risk of services developed in isolation using their ‘own’ assets and infrastructure. This can appear to be cheaper in isolation but can be much more costly in the long term because of the financial savings of corporate buying and the extra cost of supporting different architecture.

  • Insufficient time is given to the design phase, or insufficient training given to the staff tasked with the design.

  • Insufficient engagement or commitment to the application’s functional development, leading to insufficient attention to Service Design requirements.

Service Transition - Risks

Risks associated with Service transition might include:

  • Change in accountabilities, responsibilities, and practices of existing projects that de-motivate the workforce

  • Alienation of some key support and operations staff

  • Additional unplanned costs to services in transition

  • Resistance to change and circumvention of the processes due to perceived bureaucracy.

Other implementation risks include:

  • Excessive costs to the business due to overly risk-averse

  • Service Transition practices and plans

  • Knowledge sharing

  • Lack of maturity and integration of systems and tools resulting in people ‘blaming’ technology for other shortcomings

  • Poor integration between the processes – causing process isolation and a silo approach to delivering ITSM

  • Loss of productive hours, higher costs, loss of revenue or perhaps even business failure as a result of poor Service Transition processes.

Service Transition - Critical Success Factors

Service provision, in all organizations, needs to be matched to current and rapidly changing business demands. The objective is to improve continually the quality of service, aligned with the business requirements, cost-effectively. To meet this objective, the following critical success factors need to be considered for Service Transition:

  • Understanding and managing the different stakeholder perspectives that underpin effective risk management within an organization and establishing and maintaining stakeholder ‘buy-in’ and commitment

  • Maintaining the contacts and managing all the relationships during Service Transition

  • Integrating with the other service lifecycle stages, processes and disciplines that impact Service Transition

  • Understanding the inherent dependencies among the legacy systems, new technology and human elements that result in unknown dependencies and are risky to change

  • Automating processes to eliminate errors and reduce the cycle time

  • Creating and maintaining new and updated knowledge in a form that people can find and use

  • Developing good-quality systems, tools, processes, and procedures required to manage a Service Transition practice

  • Good Service Management and IT infrastructure tools and technology

Let’s now move on to learn the challenges, risks and critical success factors faced by Service Operation during process implementation.

Service Operation - Challenges

Let us learn about the challenges associated with Service operation.

The major challenge is Lack of engagement with development and project staff.

Traditionally, there has been a separation between Service Operation staff and those staff involved in developing new applications or running projects that will eventually deliver new functionality into the operational environment.

This separation was originally deliberate and driven by the desire to prevent collusion and avoid potential security risks (in some organizations it is still a legislative requirement). However, instead of using this separation of duties to create positive contributions, in many organizations it is a source of rivalry and political maneuvering.

Next challenge is Justifying funding.

It is often difficult to justify expenditure in the area of Service Operation, as money spent in this sphere is often regarded as ‘infrastructure costs’ – with nothing new to show for the investment. In reality, many investments in ITSM, particularly in the Service Operation areas, can save money and show a positive Return on investment – as well as resulting improvement in service quality.

Some examples of potential areas of savings include:

  • Reduced software license costs through the better management of licenses and deployed copies

  • Reduced support costs due to fewer incidents and problems and reduced resolution times

  • Reduced headcount through workforce rationalization, supporting roles and accountability structures

  • Less ‘lost business’ due to poor IT service quality

  • Better utilization of existing infrastructure equipment and deferral of further expenditure due to better capacity management

  • Better-aligned processes, leading to less duplication of activities and better use of existing resources.

Service Operation Managers - Challenges

The following is a list of some of the challenges that Managers in Service Operation should expect to face. There is no easy solution to these challenges, mainly because they are by-products of the organization culture and the decisions made during the process of deciding the organizational structure.

The purpose of including the list is to ensure that Service Operation Managers are conscious of them and can create a plan to deal with them. Service Design may tend to focus on an individual service at a time, whereas Service Operation tends to focus on delivering and supporting all services at the same time.

Service Design will often be conducted in projects, while Service Operation focuses on ongoing, repeatable management processes and activities. The result of this is that operational staff are often not available to participate in Service Design project activities, which in turn results in IT services that are difficult to operate, or which do not include adequate manageability design elements.

In addition, once project staffs have finished the design of one IT Service they could move onto the next project and not be available to support difficulties in the operational environment.

The two stages of the lifecycle have different metrics, which encourages Service Design to complete the project on time, to specification and in the budget. In many cases, it is difficult to forecast what the service will look like and how much it will cost after it has been deployed and operated for some time. When it does not run as expected, IT Operations Management is held responsible.

Service Transition that is not used effectively to manage the transition between the Design and Operation phases. For example, some organizations may only use Change Management to schedule the deployment of changes that have already been made – rather than testing to see whether the change will successfully make the transition between Design and Operation.

It is imperative that the practices of Service Transition are followed and organization policies to prevent poorly managed Change practices are in place. Operation, Change, and Transition Managers must have the authority to deny any changes to the operational environment, without exception, that is not thoroughly tested.

One of the most significant challenges faced by Service Operation Managers is the balancing of many internal and external relationships. Most IT organizations today are complex and as services become more commoditized there is an increased use of value networks, partnerships, and shared services models.

While a significant advantage to dynamically evolving business needs, this increases the complexity of managing services cohesively, efficiently and providing the invisible seam between the customer and the intricate web of how services are actually delivered. A Service Operation Manager should invest in relationship management knowledge and skills to help deal with the complexity of this challenge.

Service Operation - Risks

Failures to meet the challenges are obvious risks. In addition to failure, the other risks are:

Service loss which is the ultimate risk to the business of weaknesses in Service Operation is the loss of critical IT services with subsequent adverse impact on its employees, customers, and finances. In extreme cases, there may be a potential loss to life and limb where the IT services affected are used for critical health or safety purposes.

Risks to successful Service Operation are numerous – and in many cases are the opposite of the Critical Success Factors as described earlier – but also include:

  • Inadequate funding and resources: Funding must be justified, allocated and held in reserve for its original purpose.

  • Loss of momentum: Where staff sees Service Management as ‘flavor of the month’ rather than permanently changing the way they work for the future, any impetus is lost as a result: it must be made clear from the outset that a new way of working is required.

  • Loss of Key Personnel: Sometimes the loss of one or two key personnel can have a severe impact. To try to minimize this effect, organizations should seek to cross-train staff and reduce dependencies upon individuals.

  • Resistance to change: Sometimes people object to new things and are reluctant to take them on board. Education, training, communication and highlighting benefits will help.

  • Lack of management support: This often occurs among Middle Managers, who may not see the overall vision or gain the hands-on benefits that more junior staff may gain.

 

If the initial design is faulty, a successful implementation will never give the required results – and redesign will ultimately be necessary.

In some organizations, Service Management can be viewed with suspicion by both IT and the business. IT staff see it as an attempt to control them, while the business perceives it as an attempt by IT to gain more funding without actually improving anything. The benefits of Service Management should be clearly articulated for all stakeholders.

While the operational staff is encouraged to execute against standards, customer and user expectations sometimes differ. In other cases, one customer may have paid more for a superior service, but when a user from a different area sees the superior service, they feel cheated.

Service Operation - CSFs

Let us discuss the critical success factor for Service Operation as a phase.

Management Support:

Senior and Middle Management support is needed for all ITSM activities and processes, particularly in Service Operation.

Senior Management support is critical for obtaining and maintaining adequate funding and resourcing. Rather than seeing Service Operation as a ‘black hole’ for investment, Senior Management should quantify and champion the benefits of good Service Operation.

They should also be fully informed of the dire results that can occur because of poor Service Operation. Senior Management must provide visible support during the launch of new Service Operation initiatives (such as through appearances at seminars, signatories to memos and announcements, etc.) and their ongoing support must be equally well demonstrated.

Business Support:

It is important that the Business Units also support Service Operation. This level of support can be far better achieved if the Service Operation staff involve the business in all of their activities and are open in their reporting of both successes and failures – and their efforts to improve.

It is equally important that the Business Units understand, accept and carry out the role they play in Service Operation. Good service requires good customers. Adhering to the policies, processes, and procedures, such as using the Service Desk for logging all requests, is a direct responsibility of the customer to support and promote the business.

Champions:

ITSM projects and the resulting ongoing practice (performed by Service Operation staff) are often more successful if one or more champions’ are forthcoming who can lead others through their enthusiasm and commitment for ITSM.

In some cases, these champions may be senior managers who are leading from the top. But champions can also be successful if they come from other tiers of the organization. One or two junior staff can still have a significant beneficial influence on a successful conclusion.

Champions are often created or heavily influenced through formal Service Management training, particularly at more advanced levels where the potential benefits to an organization, and to the individuals who make a career path in Service Management, can be fully explored.

Staffing and Retention:

Projects for new services are usually quite good about specifying required new skills, but often underestimate the number of staff required and how to retain the new skills. The scarcity of resources who have a good understanding of Service Management, attempting to assign too much, too soon, to the existing staff, achieving efficient Service Operation will take time, but if approached correctly it will be achieved.

Service Management Training:

Adequate training and awareness can have much wider overall benefits. As well as creating champions of a few, it can be used to win the ‘hearts and minds’ of many. Service Operation staff must all be aware of the consequences of their actions, both good and bad, on the organization – and all must be instilled with a ‘Service Management culture.’

Suitable Tools:

Many Service Operation processes and activities cannot be performed effectively without adequate support tools. Senior management must ensure that funding for such tools is included in ongoing budgets and support their procurement, deployment and ongoing maintenance.

Validity of Testing:

The quality of IT services that can be provided in Service Operation is dependent upon the quality of systems and components delivered into the operational environment. The quality level will be significantly enhanced if adequate and complete testing of new components and releases is carried out in good time. Documentation should also be tested for completeness and quality.

Measurement and Reporting:

A clear definition is needed of how things will be measured and reported so that all staff has clear targets to aim for and IT and Business Managers are able to quickly and easily review progress and pinpoint any areas for attention.

In the next few sections, we will look at implementing Service operation and steps involved.

Implementing Service Operation - Planning and Implementing Service Management Technologies

Implementing Service Operation – Planning and Implementing Service Management Technologies There are a number of factors that organizations need to plan for in readiness for, and 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: For use by those staff that requires the frequent and prolonged use of the module (e.g. Service Desk staff would need a dedicated license to use an Incident Management module).

  • Shared Licenses: For staff who make fairly regular use of the module, but with significant intervals in between, so can usually manage with a shared license

  • Web Licenses: Usually allowing some form of ‘light interface’ via web access to the tool’s capabilities, this is usually suitable for staff requiring remote access, only occasional access, or usage of just a small subset of the functionality (e.g. engineering staff wishing to log details of actions taken on incidents or users just wanting to log an incident directly).

  • Service on Demand: There has been a trend within the IT industry for suppliers to offer IT applications ‘on demand,’ where access is given to the application for a period of demand and then severed when it is no longer needed – and charged on the basis of the time spent using the application.

Deployment:

Many ITSM tools, particularly Discovery and Event Monitoring tools, will require some client/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.

Even where network deployment is possible, this needs careful scheduling and testing – and records must be maintained throughout the rollout so that support staff has knowledge of who has been upgraded and who has not. Some form of interim Change Management may be necessary and the CMS should be updated as the rollout progresses.

Capacity Checks:

Some Capacity Management 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 – any that cannot need upgrading or replacing, and lead times for these actions need to be included in the plans.

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.

Timing of Technology Deployment:

Care is needed to ensure that tools are deployed at the appropriate time in relation to the organization’s level of ITSM sophistication and knowledge. 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.

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!’

Type of Introduction:

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, tool 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.

We have come to the end of this module as well as the syllabus. Let us quickly recap on this module in the next section.

Summary

In this module, we have covered information on Generic requirements, evaluation criteria for process implementation, projects, risks, staffing practices, Service design, transition and operation and lastly to plan and implement Service Management Technologies.

With this, we come to the end of Operational Support and Analysis. To get trained on ITIL Intermediate OSA, consider taking up the ITIL Intermediate OSA Certification Course.

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

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

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*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy