Issue

A decision is required as to when to deploy the new S/4HANA In-House-Bank that will replace the existing solution in the separate PI1 SAP system. 

Recommendation

Option E: Defer the deployment of In-House Bank functionality for all GBUs and Entities until after the second group go-live.

Example: (below is an indicative timeframe to illustrate the deployment option).

This is the lowest-risk option in an area that is considered higher risk. Payments and cash collection are critical processes.  There are additional layers of complexity which include running an in-house-bank, and developing and proving the correctness of the complex custom solutions to support the internal factoring process.

The recommended option has a fallback and contingency option with the ECC/PI1 IHB, allows time for integrated process to stabilize, and also allows for production simulations. This is relevant for all entities.

Interim interfaces are required, which adds complexity, however these interim interfaces are required in most of the deployment options.  The interim interfaces in this option will be developed based on the existing interfaces from PF1/WP1 to PI1, hence they are not new design, although they will have to be adapted for the new S/4HANA system.  Where interim interfaces between PI1 and S/4HANA would have already been built for group 1, extending these interfaces for group 2 will be easily manageable.

Deferring the deployment requires project resources for a longer period of time, which equates to additional cost.   Required resources will be largely limited to IHB consultants and technical developers.  This cost may be mitigated to some extent, however this will be determined within the roadmap and overall project planning.  Any additional cost will be outweighed by the risk mitigated. 

Payments outside of IHB will go-live with the groups as per the release plan. These payments will continue via Bank Communication Management (BCM), and they will draw out any issues prior to the larger volume/value payments commence via IHB. 

Being outside of the go-live of the main group/s, it can be expected that the cut-over outage will be shorter, resulting is a shorter payment outage which will be easier to manage. 

Defer period of 3 to 6 months, alignment with the deployment roadmap and business available months will also be required.

Further details on this option, and how it compares to alternatives is available in the evaluation section.

Background & Context

This KDD is focused on the deployment approach for the new S/4HANA IHB.  The IHB processes and customization are in scope for the ERP rebuild project. These processes will be reviewed in the detailed design phase, with the aim to streamline and simplify where possible. 

For clarification purposes, the Treasury application Quantum is out of scope for the ERP rebuild project.  Where required, interfaces between S/4HANA and Quantum are in scope.

In-House Bank

The existing IHB within ECC resides in PI1, within the legal entities Syensqo SA (SSA), and Solvay Finance America (SFA). 

All entities are mandated to participate in the IHB process, except where it's not legally possible (for example China). 

Interfaces are currently in place to link PF1 and WP1 to the IHB in PI1. 

SSA also reside in PF1 for all non-IHB processes. 

Internal Factoring

A high level of complexity exists with IHB largely due to the internal factoring process. 

Internal factoring is not a common process and not supported by standard SAP, hence the current solution requires numerous complex custom developments.  The "to-be" design will aim to streamline and simplify, however it is expected that some level of custom developments will still be required. 

Risk

Cash movements related to payments and receipts is a higher risk area of any ERP implementation. The internal factoring complexity increases the risk. 

Risk is a major factor in the recommendation and decision of this KDD.

Assumptions

IHB and internal factoring will continue in S/4HANA.

Entities not operating within the IHB will go-live with Bank Communication Management (BCM) in line with Overall project release/s.

Constraints

Nil 

Impacts

The recommendation will require the creation of interfaces from S/4HANA to the PI1 system that is hosting the legacy In-House Bank functionality. These interfaces are only required for the duration between the S/4HANA go-lives and the replacement of the IHB functions in PI1 with S/4HANA. Following the go-live of IHB in S/4HANA, these interfaces become obsolete and their code must be removed from S/4HANA. Their design and implementation must therefore be done in a way that facilitates clean removal. 

The new Consolidations tool will go-live with the second group. Considerations is required for the Consolidation of the entities and processes within PI1.

Business Rules

Participation in the IHB will continue to be mandatory unless not legally supported.

Options considered

Early deployment (prior to the main S/4 HANA releases) of IHB was considered, however due to the impact of extending the overall ERP project timeline, and earlier transfer of master data, this option was not reviewed in this KDD.  

IHB is a high risk, mitigating that risk is a critical factor as when compare options.

Option A: Deploy IHB  for all GBUs/entities along with  the first group of the phased deployment.

This option entails the new IHB being deployed for all entities, and execution with the first group of the release plan. 

Example: (below is an indicative timeframe to illustrate the deployment option).

Main Points (further details are in the evaluation section). 

• Higher risk option, with no ECC/PI1 fall back / contingency option, no time for overall system and process stabilization and no opportunity for production simulations.
• New interfaces required from ECC to S/4 HANA. These will be newly designed interfaces and not replication of existing interface functionality.    

Option B: Deploy IHB   for live GBUs/entities in-line with the  groups of the phased deployment (Two IHBs).

This option entails deploying the new IHB in-line with the groups in the release plan. One/existing IHB in PI1 for entities still on ECC, and a second/new IHB for GBUs/entities that have transitioned to S/4 HANA.

Example: (below is an indicative timeframe to illustrate the deployment option).

Main Points (further details are in the evaluation section). 

• Higher risk option, with no ECC/PI1 fall back / contingency option, no time for overall system and process stabilization and no opportunity for production simulations.
• Running two IHB will increase complexity and possibility of errors.
• Additional business resources will be required.   

Option C:  Deploy IHB for all GBUs/entities along with  the second Group of the phased deployment.

This option entails the new IHB being deployed for all entities, and execution with the second group of the release plan.

Example: (below is an indicative timeframe to illustrate the deployment option).

Main Points (further details are in the evaluation section). 

• This was seen as a viable alternative, however the recommended Option E is preferred due to additional de-risking.
• Risk mitigation (fall back contingency, overall system and process stabilization and production simulations are available for Group 1 Entities, but not the whole organization.
• Payments via BCM will draw out issues prior to IHB deployment - this is limited to group 1 entities.

Option D:  Deploy IHB for all GBUs/entities along with  the All-in one deployment.

This option entails the new IHC will be deployed at the same time as all GBUs/Entities as part of the all-in one deployment approach.

Example: (below is an indicative timeframe to illustrate the deployment option).

Main Points (further details are in the evaluation section). 

• This option is low complexity but higher risk.
• Interim interfaces are not required.
• The robust de-risking options mentioned in this document are not available with this option. Alternative risk mitigation will need to be determined, for example additional testing.
• No interim or alternate consolidation processes required for PI1.

Option E: Defer the deployment of IHB for all GBUs/Entities until after the second group go-live.  

Defer by 3 to 6 months (need to align with deployment roadmap and business available months).

Example: (below is an indicative timeframe to illustrate the deployment option).

Main Points (further details are in the evaluation section). 

• Lowest risk option. This option has a fall back / contingency option with the ECC/PI1 IHB, allows time for integrated process to stabilize, and also allows for production simulations. Relevant for all entities.
• Payments via BCM will draw out issues prior to IHB deployment - this is relevant for all entities.
• Interfaces need to be built between the S/4 HANA and PI1, although these will largely be replication of the existing interface functionality, and adjusted for master data changes.
• Interim interfaces between PI1 and S/4 HANA would have already been built for group 1, extending these interfaces for group 2 will be easily manageable. 
• Additional cost expected with relevant resources required for an extended period. This cost is seen to be outweighed by the risk it mitigates.

Evaluation

	Option A Deploy IHB for all GBUs/entities along with the first group of the phased deployment	Option B Deploy IHB for live GBUs/entities in-line with the groups of the phased deployment (Two IHBs).	Option C Deploy IHB for all GBUs/entities along with the second Group of the phased deployment.	Option D Deploy IHB for all GBUs/entities along with the All-in one deployment.	Option E Defer the deployment of IHB for all GBUs/Entities until after the second group go-live.	Option A	Option B	Option C	Option D	Option E
De-risk level Robust contingency / fallback option	PI1 not a possible fall back.	PI1 is not a possible fall back.    Phased transitioned entails less entities go-live in first phase is a lower risk. if there is a significant issue, it will only impact the entities which have transitioned to S/4HANA.	PI1 IHB will be available to as a contingency should there be significant issues with the S/4HANA IHB.  (only for group 1 entities)	PI1 not a possible fall back.	PI1 IHB will be available to as a contingency should there be significant issues with the S/4HANA IHB.	Low	Medium	Medium	Low	High
De-risk Level Stabilization of integrated process (Sales/Accounts Receivable, Payments/Accounts Payables)	No additional time for integrated processes to stabilize, and higher probability of integration issues.	No additional time for integrated processes to stabilize, and higher probability of integration issues.	Integrated processes will have had time to stabilize, (for GBUs/Entities from group 1).	No additional time for integrated processes to stabilize, and higher probability of integration issues.	Integrated processes will have had time to stabilize.	Low	Low	Medium	Low	High
De-risk Level Payments outside of IHB will draw out issues	IHB and BCM will go-live together. No opportunity for BCM to draw out issues in advance.	IHB and BCM will go-live together. No opportunity for BCM to draw out issues in advance.	Non-IHB payments via BCM will draw out issues prior to IHB deployment.   Relevant for group 1 entities.	IHB and BCM will go-live together. No opportunity for BCM to draw out issues in advance.	Non-IHB payments via BCM will draw out issues prior to IHB deployment.   Relevant for all  entities.	Low	Low	Medium	Low	High
De-risk level Ability to run Productions Simulations	Unable to execute production simulations prior to go-live.	Unable to execute production simulations prior to go-live.	Production simulation possible, for group 1 entities, which contributes to lowering the risk.	Unable to execute production simulations prior to go-live.	Production simulation possible, for all entities, which contributes to lowering the risk.	Low	Low	Medium	Low	High
Less Complexity Less Interfaces or lower complexity interfaces	New interfaces are required for integration of ECC (WP1) with S/4HANA, for GBUs/Entities transitioning in Group 2.  New interfaces need to be designed and built for Group 2 entities in order to match ECC with the new S/4HANA design.	New interfaces are not required for PI1 to S/4HANA	New interfaces are required for integration of PI1 with S/4HANA, for GBUs/Entities transitioning in group 1.  Interfaces will be based on existing ECC interfaces already in place.	New interfaces are not required for PI1 to S/4HANA	Requires interfaces to be built for integration of PI1 with S/4HANA. Interfaces are required for all GBUs/Entities. Interfaces will be based on existing ECC interfaces already in place. Interfaces for Group 1 would already be built, extension to Group 2 will be required.	Low	High	Medium	High	Medium
Less Complexity One IHB Operating is less complex than two IHB in operation	One IHB Operating Less complex, less chance or errors	Two IHBs Operating More complex, high chance or errors	One IHB Operating Less complex, less chance or errors	One IHB Operating Less complex, less chance or errors	One IHB Operating Less complex, less chance or errors	High	Low	High	High	High
No additional Resource Cost	No additional project resource costs.	No additional project resource costs.	No additional project resource costs.	No additional project resource costs.	With the go-live of IHB deferred, relevant project resources will be required for an extended period.	High	High	High	High	Low
Lower business resource impact	No additional/adverse impact on business resources	Additional resources likely required to run two IHBs.  Business resources will likely need to perform manual clearing to payment sub-ledgers.	No additional/adverse impact on business resources	No additional/adverse impact on business resources.	No additional/adverse impact on business resources	High	Low	High	High	High
Ease of Consolidation	Consolidations will follow the normal "interim" process for BFC Consol.	Consolidations will follow the normal "interim" process for BFC Consol. Challenge is that there are two IHB entities (PI1 and S/4HANA) to consolidate. This is similar to the existing process with PI1 & PF1.	Consolidation will follow the new Consolidation process, no interim process required.	Consolidation will follow the new Consolidation process, no interim process required.	Consolidation of the entities on PI1 will require an interim solution, for the new Consolidations Tool. Standardized process to load into Consolidation system expected to be utilized. Challenge is that SSA will existing in PI1 and S/4HANA	High	Medium	High	High	Medium
Lower Cut-over impact (less payments outages).	One payment outage as only one cut-over is required.	Two payment outages to manage.	One payment outage as only one cut-over is required.	One payment outage as only one cut-over is required.	One payment outage as only one cut-over is required. A shorter cut-over outage for payments.	High	Low	High	High	High

See also

Change log

Workflow history