Registering Third Party Service Providers and Services in CSDM

[Andy H]

I have a business requirement to register third party services in our instance of ServiceNow and have a few thoughts on how to do this but wanted to see if anybody had any better ideas.

The data (Supplier/Supplier Service) already exists I just want to load the data into SN so that we can then relate these to our existing Technical Service Offerings i.e. Technical Service Offering A is dependent on Supplier Service Offering Z.

Example: ServiceNow Discovery Technical Service Offering is dependent on ServiceNow Discovery Supplier Service Offering

Has anybody done anything similar or have any suggestions on how best to do this?

[Stuart Tucker]

Yes, interesting. All of our services are 'internal', in that we are only delivering IT to staff within the company, so they can do their jobs. Some of those services are managed in-house but an increasing number are simple third party hosting agreements and web services. We are not seeking to measure performance of those third parties, contracts are often not that complex, so there are no 'commitments' as such and these vendors are not using ServiceNow. Maybe we should use Technical Service Offerings to keep in line with the model, but it seems those records don't quite fit the requirement for an external supplier.

[Marc De Mol]

We ask the question; "Do the consumers of the service create incidents with an internal team or directly on the external provider's website?", if the answer is that consumers only interact with an internal team, and the internal team has external support when they needed from a third party, than the TSO is internal, a contract can be linked to the TSO or the TS for the Third party interaction and lineage, I'm not sure myself if we should do this on the TSO or the TS, the dependency is there but support is not given directly by the supplier to the consumer so logic would say the TS. Without relationship between TS and TSO, I'm not sure if this will show properly when doing a BIA (Business Impact Analysis) though.

[Michael Dul]

Hello Andy,

It would be great to ask the business what they intend to use it for. Answer to this can usually suggest the direction. I would also say it should be in line with your taxonomy. I would approach it with such options:

1. Offering Creation for Vendors - Exactly what you have written. You can create an offering per vendor offering.
   Benefits: very clear visualisation
   Disadvantages: Increased maintenance + if you have any offering standard validations (groups, etc.) your vendor offerings might not follow the same standard. 
2. Vendor details in the Offering - You can enhance your offering data structure to allow you to register external vendor support. As offerings include support arrangements, you can argue that supporting contract of a vendor is already part of it and that the offering would be they way they deliver their services, which your company might not be interested in. You can do this for example by linking additional contracts to the offering. In this scenario I do not mean using the field "Vendor" which you might keep as your "Service Delivery Partner". I would recommend this if this is for information only and you do not want to link any advanced technical capabilities from it. I would recommend this if (like in your scenario) this is purely "non-technical" relationship and you don't have to map impact propagation.
   Benefits: All in one place and decreased maintenance versus option (i)
   Disadvantages: Makes your Offering data structure more complex. Cannot visualise natively.
3. Application Services - If your dependency is purely to the application services of a vendor, you can use those objects to represent it, and then use the basic data structure on them to represent the vendor relationship. This is the same as option (i) but focusing on the precise technical dependency.
   Benefits: Very clear visualisation.
   Disadvantage: Limited scope.

Hope this helps. Happy to discuss it further if you want to.

Best Regards,

Michael