Overview of creating services

The IT and other business departments within a company can define offered services, publish those services in the service catalog, and automate the fulfillment of those services for their users. 

Any user with the service catalog manager role can create SRDs by using the Service-Catalog-Manager-console or the Service Request Designer console. After the SRD is approved and deployed, a corresponding request becomes available in the online catalog of available requestable services on the Request-Entry-console. The Request Entry console facilitates the management of requests as the requests progress through their life cycle. For information about user roles and features, see BMC-Service-Request-Management-overview and Roles-and-permissions-in-BMC-Service-Request-Management.

Service Request Management provides self-help support for the end users to reduce the number of incoming requests for the service desk. Service Request Management also supports automated tools to submit requests from the catalog.

Service Request Management integrates with the BMC Helix ITSM for backend fulfillment of the requests, such as incidents and change requests. The requester's responses are passed on to the fulfillment application that is responsible for fulfilling the request. The SRD specifies the automated process to fulfill the request, such as forwarding work orders to the appropriate people to fulfill the service request.

Service Request Management leverages the foundational elements of the BMC Helix ITSM and Action Request System, for example, workflow, approvals, task management, notification, and email. Service Request Management also captures the relationships between catalog items and business service definitions and service level agreements through its integration with the BMC Helix CMDB Service Catalog and BMC Service Level Management.

Additionally, you can integrate Service Request Management with other third-party applications. For more information, see Integrating.

To specify the automated process to fulfill a request for the service, you must create the following components contained in the SRD:

• An application template, such as a work order template, incident template, or change template to generate the fulfillment request. 
• An application object template (AOT) that defines the application template and the company for which you are creating the SRD. 
• A process definition template (PDT) that includes one or more AOTs, and defines the process for fulfilling a service request. 

After you have created the AOTs and PDTs, you can create the SRD and associate it with one or more PDTs.

Watch the following video to learn how to configure AOTs, PDTs, and SRDs:

https://youtu.be/-sUdcQiRjPQ

How service request definitions are related to the CMDB Service Catalog

When you create an SRD in Service Request Management, it is translated into a requestable offering in the CMDB Service Catalog. This makes the SRD information and its relationship to services and service offerings available to other consumers. Users can browse the entire service catalog in one location.

A requestable offering is part of a service offering that defines a specific agreement between a service provider and a customer for a service. Each service offering defines a level of service for a price: it combines the service (utility), a service level target (warranty), add-on options, and requestable offerings.

All technical and business services must have at least one service offering. For example, an IT organization offers different service offerings, or levels, for a database server (Gold, Silver, and Bronze) based on response times. Each service offering also costs a different amount based on the service level target. A customer selects among the different database and operating system options for the service and then selects the Silver offering, which has a service level target of a 10-minute response.

Each service offering can have one or more requestable offerings. Like a service offering, an requestable offering defines a specific agreement between the provider and customer that combines the service (utility) and a service level target (warranty) at a specified price or cost. The requestable offering defines what requests and transactions can be submitted about a service offering. These might be requests to deliver or implement an instance of the service offering, or they might be requests for changes, requests for fixing issues, and so on.

Service request definition life cycle

An SRD goes through various states in its life cycle. By default, approval is required for certain state transitions, for example, to move the SRD from Request for Approval to Deployed. You can configure to send notifications at certain points in the SRD life cycle to alert users that certain events have occurred. 

Generally, an SRD starts in the Draft state and becomes visible for selection by service requesters when it is in Deployed state and within the specified effective dates.

After the end effective date, the Service Catalog Manager can re-enable the SRD by resetting the effective dates.

When an SRD is in a Closed state, the associated services are no longer displayed in the Request Entry console, and you cannot deploy the SRD again. 

The following diagram shows the life cycle of an SRD:

You can use data captured from questions configured in an SRD to drive or route the fulfillment process. For more information, see Creating-questions-to-use-with-SRDs.

Testing your knowledge

Check your knowledge. See if you can answer each question. Click the questions to view the answer.

Do you want to learn more?

When you're ready to get started, see Managing-service-requests.