How to implement CSDM-compliant SAP services across geographies

[Franck Jaffre]

Hi everybody,

I'm opening this question in order to assess my understanding of the CSDM model when it comes to applying it SAP service to be delivered worldwide. 

Reading the previous posts on this subject here's my interpretation of how to best deliver with ServiceNow SAP ECC + application (FI, HR, ..) service in multiple locations around the globe.

- SAP would be the business Application supporting a business capabilities (FI, HR, ...)

- SAP ECC would be mapped to Application Service holding the Version, Location, Environment attributes (so one Application Service per location)

- SAP HR, SAP FI, SAP CO would be managed by Application dedicated Service Owners

- The business Service Offering would map the the correct (Application Service Location attribute), the SLA, Business continuity and different other business related attributes.

This implementation's probably quite rough / static as it considers that once the geography's selected all available applications for the region would be made available. 

Still I have some questions, probably more linked to how SAP's organised and delivered.. 

- should the location be managed directly from the Business Service offering ?

- should the Application Service be more application specific and rather consider SAP FI or SAP LOC than the generic "SAP ECC" ? 

- In case we consider SAP ECC as the application Service, how can one manage specific application attributes (FI for example) differents from SAP ECC ...  ?

Any remarks, idea, feedback's welcome. 

Thanks

[Ed Laar]

Hi,

A little late reaction. My considerations are always taking the end-user (thus the users of the several SAP-apps) in mind. As soon as they discover for example an issue with their SAP-app they should be able to raise an INC in a very easy way on that particular SAP-app. Example: User A faces performance issues with the HR application)

Taking this into scope the several SAP-apps should be available for INC logging is should be available as Application Services. In your use case: SAP HR, SAP FI and SAP CO

These Application Services rely on an infrastructure stack providing these SAP Services and underpin the Business application SAP or SAP ECC.

What do you think about this idea??

Grtz,

Ed

[Franck Jaffre]

Thanks for the remarks. I'm always questioning which differentiation should be implemented at the consumer side. 

i.e : as we can also open an INC against a business service or a service offering, should we ask the user state which Application Service it refers to? The Application Service says things about the technicalities, I must admit that I usually prefer keeping this away from the user's knowledge.

[Paul Santaniell · Accepted solution]

Ed,

Doing this in Application Service is something I've seen. However, the "Blueprint" for CSDM 2.1 and incident shows the following print screen. From a user perspective the incident is logged against the Business Service and Business Service Offering. With this approach, there's no need to break out separate application services. If one chooses not to implement Business Services in a crawl model, you'd need to do the same thing in Application Services. This would for a time, but I believe it would be subject to re-work when moving to the walk model. Also, it may require making a hierarchy of Application Services to avoid service mapping redundancy.

The CSDM 2.1 can be found in the Now Learning CSDM training which is fairly new.

Paul

[wei2]

Would you consider "SAP Support Desk" as a better name used for a business service? Multiple service offerings can then be defined by the providers, the service levels, and geography, etc.