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

[Paul Santaniell]

Frank,

Good example. I'll qualify my response in that modeling can be somewhat subjective and multiple approaches work. Here is an alternative with some rationale behind it.

- Model the modules FI, HR, CO etc... as Business Service Offerings. Why: the application services which map to the SAP instances will be service mapped to the underlying infrastructure. If you don't have multiple instances you'd end up with redundant service mapping. The ownership, location and approvals can be managed on the offering.

- For the business application, the APM requirements could dictate creating separate apps for the different modules. For example, if you want to send surveys and scorecards specific to the FI component, you'd need separate apps. Alternatively, if requirements dictate scoring, and managing TCO, for SAP as whole it can be one business app.

Paul

[Franck Jaffre]

Thanks Paul,

Thank you for your remarks. Very good hints. However, I'm still questioning which is the best mapping to manage the multiple application (FI, CO ...) in SAP. Should they be differentiated from as of the business application, then what is the application service like and the service offering ....

[Paul Santaniell]

Franck,  

Here's how I'm modeling this and why. Feel free to comment on alternatives.

Business Services - different services by module.

• We have different IT functional experts and business users/approvers by module.
• The business service would be technology agnostic and stated in business terms.
• One could be more specific and break the service down into components (i.e. Staffing, Employee Management etc...). This could be advantageous when relating to capabilities.

Business Service Offering

• There service offering is flexible and the level of granularity driven by organization preference. One could choose a single offering, but this approach allows more specific catalog offerings including offerings fulfilled by non-SAP applications.

Business Service Offering to Application Service

• Our implementation is dependent on Citrix in addition to SAP ECC Production (ECP).
• The hypothetical background check is included to illustrate non-SAP and SaaS services.
• Citrix can be Service Mapped independently to simplify the service mapping. 

Application Service to Technology

• The application service is synonymous with the instance.
• Aligns well with Service Mapping is it would be mapped once.
• Is independent of the functional modules delivered (FI, MM) etc.. These can be added/removed without changing the technology mapping to the app service.

Business Application

• The modeling of the Business Application takes on the owners perspective. The Business Application owner could decide to manage as one application (SAP ECC) or multiple (SAP HR, FI etc..). The following questions would drive the solution:
• • Do we want to assess the modules independently, or as a whole? Maybe FI module is great but HR is lacking and is a candidate for replacement. Current APM product allows for assessments by Business Application. Note that APM could be re-configured to assess at Business Service Offering, or Business Service. 
  • Other assessments (cost, technical fit, functional fit, technical risk) could impact the decision as well. 

Summary

• The sell/consume domain (business services, offerings, catalog) is where the differentiation of the SAP modules would play out. 
• The manage technical services domain (application services, tech services) is strictly driven by the physical implementation of the software and hardware. Note that location is the physical location of the hardware. 
• The business application (design domain) is driven by the needs of the business application owner. 

Paul

[Franck Jaffre]

Thanks Paul,

Very much helpful indeed.