Business Services and Offerings - CSDM

[LF080291]

We are implementing ServiceNow and we are trying to map out all of our business services and services offerings - and one minute it makes sense and the next I find myself questioning if this is going in the right direction. 

Example One

Refraining from using the software/application name within the offering

Business Service = Documentation and Content Services

Business Service Offerings = Document Editing, Document Reader, Document Storage

And then the below CI's would be selected:

Adobe Acrobat DC

Adobe Acrobat Reader

DocuSign

Nitro PDF Pro

SharePoint

Business Service = Manufacturing Management

Business Service Offerings = Performance Monitoring, Label Printing...

And then the actual software again would be linked via CI selections. 

Or...

Example Two

Using the software/application name within the offering

Business Service = Documentation and Content Services

Business Service Offerings = Adobe Acrobat DC, Adobe Acrobat Reader, DocuSign, Nitro PDF Pro, SharePoint

But then I assume the CI selection would be duplicating the offering?

Business Service = Communication Services

Business Service Offerings = Email, Conferencing, Direct Messaging

And then the CI's would be selected:

Outlook

Teams

Teams Meeting Rooms

Outlook Mobile

But then i guess Teams Meeting Rooms would not be a CI?

As you can probably tell i am starting to overthink every little detail and i need to be set back on the right track, any help, advice and guidance would be appreciated from those who have successfully implemented this. 

[Andreas Borell]

If you do what you have described above, and then use the foundation set of master data in CSDM and divide users into companies, departments and groups, it looks like you will be able to leverage the subscription part of offerings to drive catalog items and also item recorders in the self-service portal in meaningful ways, so on paper it looks ok to me. I would however sketch it out for a single site and dry-run it first, involving you (assumed) implementation partner.

[RussLaPlante]

I've been wrestling with this for quite a while too.

As I understand more clearly the value of the App Service, Offering and Service, by looking though examples on NowCreate, it makes more sense. It would be SO GREAT is the training on this were more succinct and to the point.

In the case you describe, I recommend looking at the reference in the Service Catalog to the offering.

1. If you just offer "email" in your catalog, then I think your offering is "email"

2. If you offer multiple email options in your catalog, such as "Outlook Email" and "Google Email", then have offerings in this case that match the catalog item names, since you differentiate them that way.

Even if we just provide a service to the business, such as Outlook email, by default, without needing a catalog item to order it, it helps me to think of it as catalog item -> service offering.

- Russ

[AniemDariel]

I recently faced a similar challenge with a project where we had to organize our internal tools and services in a way that made sense to everyone. We decided to be more specific with the offerings, like you’ve done in Example One, and it helped keep things from getting too broad. Regarding your second example, I found that naming the software/apps within the offerings can sometimes lead to confusion, especially when those tools overlap with other services. I’ve also been diving into business software reviews lately (business software head-to-head comparisons can be so eye-opening) to see how others structure these things. We ended up creating separate categories for software and services to avoid redundancy.

[Mathew Hillyard]

The point about being brand agnostic in service/service offering names is that if you change vendors then your service name is now meaningless. However as others have said that works fine for the Service level, but where you have multiple offerings (especially with vendor and product names everyone is familiar with), and the principle reason for splitting them into separate offerings is that they each could have different support models, SLAs, geographies, vendors or products offered, then it is perfectly OK to include a product in a Service Offering name.

In your example above, what does "Collaboration Tools" mean to the business, end users, or the service desk? Service Offerings should have names that people can understand and identify with. Imagine a scenario on the service desk (or portal). I have a problem with Google Workspace. How do I log an Incident and how will the agent that picks it up know it's Google Workspace if we choose the Service Offering "Collaboration Tools"? It might be fine for your organisation but I would recommend trialling this with a small area of the business first - I've seen this in the real world and it wasn't pretty 😉

Hope this helps,

Mat

[snowdev8]

Hi Matthew,

Let's say I have a bunch of applications,  around 150. And I want a Catalog Item for each of these, which follows a standard process  - manager approval and then Catalog Task. What would the best way to design it so that the on the common Flow, I could simply assign it to the Support Group of the Application for which access is being requested. I am also beginning to get confused by the concept of App Models and Software models approach.  It all makes sense, just that I keep going back and forth