Tenant Strategy

[stefan_resag]

Goal of this document:

In many SAP Business ByDesign projects the solution is rolled out to various companies and countries. Since SAP Business ByDesignis capable of modelling multiple companies and countries within the same tenant, it is often not an easy task to decide how many tenants to set up. There are examples where customers have modeled all of their companies in one tenant. Others have one tenant per country.

In this document I have collected aspects that shall help to take the right decision for the tenant strategy.

Some basic definitions and information:

·       System:

o   Can have multiple tenants

o   Can have tenants from multiple customers

o   All tenants on a system share same software stack (exception: add-ons)

o   Downtimes / upgrades etc. are in general on system level and not on tenant level

o   For some tenant operations (copy tenant) tenant downtimes may apply

o   System is located in one data center (US / DE / AU) --> Impact on downtimes / maintenance windows

·       Tenant:

o   One unique URL

o   Owned by only one customer

o   Modelling of multiple companies in different countries per tenant possible

o   Contracts cover one productive and one test tenant. More tenants possible.

·       Private edition:

o   All tenants of one system belong to same customer

o   One tenant or multi tenantstrategy possible

o   More flexible upgrade / downtime / maintenance schedule possible

·       Single tenant strategy:

o   All or multiple companies are modeled within one productive tenant

·       Multi-tenant strategy:

o   Different companies / countries are modeled on different productive tenants

For technical questions on the different types of tenant requests, please check out the meet-the-expert session in the SAP Enterprise Support Academy ( https://support.sap.com/support-programs-services/programs/enterprise-support/academy.html ).

1. Best Practices: Service Control Center (SAP Business ByDesign and SAP Cloud for Customer ( https://service.sap.com/sap/bc/bsp/spn/esa_redirect/index.htm?gotocourse=X&courseid=70287178 )

2. Requesting Tenants and Managing your SAP Cloud Tenant Landscape ( https://service.sap.com/sap/bc/bsp/spn/esa_redirect/index.htm?gotocourse=X&courseid=70287671 )

The SAP Enterprise Support Academy access is available to all SAP customers with an s-user.( https://www.youtube.com/user/SAPSMPTV#p/u/19/cZRy9qN0y-M )

Decision criteria to go for single- or multi-tenant strategy:

o   Maintenance / Downtime schedule:

o   As mentioned downtimes are per system

o   Downtime schedules depend on data center of system (scheduled during night time of data center)

o   Especially when modelling companies from different time zones in one tenant, maintenance hours could collide with operation hours of a company -> Critical for all scenarios where work cannot be scheduled around downtimes (e.g. warehouse operations).

o   From a technical perspective a private edition would be an option in single-tenant strategy, because downtimes can be defined by customer.

o   In the meantime downtimes for multi-customer systems are moved to weekends to minimize the impact on business hours.

·       Business Configuration

o   Scoping (selected countries, scoping elements and questions) is done per tenant. All companies on one tenant thus share the same scoping.

o   Fine-Tuning:

·       Depending on the respective fine-tuning activity a company-specific behavior can be achieved:

§  Company-independent: e.g. Party Role Definition, Cost Object Types

§  Company-dependent: e.g. Purchase Order Approval, Payment Strategy

·       Remark: Especially configurations like 'PO Approvals' could become very complex if to be defined for multiple companies in one tenant.

·       Data migration:

o   Migration workbench supports delta-migration. This means that new companies could be migrated at a later point in time -> no impact seen on tenant strategy.

·       Shared services (e.g. activities done by customer's central IT department or other centralized organizations):

o   Incident management:

·       The Central Help Desk (CHD) allows management of incidents from multiple tenants across various systems.

·       The setup of CHD can be requested from SAP.

o   Central tenant management (request tenant operations)

·   Usage of 'Service Control Center' WoC - 'Systems' view gives overview of productive and test tenants of a customer.

·   Some functions however are only available when logged on to respective productive tenant.

o   Further shared services like HR, FIN, etc.

·   Cross-tenant operations are not supported in general

·   When shared services need to manage multiple companies, this has to be done in the respective productive tenant (e.g. HR operations like hiring, central financial operations)

·   Single sign-on (SSO) can be used to reduce login-effort

·       Data privacy:

o   Access context per work center and organizational assignment of user can be used to limit visible data. Depending on the work center different access contexts apply: Company, Site, Sales Org., project lead, ...

o   All materials and customers of one tenant are visible in each company

o   Reports assigned to a work center will consider the respective access context but are in general visible to all users

·       Master data maintenance and usage:

o   Certain master data can be shared between companies of one tenant. Examples:

·       Materials and Services

·       Customers

·       Price Lists (can also be defined company-specific)

·       List Prices

·       Org. Management (e.g. for cross-company profit center finding, deviating business residence)

·       Master data deployment scenarios from ECC to ByD (subsidiaries scenario):

o   Product Master & Customer Master

·       Deployment to one or multiple tenants supported

·       Various criteria can be used to distribute product master to one or multiple tenants

·       One-time effort needed to set up ALE scenario

·       Financial consolidation preparation:

o   Preliminary Consolidation Elimination: This report gives an overview of intercompany gains and losses between all companies modelled within one tenant.

o   Financial Statement Consolidation Preparation (FSCP): This will create a data file that can be used by external consolidation systems.

o   Impact on tenant strategy:

·       If the FSCP will be used, no impact on the tenant strategy is seen, because the data file for the external consolidation system is created per company.

·      For the preliminary consolidation elimination, all companies need to be modelled within the same tenant.

·       Intercompany processes ByD to ByD:

o   Professional Service business

·       Less effort is needed for cross-company staffing and time recording in a single tenant strategy

·       ICo however is also possible in a multi-tenant approach, but with limitations (duplicate time recording, no availability overview cross-company)

o   Sell-Buy:

·       No significant difference is seen between single- and multi-tenant strategy

o   Intercompany repair (type: at supplier service-center):

·   No significant difference between single- and multi-tenant strategy is seen

o   Third-party order processing / 3rd-party direct ship / drop shipment

·   No significant difference between single- and multi-tenant strategy is seen

 

               Remark: In case both companies are in one tenant no communication arrangements need to be created. In this case a company is also a business partner, e.g. a supplier. It is then sufficient to set the corresponding output channel to 'Internal EDX' in the 'Business Partner Data' WoC.

·       Intercompany processes ByD to ECC and ECC to ByD

o   No significant difference seen between single- and multi-tenant strategy is seen

·       Reporting:

o   Cross-company reporting is supported in one tenant with built-in reporting capabilities (depending on access context)

o   Cross-tenant reporting is possible using business warehouse (BW)

o   Two main options are available for extraction of data based on analytics content:

·       ODP

§  Data are extracted based on MDAV / Data source level

§  Selection criteria can be applied

§  Delta load not supported, but workaround using selection by date possible

§  Preferred approach for extracting data into central BW

·       ODATA

§  Data are provided based on ByD Reporting content (Views / Queries)

§  Preferred approach to do reporting with alternative frontend tools

·       Localization

o   In general multiple countries can be localized by partners on the same tenant.

o   Forms visibility

·       Different forms will be visible for different countries

o   Report visibility

·       All reports assigned to a work center view will be visible for all users -> in case multiple report variants are needed for different countries in one tenant, these reports will be visible

·       Add-on's:

o   An add-on can be deployed per tenant. If several companies are modelled within one tenant, the add-on cannot be activated for dedicated companies. It has to be ensured by the add-on that e.g. business processes are only impacted in dedicated companies.

• User licensing:

o   Since some releases users with the same login username in different tenants are counted as one user and thus only need one license. The license considered is the most expensive one, that the user would need looking at all tenants. Example: In one tenant the user would need an enterprise user, in another tenant he would only need a self-service user. Then the enterprise user license is needed.

• Planned spin-offs:

o   In case an enterprise has identified businesses that are most likely to be sold in future, then those can be implemented on a separate tenant. This would allow reusing the ByDesign tenant by the new owner of the business (permanently or temporarily to support an accelerated separation).
In case those businesses are implemented on the same tenant as other parts of the enterprise, then there is still the option to delimit those organizations to be sold. ByDesign offers an option to extract master data and most open transactional data using the Data Extraction self-service, exporting data into the known migration templates. This helps reusing them when recreating the business in another ByDesign tenant.
Please consider that some documents like open production orders and open invoices cannot be extracted with this tool. The Data Extraction unloads also historical closed documents, however for a potential (re)migration of historical elements into a ByDesign tenant the usual restrictions apply (e.g. Sales Order migration covers only open items).

• Integration with Employee Central (Success Factors): It is possible to connect one Employee Central (EC) to multiple ByDesign tenants. In case multiple HR systems (SAP and / or non-SAP) need to be connected to ByDesign, integration would be simpler by also setting up multiple ByDesign tenants (1 to 1 between ByDesign and HR system). In case still only one ByDesign tenant is preferred, the usage of a middle-ware might be required to orchestrate the integration between the tenant and the HR solutions.


• Integration with SAP Concur: It is possible to integrate one Concur instance to multiple ByDesign tenants. Please keep in mind, that all employee IDs and login IDs (email addresses) need to be globally unique so that SAP Concur can use them to create the required user profiles.