The Service Portfolio table holds all of the individual service offerings related to a business service - the individual records in this table are called Services.
It is the main source for the detailed ITIL Service Catalog. It holds a record for each service that may be offered to end users or technicians through the service catalog. All services offered by the organization to end users should be managed here and this table's workflow is used to manage the on-boarding process for a new service. Each service is offered through a different request type, such as a Service Request, Incident, or Change Request. Each service is therefore associated with one of these three tables, and this association is defined in the Services field "Request type."
There are several ways the system can be configured to enable users to create a request for a particular service. Whichever method is used, users will only see the Active or In Review business services and service offerings for which their SLA customer group has an active SLA.
The system comes with Corporate SLAs that cover all users and that are linked to most of the default services, but each service may have specific SLAs available to only one set of users.
Whenever customers interact with the services or the service catalog, they only have access to the services defined as available to their SLA Customer Group. For technician users, their permissions allow them to view all services, including those that are not yet active. When submitting a request, technicians are still limited to selecting from services that are Active or In Review. Since the system filters the services a customer can view, there is no need to create a specialized catalog for each customer. Instead, customers in different SLA customer groups automatically see their appropriate services based on their own linked SLAs.
Our default End User Interface demonstrates the main three methods by which customers can access services and create requests and incidents.
The first method for presenting services is to use the Service Catalog view of Business services, which allows the user to view the service offerings within a business service and to click the Create Request button without knowing in advance whether the request will become an incident or a service request. In this method, the user clicks on the View My Service Catalog link to see the personal service catalog. This opens a view of the business services with a row for each authorized business service.
Now the user can click on a particular business service, for instance, Desktop Hardware, to view more about it and to see the individual service offerings. From the list of service offerings, the user can click on the linked service to view more information about the service offering, or they can click on the Create Request button to create a new request with the business service and service prepopulated.
A second method for presenting Business Services is to create links to create requests for the most popular services, or the services that are available to all users. This approach is represented by the Quick Links section on the interface.
Clicking one of the Quick Links open a new Service Request or Incident with the service and business service prepopulated. This simplifies services for users since it takes only one click to open the request. However, if your service catalog is large with many offerings, it is more difficult to set up and maintain.
Alternatively, users may create a new Service Request or Incident directly. To do this, click the relevant link for 'Create a Service Request' or 'Create an Incident,' then select the business service and service.
This works best if the users already know which kinds of requests are Service Requests and which are Incidents. If they do create a record in the incorrect table, staff can convert from one record type to the other.
You can make specialized catalogs available that find any subsets of services based on search criteria or fields in the Services table. The end user interface shows a second service catalog, Purchase Catalog, that displays all services that relate to a purchase.
If users click on this item, they see those specific services and can create a request directly.
Technical users who use the power user interface have additional options when creating requests. They can go directly to the appropriate table in the left pane to submit a request, or they may also use the Service Manager home page and click on a link to their own service catalog. In either case, they will see additional services that were not available to customer users, such as IT Infrastructure change, based on their own SLAs and group permissions.
Within each user record, a related table shows all the services that customer can access. In addition, reports can show which services were actually used by which customers. The report: All Services by Submitter on the Service Request table shows the services actually used by each customer.
It is possible to review the customers for whom a service is available in a few different ways. Services are linked to one or more SLA customer groups, and users are associated with those groups. So, the recommended way to view customers for a service is from the service record, and then through the linked SLA Customer Groups. Clicking on an SLA Customer group such as the Gold / Executive group shows the SLA Customer Group record. In the SLA Customer Group record, the Related Info tab shows all the users in that group.
Alternatively, you could add a field to the Service record that shows a table view of all users in the linked SLA customer groups.
We have created several sample services. Naturally, your organization will want to create its own services, delete many of our sample services, or change the associations we have made for those services. For instance, the on-boarding of new employees is currently managed through the Service Request table under the Service New Employee Setup. Some organizations may prefer to manage new employee setup through the Change Request table instead. Making this kind of change is a matter of modifying the service record and changing the field called Request Type to point to the desired table.
Since the Service Catalog is the backbone for many ITIL processes, the Services table has several special fields that are pulled into the corresponding request to enable automation, escalation, and special field visibility and dependencies based on the type of service.
The first screen displays key details about the service. The Description of the service and the Special Instructions are shown to users when they submit a service request or incident to provide them with more information about the service.
The Attached file fields such as the Supporting Service Business Case and Service Design Package can hold supporting documents about the service, while the Service Warranty field can be used to provide further information about the expected turnaround times. The Service Criticality field represents the value of the service to the business.
Additional fields define the default team to be assigned to the request and the escalation team, as well as whether the service is billable, and if so, based on what criteria. The Auto-Assign to Responsible Team determines whether the service responsible team takes priority over the CI Responsible Team, if a CI was selected for the request, when assigning a new request. If yes, then the service team is assigned, if No, then if there is a CI and it has a responsible team defined, that team will be assigned to the request.
The Level 2 Escalation Team is automatically assigned to a request or incident when the SLA is breached, and is notified both before – at the warning interval – and after the SLA breach.
Some services may be billable, and the system supports four different cost models by default: Fixed for the Service, Based on Items Purchased, Based on Task Costs, or Based on Time Spent.
Depending on the cost model, the cost information is entered in the service itself. For values of Fixed for the Service it is entered directly. For Based on Task Costs, the task templates will have values that are totaled. For Based on Time Spent, it is compiled by totaling the time spent on the request, while for Based on Items Purchased, it is the total cost for items purchased as part of the request.
When a service request or incident that is billable is completed, the Total Cost in that record is populated automatically by the system based on the entered data and the service's cost model. Reports for billable service requests and incidents can be used to export cost information to an accounting system. A Cost Center field in the request tables allows the submitter to select the appropriate cost center that should be billed for a given request. Cost center values are held in the Cost Centers table and can be modified by importing your own values there and deleting the default values.
The cost fields are only visible when setting up a service if the ITIL Functions table record for Service Costs has a Yes value in the Function Turned On field. If not, those fields will be hidden wherever they appear.
This tab holds information about the available SLAs and OLAs for this service. The links to the service are generally made from the SLA or OLA table when those records are created and their scope defined. A service may have multiple SLAs linked to it, and the SLAs are applied to a request in priority order, described more fully in the Service Level Management section.
Service level requirements are also held in the SLA table and that is where the SLR is negotiated and defined. For a service that is being planned, the SLR may be linked to that service to provide information on the requirements that are being negotiated. Once that SLR becomes an SLA, it would typically remain linked to the service as it goes live.
Note that the view of the SLA and Underpinning Agreement can show the percentage of breached agreements and/or the number of open and breached requests. The next section on the SLAs / OLAs / Priority tab shows the Priority group used for the service and the available priorities for that group.
The SLA and OLA sections on the form will be hidden if the ITIL Functions for SLA or Underpinning agreements are turned off. Specialized priority groups can be created to provide a particular service with its own impact, urgency and priority values as needed. See Impact, Urgency, and Priority Management for more details on how this is done.
Some services may have associated approval workflows or standard tasks or task workflows. These options are available from the additional tabs in the service record. Approvals and tasks are available out of the box for both Service Requests and Change Requests, while tasks are also available for incidents.
There are three options for how to handle approvals for a change request or service request, shown in the Approval Generation Method drop-down below: using a predefined approval workflow, manually created ad hoc approvals, or both. For a Predefined Workflow Only, the user will select from existing approval workflows related to change requests. If none yet exist, they can use the button to create a new approval workflow on the fly.
If the user selects Manually Created in Request Only then no further information is needed in the service record, and they will be able to add the approvals manually within the individual request.
The selections made in the Service will result in different options appearing within the Change Request.
In a request based on a predefined workflow only, the user will see the workflow listed and a button to generate the approval records. If the user has permission to edit the Approval Workflow Title field, they would also be able to change to a different workflow as needed. If both predefined and manual approval creation are permitted, the user will see an additional checkbox, Create Approvals, that can be expanded to add one or more ad-hoc approvals. If only the manual approval creation is defined, then the user will just see the option to Create Approvals and will add any approvals needed.
Note that if the Approval Required field in the service has a Yes value, at least one approval will need to be created and approved to move the request forward to completion.
The Tasks tab of the service allows the selection of a method for task generation. The available methods depend on the request type and they are different for service requests and incidents vs. change requests. Change Requests have two options for the task generation method: Predefined Task Workflow and CR Single Task from Template.
Change requests are typically associated with one or more configuration items. Task handling for change requests is therefore designed to create a task for each configuration item that has been associated with the request. If the user chooses 100 configuration items for a change request and generates tasks, whichever tasks are defined for the change request are created 100 times, one for each configuration item. The tasks are generated in this way by using a task template and pushing its details down through the configuration item records, so this necessitates restricting some of the other task generation options.
Predefined Task Workflow - allows the selection and/or creation of a Task Workflow with predefined task templates arranged in a sequential or parallel order. See more details about configuring task workflows in the Task Workflows Table section.
Note that if your workflow has 3 tasks, they will each be generated for each configuration item.
The CR Single Task from Template option is more common for change requests involving numerous configuration items. Here you define a single task template to be used with the change request.
Note that a single task may have several predefined steps, presented as a checklist, to assist technicians in performing the task. See the sections on Task Templates Table and Task Steps Table for more details on how to set this up.
Using task steps within a single task makes good sense for a change request. While setting up the service, if the task template you want to use does not yet exist, use the Create and Apply New Task Template button to open the task template screen to define a new template. After saving the template, select it for the service where you started.
In the Change Request, it is possible when using this task method to select more than this one task template to generate. After the default task is generated, the user can select from other predefined tasks and generate them as well.
For service requests and incidents, there are some different task generation options. There are three possible methods:
The user checks the boxes for the tasks he wants, and clicks the Generate Task(s) button to generate the individual tasks. These tasks, since they are all optional, are defined as parallel tasks without specific prerequisites.
User Generated Ad Hoc Tasks – this selection allows the user to manually create tasks in the service request without reference to any preexisting templates. In this case, the user will see a button in the service request to create a new task. Ad hoc tasks can be made sequential during creation by selecting one or more prerequisite tasks as the individual tasks are created.
The performance tab on the layout is used to hold information about the number of open incidents or service requests for a service and the percentage of those that have breached their SLA.
Depending the request type, it shows different fields: a related table of open incidents, or a related table of open service requests, and the relevant statistical fields.
These values can be shown in reports on the service table as well as on the Incident or Service Request tables.
This is where the workflow for on-boarding a new service is done. There are fields to track communications, updates, knowledge and other materials that may be relevant, and automation to make it easy to email people responsible with information or questions about the service.
In addition to the notes and links to files and knowledge, the Status field is used to manage the onboarding process and to define the subsets of the Service Portfolio. It has default values of Planed, Pending Approval, Approved, In Development, Active, In Review, Retired, or Canceled.
On the date of the Next Review Date the Status is automatically changed to In Review and the Service owners are notified by email. This is to cause every service to be re-evaluated on a regular basis.
Note: While the status is In Review, the service is still available to users. |
Once the Service Catalog is initially set up by creating the appropriate services in the Service table, new service items will typically be created by power users only when a new service is planned or initiated. Initial permissions are set so only users in the admin, Service Manager, and Change Manager groups can create, modify, and delete services.
Services are owned by the person who creates the service.
A few of the default saved searches are listed below.
Saved Search Name | Search Description |
---|---|
Service Pipeline | Status is Planned, Pending Approval, Approved, or In Development |
Service Catalog | Status is Active or In Review |
Retired Services | Status is Retired |
Planned Services | Status is Planned |
A few of the available reports are listed below.
Report Name | Description |
---|---|
Service Catalog | This report shows a chart and list of all active and in review services, the services that are available to customers for requests: |
Service Pipeline | This report shows all services in the pipeline. |
Retired Services Report | This report shows all services whose status is Retired. |