How do I use Service, Service Offering, Product, Service Action, and Purdue IT Service fields in TeamDynamix?

Overview

This article is intended to assist technicians using the Purdue IT Tickets app in TeamDynamix understand the purpose and use of the Service, Service Offering, Product, Service Action, and Purdue IT Service fields. We've aligned our use of terminology with ITIL to the best of our ability, adjusting for the design of TeamDynamix.

Instructions

Definitions

• Service Offering: A service offering is a description of one or more services designed to meet the needs of a specific consumer group.
  • This is not how TeamDynamix uses the term. Within TeamDynamix "Service Offering" can be thought of as a form that is related to a service. In our service catalog each "Purdue IT Request" button points to a specific service request form customized for the service currently open.
  • For FootPrints users, Service Offering was the term selected to refer to what ITIL calls "Product" now. Service Offering was not clearly defined in ITIL at the time the term was used in FootPrints.
• Service: A service is a means by which a service provider (Purdue IT) can deliver value to customers by deliver the outcomes they desire while taking on the management of risks and costs of service delivery.
  • These are defined at a high level like "Learning Management".
  • While Purdue IT does not truly deliver a full Learning Management service, because there are several critical components we do not do, like course design, Purdue IT does contribute to the overall "Learning Management" service found at Purdue that is actually delivered by several entities.
• Product: A product is a configuration of resources that may not be fully visible to the customer.
  • Resources are things like people (technical or support staff), information (data collected, maintained, or reported on), technology (infrastructure, applications, hardware tools, etc), values streams (identifying and filling gaps in service) and processes (resolving service requests, reviewing and approving changes, etc).
  • Within the Learning Management service, one product would be Brightspace. The Brightspace product includes the staff in Purdue IT and TLT that support it, the Brightspace software itself, the infrastructure that runs it, KB articles used in self-service, the processes for integrating Brightspace into other tools and many other things that may not be visible to the customer.
  • Products are displayed in the service catalog as tags on the service they support.
• Service Action: A service action is an action performed by Purdue IT to address the needs of customers.
  • These are represented in the Purdue IT Tickets app as common requests that we can build a service model to collect better data from the requester to route and resolve the service requests or incidents faster.
  • Using our Learning Management scenario a service action could be "Add a teaching assisting to my class". In which the requester is presented with a form that collects the course number and section as well as the user id of the person who will be the teaching assistant.
• Purdue IT Service: This field is a work around for a functional limitation within TeamDynamix. In TeamDynamix, native fields cannot be part of a dependency relationship between two fields. Because we wanted to filter the list of products on a (service offering) form based on the service the user was in when they click the "Purdue IT Request" button, we had to build a dummy field for portal (service offering) forms to use. This dummy field simply contains the same value as the the service so that it could be related to the product field.

How they work together

1. When a user wanting to add a TA to their Brightspace course browses or searches our service catalog they may come across a "Learning Management" service.
2. After reviewing the service description a seeing that Brightspace is listed in the service description (as a tag or in the body), they will likely click the "Purdue IT Rquest" button.
3. This action will load the "Learning Management Request" service offering form.
4. By default the "Purdue IT Service" field in the "Office use only" section of the form is defaulted to "Learning Management".
5. That value helps to filter the options in the "Product" field to only those related to that service.
6. When they choose "Brightspace" from the "Product" list, they will be presented with any "Service Actions" (common requests) related to Brightspace.
7. If they don't see their need represented by a service actions, they can select the first option in the list which is always "General Request".
8. It might be that some service actions, when selected, cause the form to dynamically change to show different fields for the user to populate. These fields and the service action option itself will assist with routing and resolving the request faster than if the needed information was not provided.

NOTE:  To view the categorization structure of products within TDX review  Product List with Cat and Serv.xlsx.

Still need help?  Click the 'Purdue IT Request' button to start a ticket.