Tag: ITIL4

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Plan
• Design and Transition
• Improve 

Description

The purpose of the knowledge management practice is to maintain and improve the effective, efficient, and convenient use of information and knowledge across the organization 

Knowledge is one of the most valuable assets of an organization. The knowledge management practice provides a structured approach to defining, building, re-using, and sharing knowledge (i.e. information, skills, practices, solutions, and problems) in various forms. As methods of capturing and sharing knowledge move more towards digital solutions, the practice of knowledge management becomes even more valuable. 

It is important to understand that ‘knowledge’ is not simply information. Knowledge is the use of information in a particular context. This needs to be understood with both the user of the knowledge and the relevant situation in mind. For example, information presented in the form of a 300-page manual is not useful for a service desk analyst who needs to find a fast solution. A better example of knowledge that is fit for purpose might be a simplified set of instructions or reference points that allow the analyst to find the relevant content quickly. 

Knowledge management aims to ensure that stakeholders get the right information, in the proper format, at the right level, and at the correct time, according to their access level and other relevant policies. This requires a procedure for the acquisition of knowledge, including the development, capturing, and harvesting of unstructured knowledge, whether it is formal and documented or informal and tacit knowledge. 

• Plan Knowledge management helps the organization to make sound portfolio decisions and to define its strategy and other plans, and supports financial management. 
• Improve This value chain activity is based on an understanding of the current situation and trends, supported by historical information. Knowledge management provides context for the assessment of achievements and improvement planning. 
• Engage Relationships at all levels, from strategic to operational, are based on an understanding of the context and history of those relationships. Knowledge management helps to better understand stakeholders. 
• Design and transition As with the obtain/build value chain activity, knowledge of the solutions and technologies available, and the re-use of information, can make this value chain activity more effective. 

• Obtain/build The efficiency of this value chain activity can be significantly improved with sufficient knowledge of the solutions and technologies available, and through the re-use of information. 
• Deliver and support Ongoing value chain activity in this area benefits from knowledge management through re-use of solutions in standard situations and a better understanding of the context of non-standard situations that require analysis. 

Skills

SFIA skill:

Knowledge Management KNOW: The systematic management of vital knowledge to create value for the organisation by capturing, sharing, developing and exploiting the collective knowledge of the organisation to improve performance, support decision making and mitigate risks. The development of a supportive and collaborative knowledge sharing culture to drive the successful adoption of technology solutions for knowledge management. Providing access to informal, tacit knowledge as well as formal, documented, explicit knowledge by facilitating internal and external collaboration and communications.

https://www.sfia-online.org/en/framework/sfia-7/skills/strategy-architecture/business-strategy-and-planning/knowledge-management

Certification and Training

Knowledge-Centered Service (KCS®) is a best practice methodology that provides a detailed description of knowledge management principles and practices for service organisations to work more effectively. The KCS methodology is developed and maintained by the Consortium for Service Innovation, a non-profit alliance of service organizations. 

The KCS Academy is the certifying body for KCS and the source for KCS resources. The KCS Academy offers KCS certification for people (KCS Fundamentals, KCS Practices and KCS Trainer) and KCS Verified and Aligned designations for tools and services.

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build

Description

The purpose of the software development and management practice is to ensure that applications meet internal and external stakeholder needs, in terms of functionality, reliability, maintainability, compliance, and auditability.

The term ‘software’ can be used to describe anything from a single program (or suite of programs) to larger constructs (such as an operating system, an operating environment, or a database) on which various smaller application programs, processes, or workflows can run. Therefore the term includes, but is not limited to, desktop applications, or mobile apps, embedded software (controlling machines and devices), and websites.

Software applications, whether developed in house or by a partner or vendor, are of critical importance in the delivery of customer value in technology-enabled business services. As a result, software development and management is a key practice in every modern IT organization, ensuring that applications are fit for purpose and use.

The software development and management practice encompasses activities such as:

• solution architecture
• solution design (user interface, CX, service design, etc.)
• software development
• software testing (which can include several components, such as unit testing, integration testing, regression testing, information security testing, and user acceptance testing)
• management of code repositories or libraries to maintain integrity of artefacts
• package creation, for the effective and efficient deployment of the application
• version control, sharing, and ongoing management of smaller blocks of code.

The two generally accepted approaches to software development are referred to as the waterfall and Agile methods

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build
• Design and Transition
•  

Description

The purpose of the infrastructure and platform management practice is to oversee the infrastructure and platforms used by an organization. When carried out properly, this practice enables the monitoring of technology solutions available to the organization, including the technology of external service providers.

IT infrastructure is the physical and/or virtual technology resources, such as servers, storage, networks, client hardware, middleware, and operating systems software, that provide the environments needed to deliver IT services. This includes any CI a customer uses to access the service or consume a product. IT infrastructure may be managed by the service provider or by an external supplier as dedicated, shared, or cloud services. Infrastructure and platform management may also include the buildings and facilities an organization uses to run its IT infrastructure.

The infrastructure and platform management practice includes the provision of technology needed to support activities that create value for the organization and its stakeholders. This can include being ready to adopt new technologies such as machine learning, chatbots, artificial intelligence, mobile device management, and enterprise mobility management.

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build
• Design and Transition
•  

Description

The purpose of the deployment management practice is to move new or changed hardware, software, documentation, processes, or any other component to live environments. It may also be involved in deploying components to other environments for testing or staging.

Deployment management works closely with release management and change control, but is a separate practice. In some organizations the term ‘provisioning’ is used to describe the deployment of infrastructure, and deployment is only used to mean software deployment, but in this case the term deployment is used to mean both.

There are a number of distinct approaches that can be used for deployment. Many organizations use a combination of these approaches, depending on their specific services and requirements as well as the release sizes, types, and impact.

• Phased deployment: The new or changed components are deployed to just part of the production environment at a time, for example to users in one office, or one country. This operation is repeated as many times as needed until the deployment is complete.
• Continuous delivery: Components are integrated, tested, and deployed when they are needed, providing frequent opportunities for customer feedback loops.
• Big bang deployment: New or changed components are deployed to all targets at the same time. This approach is sometimes needed when dependencies prevent the simultaneous use of both the old and new components. For example, there could be a database schema change that is not compatible with previous versions of some components.
• Pull deployment: New or changed software is made available in a controlled repository, and users download the software to client devices when they choose. This allows users to control the timing of updates, and can be integrated with service request management to enable users to request software only when it is needed.

Components that are available for deployment should be maintained in one or more secure locations to ensure that they are not modified before deployment. These locations are collectively referred to as a definitive media library for software and documentation, and a definitive hardware store for hardware components.

Tools that support deployment are many and varied. They are often integrated with configuration management tools, and can provide support for audit and change management. Most organizations have tools for deploying client software, and these may be integrated with a service portal to support a request management practice.

Communication around deployments is part of release management. Individual deployments are not generally of interest to users and customers until they are released.

If infrastructure is provided as a service, then deployment of new or changed servers, storage, or networking is typically managed by the organization, often treating the infrastructure as a code, so that the organization can automate deployment. In these environments it is possible that some deployments may be under the control of the supplier, such as the installation of firmware updates, or if they provide the operating system as well as the infrastructure they may deploy operating system patches. The IT organization must ensure that they know what deployments are planned, and which have happened, to maintain a controlled environment.

If application development is provided as a service, then deployment may be carried out by the external application developer, by the in-house IT department, or by a service integrator. Again, it is essential that the organization is aware of all deployments so that a controlled environment can be maintained.

In an environment with multiple suppliers it is important to understand the scope and boundaries of each organization’s deployment activities, and how these will interact. Most organizations have a process for deployment, and this is often supported with standard tools and detailed procedures to ensure that software is deployed in a consistent way. It is common to have different processes for different environments. For example, there may be one process for the deployment of client application software, and a completely different process for the deployment of server operating system patches.

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build
• Design and Transition

Description

The purpose of the service validation and testing practice is to ensure that new or changed products and services meet defined requirements. The definition of service value is based on input from customers, business objectives, and regulatory requirements, and is documented as part of the value chain activity of design and transition. These inputs are used to establish measurable quality and performance indicators that support the definition of assurance criteria and testing requirements.

Service validation

Service validation focuses on establishing deployment and release management acceptance criteria (conditions that must be met for production readiness), which are verified through testing. Acceptance criteria can be either utility- or warranty-focused, and are defined through understanding customer, regulatory, business, risk management, and security requirements.

The service validation activities of this practice establish, verify, and document both utility- and warranty-focused service assurance criteria and form the basis for the scope and focus of testing activities.

Testing

A test strategy defines an overall approach to testing. It can apply to an environment, a platform, a set of services, or an individual service. Testing should be carried out equally on both in-house developed systems and externally developed solutions. The test strategy is based on the service acceptance criteria, and should align with the requirements of appropriate stakeholders to ensure testing matches the risk appetite and is fit for purpose.

Typical test types include:

• Utility/functional tests:
  • Unit test A test of a single system component
  • System test Overall testing of the system, including software and platforms
  • Integration test Testing a group of dependent software modules together
  • Regression test Testing whether previously working functions were impacted.
• Warranty/non-functional tests:
  • Performance and capacity test Checking speed and capacity under load
  • Security test Testing vulnerability, policycompliance, penetration, and denial of service risk
  • Compliance test Checking that legal and regulatory requirements have been met
  • Operational test Testing for backup, event monitoring, failover, recovery, and reporting
  • Warranty requirements test Checking for verification of necessary documentation, training, support model definition, and knowledge transfer
  • User acceptance test The test performed by users of a new or changed system to approve a release.

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Engage
• Deliver and support

Description

The purpose of the service request management practice is to support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner.

Service request: A request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery.

Each service request may include one or more of the following:

• a request for a service delivery action (for example, providing a report or replacing a toner cartridge)
• a request for information (for example, how to create a document or what the hours of the office are)
• a request for provision of a resource or service (for example, providing a phone or laptop to a user, or providing a virtual server for a development team)
• a request for access to a resource or service (for example, providing access to a file or folder)
• feedback, compliments, and complaints (for example, complaints about a new interface or compliments to a support team).

Fulfilment of service requests may include changes to services or their components; usually these are standard changes. Service requests are a normal part of service delivery and are not a failure or degradation of service, which are handled as incidents. Since service requests are pre-defined and pre-agreed as a normal part of service delivery, they can usually be formalized, with a clear, standard procedure for initiation, approval, fulfilment, and management. Some service requests have very simple workflows, such as a request for information. Others, such as the setup of a new employee, may be quite complex and require contributions from many teams and systems for fulfilment. Regardless of the complexity, the steps to fulfil the request should be well-known and proven. This allows the service provider to agree times for fulfilment and to provide clear communication of the status of the request to users.

Some service requests require authorization according to financial, information security, or other policies, while others may not need any. To be handled successfully, service request management should follow these guidelines:

• Service requests and their fulfilment should be standardized and automated to the greatest degree possible.
• Policies should be established regarding what service requests will be fulfilled with limited or even no additional approvals so that fulfilment can be streamlined.
• The expectations of users regarding fulfilment times should be clearly set, based on what the organization can realistically deliver.
• Opportunities for improvement should be identified and implemented to produce faster fulfilment times and take advantage of automation.
• Policies and workflows should be included for the documenting and redirecting of any requests that are submitted as service requests, but which should actually be managed as incidents or changes.

Some service requests can be completely fulfilled by automation from submission to closure, allowing for a complete self-service experience. Examples include client software installation or provision of virtual servers.

Service request management is dependent upon well-designed processes and procedures, which are operationalized through tracking and automation tools to maximize the efficiency of the practice. Different types of service request will have different fulfilment workflows, but both efficiency and maintainability will be improved if a limited number of workflow models are identified. When new service requests need to be added to the service catalogue, existing workflow models should be leveraged whenever possible.

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Plan
• Engage

Description

The purpose of the service level management practice is to set clear business-based targets for service levels, and to ensure that delivery of services is properly assessed, monitored, and managed against these targets.

Service level: One or more metrics that define expected or achieved service quality.

This practice involves the definition, documentation, and active management of service levels. As services may involve a ‘bundle’ of varied and disparate activities, a number of these will need to be combined and aggregated to reflect a realistic view.

Service level management provides the end-to-end visibility of the organization’s services. To achieve this, service level management:

• establishes a shared view of the services and target service levels with customers
• ensures the organization meets the defined service levels through the collection, analysis, storage, and reporting of the relevant metrics for the identified services
• performs service reviews to ensure that the current set of services continues to meet the needs of the organization and its customers
• captures and reports on service issues, including performance against defined service levels.

The skills and competencies for service level management include relationship management, business liaison, business analysis, and commercial/supplier management. The practice requires pragmatic focus on the whole service and not simply its constituent parts; for example, simple individual metrics (such as percentage system availability) should not be taken to represent the whole service.

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Engage
• Deliver and support

Description

The purpose of the service desk practice is to capture demand for incident resolution and service requests. It should also be the entry point and single point of contact for the service provider with all of its users.

Service desks provide a clear path for users to report issues, queries, and requests, and have them acknowledged, classified, owned, and actioned. How this practice is managed and delivered may vary from a physical team of people on shift work to a distributed mix of people connected virtually, or automated technology and bots. The function and value remain the same, regardless of the model.

With increased automation and the gradual removal of technical debt, the focus of the service desk is to provide support for ‘people and business’ rather than simply technical issues. Service desks are increasingly being used to get various matters arranged, explained, and coordinated, rather than just to get broken technology fixed, and the service desk has become a vital part of any service operation.

A key point to be understood is that, no matter how efficient the service desk and its people are, there will always be issues that need escalation and underpinning support from other teams. Support and development teams need to work in close collaboration with the service desk to present and deliver a ‘joined up’ approach to users and customers.

The service desk may not need to be highly technical, although some are. However, even if the service desk is fairly simple, it still plays a vital role in the delivery of services, and must be actively supported by its peer groups. It is also essential to understand that the service desk has a major influence on user experience and how the service provider is perceived by the users.

Another key aspect of a good service desk is its practical understanding of the wider business context, the business processes, and the users. Service desks add value not simply through the transactional acts of, for example, incident logging, but also by understanding and acting on the business context of this action. The service desk should be the empathetic and informed link between the service provider and its users.

With increased automation, AI, robotic process automation (RPA), and chatbots, service desks are moving to provide more self-service logging and resolution directly via online portals and mobile applications. The impact on service desks is reduced phone contact, less low-level work, and a greater ability to focus on excellent CX when personal contact is needed.

With increased automation, AI, robotic process automation (RPA), and chatbots, service desks are moving to provide more self-service logging and resolution directly via online portals and mobile applications. The impact on service desks is reduced phone contact, less low-level work, and a greater ability to focus on excellent CX when personal contact is needed.

Skills

SFIA skill Customer service support (CSMG) is aligned to Service Desk practice. CSMG deals with the management and operation of one or more customer service or service desk functions. Acting as a point of contact to support service users and customers reporting issues, requesting information, access, or other services. The delivery of customer service through multiple channels including human, digital, self-service and automated.

SFIA Customer Service support (CSMG) skill

Parent Process Reference Framework: ITIL 4

Service Value Stream Activities

Highly impacted Service Value System(SVS) Activities:

• Obtain/build
• Design and Transition

Description

The purpose of the service design practice is to design products and services that are fit for purpose, fit for use, and that can be delivered by the organization and its ecosystem. This includes planning and organizing people, partners and suppliers, information, communication, technology, and practices for new or changed products and services, and the interaction between the organization and its customers.

If products, services, or practices are not designed properly, they will not necessarily fulfil customer needs or facilitate value creation. If they evolve without proper architecture, interfaces or controls, they are less able to deliver the overall vision and needs of the organization and its internal and external customers.

Even when a product or service is well designed, delivering a solution that addresses the needs of both the organization and customer in a cost-effective and resilient way can be difficult. It is therefore important to consider iterative and incremental approaches to service design, which can ensure that products and services introduced to live operation can continually adapt in alignment with the evolving needs of the organization and its customers.

In the absence of formalized service design, products and services can be unduly expensive to run and prone to failure, resulting in resources being wasted and the product or service not being customer-centred or designed holistically. It is unlikely that any improvement programme will ever be able to achieve what proper design could have achieved in the first place. Without service design, cost-effective products and services that deliver what customers need and expect are extremely hard to achieve.

Service design practice should also ensure that the customer’s journey from demand through to value realization is as pleasant and frictionless as it can be, and delivers the best customer outcome possible. This is achieved by focusing on customer experience (CX) and user experience (UX).

Adopting and implementing a service design practice focused on CX and UX will:

• result in customer-centred products and services that include stakeholders in design activities
• consider the entire environment of a product or service
• enable projects to estimate the cost, timing, resource requirement, and risks associated with service design more accurately
• result in higher volumes of successful change
• make design methods easier for people to adopt and follow
• enable service design assets to be shared and re-used across projects and services
• increase confidence that the new or changed product or service can be delivered to specification without unexpectedly affecting other products, services, or stakeholders
• ensure that new or changed products and services will be maintainable and cost-effective.

It is important that a holistic, results-driven approach to all aspects of service design is adopted, and that when changing or amending any of the individual elements of a service design, all other aspects are considered. It is for this reason that the coordination aspect of service design with the whole organization’s SVS is essential. Designing and developing a new or changed product or service should not be done in isolation, but should consider the impact it will have on:

• other products and services
• all relevant parties, including customers and suppliers
• the existing architectures
• the required technology
• the service management practices
• the necessary measurements and metrics.

Consideration of these factors will not only ensure that the design addresses the functional elements of the service, but also that the management and operational requirements are regarded as a fundamental part of the design, and are not added as an afterthought.

Service design should also be used when the change being made to the product or service is its retirement. Unless the retirement of a product/service is carefully planned, it could cause unexpected negative effects on customers or the organization that might otherwise have been avoided.

Not every change to a product or service will require the same level of service design activity. Every change, no matter how small, will need some degree of design work, but the scale of the activity necessary to ensure success will vary greatly from one change type to another. Organizations must define what level of design activity is required for each category of change, and ensure that everyone within the organization is clear on these criteria.

Service design supports products and services that:

• are business- and customer-oriented, focused, and driven
• are cost-effective
• meet the information and physical security requirements of the organization and any external customers
• are flexible and adaptable, yet fit for purpose at the point of delivery
• can absorb an ever-increasing demand in the volume and speed of change
• meet increasing organizational and customer demands for continuous operation
• are managed and operated to an acceptable level of risk.

With many pressures on the organization, there can be a temptation to ‘cut corners’ on the coordination of practices and relevant parties for service design activities, or to ignore them completely. This should be avoided, as integration and coordination are essential to the overall quality of the products and services that are delivered.