ITIL ITIL-4-Foundation ITIL 4 Foundation Exam Exam Practice Test

D18912E1457D5D1DDCBD40AB3BF70D5D

Over time, the focus of service desks has broadened from simply logging and resolving technical issues, to proving more comprehensive support for people and the business. They are increasingly being used to get various matters arranged, explained, and coordinated. The service desk has a major influence on user experience and how the service provider is perceived by the users. By understanding and acting on the business context of transactional activity (i.e. logging tickets), the service desk is better placed to add value to the organization.

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. It provides a clear path for users to report issues, queries, and requests, and have them acknowledged, classified, owned, and actioned.

An asset is defined as anything that is useful or valuable within a product or service. This value is generally determined financially: how much an asset costs versus how much it saves.

The first important step is identifying and managing all the stakeholder groups that an organization deals with. The first and most obvious stakeholder group is the customers, as in service management the organization’s main goal is to facilitate customer outcomes. Other examples of stakeholder collaboration include:

• Developers working with other internal teams
• Suppliers collaborating with the organization
• Relationship managers collaborating with service consumers
• Customers collaborating with each other
• Internal and external suppliers collaborating with each other

The contribution to improvement of each stakeholder group at each level should be understood, as should the most effective methods to engage with them. Depending on the service and the relationship between the service provider and the service consumer, the expectations about the level and type of collaboration can vary significantly. It is important to involve stakeholders, and address their needs at all levels. Determining the type, method, and frequency of such messaging is one of the central activities related to communication.

Value Streams & Processes

The value streams and processes dimension is concerned with how the various parts of the organization work in an integrated and coordinated way to enable value creation through products and services. This dimension defines the activities, workflows, controls and procedures needed to achieve agreed objectives. What matters in service management is that an organization establishes an operating model that that effectively organizes the key activities needed to manage products and services.

Value streams

A value stream is defined as a series of steps an organization undertakes to create and deliver products and services to consumers.

Structuring the organization’s service and product portfolios around value streams allows it to have a clear picture of what it delivers and how, and to make continual improvements to its services. By mapping its value streams, an organization can identify what is critical, what introduces waste and what can be improved upon.

Processes

A process is defined as a set of interrelated or interacting activities that transform inputs into outputs.

Processes define the sequence of actions and their dependencies, as well as describe what is done to accomplish an objective. Processes are underpinned by policies and can be broken down further through procedures which outline what is done, when, and by whom.

In order to be aligned to customer outcomes and expectations, SLM requires focus and effort to engage and listen to the requirements, issues, concerns, and daily needs of customers:

• Engagement is needed to understand and confirm the actual ongoing needs and requirements of customers, not simply what is interpreted by the service provider or has been agreed several years before. ITIL4 refers to value as being co-created, since it needs the input and validation of customers.
• Listening is important as a relationship-building and trust-building activity, to show customers that they are valued and understood. This helps to move the provider away from always being in ‘solution mode’ and to build new, more constructive partnerships. Each customer is unique, and the service provider must not have a one-size-fits-all approach.

The activities of engaging and listening provide a great opportunity to build improved relationships and to focus on what really needs to be delivered. They also give service delivery staff an experience-based understanding of the day-to-day work that is done with their technology, enabling them to deliver a more business-focused service. When the customer is engaged and listened to, they feel valued and their perception of the service and service management activities improves.

Individual metrics without a specified service context are unhelpful. They should relate to defined outcomes and not simply operational metrics. This can be achieved with balanced bundles of metrics, such as customer satisfaction and key business outcomes.

&text=Individual%20metrics%20without%20a%20specified,satisfaction%20and%20key%20business%20outcomes.

The purpose of the SLM practice is to set clear business-based targets for service performance, so that the delivery of a service can be properly assessed, monitored, and managed against these targets. SLM involves service level activities, including:

• Defining service levels
• Documenting
• Actively managing them

The purpose of the service configuration management practice is to ensure that accurate and reliable information about the configuration of services, and the CIs that support them, is available when and where it is needed. This includes information on how CIs are configured and the relationships between them.

Costs are the amount of money spent on a specific activity or resource. From the service consumer’s perspective, there are two types of cost involved in service relationships:

• Costs removed from the consumer by the service (a part of the value proposition). For example, for a car sharing service, the customer does not pay for the actual cost of purchasing the car.

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 management is dependent upon well-designed processes and procedures, which are operationalized through tracking and automation tools to maximize the efficiency of the practice. To be handled optimally, service request management should follow these guidelines:

• Service requests and their fulfilment should be standardized and automated to the greatest degree possible.
• Policies should define which 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 and costs 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.

It is important to understand the difference in these terms not just for clarity, but because outputs are much easier to measure than outcomes.

• Outputs are nearly always quantitative, with data available to show whether these have been delivered. Outputs are easy to report on and to validate. There is no grey area.
• Outcomes are more challenging to verify because they are both qualitative and quantitative. Whether your outcomes have been achieved will rely, to a great extent, on the perception of the people who receive the service. Perceptions are not easy to measure or report on, but it is essential you find a way to do so.

An SLA is defined as a documented agreement between a service provider and a customer that identifies both services required and the expected level of service.

SLAs are used to measure the performance of services from the customer’s point of view, and it is important that they are agreed in the wider business context.

Some of the key requirements for successful SLAs include:

• They must be related to a defined ‘service’ in the service catalogue. Individual metrics without a specified service context are unhelpful.
• They should relate to defined outcomes and not simply operational metrics. This can be achieved with balanced bundles of metrics, such as customer satisfaction and key business outcomes.
• They should reflect an ‘agreement’: an engagement and discussion between the service provider and the service consumer. It is important to involve all stakeholders, including partners, sponsors, users, and customers.
• They must be simply written and easy to understand and use for all parties.

&text=Some%20of%20the%20key%20requirements,and%20not%20simply%20operational%20metrics.

A guiding principle is a recommendation that provides universal and enduring guidance to an organization, which applies in all circumstances, regardless of changes in its goals, strategies, type of work, or management structure.

.

ITIL® defines a problem as a cause, or potential cause, of one or more incidents. A known error is a problem that has been analyzed but not resolved.

Don't over-engineer solutions. Think about what you can do now.

Like focus on value, this principle is heavily focused on the prevention of waste. Waste correlates with complexity. Higher complexity means there are more opportunities for waste to creep into a system.

Focus on delivering the desired outcome, not building the most elegant and elaborate solution. Use the minimum number of steps to deliver that outcome, ensuring you are not over-processing (delivering quality above and beyond what is required).

Incident management is typically closely aligned with the service desk, which is the single point of contact for all users communicating with IT. When a service is disrupted or fails to deliver the promised performance during normal service hours, it is essential to restore the service to normal operation as quickly as possible.

• Emergency changes. These are changes that must be implemented as soon as possible; for example, to resolve an incident or implement a security patch. Emergency changes are not typically included in a change schedule, and the process for assessment and authorization is expedited to ensure they can be implemented quickly. As far as possible, emergency changes should be subject to the same testing, assessment, and authorization as normal changes, but it may be acceptable to defer some documentation until after the change has been implemented, and sometimes it will be necessary to implement the change with less testing due to time constraints. There may also be a separate change authority for emergency changes, typically including a small number of senior managers who understand the business risks involved.”

&text=Emergency%20changes%20are%20not%20typically,they%20can%20be%20implemented%20quickly.

More complex incidents will usually be escalated to a support team for resolution, or even suppliers and partners who offer support for products and services they provide.