ITIL® Intermediate RCV Tutorial : Technology and Implementation Considerations

Technology and implementation considerations

Welcome to lesson 10 of the ITIL Intermediate RCV tutorial, which is a part of the ITIL Intermediate RCV Foundation Certification course. This module deals with technology and implementation considerations and how they contribute to RCV practices.

Let us look at the objectives of this lesson.

Objectives

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

  • Explain the technology and implementation considerations and their application for the effective management of release, control, and validation.

  • Explain the technology requirements for service management tools, where and how these would be used within RCV, the need, and benefits of tools that support service transition as related to RCV and implementing RCV processes

In the next section, we will look at the Generic requirements for integrated ITSM technology.

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 utilities

  • Reporting

  • Dashboards We discuss each point in detail in the next few sections.

Let us begin with the Self – Help requirement.

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.

Workflow or process engine

A workflow or process control engine is needed to allow the pre-definition and control of defined processes such as an incident lifecycle, request fulfillment lifecycle, problem lifecycle, change model, etc. This should allow responsibilities, activities, timescales, escalation paths and alert to be predefined and then automatically managed.

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.

Discovery/deployment/licensing technology

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

Remote control

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

Diagnostic utilities

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

In the next section, we discuss few more requirements such as reporting and others

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 into industry-standard reporting packages, dashboards, etc.

Dashboards

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

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 the generic requirements of the ITSM technology.

In the next section, let us look at the benefits of the technology and tools used in the process implementation.

Benefits of Technology and Tools for Process Implementation

Let’s talk about the benefits of technology and tools in process implementation.

  • 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 sections, let see how the definition of tool requirements are done?

Defining Tool Requirements

Let us understand the different requirements for the tools required to perform the release control and validation processes. They are:

  • The data structure, data handling, and integration applicability

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

  • Conformity to international open standards 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

  • 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) are necessary for better management of the data.

  • Conversion requirements for previously tracked data

  • Data backup, control, and security is again required for better data management

  • Support options provided by the tool vendor is needed

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

Consideration must be given to the exact requirements for the tool. These considerations include:

  • What are the mandatory requirements and

  • What are the desired requirements?

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.

Evaluating Technology and Tools for Process Implementation

Let us look at the points considered for evaluation of technology and tools for process implementation. 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 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 for 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.

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

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 is 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 fulfillment of requirements be differentiated?

Let’s discuss this in the next section.

The Fulfilment of the Tools Requirements

Whatever tool or type of tool is chosen, the fulfillment 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 fulfill the requirement, and this will be preserved over product upgrades

Customization – the tool must be reprogrammed with x days of effort to fulfill 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 section.

Service Management Tool Evaluation Process

The following figure 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 necessary 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 section.

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 some issues:

  • An 80% fit to all functional and technical requirements

  • A meeting of ALL mandatory requirements

  • Little (if any) product customization required

  • Adherence to 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 managing change in Service Operation.

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 change triggers in the Service Operation.

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 underpinning tools to improve IT delivery or reduce financial costs

  • Changes in 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 section.

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 before 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 section, we will discuss Service Operation and Project management.

Service Operation and Project Management

Since Service Operation is 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 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 assessing and managing risk in Service Operation (SO) in the next section.

Assessing and Managing Risk in Service Operation

There will be some 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 also 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 operational staff in Service design and transition.

Operational staff in Service Design and Transition

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

Additionally, Service Operation staff must be involved during the early stages of Service Design and Service Transition to ensure that when new services reach the live environment, they are fit for purpose, from a Service Operation perspective, and are ‘supportable’ in the future. In this context, ‘supportable’ means:

  • Capable of being supported from a technical and operational viewpoint from within existing, or pre-agreed additional resources and skills levels

  • Without adverse impact on other existing technical or operational working practices, processes or schedules

  • Without any unexpected operational costs or ongoing or escalating support expenditure

  • Without any unexpected contractual or legal complications No complex support paths between multiple support departments of third-party organizations.

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 section, let us discuss the challenges relating to the implementation of service transition practices and processes.

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 were 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 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 section.

Challenges Relating to Implementing ST practices and processes

In addition to the challenges discussed in last two section, here are few more. 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 on risk management and corporate governance, including the provision of reporting required by Sarbanes-Oxley, ISO/IEC 20000, ISO/ IEC 38500 and COBIT if these are applicable.

In the last section, we discussed challenges. In the coming sections, let’s discuss CSFs and risks of implementing ST practices and processes.

CSF Relating to Implementing ST practices and processes

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 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 the 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 the risks in the next section.

How about investing your time in an ITIL Intermediate RCV Certification? Check out our Course Preview now!

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 the planning and implement Service management technologies.

Planning and Implementing Service Management Technologies

There are some 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

  • The timing of technology deployment and

  • Type of introduction.

Let us discuss each factor in detail in the next few sections.

Licenses

The overall cost of ITSM tools, particularly the integrated tool that will form the heart of the required toolset, is usually determined by the number and type of user licenses that the organization needs.

 

Such tools are often sold in a 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.

 

Licenses are often available in the following types (the exact terminology may vary depending upon the software supplier).

 

Dedicated licenses

For use by those staff that requires the frequent and prolonged use of the module (e.g., Service Desk staff would need a dedicated license to use an Incident Management module).

Shared licenses

For staff who make fairly regular use of the module, but with significant intervals in between, so can usually manage with a shared license (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 licenses to users needs to be estimated so the correct number of licenses 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 license is usually more expensive than that of dedicated licenses – but the overall cost is less as users are sharing and fewer licenses are therefore needed in total.

Web licenses

Usually allowing some form of ‘light interface’ via web access to the tool’s capabilities, this is 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 licenses usually cost a lot less than other licenses (may even be free with other licenses!) and the ratio of use is also often lower – so overall costs are reduced further.

Note that some staff may require access to multiple licenses (e.g., support staff may require a dedicated or shared license when in the office during the day, but may require a web license when providing out of hours support from home). Keep in mind that licenses may be required for customers/users/suppliers using the same tool to input, view or update records or reports.

Note: Some license 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 by 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 specialized 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 license 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 simulation software (e.g., agent software that can simulate pre-defined customer paths through an organization’s website, to assess and report on performance and availability).

Such software is typically charged by the number of agents, their location and 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 surprise.

Next, let us discuss the second factor known as deployment.

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 knows 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 the staff does not 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 are the third factor that needs to be considered for implementing service management technologies.

Capacity Checks

Some Capacity Management may be necessary in advance to ensure that all of the target locations have sufficient storage and processing capacity to host and run the new software – any that cannot need upgrading or replacement, 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 the type of introduction in the next section.

Type of Introduction

A decision is needed on what type of introduction is needed – whether to go for a ‘Big Bang’ introduction or some 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 rely 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 the technology consideration for implementing knowledge management.

Technology consideration for Implementing Knowledge Management

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 section.

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 sections, we will learn about few terms of Knowledge management and implement them for process execution.

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 communities in the next section.

Implementing the Collaboration for Process Execution - Communities

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 by 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.

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

Implementing the Collaboration for Process Execution - Workflow Management

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

  • Routing 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 sections, we will learn about technology considerations for implementing configuration management.

Technology Considerations for Implementing Configuration Management (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.

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

Willing to invest in an ITIL Intermediate RCV course? Check out our Course Preview here!

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 are installed and how applications are mapped to the infrastructure.

This results in 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.

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 section

  • The factors that organizations need to plan for in the deployment and implementation of ITSM tools are licenses, deployment, capacity checks, the 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 e-learning course.

Conclusion

This brings us to the end of the ITIL Intermediate RCV Tutorial. Hope you had a good understanding of all the topics covered in this tutorial. You can enroll in our ITIL Intermediate RCV Course to further enhance your knowledge.

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