Creating a service catalog
The end-to-end process for setting up the BMC Service Request Management system involves setting up a catalog of requestable service offerings from which your users can select and submit a service request. Examples of services requests include reporting issues with IT systems, requesting changes to employee data, and onboarding new employees.
When you are ready to start creating services, review the information in Guidelines for designing services. Make sure that you have completed all of the configuration steps required for the application, as described in Onboarding and implementing.
Creating a service catalog workflow
Perform the following actions to create a service catalog:
| Action | Description | Reference |
|---|---|---|
| Analyze | Before you begin using the Service Request Management application, analyze what services users will be requesting. In Service Request Management, these services are defined in service request definitions (SRDs). Start by listing all the user requests your company might have, and then organize the user requests into categories. For example, an IT category might include a service for setting up a new employee's computer, phone, and email. A Facilities category might include a service for moving an office or replacing a broken light bulb. You must also analyze your processes and roles. For example, do certain kinds of requests require approvals? From whom? Are certain kinds of requests handled by a specific support group? | Guidelines for designing services |
| Set up user roles and permissions | Set up users and assign these users to the appropriate permissions and functional roles. You can also associate them with the appropriate support groups, if necessary. Service Request Management includes some predefined roles. Additionally, set up permissions for users and groups to ensure that the appropriate people have access to the forms. | |
| Configure navigational categories | You must configure the navigation categories for the services that you want to provide. Users can browse these categories when searching for requests. The categories can also be used to route the assignment of support staff for the request. | Configuring navigational categories |
| Create building blocks for the request fulfillment process (templates and AOTs) | The building blocks of the fulfillment process are application templates and application object templates (AOTs). Application templates are also known as application fulfillment templates because you create them from the underlying applications that fulfill their tasks. For example, you can create:
An AOT defines a process step within a PDT. In an AOT, you can specify an application template to pre-populate fields in the fulfillment record when a request is created. |
|
| Define fulfillment processes (PDTs) | Define fulfillment processes by creating process definition templates (PDTs). A PDT defines one or more processes, and must contain at least one AOT. Each AOT defines a process step. Consolidate multiple processes into a single SRD to facilitate fulfilling and tracking the request. For example, when you create a request for onboarding new employees, you can build processes to trigger fulfillment of services by multiple groups within your organization, such as IT, human resources, facilities, security, finance, and training. You can define multiple steps for a process. For example, when you create a facilities request offering for changing employee cubicles, you can define questions to gather information such as:
You then map this information to the process that creates a change management record for fulfillment. To fulfill the request, you can define processes for:
Each process can be further broken down into smaller steps. For example, the process of ordering a new desk might involve:
| Creating process definition templates |
| Create requestable services (SRDs) | Use the Service Catalog Manager console to define requestable services (service request definitions, or SRDs). An SRD might include questions that users must answer when they request that service. Data collected in the request can be used to help drive the fulfillment process. You can also create SRDs that enable the users to order hardware and software products. These specific SRDs use the Product Ordering form, whereas SRDs for other types of service requests use a separate form called the Provide Information form. | Creating service request definitions |
| Complete any optional configurations | Perform a set of optional configurations that suit your business goal. | See the following table for Optional tasks. |
| Configure surveys | After the service request is marked Completed, Service Request Management notifies the requestor through email and send a request for a survey. Each request generates a separate survey. To generate surveys, the surveys must be configured for your company and the survey option must be selected. If you reopen a completed service request that already has a survey filled out, at the completion of the service request, the system sends out another survey notification for this reopened service request with the link pointing to the already filled-out survey response. Update the same survey for this reopened service request. | Setting up surveys and viewing results |
Optional tasks
You can complete any of the following optional tasks:
| Optional task | Description | For more information |
|---|---|---|
| Configure approval processes | You can choose to require approvals for new and updated SRDs. You can also optionally require approvals for service requests based on various factors, such as the cost. Service Request Management includes default approval processes that you can choose, such as Manager approval for a service request. You can also define your own custom approval processes. You map the approval processes to individuals and groups for an organization. | Configuring approvals for SRDs and service requests |
| Configure automatic assignment | You can automatically route requests and work orders to the appropriate support group, for example, based on the requester's location. | Configuring work order assignments |
| Configure entitlement to SRDs | You can determine access to SRDs by using rules that match user characteristics, such as location, with SRD characteristics, such as category. | |
| Configure on-behalf-of (OBO) definition rules | Use OBO rules to define who is authorized to submit requests on behalf of other users. | Creating on-behalf-of definition rules |
| Configure service targets for SRDs | If BMC Service Level Management is installed, you can set service goals and monitor your service requests to make sure you are meeting those goals. | Defining service targets for an SRD |
| Configure surveys | Set up surveys for your end users to help evaluate the effectiveness of services. | Setting up surveys for SRDs |
| Configure the Request Entry console | Configure the overall appearance of the Request Entry console. | Configuring the Request Entry console to display the service catalog and provide self-service |
| Localize services | To localize services, you must localize all components, such as AOTs, PDTs, and SRDs, separately. | Localizing the application |
Creating a service catalog results
After an SRD is approved and deployed, the users use the Request Entry console to view and submit requests for the services specified in the SRD.
Watch the following video to see how to order products using the product ordering form:
When the fulfillment provider successfully finishes the request fulfillment process, the request automatically reaches the Completed status. If the request has been completed (or rejected) but the service is incomplete, you can reopen it from the Request Entry console. For more information about reopening a request, see the following points:
- You can reopen a request from a survey.
- You cannot reopen a request after it reaches the Closed status.
- Requests that are in Completed state are automatically closed after 15 days. This happens when an associated incident is closed and incident rules are configured to automatically close resolved incidents. But, if you reopen the request within those 15 days, the incident doesn't reopen. Instead, the original request is reopened in the fulfillment application, or a work order is created.
- If you are reopening a request that was rejected during an approval process, the request status changes to Draft. If you are reopening a completed request, or a request that was rejected by a fulfillment application worker, the request status changes to Initiated or In Progress, depending on the status of the fulfillment request.
- If you reopen a completed service request, the system sends out another survey notification when the re-opened service request is completed. This survey notification points to the same survey and allows you to make updates to the previously submitted survey response. For more information, see Submitting a request survey.
Comments
Log in or register to comment.