Service offering as parent to another Service offering

[Amit6]

How it is possible to have Service offering as parent to another Service offering.

I could see this relationship exist in PDI instance in demo data. Could not create one.

Please check below. Any help is appreciated.

[CMDB Whisperer]

@Kristine Naess I agree with you that opening up the parent/child capability for Business/Technical Services is another worthwhile discussion, in addition to parent/child Offerings.  Having both of these available does make it much more flexible to build out a portfolio that has the appropriate level of granularity to meet the needs that are ultimately dictated by the size, structure, and maturity of the company.  Choosing a rigid structure that doesn't allow for this flexibility is an impediment to adoption and that just doesn't seem like a good business choice.

That said, like you I have considered possibly extending the Taxonomy itself to try and compensate for this.  My thought was rather than using just Service Types and Service Categories from TBM, one could extend the Service itself to be a Taxonomy Level, which would allow you to (as needed) break down those Services by function/component/etc., as you would normally do at the Offering level, and then further break each down into separate Offerings.  But that seems like a hack that would introduce more cognitive dissonance than it would solve problems.

[Mark Bodman]

Just chiming in on an architectural principle I have adopted over the years that I tend to apply in answering this question: 

Don't mix the taxonomy with the entity you are managing.  

For the specific question, what does a child mean?  Does it mean, decomposition, or is it a dependency?  You need to be specific in order to effectively manage things.  

I discuss this situation in an APM blog a long time ago, applying the same principle works here just as well.

[CMDB Whisperer]

@Mark Bodman I think that is the key question, and as I mention in my comment, since there are a variety of possibilities for distinguishing Offerings from one another (by function, by environment, by SLA, by location, etc.) the parent/child justification could be any one of these.  I provided an example where I use the TBM taxonomy to define the services for Backup and Archive, and then define Service Offerings based on function, but then if I want to have different treatments for those offerings managed by different regional service owners using different technologies, I am left in a lurch.

I do agree with the principle of keeping things as flat as possible, but with the addition of "as deep as necessary".  I think this is where the conversation needs to happen.  How to allow for the flexibility of going down a level if needed, rather than adopt a rigid model that only allows for a single flat layer.  There are clear scenarios where some level of depth is justifiable.

[Kristine Naess]

Hello again @Mark Bodman @scott_lemm,

Thanks for good advices on this. I agree that parent-child-relationships between services is not a good idea. 

After having discussed this with several stakeholders the last three months, I have the following suggestion:

What if ServiceNow detaches the TBM taxonomy nodes from the service portfolio structure (table), so that we can maintain these as two different structures? This would remove our needs for having parent business services, and other remediations to be able to handle reporting in an understandable structure.

In the IRM module, the Risk Taxonomies are separate from the other structures such as the ones that link Authority Documents -> Citations -> Policies -> Control Objectives. So why shouldn’t this be possible in the SPM module as well?

If the TBM taxonomy could have a separate structure, the ways of reporting could be more user friendly for various stake holders:

For Business Continuity Management stakeholders, the organisation structure based (Responsibility Roll-up) reporting is the most crucial. This makes use of a service-to-department responsibility mapping. People and tech together. Contracts, SLAs and service mapping are crucial parts in this. In this case the risk managers and BCM stakeholders want to filter on departments to see the totality of each department’s achievements and readiness.

For day-to-day management of service life cycle activities, and for charge back to subscribers of those services, the Charge back structure would be the most useful. This shows cost related to delivering IT as a service to transfer pricing units.

Whereas for financial controlling and cost optimisation, the “cost archetype” (Bench mark Roll-up) structure is the best. This focuses on what similarities there are between what’s being delivered, and how well comparable companies are performing when delivering these.

Sometimes the levels in these structures match, but far from always. I have used dotted lines to suggest a mapping between services/service portfolio structure and the department structure to show that this is optional. In our case, the business/technical services often cross TBM taxonomy nodes on Category level, so there’s only a dotted line here.

In our case we charge back to both transfer pricing units that are separate legal entities (with their own records having unique DUNS numbers in the core_company table) and some the business units within the mother company.  Therefore we need to be able to report on tax and other figures on a company level as well as a business unit level.

All in all, we really need to do something about the too close relation between the TBM taxonomy structure and the Service portfolio structure. Today we have removed the nodes and follow up on our custom, though TBM inspired, portfolios. That’s the only level that matches our needs.

Is that a possible way going forward?

Regards,

Kristine

[abhinavbansal]

I see that the Thread says that its Solved,  but is it really solved ? 
Has the OP or anyone else been able to solve it for TBM and if yes how it scaled ? 

It would really be helpful In case anyone can add some example of before(option 1) and after(opt 2 or 3 or any other ?) of mapping the service offerings ?