Body
This getting started article will help Administrators to build a Service Catalog using the TDClient and TDAdmin interfaces. The user must have the Administrator privileges in both interfaces.
In this article:
A service is a means of delivering value to customers. If users want the benefits and value of utilities such as email, storage, and wireless networking, but don’t want to assume the burden of managing those items themselves, an IT department provides those things to them as a service.
The TeamDynamix service catalog is a list of services that customers can choose from and request. This is a key support structure for ticketing applications. For example, tickets can be related to services, and every form can have a client portal view for use in the service catalog. The service catalog is also key for project requests as project request forms can be built out via the service catalog.
Service catalog entries can initiate a new ticket within any ticketing application, begin a new project request, or be a link to another website.
Each service and service offering includes a detail page for you to document and publish various pieces of information about the service. As you begin implementing your service catalog, you need to consider the various services provided by your department, organization, or institution. You can categorize and directly link to services for your users to easily find the services they wish to request.
If you are new to service catalogs, we highly recommend reading the EDUCAUSE Center for Analysis and Research (ECAR) article on Higher Education IT Service Catalogs.
Transcript
The Service Catalog Module will discuss how to use both the TDAdmin and TDClient interfaces to create and organize your services to be requested by users. You will discuss how to use categories, services, and service offerings on your portal to set up a structure that is easy for your users to navigate. You will also learn how to use visibility permissions to show and hide services for different user bases.
This feature appears in the TDClient and TDAdmin interfaces.
TDAdmin is where Administrators can go to manage services, categories, and forms; and TDClient is where both Administrators and service owners/managers can go to manage services, categories, and forms.
Navigate to your service catalog and settings following these paths:
- TDAdmin
- Applications > [Ticketing Application] > Request Forms
- Applications > [Client Portal Applications] > Service Catalog > Services or Categories
- Portfolio Planning > Request Forms
An Introduction to Service Catalogs [Video 35 min]
Define your services before you define your service categories. It's easier to define what a container should be called after you have items to put in the container and can see what you need.
Services can be defined outside of TeamDynamix before configuring them. You could do your planning in Excel by using the attached Defining Services Template.
Collaborate with other teams. It is easier to ask each team lead in your organization to think about their services than for one person to try to define all of them.
Talk to your tier 1/first line of support staff, as they will interact with the ticket more day-to-day than those in managerial roles.
Follow the ITIL Guiding Principle – Start where you are. If your organization has an existing catalog, take what works from it and leave what doesn't. There is no requirement to start from scratch.
If you are having trouble getting started, check out professionalservices.teamdynamix.com. Here you can find sample services that you can use for your own environment.
TeamDynamix Services can be created from the TDAdmin site or directly from TDClient, assuming the proper user permissions. To learn about creating a service, see Creating a Service for Requests.
After establishing your services, you can move on to creating service categories.
Note: Forms built via TDClient are considered service-specific forms and can be edited later via TDClient. Forms built via TDAdmin are considered shared forms and can be used for many services, but they cannot be edited later via TDClient.
Note: when using multiple Service Catalogs with multiple Client Portal in TDNext forms all Services in all Service Catalogs will display in that service lookup. To help support staff find and select the correct service, append the service name with the service catalog name such as "[Name of Catalog] - [Name of Service]". For example: "TDX Academy - New Account Request."
Note: In some scenarios, you may need to create a Service Offering for your services that your organization provides. For more information on Service Offerings, please take a moment and read through Service Offerings for an overview of it and how to utilize it within TeamDynamix.
To create a service that serves as a link to another site of your choosing:
- In your Services application in Client Portal, click the New Service button.
- Select the Category this service will primarily reside in.
- Add the Name, Short Description, Long Description, add ordering, select the Manager for the service, choose the Assets/CIs application the service will reside in, and add a Maintenance Window if needed.
- Select Link in the Request Application field. A new field will appear which allows you to enter in the URL of the site to which you'd like to link this service.
- Choose the text to appear on the Request Service button in the service catalog.
- Add Tags for the service to make it easier to search for it.
- Click the Save button.
To create service that submits a project request:
- In your Services application in Client Portal, click the New Service button.
- Select the Category this service will primarily reside in.
- Add the Name, Short Description, Long Description, add ordering, select the Manager for the service, choose the Assets/CIs application the service will reside in, and add a Maintenance Window if needed.
- Select Projects in the Request Application field.
- Select the appropriate project type in the Request Type field.
- Choose the text to appear on the Request Service button in the service catalog.
- Add Tags for the service to make it easier to search for it.
- Click the Save button.
To create an informational service that does allow a user to submit a request:
- In your Services application in Client Portal, click the New Service button.
- Select the Category this service will primarily reside in.
- Add the Name, Short Description, Long Description, add ordering, select the Manager for the service, choose the Assets/CIs application the service will reside in, and add a Maintenance Window if needed.
- Select None in the Request Application field.
- Add Tags for the service to make it easier to search for it.
- Click the Save button.
To edit the description of an existing service:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- In the Content tab, update or modify the name, long description, and short description of the service.
- Click Save.
To modify the settings of a service:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- In the Settings tab, update or modify the category, manager/owner, request application and type, and the request service button text.
- Click Save.
To modify the form used by a service:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- In the Form tab, update or modify the form (if it is a service-specific form) and the public requestor settings.
- Click Save.
To modify the visibility permissions of a service:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- In the Permissions tab, update or modify the visibility permissions of the service.
- Click Save.
To add relationships to individual assets/CIs:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- Select the Relationships tab
- Click Add
- Choose a Relationship Type
- Choose one or more items to associate with the selected relationship type
- Click Save.
To add or manage related knowledge base articles:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- In the Related Articles tab, select related articles to add to the service.
- Click Add.
To add file attachments to a service:
- In TDClient, navigate to Services > [service category] > [service to modify]
- Click Edit Service
- In the Files tab, click +Add to select files to attach to your service.
EDUCAUSE Center for Analysis and Research (ECAR)/TDX Mappings
If you are unsure how you want to organize your service catalog and ticket types, try starting with the structure outlined in the ECAR article on Service Catalogs and mapping the categories and terms to TeamDynamix components and terms. With the addition of Service Categories in 11.3, there are now a few options for this approach, depending upon your reporting needs.
Simple Structure Option
This is recommended for most organizations where service category reporting is not required in TDNext and for those who wish to keep their back end structure simple. It uses a single ticket type category for the department, which is great for ESM clients, and a single ticket type to keep structure easy to maintain. Additional ticket types can be introduced if a technical configuration need is needed (i.e. different default time types, different reviewers, etc.).
- ECAR Service Categories = TDX Service Category or subcategory (TDClient reporting)
- ECAR Services = TDX Service (both TDNext and TDClient reporting)
- ECAR Service Offering = TDX Service Offering (both TDNext and TDClient reporting)
- ECAR Service Attributes = TDX Service Descriptions and/or TDX Custom attributes on TDX Services (both TDNext and TDClient reporting)
- ECAR Service Offering Attributes = TDX Service Offering descriptions and/or TDX Custom attributes on TDX Service Offerings (both TDNext and TDClient reporting)
Moderate Structure Option
This approach provides excellent balance for organizations that wish to have service category reporting on the back end, support enterprise service management, and keep the structure easy to manage. Here, ticket type category is still used to reflect the department, but introduces using ticket types to reflect service category. This makes service category reporting easy while allowing for flexibility in the service catalog structure. Organizations can follow ECAR for service categories or they can modify it to suit their community's needs. Service reporting is performed with the Services set up in the Service Catalog.
- ECAR Service Categories = TDX Service Category or subcategory (TDClient reporting) = TDX Ticket Type (TDNext Reporting)
- ECAR Services = TDX Service (both TDNext and TDClient reporting)
- ECAR Service Offering = TDX Service Offering (both TDNext and TDClient reporting)
- ECAR Service Attributes = TDX Service Descriptions and/or TDX Custom attributes on TDX Services (both TDNext and TDClient reporting)
- ECAR Service Offering Attributes = TDX Service Offering descriptions and/or TDX Custom attributes on TDX Service Offerings (both TDNext and TDClient reporting)
Complex Structure (Full ECAR back end)
This approach is for organizations who wish to have a full structure on the ticketing application back end for reporting to ECAR standards. This creates the most flexibility for service catalog structure, but is the most complex to maintain. Service category is used for ticket type category and ticket types reflect services. For organizations with a lot of services, this will result in creating and managing many ticket types. However, the benefit is reporting structure is managed on the back end and can be structured in the way that helps an IT organization most.
- ECAR Service Categories = TDX Ticket Type Categories (TDNext reporting) = TDX Service Category or subcategory (TDClient reporting)
- ECAR Services = TDX Ticket Types (TDNext reporting) = TDX Service (both TDNext and TDClient reporting)
- ECAR Service Offering = TDX Service Offering (both TDNext and TDClient reporting)
- ECAR Service Attributes = TDX Service Descriptions and/or TDX Custom attributes on TDX Services (both TDNext and TDClient reporting)
- ECAR Service Offering Attributes = TDX Service Offering descriptions and/or TDX Custom attributes on TDX Service Offerings (both TDNext and TDClient reporting)
This is important because it allows flexibility in the creation of the TeamDynamix Service Catalog Taxonomy and enhances reporting. A good example of this is the classic Help service that many clients put at the root of the service catalog so that it’s front and center. By the book, ECAR would have this under an IT Professional Service or IT Service Management bucket (Category or Service). If you have these values as Type Category and Ticket Type, it allows you to report on it in its correct bucket without placing it in a TeamDynamix service category with a similar name.
Q. What is the definition of a service?
A. ITIL's definition of a service is "a means of providing value through facilitating outcomes for customers without the ownership of specific costs and risks." However, much like the Project Management Body of Knowledge’s (PMBOK) definition of a project, this definition is less helpful in practice. The term service can actually apply to several levels of a service: from the lines of service that a board or cabinet may want to see, to the services advertised to customers around campus, to specific service offerings that can be ordered. In TeamDynamix, the service catalog services best map service offerings.
Q. What is the best way to structure our service catalog?
A. Ideally, you can conduct usability analysis to test your service catalog structure with your end users. That said, consider also that your users may use search to find services. It is also possible to link people directly to services and/or service offerings. There is no one best organizational structure for the catalog.
Q. The service catalog seems overwhelming – where do I begin?
A. Ideally, begin with your most common requests. Your service catalog will have the most return when it helps to streamline the provisioning of common requests. A good service catalog should collect all the data you need upfront and route these requests directly to the teams or, in some cases, tools that can best provision them.
Q. Should I limit some services to logged-in users or to certain groups?
A. Service permissions can be controlled at the category or the service entry level. Permissions control whether people can see the service. If you require logins to see certain services, ensure that your users will know to log in to see those services. If you want to restrict services further, use TeamDynamix groups to restrict service. Please note that this adds additional overhead for you to populate and maintain group membership.
Q. Should I create catch-all services for requests that don't match anything else?
A. It is very common to create one or several catch-all services such as Need help? or Other enhancement request. The advantage of these catch-all requests is that users can put in requests rather than email or call your service desk. The disadvantage is that these requests cannot be routed directly to a group, and don't collect all the information needed. There's no one right answer but you can consider conducting a usability study on your service catalog to help design it so that these catch-all services are used as a last resort.
Q. Should I allow public requestors for services?
A. Ticket requests can have public requestors, which means that anyone in the world can request these services. If you turn on public requestors, carefully consider how to indicate to your support staff that these requests came in from the public – no one had to log in to order these services. One way to do this is by keeping requestor matching mode off.
Organizations without a service catalog often try to define every possible service, which will add time to the implementation.
The more complex the review and approval process, the riskier implementation of this module becomes. The more people involved, and the more levels of approval involved, the longer implementing this module will take.
TeamDynamix encourages our clients to use a minimum viable product (MVP) approach to their service catalog.
professionalservices.teamdynamix.com, the TeamDynamix sample service catalog based on great service catalogs we've seen.
Here are links to several TeamDynamix clients that have used the application to publish their service catalogs:
- Getting started with the client portal, for information on styling the client portal
- Treejack, usability testing tool for decision trees (such as your service catalog hierarchy)
- Higher Education IT Management list of Higher Education Service Catalogs.
- Defining Services Template attachment in the Attachments section of this article.
- Columns A, B, and D (Service, Owning Person/Team, and Short Description) will directly translate to fields used when creating services in TDX.
- Column C (Needed Information for Request to Be Completed) will translate to attributes that will need to be created when configuring forms.
- Columns E–I (What Is It? Who Is Eligible to Use It? Where Can I Get It? How Do I Use It? How Much Does It Cost?) are flexible (i.e., change them to best fit your organization, if necessary) and will help define a template for service descriptions (see the Article and Service Templates article).