Issue

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

Recommendation:    

Background & Context

This KDD is focused on the deployment approach for the new S4/HANA IHB.  The existing processes and customisation 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. 

In-House Bank

The existing IHB within ECC resides in PI1, within the legal entities SSA and SFA. 

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

 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.  To "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 S4/HANA.

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

Constraints

Nil 

Impacts

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

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 S4/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 review in this KDD.  

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

Option A: 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).

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

• Lowest risk option. This option has a fall back \ contingency option, allow time for integrated process to stabalize, and also alows for production simulations.
• Interfaces need to be built between the S4/HANA and PI1, although these will largely be replications of the existing interface functionality, and adjusting from master data changes.
• Additional cost expected with relevant resources required for an extended period.

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 S4/HANA.

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

• 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 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. 

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 stabalization and no opportunity for production simulations.
• New interfaces required from ECC to S4/HANA. These will be newly designed interfaces and not replication of existing interfaces.    

Option D: 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.

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

• This was seen at the best alternative, however the recommended Option A is preferred due to additional de-risking.

Option E: 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.

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

• This option is low complexity but higher risk.

Evaluation

	Option A	Option B	Option C	Option D	Option E	Option A	Option B	Option C	Option D	Option E
De-risk level Strong Contingency \ fallback option	PI1 IHB will be available to as a contingency should there be significant issues with the S4/HANA IHB.	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 S4/HANA.	PI1 not a possible fall back.	PI1 IHB will be available to as a contingency should there be significant issues with the S4/HANA IHB.  (only for group 1 entities)	PI1 not a possible fall back.	High	Medium	Low	Medium	Low
De-risk Level 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).	No additional time for integrated process to stabilise, and higher probability of integration issues.	High	Low	Low	Medium	Low
De-risk level Ability to run Productions Simulations	Production simulation possible, for all entities, which contributes to lowering the risk.	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.	High	Low	Low	Medium	Low
Less Complexity Less Interfaces or lower complexity interfaces	Requires interfaces to be built for integration of PI1 with S4/HANA. Interfaces are required for all GBUs\Entities. Interfaces will be based on existing ECC interfaces already in place.	New interfaces are not required for PI1 to S4/HANA	New interfaces are required for integration of ECC (WP1) with S4/HANA, 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 S4/HANA design.	New interfaces are required for integration of PI1 with S4/HANA, 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 S4/HANA	Medium	High	Low	Medium	High
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	With the go-live of IHB deferred, relevant project resources will be required for an extended period.	No additional project resoure costs.	No additional project resoure costs.	No additional project resoure costs.	No additional project resoure costs.	Low	High	High	High	High
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 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	Consolidation of the entities on PI1 will require an interim solution, for new Consolidations Tool. Standard process to load into Consol 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   Standand process to load into Consol are expected to be utilised	Consolidation will follow the new Consol process, no interim process required.	Medium	Medium	High	Medium	High
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.	High	Low	High	High	High

See also

Change log

Workflow history