Parent/Child Service Offerings?

[CMDB Whisperer]

I understand that the parent field on Service Offering should be filled in with the Technical or Business Service according to CSDM, and that Business Services themselves should not reference other Business Services as a parent.  However, there may be a case to be made for Service Offerings having child Offerings.  The use case is for an IT department which is globally distributed, which has a global owner for a given primary offering, but has regional owners for the regional offerings.  Each offering can be owned separately, can have different relationships to different app services or dynamic CI groups for each region, and different Subscriptions and Catalog relationships specific to the region, but ultimately all roll up to a single Service Offering.  Should this model be used for that scenario, and if not how would you define this?  I could see just defining adjacent Service Offerings at the same level and having the Technical Service be the point of rollup, but that presumes a level of granularity that might be more specific than you really want to define at that level.

[Community Alums]

in my opinion, A Taxonomy Node as IT-Global can be set up and then multiple TS under that defined based on location/region with each having their respective Service Offering. This will allow to have separate SLA commitments against each offering and allow the leadership to have a view on how each TS is performing on portfolio level. Please let me know if you have any reservations with this approach. Thanks - 

[CMDB Whisperer]

That is an interesting idea.  However, I wonder if the question posed with the assumption that we are using TBM to define our taxonomy nodes would give a different answer.  If the taxonomy nodes are pre-determined by TBM, I don't think this would work.

[Barry Kant]

Good day Paul,

as the Service Offering level links indeed to:

• Catalog Items
• Subscriptions
• Support/Approval Groups (regional support?/global support?)
• SLM

then it does make sense to make a break down on this level. The same applies on the business side, and even on the Business Application side if strategic wise there are multiple parties there can be multiple Business Applications records of the same application.

In my opinion it is mapping a pre-determind TBM model and make it fit for purpose. (in the end it should work, otherwise it isn't a good solution right)

Cheers,

Barry

[CMDB Whisperer]

@Barry Kant - I posted a related comment here: https://www.servicenow.com/community/in-other-news/services-and-offerings-what-s-the-difference/bc-p... and I'm wondering if you have any thoughts on this.  

Quoting the comment from that thread below but feel free to respond in whichever thread makes the most sense:

I have a good conceptual understanding that there are various potential criteria that one can use to define Service Offerings -- location-based, product-based, scope-based, etc.  But what I struggle with is how to approach the challenge of defining Offerings when there are multiple factors at play.  For example, let's say I am defining the following Technical Service:

Service Taxonomy (TBM based): Service Type = Infrastructure Services; Service Category = Network

Technical Service: Virtual Private Network

Now there may be several different offerings here that vary by several factors, which may or may not overlap:

* Desktop vs. Mobile

* Full client vs Thin Web Client

* Cisco vs. Juniper

* High availability vs. Standard

Let's say a region in the US where headquarters are located may provide all of the above to support their remote workforce in a variety of different ways and scenarios.  Each of these would be different offerings.  But another region, let's say a Sales office in the UK, may choose to define only a single Service Offering, Cisco which they manage locally.  

So having said all that, what would be the best method of defining the various flavors of VPN in appropriate Offerings?

Seems there are a lot of things that we could do but I am not sure which would be the most beneficial.

1. Define offerings in a flat structure and just overload each offering with all of the attributes that distinguish it from other offerings - use Location, Scope, Service Commitments, relation to the applicable Application Services, and the Name of the Offering itself (which could also be overloaded with some of this information, e.g. US HQ Cisco VPN).
2. Possibly consider using Parent/Child Services (CSDM advises against this) or Parent/Child Service Offerings (it isn't clear whether this is allowed)?
3. Other approaches I haven't considered?