Is my current service structure aligned properly to the CSDM?

[ahbrook]

Hey everyone! After the post a couple weeks back about business applications and service instances, I have been trying to dig deeper into the conversations here and make sure I'm not misunderstanding anything else. That said, I am also trying to come up with practical solutions to issues we're facing. 

The big one I've been grappling with right now has been representing our endpoint support and asset management processes. 

Here's my context:

I work for a state University. We have around 40 distinct "Tech teams" between administrative support, student support, and the various colleges out there. Each college's IT staff is responsible for configuring, deploying, and maintaining their endpoints (desktops and laptops). Central It then handles things like shared learning spaces (classrooms), computer labs, AV equipment, and so on. 

Our biggest hurdle is figuring out routing for calls about computer issues. We have a central support desk, but at some point an incident or service request needs to be routed to the local endpoint team. This means we need to have ServiceNow figure out that routing, somehow.

We currently only have ServiceNow ITSM. It is a long shot to get the University to consider any form of ITAM, ITOM, or Enterprise Architecture. This means we are currently relying on SCCM to bring endpoints into the system as assets and CIs. We do not have access to Service Mapping or Discovery. 

I want to align our processes with the CSDM as much as possible, both to leverage whatever automation the base ITSM product has, and so that if we do acquire the more advanced models, that our data is compatible with it.

So here's my scenario/questions: 

1. I have a portfolio category/node of "End-User computing services." I currently have all of the services and service offerings under it penciled in as business services/ business service offerings. Would you consider this correct?

• Endpoint Hardware Lifecycle Support (Business Service)
  • Endpoint Hardware Decommissioning (Service Offering)
  • Endpoint Hardware Delivery (S.O.)
  • Endpoint Hardware Leasing (S.O.)
  • Endpoint Hardware Procurement (S.O.)
  • Endpoint Hardware Refresh (S.O.)
• Endpoint Software and Application Support (B.S.)
  • General Software and Application Support (S.O.)
• Endpoint Support (B.S.)
  • Android Device Support (S.O.)
  • Apple Desktop Support (S.O.)
  • Apple Laptop Support (S.O.)
  • Apple Mobile Device Support (S.O.)
  • Other End User Device Support (S.O.)
  • Windows Desktop Support (S.O.)
  • Windows Laptop Support (S.O.)

(Note: These divisions of endpoints were requested by our tech team management because they want to track tickets by hardware type.)

I keep going back and forth on if these should be Technology Management Services, because I do not believe they provide actual business value, but they are critical to maintaining our environment.. and we do things like offer loaner laptops to students and the like. There's also some distinction between receiving and deploying an endpoint and supporting/maintaining it in some areas of campus.

2. I want to use dynamic CI groups to apply asset/CI ownership and management values. Am I correct that this will require a unique service instance for each tech team? I am leaning this way, because the nearest analogue I can find to our scenario is that each college's tech team acts the same as local support for a regional office, complete with location data (on the scale of buildings, not cities/regions). However, this very much might be me approaching things wrong, and what I really need is a separate technology management service offering for each team's delivery of endpoint support. 

I'm trying to use the "CSDM Data Model Examples" powerpoint as a guide, but the slides that talk about desktop services ( 59 and 60) both just reference "services" and "Service offerings" without calling them business or technology management services.

I know the advice is to keep things as simple as possible and focus on the crawl/walk stage at this point. But I am struggling to reduce complexity while still properly accounting for how we support thousands of employees and tens of thousands of students. 

As always, thank you all for any help, advice, or pointers you can give. I really want to leverage the CSDM at this early stage so that we don't have to do a ton of rework in the future if we do expand our ServiceNow footprint. 

[meghanakra]

I tried to understand your design and I hope I make sense . As per me your main goal is not to create a separate service for every support team. Your main goal is to make sure tickets go to the correct team automatically.

For Question 1:

I would recommend modeling these as Technology Management Services, not Business Services.

Why?

Because services like:

• Endpoint Support
• Device Refresh
• Device Procurement
• Software Support

are mainly internal IT operational services. They help IT manage and support devices, but they are not directly business-facing services like Email, LMS, or Student Portal.

So something like this would make more sense:

Technology Management Service:

• Endpoint Support

Service Offerings:

• Windows Endpoint Support
• macOS Endpoint Support
• Mobile Device Support

And:

Technology Management Service:

• Endpoint Lifecycle Management

Service Offerings:

• Procurement
• Deployment
• Refresh
• Decommissioning

I would also avoid creating separate services for every hardware type or every college/team unless there is a real SLA or process difference.

For Question 2:

No, I would not create a separate service instance for each tech team.

Instead:

• Keep the services simple and shared
• Use CI ownership, support groups, locations, and dynamic CI groups for routing

Example:

The service can simply be:

• Windows Endpoint Support

But the CI itself can contain:

• Support Group = Engineering IT
• Location = Engineering Building

Then ServiceNow can automatically assign the ticket to the correct team based on the CI data.

This keeps the model clean, scalable, and aligned with CSDM without creating hundreds of duplicate services.

I think your direction is good overall. You are already thinking the right way by focusing on:

• clean CSDM alignment
• future scalability
• minimizing future rework

For a university environment with distributed IT teams, keeping services centralized and handling complexity through support groups and CI ownership is usually the better long-term approach.