Technology and Implementation considerations Tutorial

8.1 Technology and Implementation Considerations

Welcome to learning unit 8 on Technology and Implementation considerations for PPO. Let’s begin with the agenda on the next slide.

8.2 Technology and Implementation Considerations

Here are the technology and implementation requirements, which we will discuss in detail in the subsequent slides. • Generic requirements • Evaluation criteria • Good practices for Process Implementation • Projects, Risks and Staffing Practices • Service Design, Service Transition and Service Operation ( Challenges, CSFs and Risks) • How to plan and implement Service Management Technologies • Consideration for implementing technologies in supporting the processes within planning, protection and optimization practice Let ‘s start by learning about the tools and technology used in PPO.

8.3 PPO Technology Considerations

Tools & Technologies in PPO supports whole service lifecycle, like • Management of all stages of the Service Lifecycle, aspects of the service and its performance • Identifying service achievement • Consolidating metrics and Metrics Trees • Consistent and consolidated views across all processes, systems, technologies and groups • Comprehensive set of search and reporting facilities • Management of service costs • Management of relationships, interfaces and inter-dependencies • Management of the Information Security system • Maintenance & support of AMIS • Maintenance & support of CMIS. In the next slide we will look at designing technology architectures.

8.4 Designing Technology Architectures

The architectural design activities within an IT organization are concerned with providing the overall strategic blueprints for the development and deployment of an IT infrastructure that will satisfy the current and future needs of the business. Although these aspects underpin the delivery of quality IT services, they alone cannot deliver quality IT services, and it is essential that the people, process and partner/supplier aspects surrounding these technological components (products are also considered). Architecture’ is a term used in many different contexts. In this context it can be described as the fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. ‘System’ is used in the most general, not necessarily IT, sense to mean a collection of components organized to accomplish a specific function or set of functions. Management architectures IT must manage costs, deliver the right services at the right time, secure information assets, provide dependable service and lead the business in leveraging technologies. This requires automated procedures and management tools in order to achieve this effectively and efficiently. The selection of appropriate management architecture is the key to establishing required level of control and automation. There are two separate approaches to developing management architecture. • Selecting a proprietary management architecture This is based on selecting a single set of management products and tools from a single proprietary management solutions supplier. This approach will normally require less effort, will support and integrate within an overall tool architecture, but will often mean that compromises will have to be made with management functionality and facilities, which may result in gaps. • Selecting a ‘best of breed’ architecture This approach involves the selection of a set of ‘best of breed’ management tools and products from number of management solutions suppliers and then integrating them to provide a comprehensive management solution. Although this will generally require more effort in the integration of the tools into a single comprehensive management solution, it will often provide greater management functionality and facilities, leading to long-term cost savings. In the next slide we will look at the generic requirements of PPO.

8.5 Generic Requirements (Toolsets)

The Generic Requirements are as follows: • Establish the generic lifecycle for IT Assets (Requirements, Design and Develop, Build, Test, Deploy, Operate and Optimize, Dispose) and define the principal processes, policies, activities and technologies within each stage of the lifecycle for each type of asset • Formalize the relationships between different types of IT asset, and the relationship between IT asset acquisition and management and other IT disciplines • Define all roles and responsibilities involved in IT asset activities • Establish measures for understanding the (Total) Cost of Ownership of an IT service • Establish policies for the re-use of IT assets across services, e.g. at the corporate level • Define a strategy for the acquisition and management of IT assets, including how it should be aligned with other IT and business strategies. For the applications asset type, additionally: • Define a strategy for the acquisition and management of IT assets, including how it should be aligned with other IT and business strategies • Document the role played by applications in the delivery of IT services to the business • Ensure the generic IT asset lifecycle model is adapted to an applications lifecycle, tailored to different application types • Set standards for the use of different approaches to developing applications, and recognize the role of development methodologies, including those based on‘re-use’ (see the section on Design and Development for further discussion) • Ensure that procedures are in place to consider all requirement types (such as operability, service performance, maintainability, security) in the early stages of application development • Set standards for deciding on the optimal delivery of applications to the organization, such as the use of Application Service Providers, customized developments, COTS and package customization. For the data/information asset type, additionally: • Establish how the general principles of IT asset acquisition and management can help to manage the data/information resources of an organization. Ensure that data designs are undertaken in the light of: • The importance of standardized and re-usable metadata • The need for data quality • The value of data to an organization • The need for data administration and database administration skills • Understanding the ‘corporate’ (or common/cooperative) subject area and individual service (‘system’) views of data • The need to manage data of non-traditional data types such as text, scanned images, video and audio • Awareness of the major storage, security and legal issues for data • Specify how the generic IT assets lifecycle model can be adapted to the data asset type. For the IT infrastructure and environmental asset type, additionally: • Establish standards for acquisition and management of the IT infrastructure and environmental equipment (including hardware, power, O/S software, DBMS software, middleware and networks) and ensure they provide a stable yet adaptable foundation that underpins the provision of IT services to the business • Establish how the generic IT assets lifecycle model should be adapted to a specific IT infrastructure lifecycle • Establish activities to optimize the usage of IT infrastructure assets through their re-use • Specify the need for tools and describe how their overall use and integration assists in the management of an effective IT infrastructure and related services. • Formalize how the competencies of individuals responsible for the IT assets and related services can be regarded as an asset within the organization and are managed as such • Specify how the IT asset lifecycle applies to people assets, particularly in terms of measurable competencies, such as skill, knowledge, understanding, qualifications, experience, attitude and behaviour Next, we will look at evaluation criteria for technology.

8.6 Evaluation Criteria for Technology

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 analysed, 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 modelling 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 of increasing capacity (the number of users, volume of data and soon). In the next slide we will look at the requirements classification.

8.7 Requirements Classification - MoSCoW

Consideration must be given to the exact requirements for the tool. What are the mandatory requirements and what are the desired requirements? Generally the tool should support the processes, not the other way round, so minimize modification of the processes to fit the tool. Where possible, it is better to purchase a fully integrated tool (although not at the expense of efficiency and effectiveness) to underpin many (if not all) Service Management processes. If this is not possible, consideration must be given to the interfaces between the various tools. It is essential to have a Statement of Requirements (SoR) 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: • M – MUST have this • S – SHOULD have this if at all possible • C – COULD have this if it does not affect anything else • W – WON’T have this time but WOULD like in the future. Let us now understand process implementation steps in the next slide.

8.8 Process Implementation

Here are the steps that are part of process implementation: • All the processes are interrelated and in some cases totally dependent on others • Review all processes • Focus on those that need to be addressed first • Conduct a detailed assessment to determine strengths and weakness of IT service provision • Look for quick wins, but not at the expense of the long-term objectives • Throughout the implementation process, key players must be involved in the decision making Next, we will learn about the service valuation criteria.

8.9 Service Design Evaluation Criteria

The figure on the slide 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 (SoR) 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: • M – MUST have this • S – SHOULD have this if at all possible • C – COULD have this if it does not affect anything else • W – WON’T have this time but WOULD like in the future. Let’s look at the challenges of service design in the next slide.

8.10 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. Let us now discuss the risks.

8.11 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 and they are: • If any of the PFSs for Service Design are 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 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 given to the design phase, or insufficient training given to the staff tasked with the design. • Insufficient engagement or commitment with then application’s functional development, leading to insufficient attention to Service Design requirements. In the next slide, we will discuss about the CSFs & KPIs of SD.

8.12 Service Design - CSFs and KPIs

Critical success factor (CSF) is a term for an element that is necessary for an organization or project to achieve its mission. CSFs can be used as a means for identifying the important elements of success. Key performance indicators (KPIs) are measures that quantify objectives and enable the measurement of performance. KPIs should be set and measured against the design and for each of the processes to ensure that the CSFs are met. Together, CSFs and KPIs establish the baseline and mechanisms for tracking performance. Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the CSI register for evaluation and possible implementation. It is important that CSFs are agreed during the design stage of a service and of the processes, and that KPIs are set, measured and reported on to indicate the quality of the service design and the service design processes. There is a requirement to be able to analyse how well the service infrastructure was designed. It is possible to arrive at a good design in a very resource-inefficient manner, and vice versa, so it is important to look at the quality as well as resources needed to achieve the required quality. KPIs around the success of delivery of the service indicate the effectiveness of the service design – for example, does the service meet the (defined) business requirements for availability, reliability, throughput, security, maintainability, serviceability, functionality etc.? KPIs around the resource estimates, however, will show us how efficient the design is. These should be defined as part of quality assurance (QA) planning and release acceptance. These KPIs could be supported by similar component metrics. KPIs for the service design stage may include: • Percentage of service design requirement specifications produced on time (and to budget) • Percentage of service design plans produced on time • Percentage of service design packs completed on time • Percentage of QA and acceptance criteria plans produced on time • Accuracy of service design – for example, was the correct infrastructure built to support the service? • Percentage accuracy of the cost estimate of the whole service design stage • Accuracy of service level agreement(s), operational level agreement(s) and contract(s) – do they really support the required level of service? Let us now proceed to understand challenges of Service Transition.

8.13 Service Transition - Challenges

The complexity of services across the supply chain is increasing and this leads to challenges for any service provider that implements new services or changes existing services. IT within e-business not only supports the primary business processes, but is part of the primary business processes. This prime position brings a wide range of challenges to successful Service Transition, such as: • Enabling almost every business process and service in IT. • Managing many contacts, interfaces and relationships through Service Transition, including a variety of different customers, users, programmes, projects, suppliers and partners • There being little harmonization and integration of the processes and disciplines that impact Service Transition, e.g. finance, engineering, human resource management etc. • There being inherent differences among the legacy systems, new technology and human elements that result in unknown dependencies and are risky to change • Achieving a balance between maintaining a stable production environment and being responsive to the business needs for changing the services • Achieving a balance between pragmatism and bureaucracy • Creating an environment that fosters standardization, simplification and knowledge sharing • Establishing leaders to champion the changes and improvements • Establishing ‘who is doing what, when and where’ and ‘who should be doing what, when and where’ • Developing a culture that encourages people to collaborate and work effectively together and an atmosphere that fosters the cultural shifts necessary to get buy-in from people • Developing standard performance measures and measurement methods across projects and suppliers. • Evaluating the effectiveness of reporting in relation to risk management and corporate governance

8.14 Service Transition - Risks

Implementing the service transition practice should not be made without recognizing the potential risk to services currently in transition and those releases that are planned. A baseline assessment of current service transitions and planned projects will help service transition to identify implementation risks. Service transition risks 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. Let us move to the next slide on CSFs of ST.

8.15 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 to 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 In the next few slides we will discuss about service operations.

8.16 Service Operation - Challenges

There are a number of challenges faced within Service Operation that need to be overcome. These include those set out in this section. 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. 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 usage of existing resources.

8.17 Service Operation Managers - Challenges 1of2

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. The differences between Design activities and Operational activities will continue to present challenges. This is for a number of reasons, including the following: • 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. Operation Managers should work closely with Service Design and Service Transition to provide the Operation perspective to ensure that design and transition outcomes support the overall operational needs. • 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 is 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 staff has 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 in the lifecycle have different metrics, which encourages Service Design to complete the project on time, to specification and in 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.

8.18 Service Operation - Challenges 2of2

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 into the operational environment, without exception, that are not thoroughly tested. These challenges can only be dealt with if Service Operation staff are involved in Service Design and Transition, and this will require that they are formally tasked and measured to do this. Roles identified in the Service Design processes should be included in Technical and IT Application Management staff job descriptions and their time allocated on a project-by-project basis. Another set of challenges relates to measurement. Each alternative structure will introduce different combinations of items that are easy or difficult to measure. For example measuring the performance of a device or team could be relatively easy, but determining whether that performance is good or bad for the overall IT Service is another matter altogether. A good Service Level Management process will help to resolve this, but this means that Service Operation teams must be an integral part of that process. A third set of challenges relates to the use of Virtual Teams. Traditional, hierarchical management structures are becoming inadequate because of the complexity and diversity of most organizations. A management paradigm (Matrix Management) has emerged where employees report to different sources for different tasks. This has resulted in a complex web of accountability and an increased risk of activities falling through the cracks. On the other hand, it also enables the organization to make skills and knowledge available where they are most needed to support the business. Knowledge Management and the mapping of authority structures will become increasingly important as organizations expand and diversify. This is discussed in the ITIL Service Strategy publication. 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.

8.19 Service Operation - Risks

Failures to meet the challenges are obvious risks – but others are described as set out below. Service loss 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 potential loss to life and limb where the IT services affected are used for critical health or safety purposes. Risks to successful Service Operation The risks to achieving 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. • Differing customer expectations. While 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. This problem should be resolved through clear SLM and careful communication during Service Design. Complaints of this nature should be taken up through Continual Service Improvement processes and should not simply involve Service Operation automatically increasing service upon request. Let us discuss about the CSFs in the next slide.

8.20 Service Operation - CSFs 1of3

Following would be the critical success factors we should be consider: 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.

8.21 Service Operation - CSFs 2of3

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. Scarcity of resources who have a good understanding of Service Management. Attempting to assign too much, too soon, to 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’. It is possible to have the finest Service Operation practice and tools in the world – but Service Management will not be successful unless the people are also attuned to the overall Service Management objectives. Let’s continue to discuss in the next slide.

8.22 Service Operation - CSFs 3of3

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. This requires a comprehensive and realistic testing environment to be in place for all systems and components – which mirrors the operational environment in terms of volume as well as characteristics. There should be independent testers wherever possible. Funding for such testing environments is essential if high-quality services are to be achieved. Additionally, sufficient time and effort are needed to ensure that testing is properly planned and designed – and adequate time is included for testing, and re-testing should some parts fail! 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.

8.23 Implementing Service Operation - Planning

In this slide we will discuss about Implementing Service Operation – Planning and Implementing Service Management Technologies There are a number of factors that organizations need to plan for in readiness and during deployment and implementation of, ITSM support tools. These include the following: 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 licences that the organization needs. Licences are often available in the following types • Dedicated Licenses: For use by those staff that requires frequent and prolonged use of the module (e.g. Service Desk staff would need a dedicated licence 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 licence • 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 have 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 will 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. Let’s continue to learn about this in the next slide.

8.24 Implementing Service Operation - Planning

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. With this we have come to the end of learning unit 9.

8.25 Exercise - 4

XYZ IT department has carried out a review of all current ITIL projects and have decided to purchase a tool that will support their current and near future needs. Currently, XYZ’s IT has board backing to implement the Service Operation processes and Change Management. Over the next two years the rest of the Service Transition processes will be launched and there is currently a business case awaiting review and approval for Service Level Management and Supplier Management. 1. The IT director has tasked you with producing a MoSCoW chart to define the requirements for a new Service Management tool to support the planned Service Management activities. Budget constraints are tight and you must be able to justify all your decisions.

8.27 Summary

Under the learning unit Technology Considerations and Implementation, we discussed about the following topics. • Generic requirements • Evaluation criteria • Projects, Risks and Staffing Practices • Service Design, Service Transition and Service Operation ( Challenges, CSFs and Risks) • How to plan and implement Service Management Technologies The next section is the quiz section1

  • 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