10 Important Decisions For Your ITSM Implementation

Body

Table of Contents

Service Catalog

What will you include in your service catalog for go-live?

The service catalog is a foundational, keystone component of your TeamDynamix implementation. Often, customers struggle to define an appropriate scope for their service catalog - especially if the idea of a service catalog is new to the organization. How many services and offerings should we have? How broad or detailed should we be with our services? It can be very challenging for your organization to develop to a satisfying answer.

Some guidelines that may help:

  • 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!
  • Avoid building out your service catalog in a silo. Collaborate with other teams! It'll be much easier to have each team in your organization think about the services they offer or work with frequently, than it would for one person to try to define all possible services in all possible areas all on their own.
  • In order to avoid getting overwhelmed while trying to identify and define all the different services and service offerings your organization might provide, focus heavily on the few specific services that you already know are valuable and popular. These are the requests that will provide the most immediate return on your effort and the ones that are most likely to be needed for go-live! Take anything that's not identified as important for your go-live and make a plan to address it over time afterwards.
  • Talk to your tier 1/first line of support staff - they'll have unique insight on what your most common tickets are day-to-day. If possible, pull data from your existing ticketing system to help identify the most common types of requests and tickets, and use that to start brainstorming what your most popular services/offerings are. From that list, you can begin prioritizing based on popularity, impact/value to your organization, and strategic priority.
  • Develop your service catalog with a holistic, customer-centric viewpoint. Ideally you want your service catalog as a whole to strike a balance between overly detailed and granular, and too broad and generic. There may be some areas or categories that need more granular detail and some where you can simplify. Review your list of services with a critical eye and with a customer's perspective in mind, and gauge if you are being too detailed or too high-level for your audience. If you're unsure, try keeping it simple for now and but with a plan to collect and review feedback on if additional detail is needed later.

Resources:

 

How will you organize and structure your service catalog?

In addition to thinking about the scope and what's going to be included in your service catalog, also spend time thinking about the appropriate way to organize and structure your services in order to make it work effectively for all stakeholders: clients browsing for a service to request; technicians organizing those service requests and processing them; leadership reviewing metrics and reporting off the services.

Be flexible with your structure - utilize category and service shortcuts to help your users find content where they might expect it to be. Think about your user flow and how you might utilize different navigation paths. For example: Direct links for targeting communication; Client portal search for immediate access to specific services/needs; Shortcuts and categories for discovery and browsing.

If you have the time and capability, usability analysis and focus testing with your users can help validate your assumptions or provide new perspectives on how your users may interact with your structure. Are there areas that are confusing or poorly worded? Are your common services hard to find or take many clicks to navigate to?

Resources:

 

What information do you need to capture with your service forms?

Your service catalog will have the most value and return on effort when it helps to streamline the fulfillment of common requests. A good service catalog should collect all the data you need upfront and route these requests directly to the teams, tools, or systems that can best fulfill them.

If you have the data, review examples of similar requests in your old ticketing system and look for the kinds of questions, follow-up information, or details that are used to help fulfill the request. Incorporate those insights into your forms and make it easier to collect that information up front.

Take a look at how those requests are processed or fulfilled. Are there fields you can add to the request form to help create dashboards or reports that could be used by technicians to better fulfill those requests?

Think about the customer experience when filling out the form. Is it intimidatingly long? If they make a mistake, do they have to backtrack and re-fill a lot of the form? Ideally, you want your forms to capture just enough detail to fulfill the request efficiently but not burden your customer with many fields, choices, or complex dependencies that they have to navigate just to submit a request.

Resources:

People Import, Integrations, and Technical Setup

Have you decided on a vanity URL?

If you have purchased a custom domain (also known as a "vanity URL"), have you decided on what that domain will be? Your domain is used in many other areas of configuration and implementation, so you will need to have your custom domain configured prior to setting up SSO, People Import, and other integrations. The longer you wait to configure your custom domain, the more painful the cutover process will be.

If your desired custom domain is already in use and cannot be used until go-live (e.g. it's currently in use by your old ticketing system), you will need to plan appropriately for the cutover process ahead of time to ensure a smooth cutover process.

Examples of changes you may need to perform when configuring a custom domain:

  • Client IdP SSO configs (client has to reconfigure IdP SSO settings to reference vanity URL domain)
  • Briefcase integrations (client now has to set up their own integration projects and pass info to TDX)
  • Client saved bookmarks and old URLs in emails/websites/TDX KB articles/services/portal pages need to be updated
  • Anything calling the API will need to be adjusted or their API calls will fail. That includes:
    • People Import Utility
    • Asset Import Utility
    • Group Management Utility
    • Web service steps in ticket workflows
    • Any external scripts which call the API
  • iPaaS TDX Connectors must be updated to use new API endpoints
Some of the Vanity URL benefits are highlighted below:
 
  • Allows for branding of the TDX offering,
  • Provides a trustworthy organization domain URL,
  • Provides a URL that is easy for users to remember and is tied to your domain,
  • Suggestions on URL design in particular if you plan to roll out to other departments for Enterprise Service Management:
    • Shy away from IT centric terms to better support enterprise service management, 
    • Keep it generic to apply to any department (ex. services.yourdomain.com),
    • Keep it short and simple to remember,

Where will your people data come from? Who is included?

Who should be included in your people import? Typically, most clients will import their employees and staff. If you're an educational institution, you'll likely want to import faculty and students as well. Will you want to include prospective students, alumni, etc? Do these people need to have a full user record and be able to log in, track their request history, etc. or do you only need simple contact info for service request management purposes?

Once you've defined who should be included in your people data, determine what system or systems that data will come from. How will you be extracting that data from those systems? Do you need to combine it with data from other systems in order to fully populate what's needed for import into TeamDynamix? What does your data flow look like?

Resources:

Ticketing and Service Management

Will you need more than one ticketing app/asset app/client portal?

Do you have multiple different colleges, campuses or branded sub-divisions with distinct customer populations in your organization? If so, you may want to consider having multiple client portal applications to help provide consistent and familiar branding for your distinct groups of customers.

With multiple client portals, you can have uniquely branded landing pages for that entity, including logos, colors, introductory info, etc. Additionally, portal access is handled through user permissions, so you need to rely less on group permissions to manage visibility and show/hide items. However, adding multiple client portals does create more complexity for your customers - there are multiple places for your customers to find knowledge articles, services, and general information. Consider carefully what expectations your customers have around branding, access, and UX when requesting services or looking for information.

Will you have multiple departments using TeamDynamix to manage and fulfill requests? For example: HR, Facilities, Admissions. If so, you will likely want to consider having multiple ticketing applications to help intake those requests and keep them separate and scoped to the appropriate department: Tickets are only visible to admins and users who explicitly are given access to the ticketing app, and some branding (e.g. notification templates, email integrations) can be customized for each organization's branding.

Similarly, do you have multiple departments who need to track and manage assets? For example: IT, Facilities, Athletics, Manufacturing. If so, you will likely want to consider having multiple separate asset applications to help provide appropriate access and management of those items.

Resources:

 

Where will your asset data come from?

Asset Management is often a challenging component for many clients. Not necessarily due to configuration, but because existing asset management processes in an organization can be scattered and disorganized. Information needed for effective asset management may be incomplete or spread across the organization; data may live in spreadsheets owned by different teams or individuals, in standalone databases, ITSM or ITAM apps, endpoint management apps like SCCM, Intune, or JAMF. Or it may not exist at all!

Think about your asset management processes holistically as you consider how data may flow through your organization:

  • What teams, systems, or apps need to work with this data?
  • Do you need to combine data from multiple sources? Does this data need to be cleaned up?
  • If you're bringing asset data into TeamDynamix, where are you getting it from?
  • Do you need to push data back out from TeamDynamix to other systems?
  • Do you need to do a walk-through audit of your physical locations to verify your inventory?
  • Consider your data needs carefully - is this information actually useful? Or is it just going to be low value data that will require additional work to maintain it for little benefit to the organization?

Resources:

Implementation Scope and Go-Live Planning

How much can you realistically accomplish for your phase 1 go-live?

At the start and also ongoing throughout your implementation, be sure that you are appropriately planning and adjusting your scope according to your capability and deadlines. Is what you are planning actually realistic to accomplish for your target deadlines? Have you included slack time to account for unforeseen issues and delays? Or are you being overly optimistic with how quickly you can make decisions or configuration?

Review your planned scope alongside realistic demands on your resources from other projects/areas of your organization, and ensure you are appropriately planning for "unknown unknowns" that you may need to address - other projects, shifting priorities, emergencies, PTO/OOO/Holidays, etc.

You may want to do a work-back exercise: Starting from your target go-live deadline, work backwards to block out how much time is needed for: training, QA/UAT, organizational change management, communication, configuration, etc. Your implementation consultant can help guide you on typical timelines for different areas of configuration and provide reasonable first-guess estimates.

 

What critical processes need to be represented in TDX?

You may also want to review your processes and decide which ones are "must-haves" to build out in your TeamDynamix system prior to go-live, and which ones are "should-haves" that can wait until after your go-live. How well defined are those critical processes? Do you need to spend additional time or discussion to develop your process more thoroughly? Be sure to incorporate any additional time needed for process development into your planned scope above.

Examples of common critical processes for service management:

  • Change management
  • Employee onboarding/off-boarding
  • Access control
  • Procurement
  • Major incident management

Resources:

 

How do you want to deploy TDX to your stakeholders?

In addition to planning out your availability, resources, and timing for configuration, it's important to start planning your overall deployment strategy early. Your go-live is not only technical changes like a new system, new interface, and potentially new processes... but also an organizational and political change: the way people work, request help, access resources, and interface with your services will all be different. Change is scary! Planning out your deployment process early will help make those changes be accepted and integrated into your organization and give you opportunities to respond empathetically to negative reactions throughout the process.

Review your communications plans and work with resources in your organization to identify the best ways to manage communications about your implementation early and often. You may want to ask your HR department, PMO, or other similar departments to get tailored advice about what strategic key points should be considered when developing a communications plan for your specific organization's needs.

Think about what other outreach or deployment activities you may want to add into your deployment plan. Do you want to do user demos? A go-live party for the implementation team? Town hall discussions with stakeholders? Internal advertising and messaging on signage? Training or peer support forums? Email status updates to leadership? Think about the different stakeholder groups you want to engage, and the best way to manage the narrative about the implementation that you provide to those stakeholder groups.

 

Details

Details

Article ID: 157356
Created
Fri 2/23/24 12:49 AM
Modified
Thu 11/7/24 9:20 PM