Issue

Syensqo is currently using a SaaS application named ‘CCH Tagetik’ provided by Wolters Kluwer for I/C reconciliations carried out as part of the local and group period-end closing activities. The application has also been integrated into the current consolidation system used at Syensqo through custom API developments to provide data feeds for easy reconciliation and faster group closes.

In S/4 HANA, a not entirely new but completely revamped I/C reconciliation tool and solution has been introduced under the product name 'Intercompany Matching and Reconciliation' or in short ICMR. It has a lot of benefits compared to its predecessor with view to ease of use, automation and integration and following the project's overarching principle of 'SAP first' this document is meant to outlay and evaluate possible deployment options for ICMR at Syensqo.

Recommendation

While the new ICMR tool available in S/4 HANA is a game changer for I/C reconciliations compared to the obsolete special ledger solution previously available in SAP ECC systems, it is only able to play out its full potential of technical and business benefits once all operational entities have started using S/4 HANA.

While some cost savings could be reaped from an immediate deployment of ICMR in S/4 HANA and the replacement of the current ‘CCH Tagetik’ solution from a licensing cost perspective, additional customization would be required to integrate the ICMR tool with the existing diverse SAP landscape upstream for local closing activities and down-stream for group closing activities under the assumption that the current degree of automation of the respective process designs should not be decreased in S/4 HANA.

As such it is recommended to go with option 2 and deploy ICMR together with the new consolidation software at a later stage in the S/4 HANA transformation program to keep business disruptions minimal and capitalize on its full capabilities through its native integration with Group Reporting in S/4 HANA.

Background & Context

Explain the context in which the decision is being made.

Assumptions

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

Business Rules

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 

Options considered

List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.

Option A: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Option B: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Option C: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Option D: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

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
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

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