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.

Capture.JPG

·       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).

To report this post you need to login first.

11 Comments

You must be Logged on to comment or reply to a post.

  1. Eelco Essenberg

    Hi Stefan,

    Thanks for the comprehensive overview, this is very helpful. For us it validates the choice for a single tenant we made when going live last year. Still, your overview would have helped us make the choice more explicit.

    I do have a question on consolidation in a single tenant scenario (multiple companies, with quite a bit of intercompany activity). As you point out, ByD can factor out the intercompany sales volumes, but at this time seems unable to factor out intercompany cost of sales in any easy manner. This is a serious bottleneck for preparing the actual consolidation (which happens outside ByD). We do not use consolidation software since the price tag of those systems would be very hard to justify for a company of our size.

    Beyond consolidation, this issue also impacts out ability to generate certain types of management reports where you would want to factor out the intercompany margins.

    Any thoughts or suggestions on this topic?

    Thanks & best regards,

    Eelco

    (0) 
    1. Stefan Resag Post author

      Hi Eelco,

      I need to talk to our consolidation experts, but this will take some time. I will come back to you asap.

      Best regards,

      Stefan

      (0) 
        1. Marlene Katzschner

          Hi Eelco,

          thank you for your comment. As you might have see we adjusted the document to be more precise. The current wording is “Preliminary Consolidation Elimination: This report gives an overview of intercompany gains and losses between all companies modelled within one tenant.

          Important is to understand that this is only a report that helps you to see the gains and losses. No cost of sales, etc. and considered. No postings are done.

          Currently we do not plan to provide additional consolidiation functionality. This needs to be done outside ByDesign. Some customers that use consolidation systems, in addition some customers also use Excel to create there consolidation reports with the information provided by ByDesign.

          For the management reports where you would like to factor our intercompany margins, we do not plan any standard reports in ByDesign. We know such requirements, but those were implemented as customer specific within the implementation project itself.

          Best regards and thanks
          Marlene

          (0) 
          1. Eelco Essenberg

            Hello Marlene,

            Thank you for your reply. It is clear ByD does not do the actual consolidation and the relevant postings, and we are comfortable with that.

            Where we have difficulty is that whereas on the revenue side, it is possible quite easily to separate intercompany from 3rd party revenue (through use of the “partner company” flag and the ability to post revenues to separate G/L accounts), there is no such functionality on the cost of sales side.

            This makes it very hard to correctly match intercompany costs of sales to intercompany revenue – and hence do the elimination (in Excel in our case), because we simply cannot produce the relevant reports.

            Neither our implementation partner nor an SAP consultant have been able to (help us) figure this out, and this will become a significant audit issue.

            W.r.t. the management reports factoring out intercompany margins, can you maybe share contact information for someone who has done this and who could help us with that? Or ask them to contact us?

            Thanks again,

            Eelco

            (0) 
  2. Thomas Vogt

    Hi Stefan,

    excellent blog summarizing the decision criteria in an early project phase, definitely worth its 5 stars.

    Do you have any hint about the feasibility of later changes? Do you happen to have some feedback or experience with e.g. carving out a company from a live tenant? Or merging tenants?

    I would expect the recommendations could also dependend on expexted data volume and variability of processes among subsidiaries.

    Thanks and best regards,

      Thomas

    (0) 
    1. Stefan Resag Post author

      Hi Thomas,

      first of all thank you.

      I had a brief look at what it means to carve out a company from a live tenant and also talked to our migration expert. The following steps need to be done and considered:

      1. The EOL tool can be used to extract the data. Assumption is that those data are needed to migrate company to another tenant. However the EOL tool should only be used by experienced consultants. Since the EOL time has some restrictions (e.g. query of data), the data extract needs some rework. Also the data are sometimes not in exactly same format as the migration templates and also here some rework is needed in case the data need to be used to bring the company to another ByD tenant.

      2. There are some data currently not covered by the EOL tool or that are tricky to be extracted, like fixed assets. For this ODATA services or reports can be used instead.

      3. The comany / org elements then need to be delimited in the org management.

      Merging tenants would mean that you extract the companies from one tenant as described above and migrate those to the other tenant. As a consequence the history of transactional data is not visible in the new tenant for the migrated company. Hope this helps.

      Best regards,

      Stefan

      (0) 
  3. AGILITA Support

    Hi Stefan

    We are an implementation partner for SAP Business ByDesign.

    We often have to create the incidents for our customer in their systems. So the managing of the different systems are difficult.

    Can the Central Help Desk (CHD) be used for managing the incidents of different customer tenants? When yes, how we can request it from SAP?

    Thanks for your help and best regards, Jasmin Schaad

    (0) 
        1. NithinKumar B

          Hi Jasmin,

          Please find the details here –

          Description:

          In a normal customer scenario incidents created by the end user can be tracked by the key user in the Application and User Management Workcenter. The key user can forward the incident to SAP Support.

          Due to the flexible architecture it is also possible to implement other variants of the process.

          We distinguish the following scenarios

          • CHD (Central Help Desk Scenario)
          • CCC (Customer Competence/Partner Scenario)

          CHD-Scenario
          In the CHD Scenario, all incidents which are reported by a user in a tenant are automatically forwarded to another tenant. In the other tenant a key user can track the incidents from multiple tenants. He still can forward the incidents to a Service Provider which is normally SAP Support – exception in the CCC scenario.

          Resolution:

          Requesting CHD/CCC via an incident

          In order to get the setup established just follow the steps:

          • Create an incident with the short text “CHD Setup required” or “CCC Setup required”; note most customer have the Central Help Desk (CHD) scenario in use
          • Add the template and your custom system URL data indicated by <>

            

          *************** template start – do not copy ***************

          Dear Support,

          we like to get our test/migration tenants connected to the central incident processing tenant

          • Our Central system is <add central tenant via URL where the incidents shall arrive>
          • The client to be connected is <Add client tenant URL which is to be connected to the central system>

          Choose your setup option by deleting the option not required

          -> We wish to be contacted to agree on a specific switchover date and exact time

          -> Switchover at any time preferred, we have understood that pre-switch incidents are not transferred to the central scenarios.

          <sign as key user or stakeholder contact, email + phone>

          *************** template end – do not copy ***************

          Note that only new incidents will use the feature. Previously created incidents will not be transported to the central system.

          Thanks,

          Nithin

          (0) 

Leave a Reply