7 Request to Fulfill (R2F) Value Stream

This chapter provides an overview of the Request to Fulfill (R2F) Value Stream – one of four IT Value Streams that comprise the IT Value Chain. It describes the business context, objectives, and details behind the R2F Value Stream.

7.1 Objectives

The R2F Value Stream represents a modern, consumption-driven engagement model and goes beyond the traditional IT service request management. It is a framework for connecting the various consumers (business users, IT practitioners, or end customers) with goods and services that they need to drive productivity and innovation. It fosters service consumption and fulfillment, service costing knowledge sharing, self-service support, and collaboration between communities of interest to improve the overall engagement experience with IT.

Many organizations use multiple IT requests and/or Service Catalogs to address the needs of their consumers. The R2F Value Stream brings these different catalogs and consumer personas into a single consumption experience thereby eliminating the complexity and confusion consumers experience today. The goal of the R2F Value Stream is to provide a blueprint for creating a streamlined consumption experience that consistently engages consumers and eliminates the need for them to avoid working with their IT organization.

The key to success with R2F is dependent upon two primary factors:

The common limitations for current R2F practices include:

7.2 Business Value Proposition

The R2F Value Stream places emphasis on time-to-value, repeatability, and consistency for consumers looking to request and obtain services from IT. It optimizes both service consumption and fulfillment experiences by delineating between the creation of offers and catalog aggregation and Service Catalog Entry composition.

Today IT organizations struggle to increase the ratio of self-sourced services over workflow-based fulfillment requiring direct human intervention. Many fulfillments today require too much intervention that consumes valuable IT resources. By increasing self-sourcing, companies will see improved business velocity and reduction in friction. They will also be able to reduce “shadow-sourcing” within the lines of business because of a more responsive consumption experience. Today’s IT is focused on delivery of technical capabilities – tomorrow’s IT must be positioned to focus on facilitating consumption of multi-sourced services.

The R2F Value Stream emphasizes the importance of deploying standard changes (a form of request management) rather than normal changes for internal fulfillments. Normal, risk-assessed and individually approved changes are one of the most time-consuming and resource-intensive activities in an enterprise-wide IT organization. Service fulfillments should be based on standard Service Models where request criteria and approvals are designed into the model and fully automated fulfillment processes orchestrate all necessary provisioning and Change Management.

The R2F Value Stream plays an important role in helping IT organizations advance toward a service broker model. Such a model is dependent on the organization’s ability to leverage both internal and external sourcing options for satisfying consumer demand. Enterprise IT organizations have been using external suppliers for goods and services for many years. However, the multi-sourcing environment will become more complex as companies expand their use of cloud-based offerings. The R2F Value Stream enables the aggregation of catalogs and catalog entries from multiple providers into a single consumption experience. Therefore, while there is complexity on the delivery side in managing the various catalogs and catalog entries, it is not exposed to the consumer and the ordering experience is seamless and inviting. The R2F Value Stream also enables effective chargeback and service costing mechanisms, a key requirement in a multi-sourcing environment.

The key value propositions for adopting the R2F Value Stream are:

7.3 Key Performance Indicators

The R2F Value Stream critical success factors and Key Performance Indicators (KPIs) are as follows:

Critical Success Factors

Key Performance Indicators (KPIs)

Ability to Meet Customer Expectations

New or modified Subscriptions per time period

% and number of Subscription requests complying or breaching SLA or OLA agreements

Number of Subscription requests accepted and rejected by the requestor for the first time right delivery/fulfillment

Variation in the average time to fulfill Subscription requests for the predictability of delivery

Number of Incidents related to request fulfillment

Arrival and departure rate of service requests

Reduce Costs

Costs (burned resources) per service and per fulfillment step

Breakdown of self-source fulfillments versus one-off fulfillments

% and number of fulfillments requiring human intervention to be completed

Number of service request queues being managed

External Service Provider Compliance

Number of purchase orders per time period

% and number of orders delivered and accepted complying with underpinning contract agreements

% and number of delivered orders breaching underpinning contract agreements

Number of Incidents related to the purchase order fulfillment

Number of purchase orders unfulfilled at the end of a given period

Number of orders delivered and accepted by the requestor per time period

Number of purchase orders rejected via no delivery or cancelled purchase orders

Increase Speed/Agility/Flexibility (Operational Performance)

Completed service requests

Service request work-in-progress

Number of interactions with consumers per service during delivery

% of work-in-progress within SLA

% of completed work within SLA

7.4 Value Stream Definition

The Request to Fulfill (R2F) Value Stream contains primary and secondary functional components. Primary functional components are core to the value stream and are essential for managing the service at this stage of its lifecycle. Secondary functional components are not dedicated to R2F but provide relevant data objects to primary functional components. R2F includes the following primary functional components that provide the technology necessary to support IT portfolio activities:

A functional component utilizes an input data object to conduct key activities and may also provide output data objects to another functional component that requires that data.

The R2F Value Stream primarily focuses on system of record integrations between two functional components like other value streams. However, the R2F Value Stream also includes system of engagement integrations enabling a common user experience or graphical user interface mash-up. The R2F Value Stream functional components with system of engagement integrations are the Engagement Experience Portal and Offer Consumption functional components. The Offer Consumption functional component integrations include system of engagement integrations with the following functional components: Offer Management, Request Rationalization, and Chargeback/Showback.

The Engagement Experience Portal functional component is a secondary functional component since its scope can expand beyond the IT4IT Reference Architecture and into the business domain. It exposes and facilitates a unified engagement between consumers and the IT functions. The main objectives of the Engagement Experience Portal are to:

There may be other engagement experiences presented through the portal but this is the core set called out explicitly in the R2F Value Stream.

Figure 56: Request to Fulfill Level 2 Value Stream Diagram

7.4.1 Engagement Experience Portal (Secondary Functional Component)

The Engagement Experience Portal functional component is based on system of engagement integration design patterns where consumers access different functional components through a common user experience. Consumers manage certain aspects of their profile; for example, localization, preferred method of communication, user interface settings, and so on.

Purpose

Facilitate service consumption by connecting any potential consumer with the right information, goods, services, or capability at the right time through a single experience, taking into account the consumer profile. Provide an intuitive experience that draws consumers in instead of being viewed as an inhibitor to productivity that is forced upon them. Provide a self-configurable experience (such as mash-ups) so that the different types of consumers can tune the experience to best suit their needs. Provide an interface supported across multiple devices such as smartphones, tablets, etc. Provide plug-and-play connectivity for components that need to be exposed through the portal. Components for connectivity include but are not limited to catalog-driven service consumption.

Key Data Objects

Key Attributes

The User Profile data object shall have the following key data attributes:

Key Data Object Relationships

The User Profile data object shall maintain the following relationships:

Functional Criteria

The Engagement Experience Portal functional component:

Model

Figure 57: Engagement Experience Portal Level 2 Model

7.4.1.1    Service Catalog Functional Sub-Component

The Service Catalog functional sub-component enables consumers to engage with and consume services through the Offer Consumption functional component. This includes but is not limited to ordering new services, modifying Subscriptions, viewing the status of existing services or requests, and costs associated with services. For a detailed description of the functionality of the Service Catalog, refer to Section 7.4.2.

7.4.1.2    Collaboration Functional Sub-Component

The Collaboration functional sub-component provides the user front end for an enterprise collaboration experience, such as a chat capability.

7.4.1.3    Knowledge Functional Sub-Component

The Knowledge functional sub-component provides the interface for users to search and read Knowledge data objects of all types and sources. Knowledge data objects may include but are not limited to IT or supplier-created technical briefs, training videos, and user-created content.

7.4.1.4    Self-Service Support Functional Sub-Component

The Self-Service Support functional sub-component:

The Self-Service Support functional sub-component:

7.4.2 Offer Consumption Functional Component

Purpose

Present service offers to various service consumers. Facilitate consumption/management of and payment for IT services rendered. Utilize the User Profile to present a personalized experience which includes consumer-specific information such as personal preferences, location, or job function. Present consumable offers derived from Service Catalog Entries with associated descriptions, pictures, prices, and purchasing options to prospective consumers. Enable consumers to manage their Subscriptions by:

Key Data Objects

Note: Shopping Cart is an auxiliary data object (not key) but is being described here to help with the reader’s understanding of the R2F Value Stream.

Key Attributes

The Shopping Cart data object shall have the following key data attributes:

Multiple services can be ordered for every item ordered in one Shopping Cart, therefore these attributes apply per item in the Shopping Cart:

Key Data Object Relationships

The Shopping Cart data object shall maintain the following relationships:

Functional Criteria

The Offer Consumption functional component:

Model

Figure 58: Offer Consumption Functional Component Level 2 Model

7.4.3 Offer Management Functional Component

Purpose

Aggregate (mash-up) all Catalog Composition items and external supplier catalogs into consumable Offers that users can order through the Offer Consumption functional component. Build and publish the various offerings into Offer Catalogs for various populations to consume, determine prices, and valid options that consumers can select. Enable Offers to be grouped into an Offer Catalog to expose them as a collection of consumable items for a given group of consumers. Fulfill each Offer through numerous underlying Catalog Compositions as determined by this functional component.

Key Data Objects

Auxiliary Data Objects

Key Attributes

The Offer data object shall have the following key data attributes:

The Offer Catalog data object shall have the following key data attributes:

Key Data Object Relationships

The Offer data object shall maintain the following relationships:

The Offer Catalog data object shall maintain the following relationships:

Functional Criteria

The Offer Management functional component:

Model

Figure 59: Offer Management Functional Component Level 2 Model

7.4.4 Catalog Composition Functional Component

Purpose

Create and publish the Service Catalog Entries, including all of their dependencies, at the level at which these can be presented as Offers in the Offer Management functional component. Service Catalog Entries are created from the Service Release Blueprint in the Release Composition functional component (R2D Value Stream). Services, as well as their dependencies and details, are accurately defined, including supplying the necessary information for the service to be instantiated. Service Catalog Entries are created and updated to prepare them for consumption, including configurable options (e.g., pricing, subscription terms, bundles, service level, support conditions, etc.).

Key Data Objects

Key Attributes

The Service Catalog Entry data object shall have the following key data attributes:

Key Data Object Relationships

The Service Catalog Entry data object shall maintain the following relationships:

Functional Criteria

The Catalog Composition functional component:

Model

Figure 60: Catalog Composition Functional Component Level 2 Model

7.4.5 Request Rationalization Functional Component

Purpose

Rationalize, break down, and route “clean order” requests (ready for fulfillment) to appropriate Fulfillment Execution engines or providers in order to deliver services to consumers. May involve breaking down a single order/request into multiple Fulfillment Requests. Ensure appropriate fulfillment-related Subscription information is kept up-to-date, such as approval/rejections, modifications, cancellations, and so on. Enable the recording of patterns of service consumption that can be used to shape demand for new and/or improved services. Break the request down into the IT services and provide these to the Fulfillment Execution functional component and create the Subscriptions for these services upon their successful fulfillment. Fulfillment status is tracked and completion notifications from fulfillment channel(s) are received. Consumers will be able to receive status updates at the Subscription level, not at the level of the underlying requests needed to fulfill the Subscription.

Key Data Objects

Key Attributes

The Request data object shall have the following key data attributes:

The Subscription data object shall have the following key data attributes:

Key Data Object Relationships

The Request data object shall maintain the following relationships:

The Subscription data object shall maintain the following relationships:

Functional Criteria

The Request Rationalization functional component:

Model

Figure 61: Request Rationalization Functional Component Level 2 Model

7.4.6 Fulfillment Execution Functional Component

Purpose

Orchestrate the delivery of the various requests amongst (one or more) fulfillment engines in order to deliver the IT service. Fulfillers may be systems that perform actions directly, or engage other systems in order to perform actions. They may also include external providers. In order to be able to engage the fulfillers, the Fulfillment Execution functional component needs to:

—  What each fulfiller does (capabilities)

—  How to engage each fulfiller (where they are located and how to invoke them)

The Fulfillment Execution functional component can be used via two paradigms:

Key Data Objects

Key Attributes

The Fulfillment Request data object shall have the following key data attributes:

The Desired Service data object shall have the following key data attributes:

Key Data Object Relationships

The Fulfillment Request data object shall maintain the following relationships:

The Desired Service data object shall maintain the following relationships:

Functional Criteria

The Fulfillment Execution functional component:

Model

Figure 62: Fulfillment Execution Functional Component Level 2 Model

7.4.7 Usage Functional Component

Purpose

Track and manage actual usage of subscribed IT services and their associated costs.

Key Data Objects

Key Attributes

The Usage Record data object shall have the following key data attributes:

Key Data Object Relationships

The Usage Record data object shall maintain the following relationships:

Note: In-case of fixed-price billing, no Usage Record may exist for a given Chargeback Record.

Functional Criteria

The Usage functional component:

Usage Records can have any unit:

—  CPU usage, storage consumption, transaction numbers, …

—  It can also be a cost number from Asset Management.

—  It can be the price a sub-supplier is reporting. A price will be considered the cost of running that component.

Model

Figure 63: Usage Functional Component Level 2 Model

7.4.8 Chargeback/Showback Functional Component

Purpose

Provide chargeback or showback for internal and external services based on Subscription, Service Contract, and/or Usage information.

Key Data Objects

Key Attributes

The Chargeback Contract data object shall have the following key data attributes:

The Chargeback Record data object shall have the following key data attributes:

Key Data Object Relationships

The Chargeback Contract data object shall maintain the following relationships:

Functional Criteria

The Chargeback/Showback functional component:

Model

Figure 64: Chargeback/Showback Functional Component Level 2 Model

7.4.9 Knowledge & Collaboration Supporting Function

Purpose

Provide knowledge in the form of content and Conversations that help to address the needs of IT service consumers. Knowledge includes structured IT/supplier produced articles, or unstructured Conversations from business/IT users, webinars, videos, training materials, etc. which are searchable by the IT service consumers. Increase the contribution to knowledge by providing all users with the ability to generate new content, either through informal Conversations, or by more formal submissions of knowledge. Encourage contributions by promoting a collaborative culture through various techniques such as gamification. Improve accessibility of knowledge in the organization by:

Reduce the number of requests for information/knowledge that arrive at the IT service desk. Provide knowledge for consumption by additional value streams in general and specifically by the D2C Value Stream. IT staff participate in Conversations related to IT services that they plan, develop, or operate. IT service consumers and IT staff consume third-party knowledge through the same experience as the formal and informal forms of knowledge the company provides.

Key Data Objects

Key Attributes

The Knowledge data object shall have the following key data attributes:

The Conversation data object shall have the following key data attributes:

Key Data Object Relationships

The Knowledge data object shall maintain the following relationships:

The Conversation data object shall maintain the following relationships:

Functional Criteria

The Knowledge & Collaboration component:

—  Supporting keyword search capabilities

—  Providing filter capabilities based on various attributes of the Knowledge, such as subject category, time range, source types (internal versus external), etc.

—  Supporting natural language queries to reduce the complexity of finding relevant information

—  Providing users with access to third-party Knowledge and forums

—  Providing natural language processing analytics so (for example) “trending topics” can be reported from service desk interactions

Model

Figure 65: Knowledge & Collaboration Supporting Function Level 2 Model

return to top of page