ITIL® Intermediate RCV Tutorial : Technology and Implementation Considerations

10.1 Technology and implementation considerations

This module deals with technology and implementation considerations and how they contribute to RCV practices. Service Design is specifically used to identify good practices and evaluation criteria for technology and tools. Service Operation provides the specifics on managing changes in operations, service operation and project management, assessing and managing risk in service operation, operational staff in service design and transition and planning and implementing service management technology. Service Transition provides the specifics on the technology considerations for implementing and collaboration for service asset and configuration management and knowledge management. In the next slide we will look at the Generic requirements for integrated ITSM technology.

10.2 List of Generic requirements for integrated ITSM Technology

Let us now list the generic requirements for an integrated ITSM technology . Every ITSM tool should have scope for • Self help • Workflow or process engine • Integrated CMS • Discovery or deployment or licensing technology • Remote control • Diagnostic utilitiesz • Reporting • Dashboards We discuss each point in detail in the next few slides. Let us begin with the Self – Help requirement.

10.3 List of Generic requirements for integrated ITSM Technology

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 –with a direct interface into the back-end process-handling software. The next requirement would be 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 fulfilment lifecycle, problem lifecycle, change model etc. This should allow responsibilities, activities, timescales, escalation paths and alerting to be predefined and then automatically managed. In the following slide we will look at the integrated CMS requirement.

10.4 List of Generic requirements for integrated ITSM Technology

Integrated Configuration Management System Toolsets should have an integrated CMS to allow the organization’s IT infrastructure assets, components, services and any ancillary CIs (such as contracts, locations, licences, suppliers – anything that the IT organization wishes to control) to be held, together with all relevant attributes, in a centralized location, and to allow relationships between each to be stored and maintained, and linked to incident, problem, known error and change records as appropriate.Next, is the Discovery,deploymentand licensing technology In order to populate or verify the CMS data and to assist in licence 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. Moving on, let us look at the remote control and diagnostic utilities in the next slide.

10.5 List of Generic requirements for integrated ITSM Technology

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. Next, 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 (such as, for example, case-based reasoning tools) to help with earlier diagnosis of incidents. In the next slide, we discuss on few more requirements such as reporting and others

10.6 List of Generic requirements for integrated ITSM Technology

Reporting There is no use 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 allowing standard interfaces which can be used to input data to industry-standard reporting packages, dashboards etc. Let us now look at Dashboards. Dashboard-type technology is useful 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. Lastly, Integration with the business To facilitate greater business alignment, business applications and tools need to be able to interface with ITSM support tools to give the required functionality.So far we discussed about the generic requirements of the ITSM technology. In the next slide let us look at the benefits of the technology and tools used in the process implementation.

10.7 Benefits of Technology and Tools for Process Implementation

If we talk about the benefits of the technology and tools in process implementation then following would be answers Tools will enable the Service Design processes to work more effectively Tools will increase efficiency and effectiveness, and provide a wealth of management information, leading to the identification of weak areas The longer-term benefits to be gained from the use of tools are cost savings and increased productivity, which in turn can lead to an increase in the quality of the IT service provision 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.” With the implementation of tools Preventive measures can then be implemented, again improving the quality of the IT service provision The technology and tools can be implemented only when required. Therefore in the next two slides let see how the defining of tool requirements are done?

10.8 Defining Tool Requirements (1 of 2)

Here we will understand the different requirements for the tools required to perform the release control and validation processes It should have proper Data structure, data handling and integration applicability Should have the 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 should be a must Flexibility in implementation, usage and data sharing is needed for better usage of the tool Usability – the ease of use permitted by the user interface is gain enhance the usability It should give proper Support for monitoring service levels so that the improvement approaches can be properly implemented Distributed clients with a centralized shared database (e.g. client server) is necessary for a better management of the data. Conversion requirements for previously tracked data and Data backup, control and security is again required for better data management Support options provided by the tool vendor is needed And Scalability at increasing of capacity (the number of users, volume of data and so on) is advisable Let’s continue this discussion in the next slide.

10.9 Defining Tool Requirements (2 of 2)

Consideration must be given to the exact requirements for the tool like 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. It is essential to have a statement of requirements (SoR) for use during the selection process – this statement can be used as a checklist. 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. Now let us proceed to learn about the evaluation of technology and tools for process implementation.

10.10 Evaluating Technology and Tools for Process Implementation

In this slide we will look at the points considered for evaluation of technology and tools for process implemenatation and they are: The tool must be adequately flexible to support your required access rights. You must be able to determine who is permitted to access what data and for what purpose, e.g. read access to customers. In the early stages, consideration must also be given to the platform on which the tool will be expected to operate – this may be on existing hardware and software or a new purchase. There may be restrictions laid down by IT strategy – for example, all new products may have to reside on specific servers. This might restrict which products could be included in the evaluation process. Make sure that the procurement fits within existing approved budgets. There are many Service Management tools available. Details can be found on the internet, Service Management publications, from asking other organizations, from asking consultants or attending seminars and conferences to see what products are available. During the early stages of the selection process, think about vendor and tool credibility. Are they still going to be supporting the purchase in a few months’ or a year’s time? Consider the past record of the supplier as well as that of the tool. Telephone the supplier’s Service Desk to see how easy it is to get through, and ask some test questions to assess their technical competence. Ask the vendor to arrange a visit to a reference site to see what the experience is with the tool in practice – if possible without the vendor or supplier present. Make sure that the organization has similar requirements of the tool. See the tool in operation and speak to the users about their experiences, both initially and ongoing. Assess the training needs of the organization and evaluate the capability of the supplier to provide the appropriate training. Also the ongoing training and tool update (upgrades and changes in user requirements) will need to be assessed to ascertain the support and training costs. In particular, consider training costs, training location, time required, how soon after training the tool will be in use, and during the implementation project ensure that sufficient training is provided – think about how the new tool will impact both IT and customer. Also ensure that interfaces with other tools and telephony are functioning correctly. It is wise to identify whether the planned combination has been used (or tried) elsewhere and with what results. Consider periods of parallel running alongside existing solutions before finally going live. When evaluating tools, a 100% fit to requirements should not be expected and will almost certainly not be found. The ‘80/20 rule’ should be brought into effect instead. A tool is deemed to be fit for its purpose if it meets 80% or more of the business’s operational requirements. Those operational requirements should be categorized as discussed earlier. Any product should be rejected as unsuitable if not all of the mandatory requirements (‘must haves’) are met. In some circumstances, it will be impossible to find an existing software product that will either meet all of the mandatory requirements or provide an 80% match. In this situation, the product offering the best functional design should be selected and the unsuitable elements re-written. This enhancement process should be done by the vendor if at all possible. In some cases, part of the enhancement costs may be met by the purchaser. Some products have been designed to include user hooks – this provides accessibility to site-written code at key procedural points, without the need for the package to be modified. It doesn’t end when the product has been selected. In many ways this could be considered as only the beginning. The tool now has to be implemented. Once the hardware platform has been prepared and the software loaded, data population needs to be considered. What, where from, how and when? Timing is important to the testing, implementation and the go-live processes. Resources must be available to ensure success. In other words, don’t schedule implementation during a known busy period, such as year-end processing. Today ‘software as a service’ products are available where hardware and software are not required. These products give network based access to and management of commercially available software. These types of products will still require planning and implementation, but this should simplify the process as no dedicated hardware is required. Consideration should also be given to managed service providers and Application Service Providers who may be able to provide the same functionality. So, this is about evaluation, how can the fulfilment of requirements be differentiated? Let’s discuss this in the next slide.

10.11 The Fulfilment of the Tools Requirements

Whatever tool or type of tool is chosen, the fulfilment of the requirements can be differentiated between: Out-of-the box – the requirement is fulfilled Configuration – the tool can be configured with x days of effort to fulfil the requirement and this will be preserved over product upgrades Customization – the tool must be reprogrammed with x days of effort to fulfil the requirement, and this may have to be repeated on every product upgrade. Extensive customization of any product is always best avoided because of the high costs incurred at product upgrade. Vendors may be unwilling to support old releases, and purchasers may be unable to resource the necessary re-application of any bespoke customization. Customization may also release the vendor from much of their support obligations – this would be disastrous if, as a result, your Service Management system is unavailable for any length of time. Further costs would be incurred in providing the bespoke training that would be required. It would be impossible to take advantage of any cheap scheduled training courses being run by the software supplier. Let us now proceed to learn about the Service Management evaluation tool process in the next slide.

10.12 Service Management Tool Evaluation Process

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 usedwhen 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. As we are clear on the process of evaluation let us now look at the evaluation criteria in the next slide.

10.13 Evaluation Criteria

Remember the considerations about the supplier’s suitability, and carry out a formal evaluation of the products under consideration. If well-developed and appropriate tools are used to support the processes, the results achieved will be far greater and often the overall costs of service provision will be less. Selecting the right tool means paying attention to a number of issues: An 80% fit to all functional and technical requirements A meeting of ALL mandatory requirements Little (if any) product customization required Adherence of tool and supplier to Service Management best practice A sound data structure and handling Integration with other Service Management and Operational Management tools Support of open standards and interfaces Business-driven not technology-driven Administration and maintenance costs within budget Acceptable levels of maintenance and release policies Security and integrity Availability of training and consultancy services Good report generation Scalability and growth. Next, we will discuss about managing change in Service Operation.

10.14 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. Let us now discuss about change triggers in the Service Operation.

10.15 Change Triggers in Service Operations

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 take-overs or acquisitions) Change of service levels or in service provision – outsourcing, in-sourcing, partnerships, etc. Let us look at the change assessment in the next slide.

10.16 Change Assessment and Measurement of Successful Change

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 commence as soon as possible and not just at the later stages of change – i.e. CAB and ECAB membership – by which time many fundamental decisions will have been made and influence is likely to be very limited. 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. Along with assessment, let us also look at the 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 slide we will discuss about Service Operation and Project management.

10.17 Service Operation and Project Management

Since 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 the following benefits: The project benefits are clearly stated and agreed There is 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 cost justify Greater consistency and improved quality Achievement of objectives results in higher credibility for operational groups. Let us discuss about assessing and managing risk in Service Operation (SO) in the next slide.

10.18 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 (already covered elsewhere) 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/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/services to be supported. Moving on, let us discuss about operational staff in Service design and transition.

10.19 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 preagreed 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. Note: Change is not just about technology. It also requires training, awareness, cultural change, motivational issues and a lot more. Further details regarding wider management of change are covered in the Service Transition publication. In the next three slides let us discuss about the challenges relating to implementation of service transition practices and processes.

10.20 Challenges Relating to Implementing ST practices and processes

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, resulting in a large customer and stakeholder group that is involved and impacted by service transition 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

10.21 Challenges Relating to Implementing ST practices and processes

The Challenges will also include Achieving a balance between maintaining a stable live 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 Being an enabler of business change and, therefore, an integral component of the business change programmes 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 Let’s continue to discuss few more in the next slide.

10.22 Challenges Relating to Implementing ST practices and processes

In addition to the challenges discussed in last two slide, here are few more and they are: Ensuring that the quality of delivery and support matches the business use of new technology Ensuring that the service transition time and budget are not impacted by events earlier in the service lifecycle (e.g. budget cuts) Understanding the different stakeholder perspectives that underpin effective risk management within an organization Understanding, and being able to assess, the balance between managing risk and taking risks as this affects the overall strategy of the organization, and potential mismatch between project risks and business risk Evaluating the effectiveness of reporting in relation to risk management and corporate governance, including provision of reporting required by Sarbanes-Oxley, ISO/IEC 20000, ISO/ IEC 38500 and COBIT if these are applicable. In the last three slides we discussed about challenges, in the coming slides let’s discuss about CSF’s and risks of implementing ST practices and processes.

10.23 CSF Relating to Implementing ST practices and processes

Let us begin with CRITICAL SUCCESS FACTORS on this slide. Service provision, in all organizations, needs to be matched to current and rapidly changing business demands. The objective is to continually improve 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 ‘buying’ and commitment Having clearly defined relationships and interfaces with programme and project management 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 Being able to appreciate and exploit the cultural and political environment Being able to understand the service and technical configurations and their dependencies Developing a thorough grasp of the hard factors (processes and procedures) and soft factors (skills and competencies) required to manage a service transition practice Developing a workforce with the necessary knowledge and skills, appropriate training and the right service culture Defining clear accountabilities, roles and responsibilities Establishing a culture that enables knowledge to be shared freely and willingly Demonstrating improved cycle time to deliver change and less variation in time, cost and quality predictions during and after transition Demonstrating improved customer and user satisfaction ratings during service transition Demonstrating that the benefits of establishing and improving the service transition practice and processes outweigh the costs (across the organization and services) Being able to communicate the organization’s attitude to risk and approach to risk management more effectively during service transition activities Building a thorough understanding of risks that have impacted or may impact successful service transition of services in the service portfolio. Let’s now discuss about risks in the next slide.

10.24 Risks Relating to Implementing ST practices and processes

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. These 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 generated by overly risk-averse service transition practices and plans Knowledge sharing (the wrong people may have access to information) 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 IT service management (ITSM) Loss of productive hours, higher costs, loss of revenue or perhaps even business failure as a result of poor service transition processes. Next, we will discuss about planning and implementing Service management technologies.

10.25 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 the following. Licenses, deployment, capacity checks , timing of technology deployment and type of introduction. Let us discuss about each factor in detail in the next few slide.

10.26 Planning and Implementing Service Management Technologies

First, let us look at the factor known as Licences 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. Such tools are often sold in modular format, so the exact functionality of each module needs to be well understood and some initial sizing must be conducted to determine how many – and what type – of users will need access to each module. Licences are often available in the following types (the exact terminology may vary depending upon the software supplier). Dedicated licences 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 licences For staff who make fairly regular use of the module, but with significant intervals in between, so can usually manage with a shared licence (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). The ratio of required licences to users needs to be estimated, so the correct number of licences can be purchased – this will depend upon the number of potential users, the length of periods of use and the expected frequency between usages to give an estimated concurrency level. The cost of a shared licence is usually more expensive than that of dedicated licences – but the overall cost is less as users are sharing and fewer licences are therefore needed in total. Web licences 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).Web licences usually cost a lot less than other licences (may even be free with other licences!) and the ratio of use is also often lower – so overall costs are reduced further. Note that some staff may require access to multiple licences (e.g. support staff may require a dedicated or shared licence when in the office during the day, but may require a web licence when providing out of hours support from home). Keep in mind that licences may be required for customers/users/suppliers using the same tool to input, view or update records or reports. Note: Some licence agreements (of any of the types mentioned above) may restrict the usage of the software to an individual device or CPU! 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. This type of offering may be offered by some ITSM tool suppliers – which could be attractive to smaller organizations or if the tools in question are very specialised and used relatively infrequently. An alternative to this is where the use of a tool is offered as part of a specific consultancy assignment (e.g. a specialist Capacity Management consultancy, say, who may offer a regular but relatively infrequent Capacity Planning consultancy package and provide use of the tools for the duration of the assignment). In such cases the licence fees are likely to be included as part of, or as an addendum to, the consultancy fee. A further variation is where software is licensed and charged on an agent/activity basis. An example of this is interrogation/monitoring and/or simulation software (e.g. agent software that can simulate pre-defined customer paths through an organization’s website, to assess and report upon performance and availability). Such software is typically charged on the basis of the number of agents, their location and/or the amount of activity generated. In all cases, full investigations of the licensing structure must be investigated and well understood during the procurement investigations and well before tools are deployed – so that the ultimate costs do not come as any sort of surprise. Next, let us discuss about the second factor known as deployment.

10.27 Planning and Implementing Service Management Technologies

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. It is often necessary for a reboot of the devices for the client software to be recognized – and this needs to be arranged in advance, otherwise long delays can occur if staff do not generally switch off their desktops overnight. There may be particular problems deploying to laptops and other portable equipment and special arrangements may be necessary for staff to log on and receive the new software. Capacity checks is the third factor that needs to be considered for implementing service management technologies.

10.28 Planning and Implementing Service Management Technologies

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 talk about type of introduction in the next slide.

10.29 Planning and Implementing Service Management Technologies

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. Caution: older tools generally relied on more manual entry and maintenance of data so if electronic data migration is being used, an audit should be performed to verify data quality. Where data transfer is complicated or time consuming to achieve, an alternative might be to allow a period of parallel running – with the old tool being available for an initial period alongside the new one, so that historical data can be referenced if needed. In such cases it will be prudent to make the old tool ‘read-only’ so that no mistakes can be made by logging new data in the old tool. Moving on let us discuss about the technology consideration for implementing knowledge management.

10.30 Planning and Implementing Service Management Technologies

Knowledge management tools address an organization’s need to manage the processing of information and promulgation of knowledge. Knowledge management tools address the requirements of maintaining records and documents electronically. Records are distinguished from documents by the fact that they function as evidence of activities, rather than evidence of intentions. Examples of documents include policy statements, plans, procedures, service level agreements and contracts. Let us look at different types of knowledge management tools in the next slide.

10.31 Type of Knowledge Management Tools

The types of knowledge management tools are: Document management Defines the set of capabilities to support the storage, protection, classification, searching, retrieval, maintenance, archiving and retirement of documents and information Records management Defines the set of capabilities to support the storage, protection, classification, searching, retrieval, maintenance, archiving and retirement of records Content management The capability that manages the storage, maintenance and retrieval of documents and information of a system or website. The result is often a knowledge asset represented in written words, figures, graphics and other forms of knowledge presentation. Examples of knowledge services that directly support content management are: Web-publishing tools Web conferencing, wikis, blogs etc. Word processing Data and financial analysis Presentation tools Flow-charting Content management systems (codify, organize, version control, document architectures) Publication and distribution. In the next few slides we will learn about few terms of Knowledge management and implementing them for process execution.

10.32 Implementing the Collaboration for Process Execution

Let us begin with COLLABORATION: Collaboration is the process of sharing tacit knowledge and working together to accomplish stated goals and objectives. The following is a list of knowledge services widely available today, which, when properly implemented, can significantly improve the productivity of people by streamlining and improving the way they collaborate: Shared calendars and tasks Threaded discussions Instant messaging White-boarding Video or teleconferencing Email. Let us discuss about communities in the next slide.

10.33 Implementing the Collaboration for Process Execution

Communities are rapidly becoming the method of choice for groups of people spread across time zones and country boundaries to communicate, collaborate and share knowledge. These communities are typically facilitated through an online medium such as an intranet or extranet, and the community often acts as the integration point for all knowledge services provided to its members. Well-run communities will typically elect a leader to manage and run the community and a group of subject matter experts to contribute and evaluate knowledge assets within the community. Examples of services and functions provided within the typical online community are: Community portals Email alias management Focus groups Intellectual property, best practice, work examples and template repository Online events and net shows. Successful communities often implement a reward and recognition programme for their members. Such a programme is a means to acknowledge and reward the contribution of valuable knowledge assets. These assets are submitted by members of the community and are evaluated by the community leader and elected subject matter experts. The author(s) are then recognized within the community and meaningfully rewarded in some fashion for their contribution. This is a highly effective way to encourage members to share their knowledge and move past the old paradigm that knowledge is power and job security and therefore needs to be hoarded. In addition, it is highly recommended that senior management actively participates in these communities to foster a culture and environment that rewards knowledge sharing and collaboration. Lastly, we will look at workflow management which is an integral process of an organization.

10.34 Implementing the Collaboration for Process Execution

Workflow management is another broad area of knowledge services that provides systemic support for managing knowledge assets through a predefined workflow or process. Many knowledge assets today go through a workflow process that creates, modifies, augments, informs or approves aspects of the asset. For example, within the sphere of application management, a change record is a knowledge asset that moves through a workflow that creates it, modifies it, assesses it, estimates it, authorizes it and ultimately deploys it. Workflow applications provide the infrastructure and support necessary to implement a highly efficient process to accomplish these types of tasks. Typical workflow services provided within this services category include: Workflow design Routeing objects Event services Gate keeping at authorization checkpoints State transition services. Many service management tools include workflow capability that can be configured to support these requirements. In the next few slides we will learn about technology considerations for implementing configuration management.

10.35 Technology Considerations for Implementing Config. Mgmt (1 of 3)

Many organizations have some form of configuration management in operation, but in some cases it is paper-based and not fit for purpose. For large and complex infrastructures, service asset and configuration management will operate more effectively when supported by a software tool that is capable of maintaining a CMS. The CMS contains details about the attributes and the history of each CI and details of the important relationships between CIs. Ideally, any configuration management database (CMDB) should be linked to the definitive media library (DML). Often, several tools need to be integrated to provide the fully automated solution across platforms, e.g. a federated CMDB. The service asset and configuration management process should work with change management to prevent changes from being made to the IT infrastructure or service configuration baseline without valid authorization via change management. The authorization record should automatically ‘drive’ the change. As far as possible, all changes should be recorded on the CMS at least by the time that the change is implemented. The status (e.g. ‘live’, ‘archive’ etc.) of each CI affected by a change should be updated automatically if possible. Examples of ways in which this automatic recording of changes could be implemented include automatic updating of the CMS when software is moved between libraries (e.g. from ‘acceptance test’ to ‘live’, or from ‘live’ to an ‘archive’ library), when the service catalogue is changed, or when a release is distributed.

10.36 Technology Considerations for Implementing Config. Mgmt (2 of 3)

When designing a configuration management system you should consider whether you will need the following functionality: Ability to integrate multiple data sources, based on open standards or known interfaces and protocols Sufficient security controls to limit access on a need-to-know basis Support for CIs of varying complexity, e.g. entire systems, releases, single hardware items, software modules Hierarchical and networked relationships between CIs; by holding information on the relationships between CIs, SACM tools facilitate the impact assessment of requests for change (RFCs) Easy addition of new CIs and deletion of old CIs Automatic validation of input data (e.g. are all CI names unique?) Automatic determination of all relationships that can be automatically established when new CIs are added Support for CIs with different model numbers, version numbers, and copy numbers Automatic identification of other affected CIs when any CI is the subject of an incident report/ record, problem record, known error record, change or release Integration of problem management data within the configuration management system, or at least an interface from the CMS to any separate problem management databases that may exist Automatic updating and recording of the version number of a CI if the version number of any component CI is changed Maintenance of a history of all CIs (both a historical record of the current version – such as installation date, records of changes, previous locations etc. – and of previous versions) Support for the management and use of configuration baselines (corresponding to definitive copies, versions etc.), including support for reversion to trusted versions Ease of interrogation of the CMS and good reporting facilities, including trend analysis (e.g. the ability to identify the number of RFCs affecting particular CIs) Ease of reporting of the CI inventory so as to facilitate configuration audits Flexible reporting tools to facilitate impact analyses The ability to show graphically the configuration models and maps of interconnected CIs, and to input information about new CIs via such maps The ability to show the hierarchy of relationships between ‘parent’ CIs and ‘child’ CIs.

10.37 Technology Considerations for Implementing Config. Mgmt (3 of 3)

For software, support tools should allow control to be maintained, for applications software, from the outset of systems analysis and design right through to live running. Ideally, organizations should use the same tool to control all stages of the lifecycle, although this may not be possible if all the platforms cannot be supported by one software tool. If this is not possible, then the ITSM infrastructure SACM tool should at least allow service asset and configuration management information to be transferred from a software development configuration management system into the CMS without the need for re-keying. These individual tools and solutions may be integrated with the main service management system or the configuration management system where the effort of integration is beneficial. Otherwise, the integration may be undertaken at the procedural or data level. Automating the initial discovery and configuration audits significantly increases the efficiency and effectiveness of SACM. These tools can determine what hardware and software is installed and how applications are mapped to the infrastructure. This results in a greater coverage of audited CIs with the resources available, and staff can focus on handling the exceptions rather than doing the audits. If the DML is not integrated with the CMDB it may be worth automating the comparison of the DML contents with the CMDB. With this we have come to the end of Module 10. In the next slide we have a scenario based quiz.

10.38 Scenario and Questions

Here is a scenario based question sample. Take time to go through the scenario and answer all questions as well as check for right anwers at the same time.

10.41 Learning Unit Summary

Here is the summary of Module 10 topics that we covered so far: • The generic requirements for ITSM tools include: self-help, workflow or process engine, integrated CMS, discovery / deployment/licensing technology, remote control, diagnostic technologies, reporting, dashboards, and integration with business service management • Service Operation staff must ensure that changes are absorbed without adverse impact upon the stability of the IT services being offered • Change triggers, change assessment, and measurement of successful change are important in managing change in operations Let us quickly summarize on this module in the next slide • The factors that organizations need to plan for in the deployment and implementation of ITSM tools are licenses, deployment, capacity checks, timing of technology deployment, and type of introduction • Technology considerations for collaboration for process executions include communities and workflow management • The four key stages of the Deming Cycle are Plan, Do, Check, and Act, after which a phase of consolidation prevents the circle from rolling back down the hill With this we have come to end of the elearning course. Thankyou for participating and do not forget to take up the quiz on each module. Happy Learning!

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