| Status | Approved |
| Owner | Antonio Zappone |
| Stakeholders |
Issue
Decision is required as the when to deploy the new S4/HANA In-House-Bank.
Recommendation:
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 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 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.
Option A: Defer the deployment of IHB for all GBUs\Entities until after the second group go-live.
Defer by 4 to 6 months (need to align with deployment roadmap and business available months).
- Lowest risk option. IHB is a high risk \ high complexity process. This option allows for a fall back \ contingency.
- Allows time to integrated process to stabalise.
- Allows the option of production simulations.
- Interfaces need to be built between the S4/HANA and PI1, although these will largely be replications of existing interfaces.
- 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.
- Running two IHB can 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.
- Highest risk option
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.
- 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.
- 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
|
|
|
|
|
| High | Medium | Low | Medium | Low | |
De-risk Level
|
| High | Low | Low | Medium | Low | |||||
De-risk level
| High | Low | Low | Medium | Low | ||||||
Less Complexity
|
Interfaces will be based on existing ECC interfaces already in place. |
|
New interfaces need to be designed and built for Group 2 entities in order to match ECC with the new S4/HANA design. |
Interfaces will be based on existing ECC interfaces already in place. |
| Medium | High | Low | Medium | High | |
Less Complexity
|
Less complex, less chance or errors |
More complex, high chance or errors |
Less complex, less chance or errors |
Less complex, less chance or errors |
Less complex, less chance or errors | High | Low | High | High | High | |
| No additional Resource Cost |
| Low | High | High | High | High | |||||
| Lower business resource impact |
| High | Low | High | High | High | |||||
| Ease of Consolidation |
Standard process to load into Consol are expected to be utilised |
Standand process to load into Cosnsol are expected to be utilised |
| Medium | Medium | High | Medium | High | |||
| Lower Cut-over impact (less payments outages). | High | Low | High | High | High |
See also
Change log
Workflow history
| Title | Last Updated By | Updated | Status | |
|---|---|---|---|---|
| There are no pages at the moment. | ||||




