Issue

Decision is required as the when to deploy the new S4\HANA In-House-Bank.

Recommendation:    Option A: Defer the deployment of IHB for all GBUs\Entities until after the second group go-live. 

This is the lowest risk option in an area that is general ly cosnidered higher risk. Payments and receipts is a critical processes.  There are additional layer's of complexity with running an in-house-bank along with the higher compexity custom solutions to support the internal factoring process.

Interim interfaces are required, which add compleity, however these interim interfaces are requird in most of the deployment options.  The interim interfaces will be developed based on the existing interfaces from PF1\WP1 to PI1, hence they are not new design, although the will have to be adapted for the S4HANA. 

Deferring the the deployment requires project resources for a longer period of time, which equates to additional cost.   Required resources will be limited to IHB consultants and technical developers.  Whether this is an "additional cost, or whether resources can commence later and finish later needs to be determine in the overall project planning. 

Background & Context

In-House Bank

The existing IHB within ECC resides in PI1, within the legal entities SSA and SFA.  SSA and SFA entities also reside in PF1 for all non IHB processes.  Interfaces are current in place to link PF1 and WP1 to the IHB in PI1. 

All entities are mandated to participate in the IHB process, except where it's not legally possible.  For example, China, x ,x ,x , is not part of the IHB due to legal restrictions.

Internal Factoring

A high level of complexity exists with IHB largely due to the internal factoring process. Internal factoring brings benefits in the way of; 

• Tax cash advantage of ~3 m€ per year for Syensqo
• Native centralisation of the cash flows onto Syensqo SA and SFA without the need to pool further
• Centralisation of the FX exposures that enable centralised and efficient hedging over the largest exposures possible
• Centralisation of the collection and credit risk allowing to streamline the CCT activities (Note: should be shared with CCT)
• Centralisation of the vendor payments allowing the streamline the A/P and Payroll activities (Note: should be shared with A/P and HR-Payroll)

Internal factoring is not a common process and not supported by standard SAP, hence the current solution requires nemerous complex custom developements.  To "to-be" design will aim to streamline and simplify, hwever it is epected 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 S4HANA.

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

Constraints

Nil 

Impacts

Depending on the approach,  interfaces from S4HANA to PI1 require consideration. If they are required, the existing interfaces from PF1 \ WP1 will need to be replicated for S4HANA.

The new Consolidations tool will go-live in the last release.  This requires considerations 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 S4HANA 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 review in this KDD.  

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

Lowest risk option, for IHB is a high risk \ high complexity process by allowing for a fall back \ contigency for the IHB payments and receipts

Allows time to integrated process to stabalise

Allows the poption of production simulations

Interfaces need to be built between the S4HANA and PI1, although these will largely be relications of existing interfaces.

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

This option entails deploying the IHB in line with the groups in the release plan. One IHB in PI1 for entites still on ECC,  and a second IHB for GBUs\entities that have S4HANA for transitioned to S4HANA.

The main drawbacks with this option;

1. Running two IHB can increase complexity 
2. Additional business resources will be required

Option C: Deploy IHB for live GBUs/entities in the first group of the phased deployment.

This option entails IHB being deployed for all entities in the first group of the release plan. 

The main drawback with this option;

1. Highest risk option 

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

This option entails IHB being deployed for all entities in the second group of the release plan.

This was seen at the best alternative, However the recommendation Option A is preferred due to additioanal de-risking.

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

	Option A	Option B	Option C	Option D	Option A	Option B	Option C	Option D
De-Risk Strong Contigency \ fallback option	PI1 will be available to as a contigency should there be significants issues with the S4HANA IHB.	PI1 will not be 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 S4HANA.	PI1 will not be a possible fall back.	PI1 will be available to as a contigency should there be significants issues with the S4HANA IHB.  (only for group 1 entities)	High	Medium	Low	Medium
De-risk Stabilisation on integrated process (Sales\Accounts Receivable, Payments\Accounts Payables)	Integrated processes will have had time to stabilise.	No additional time for integrated process to stabilise, and higher probability of integration issues.	No additional time for integrated process to stabilise, and higher probability of integration issues.	Integrated processes will have had time to stabilise, (for GBUs\Entities from group 1).	High	Low	Low	Medium
De-risk Ability to run Productions Simulations	Production simulation possible, for all entities, which contributes to lowering the risk.	Unable to excute production simulations prior to go-live.	Unable to excute production simulations prior to go-live.	Production simulation possible, for group 1 entities,  which contributes to lowering the risk.	High	Low	Low	High
Less Complexity - Less Interfaces	Requires interfaces to be built for integration of PI1 with S4HANA. Interfaces are required for all GBUs\Enttites.	New interfaces are not required for PI1 to S4HANA	New interfaces are required for integration of ECC (WP1) with S4HANA., for GBUs\Entities transitioning in Group 2.	New interfaces are required for integration of PI1 with S4HANA., for  GBUs\Entities transitioning in group 1.	Low	High	Medium	Medium
Less Complexity - One IHB Operating is less complex than two IHB in operation	One IHB Operating	Two IHBs Operating	One IHB Operating	One IHB Operating	High	Low	High	High
Additional Resource Cost	With the go-live of IHB deferred, relevant resources will be required for an extended period.	No additional project costs.	No additional project costs.	No additional project costs.	Low	High	High	High
Business resource impact	No additional\adverse impact on business resources	Additional resourcs likely required to run two IHBs.  Business resources will likely need to perform manual clearing payment sub-ledgers.	No additional\adverse impact on business resources	No additional\adverse impact on business resources	High	Low	High	High
Ease of Consolidation	Consolidation of the entities on PI1 will require an interim solution, for new Consolidations Tool. Stardard process to load into Cosnsol are expected to be utilised	Consolidation of the entities on PI1 will require an interim solution. Utilise existing approach into BFC Consolidation Tool.	Consolidations will follow the normal interim process for BFC Consol.	Consolidation of the entities on PI1 will require an interim solution, or new Consolidations Tool   Stardard process to load into Cosnsol are expected to be utilised	Medium	Medium	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.	High	Low	High	High

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log

Workflow history