| Status | Approved |
| Owner | Antonio Zappone |
| Stakeholders | MADJARIAN, Gilles UL HASAN, Selim , Mario Tondo |
Issue
A key decision is required on when to deploy the new Consolidation tool. Along with a multiphase ERP implementation comes options on when to deploy, whether in Release 1, 2 or n.
Recommendation
The new Consolidation Tool to be deployed in the last Release. The exact release timing will be concluded when the overall project Deployment Approach is finalised.
Background & Context
BFC (Business Objects Financial Consolidation) is the current consolidations tool. This is an SAP system however it is not fully integrated with the SAP ERPs, rather data is loaded from the source SAP ECCs. Data loads are via flat files that are produced with automation tools (RPA).
SAP is phasing out BFC and support will cease in 2030 (extended from 2027).
As-Is Systems Integration for Consolidations
Assumptions
Deployment:
- S/4HANA will be Deployed over more than one Release.
Tools:
- Group Reporting is the current/latest SAP tool for consolidation processes, and is on the SAP Roadmap for the future.
- With the Syensqo consolidations tool implementation occurring in a later Release of the deployment comes additional time in the detailed design Release. The final decision on the Consolidation tool will not be made at this stage, and is not a key decision of this document.
- Simplification and synergies can be gained utilizing a fully integrated SAP Module, and it is assumed Group Reporting will be utilized unless there are major gaps in the business requirements.
Risk.
- Syensqo's financial statements are produced from the Consolidations tool. A risk resides in presenting inaccurate numbers. A key evaluation criteria will relate to the deployment approach which lowers this risk.
Design, Build and Test.
- The timing of when dedicated Consolidations resource will commence will be determined in line with the overall Deployment approach, taking into consideration transition to new a application, integration of design, and resource costs.
- Design and build in the initial Release\s will support parallel testing of S4HANA Group Consolidations with the existing BFC tool. This will contribute to de-risking the deployment.
The below section in blue text has been added into this KDD during the Detailed Design phase for the purpose of confirming the assumption from Conceptual Design
The below section is repeated from the above assumption for clear reference.
Tools:
- Group Reporting is the current/latest SAP tool for consolidation processes, and is on the SAP Roadmap for the future.
- With the Syensqo consolidations tool implementation occurring in a later Release of the deployment comes additional time in the detailed design Release. The final decision on the Consolidation tool will not be made at this stage, and is not a key decision of this document.
- Simplification and synergies can be gained utilizing a fully integrated SAP Module, and it is assumed Group Reporting will be utilized unless there are major gaps in the business requirements.
DETAILED DESIGN REVIEW: S/4HANA GROUP REPORTING FOR FINANCIAL CONSOLIDATION
Executive Summary:
A review was conducted during the detailed design phase from April to June 2025. This review included a Proof Of Concept (POC), partly within the EML sandbox, and also via documented supporting slides. The POC focused on determining whether there were any major gaps between Group Reporting functionality and Syensqo business requirements relating to financial consolidation activities for the organization.
Gap Analysis:
The outcome of the review is that there are no major gaps between Syensqo business requirements and Group Reporting (GR) functionality.
Refer below to the business requirements analysis section.
Benefit Summary:
In addition, Group Reporting has additional value adding benefits.
- One source of truth, with data tightly linked to the underlying financial documents, and the FI universal journal.
- Drill down capabilities, from financial results within GR to the underlying postings.
- Removal of the need to submit packages as is the case currently with BFC.
- The use of the “Versions” functionality to support various views of the financial results, including: IFRS, Underlying, RSB, additional currencies (USD) and simulation.
- The use of integrated master data (Profit Centre, Company, Custom Fields) to support GBU, Operating Segment, Market, Geographic/Regional view of financial results.
- The use of Transaction Types (flows) aligned with the underlying financial posting, with no human intervention, to assist with financial reporting like Cashflow.
- Improved Cashflow Reporting. automated and dynamic & can support the business requirement to produce the “Simplified Cashflow” by GBU.
- Group Reporting Data Collection (GRDC) - allows input of data from other SAP & non-SAP Systems. This will be utilized to bring data from the China and CUI (Controlled Unclassified Information) systems, and can also support integrating data for consolidation for any future acquisitions.
- Flexibility and currency valuation, allowing different currency valuation at a granular level (e.g. GL account).
- Support the comparison to Budget and Forecast.
- Integration with the Intercompany Matching & Reconciliation (ICMR) - for detailed reconciliation of Intercompany transactions.
- Inherit integration with Datasphere and SAP Analytics Cloud (SAC) for additional analysis and reporting capabilities.
- Support integration with S/4 Green Ledger (carbon accounting) based on use case assessment.
- Automation opportunities - for example the execution of the financial consolidation process at period end, group journal workflows.
Business Requirements Analysis:
Business Requirements | Details for the Current State | How this requirement is addressed in S/4HANA Group Reporting | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Reporting Data Category | Reporting Data are determined based on a combination of BFC dimension Category, Scope, Variant and Flow as shown below:
Syensqo consolidates in group currency EUR. Currently BFC does not have consolidation in additional Group Currency. | BFC Reporting Categories to be defined as Versions in Group Reporting. In SAP S/4HANA for Group Reporting, a version represents a specific data area within the consolidation database, used to differentiate between various sets of financial data, such as actual data, plan data, or different scenarios like restatements and simulations. It allows for the parallel processing of these different data sets within the same system The Version stacking feature will be used to optimize data and process. In Version stacking multiple extension versions can be linked to a single standard version, forming a "version stack," allowing for the analysis of different scenarios built on the same foundational data. Group Reporting Versions identified that cover existing business requirements are as follows:
Additional consideration.
The version can share master data, configuration and rules and at the same time it is possible to use different methods or rules for achieving the specific Consolidation effect, including elimination rules, validation rules or reporting rules in the specific version. | ||||||||||||||||||||||
Single Consolidation Group | Syensqo consolidates all legal entities from the perspective of top group SYENSQO. The intercompany transactions are eliminated completely irrespective of whether the partner is part of the GBU or region. There is no sub-consolidation performed in BFC. | Group Reporting can manage the existing consolidation approach\level performed in BFC. Following the current approach, SYENSQO as a Consolidation Group will be created in Group Reporting consisting of all the company codes. The intercompany transactions will be eliminated from group perspective at Company Code level. This is also the simplest approach to consolidation. At present, there is no requirement for Synesqo to perform sub-consolidation, and this will also be confirmed in Detailed Design. If required, Group Reporting can support sub-level consolidation, by utilizing Profit Centre to determine sub-levels. | ||||||||||||||||||||||
Additional View: Global Business Unit (GBU) Reporting | GBU is derived based on the BFC dimension called Activity. The dimension “Activity" is derived from the Business Area field in ECC based on naming convention and updated in the data package load for BFC. The “Data Package” is prepared in a csv file for upload in BFC. Example:
In BFC, the Activity is a manual input field which is derived from the naming convention of Business Area in ECC. |
Note: Each GBU is a roll-up of Profit Centres. Each Profit Centre belongs to single GBU | ||||||||||||||||||||||
Additional View: Operating Segment | Syensqo reports financials by Operating Segment which are derived by roll-up of GBU’s in BFC.
GBUs are roll-ups of BFC Activity that are captured in manual data packages | An operating segment is a component of an entity that engages in business activities from which it may earn revenues and incur expenses (including revenues and expenses relating to transactions with other components of the same entity) (IFRS). Syensqo has the following target operating segments:
| ||||||||||||||||||||||
Additional View: Regional Reporting | At Syensqo, the region is a grouping of company codes based on Country of incorporation. The financials by country or region are reported using dimension “Scope” by selecting relevant values. |
| ||||||||||||||||||||||
Sales Reporting for external result publication | Syensqo requires additional sales information for result publication.
|
| ||||||||||||||||||||||
Flow Type | Syensqo uses BFC Flow Type to classify and categorize financial transactions within its consolidation process. Flow types are further designated to be used for different set of accounts for example
Example of BFC Flows: Flow for all accounts/Mutual flows: F00 OPENING F99 CLOSING F15 VARIATION F50 RECLASS F60 OTHER VARIATION F70 SPECIAL OPERATIONS F80 FOR.EX. DIFF. F01 PERIMETER INFLOW F90 CHG METH. (NEW) F91 VAR INTEG RATE F98 PERIMETER OUTFLOW Flow for Fixed Assets- Gross Values: F20 INCREASE F30 DECREASE F33 ASSETS OUT OF SERVICE F34 ASSETS BROUGHT INTO SERVICE Flow for Fixed Assets- Depreciation and Impairment: F25 ALLOWANCE F36 WRITE BACK (NOT USED PROV.) F30 DECREASE F33 ASSETS OUT OF SERVICE F34 ASSETS BROUGHT INTO SERVICE Rest of flows: F05 NET INC N-1 F06 DIVID PAID F10 NET INCOME F24 ALLOWANCE F26 RESEARCH ALLOW F27 REV PREV MEASURES F28 NEW MEASURES F31 SHORT TERME TRANSFERT F32 ACTUALIZATION / CURRENCY F35 W.B. (USED PROV.) F37 WRITE BACK (NOT USED PROV.) F40 CHG CAP F51 EQ. COMP. FIN. INST F52 SHARE-BASED PAIEMENTS F53 ASSETS CREATED WITHIN GROUP F55 FAIR VALUE DIFF. F56 ACCRETION OF DISCOUNT F57 EFFECT OF HIGH INFLATION F61 RECYCLING CFH F89 CHG METH (FORMER) F92 PROFIT SHARE INCREASE | In Group Reporting Subitems are used to classify and categorize financial transactions by providing further breakdown of values recorded on financial statement items / accounts. The breakdown is categorized by transaction types or functional areas commonly known as sub-assignments.
Group Reporting offers Breakdown Category to classify transaction type/functional areas needed for financial statement (FS) items/account. It determines which sub-assignments must be recorded for each FS item. Example of Breakdown category that can be configured in the system are
Below is a list of pre-delivered Transaction Types in Group Reporting that as an example can be adapted or additional transaction types created to meet consolidation and reporting requirements. 900 Opening balance 901 Incoming units 902 Cons Mthd Chg(Old) 903 Cons Mthd Chg(New) 904 EquityMth Rate Chg 906 Dividends 909 Change in accounting policies 915 Net variation 920 Increase/Purchase 925 Increase in depreciation 930 Decrease /Disposal 935 Decrease in depreciation 940 Capital increase/decrease 950 Reclassification 955 Fair Value 970 Internal Merger 980 Currency translation adjustment 992 Change in ownership interest 998 Outgoing unit 9R0 Opening Restatement Further, transaction types and functional areas are supported for hierarchy set-up to enable movements report for example Fixed Assets Movements Report. | ||||||||||||||||||||||
Finance Integration – Company Codes | BFC Reporting Units are not automatically integrated with the ECC system. The integration is done manually while preparing the csv file called data package. The data package has some mandatory and optional dimensions. Example: Mandatory BFC dimensions:
Optional BFC dimension:
| The Company Codes in Finance will be integrated as Consolidation Units in Group Reporting for seamless data integration. The integration takes place in source with Core Consolidation Fields populated for every transactional line item in Universal Ledger/table ACDOCA. The core consolidation fields are:
The core consolidation fields in the finance ledger creates a tight and seamless integration layer which is used for pulling data via release mechanism into the consolidation database /table ACDOCU. Example of Consolidation Data base:
| ||||||||||||||||||||||
Finance Integration – Chart of Accounts | Syensqo has a disparate chart of accounts between accounting and consolidation. Operating GL chart of account is mapped to BFC Reporting items and uploaded in BFC via data package. | Group Reporting will use the same Chart of Account as General Ledger Operating Chart of Account. The Operational Chart of Accounts will be mapped as a Financial Statement (FS) item on one to one basis in Group Reporting. | ||||||||||||||||||||||
Finance Integration – Additional Master Data | Additional Master Data for reporting are created as custom fields in BFC for data loading and reporting. | Group Reporting can integrate and read additional fields from S/4HANA accounting for reporting. For example:
Note: Additional Custom fields can be set up to meet consolidation and reporting requirements to be determined in detail design phase. | ||||||||||||||||||||||
Finance Integration – Drilldown to GL Document | Drill down from BFC to ECC is not possible. | Group Reporting provides functionality for analysis and processing with full drilldown to source data at its origin. Note: Drill-down to source will not be available in other S/4 instances for example China and CUI systems, however common charts of account and system design will still enable easy access to detailed information in China and CUI systems. | ||||||||||||||||||||||
Finance Integration – Intercompany Matching and Reconciliation (ICMR) | No integration to BFC available | S/4HANA Intercompany Matching and Reconciliation (ICMR) a built-in and integrated solution will be used to automate and streamline the intercompany matching and reconciliation process. It supports real-time matching and reconciliation of financial data, eliminating the need for separate load processes. ICMR can also connect to separate S/4HANA China and CUI systems. | ||||||||||||||||||||||
Integration with separate ERP System – China / CUI | China is not in a separate system. Although BFC could manage this via the existing manual data package loads. | SAP Group Reporting Data Collection (GRDC) App will be used to integrate with China/CUI instances of S/4 system for collection of data. GRDC is specifically designed to integrate with SAP S/4HANA for Group Reporting , allowing for seamless data transfer and consolidation. | ||||||||||||||||||||||
Cash Flow | BFC used cash flow codes (CFxxxx) and rules based on account and flow to produce automated cash flow reports with some manual adjustments. BFC produce below two cash flow reports :
| Group Reporting offers functionalities that can help develop Cash Flow Reporting through “Reporting Rules”. These include a range of mathematical operators to instruct the system on how to compile data for each line in the cash flow statement. Group Reporting's reporting rules provided extensive customization capabilities, including account movements (transaction types/functional areas), journal entries (document types), consolidation units and reverse sign indicators among others. This solution can be used to prepare multiple versions of fully automated cash flow reports in Group Reporting.
The system flexibility can be built to adjust cash flow line items by manual journal entries. The report can drill-down to underlying FS items and transaction types aiding in understanding the composition of balance and reconciliation. The cash flow reports can be executed for Syensqo, Operating Segments, GBU’s and to the lowest unit for example Consolidation Unit/Company codes or Profit Centre. In addition, validation rules/controls can be built to ensure accuracy and consistency of cash flow reporting using Group Reporting Validation Rules. | ||||||||||||||||||||||
Currency Translation | Syensqo used BFC currency translation features to translate reported local currency into EUR and re-state for RSB versions. | Group Reporting has standard currency translation features using S/4HANA exchange rate table to translate trial balance of entities as per configurable translation rules and methods. Translation Rules can be set-up for FS items for example
Translation Method can be configured to:
| ||||||||||||||||||||||
Audit ID and Ledger Dimension | BFC uses Audit ID to identify the source of data stored in the consolidation database for example:
Audit ID also enable to build control such as
There are approx. 175 Audit IDs set-up in BFC. Example:
| Group Reporting uses Posting Level and Document Type to identify source of data and their purpose within the consolidation process. Posting level enables to distinguish posting entry types and select data accordingly. They are not user-defined, but rather built-in to the solution.
Document types identify the type and source of data. For example, reported data is stored on different document types than elimination data. Document types have various attributes assigned, including data source for example manual or automatic posting, file upload or API, deferred income tax handling, automatic reversal and currencies to be used in posting. Document types are always assigned to a posting level thus document type in conjunction with posting level help identify source and type of data. Document type is user defined, however SAP also delivers some pre-defined document type for our use. Example:
| ||||||||||||||||||||||
Manual Journals | BFC uses dimension “Ledger” to control and classify manual journal entries. Manual Journal entries (for example top entries) are copied, adjusted and posted using the BFC ledger feature. Currently there is no workflow/approval process for manual journals in BFC. The manager needs to be intimated offline for review when a journal is posted in BFC. | Group Reporting allows manual journal positing by document type (equivalent of ledger in BFC) which can be configured to track and manage financial data for consolidation purposes. Document Type, a familiar concept in accounting, can be designed for easy identification as manual journals, classification of postings and checks and control can be built on it. Manual Group Journal can be submitted via
Reporting on Manual Journal via Display Group Journal Entries App - This is a report to display a list of documents based on parameters such as consolidation units/groups and the fiscal year/period. Group Reporting also provides Standard Workflow which can be configured for group manual journal entries to automate review and approval (or rejection) of manual journals. | ||||||||||||||||||||||
Data Package | There is no automatic system integration between BFC and ECC systems. The data for ECC or non ECC entities are mapped and prepared outside the system in a csv file data package and loaded into the BFC system. Similarly if there is new acquisition made, the trial balance is prepared in csv file and loaded via Data Package in BFC for consolidation. | Group Reporting is fully integrated within the S/4HANA platform. This integration allows for real-time extraction of accounting journals from S/4HANA finance system. Group Reporting is closely connected with the Group Reporting Data Collection (GRDC) tool that facilitates the collection of data from various sources, including both SAP and non-SAP systems for use in group reporting and consolidation processes.
| ||||||||||||||||||||||
Inter Co Eliminations | BFC uses Audit Ids for intercompany elimination postings. Example:
| Group Reporting provides a reclassification function for interunit elimination. Using the reclassification function, automatic elimination tasks will be created for intercompany business transactions. Following is an example of elimination tasks each with specific method/rule and unique document type will be created for inter company elimination
The above broader category can be further split by group of business transactions. For example elimination of intercompany balance sheets can be split into the following sub-group with each group having its own elimination tasks.
| ||||||||||||||||||||||
Inter Co Matching and Reconciliation | Intercompany matching and reconciliation is performed in the source ECC system. Consolidated elimination mismatch report is available in BFC. | Group Reporting offers pre-delivered “Reporting Item” solutions which can be configured for Intercompany reconciliation reports. In addition, a fully integrated ICMR (Inter Company Matching & Reconciliation) tool can be used not only for matching and reconciliation but also for elimination posting in Group Reporting. | ||||||||||||||||||||||
Consolidation of Investment – Subsidiary, associate | BFC uses Audit ID to perform elimination of investment in subsidiaries and related equity. | Group Reporting offers two design options for consolidation of investment. Option 1: Rule based: The system performs C/I calculation and postings by processing a sequence of reclassification steps defined in reclassification methods. Option 2: Activity based: The system performs C/I calculation and postings by processing one automatic posting task of category Consolidation of Investments. The behavior of the task is influenced by configuration settings which are predefined and delivered by SAP. Activity Based Consolidation of Investment provides automated posting for:
Each Consolidation Units are assigned a Consolidation Method based on IFRS consolidation requirement. Available methods are:
| ||||||||||||||||||||||
Balance Carry forward | The balance carry forward is performed in BFC using which creates opening balance for balance sheet account on opening flow F00. | Group Reporting offers standard Balance Carryforward Task to pull the balances of relevant financial statement (FS) items from the previous financial year to the current financial year. The system records these balances as opening balances on specified transaction type in period 00. The balances are carried forward based on the FS item type of account:
In addition, it is also possible to define a source document type and a destination document for a specific time frame as a result closing balances at year-end are carried forward from the source document type to the destination document type. | ||||||||||||||||||||||
Profit in Stock Elimination (PISE) | Stock Margin custom program executed by shared service team is used in BFC to remove profit from intercompany stock. | Group Reporting has following options: Option 1: Directly source group valuation ledger as a basis for financial group statements
Option 2: Keep legal valuation as consolidation ledger and use group valuation to calculate elimination postings.
Option 3: As this area is still evolving under future innovation further solution may be possible in future releases such as extension version/reference version/stack. The options require further study and analysis during the detailed design phase. *SAP GRDC stands for SAP Group Reporting Data Collection which is part of SAPs product strategy for consolidation and may require additional licenses. | ||||||||||||||||||||||
Excel Retrieve | Integrated Excel retrieve is available in BFC | Integrated Excel retrieve will be available with Group Reporting. | ||||||||||||||||||||||
Blocking Controls and Validation Rules | BFC has blocking controls on specific accounts for example provision accounts where only specific flows are allowed and one cannot post with non-allowed flow. | Line Item Validation :Group Reporting has Breakdown Category Check on account which defines whether transaction type (flows), functional area and trading partner are mandatory and within the list of permissible transaction types. This is checked during postings in group reporting and error is issued if not complied. In addition, validation will be built in S/4HANA on a specific set of GL accounts with a permissible list to control postings of transaction types/functional areas. In addition to Line Item Validation, Group Reporting also offers validation rules at different postings levels. Validation Rule for Entity Data (up to posting level 10)Validation Rule for Consolidated Data (up to posting level 30)Example of validation rule that can be set up:
| ||||||||||||||||||||||
Tax Reporting | Tax Reporting is currently completed utilising BFC to bring data together. Source information comes from the ECC systems. Some calculations are performed in Excel. Country Finance reps submit data. | Options have been identified for Tax Reporting. Options will be reviewed and assessed as part of the tax sub stream. Tax Reporting design is separate to the Group Reporting tool decision. |
End of Section added in Detailed Design.
Constraints
BFC product support by SAP ends in 2030. It is assumed SAP Group Reporting or alternative Consolidations tool will be deployed prior to this date.
Impacts
Below are the major impacts on the decision are on the following:
Integration impacts: Interfacing or data loading into the consolidation system. There is an impact whether data is flowing into BFC or new Consolidation tool.
- Aligned with the deployment decision, loading data packages into BFC from the source system, being PF1, WP1, or S4HANA, will continue.
Data Conversion:Timing and complexity of data conversion.
- Aligned with the deployment decision, historical data loads will occur in the later Release. Conversion will be a one off activity upon deployment.
Reporting: Reports currently being produced from BFC.
- Aligned with the deployment decision, existing Reports will continue to be produced from BFC until the new Consolidation tool is implemented in the later Release.
Business Rules
- Existing BFC Rules will continue.
- S/4HANA business rules relevant at this point in time will be largely governed by the Enterprise Structure Definition. More specific Consolidation Rules will come in detailed design.
Options considered
Option A: Deferred Deployment
Continue with BFC in the initial Releases and deploy the new Consolidation tool in the later Release
Orange Box and Arrows are new / added, the rest remains as is.
Key Points:
- System: BFC will stay in place until the last Release of the deployment.
- IC Eliminations: All existing intercompany elimination, reporting and reconciliation processes remain.
- Reporting: Existing Reports will continue from BFC.
- Existing ECC entities: will continue to integrate with BFC in the same manner.
- Entities transitioning to S4HANA: will transfer data in the same manner as the ECC system entities. Data load output templates will remain largely the same, the data to fill the template will come from S4HANA. Mapping of data will be required and tested.
Option B: Upfront Deployment
Implement the new Consolidation Tool and discontinue BFC in Release 1 of the Deployment.
Orange text Boxes show what will change with an upfront deployment.
Key Points:
- System: BFC will be replaced by the new consolidation tool in the initial Deployment Release.
- Intercompany Eliminations: All existing intercompany elimination will need to be designed and built in the new tool. Existing ECC entities will need to adopt the new rules to integrate with the new tool.
- Reporting: Reports from BFC will need to be replaced with new S4HANA equivalents.
- Existing ECC entities: will need to load data into the new consolidation tool, new templates and processes need to be developed. Additional training also required for the interim.
- Entities transition to S4HANA: Data from S4HANA will automatically be consumed by the new Consolidation tool.
Evaluation
| Criteria | Option A - Defer Deployment | Option B - Upfront Deployment |
|---|---|---|
Risk | Pro Low Risk. Existing tool continued to be utilized. Loading from the existing source system not initially transferring to S4HANA will continue as is. Data from the entities transitioning to S4HANA will follow the same\existing approach to load into BFC. | Con Higher Risk approach with high likelihood of business disruption for the initial closing periods. Early deployment carries a higher likelihood of inaccurate data feeding into Consolidations and presenting in the Syensqo financial statements. |
Stabilization at Deployment | Pro Most of the new processes\modules have an impact on the Consolidated result. Allowing time for the initial Release\s to stabilise will result in more accurate data being automatically consumed by Consolidation, and leading to more accurate financials. | Con Most of the new processes\modules have an impact on the Consolidated result. Upfront deployment will have higher probability on process and data issues from integrated process feeding into the final consolidated figures. |
Simplicity | Pro Data Loads: Existing Data load process to continue for ECC entities that transition in later Release/s. Consolidation & Intercompany Elimination: rules to remain and continue for the transition period. Reporting: will continue for both ECC and S4HANA Entities Con Data Loads: Data loads for tranisitioning entities to be developed, but to follow existing processes | Con Data Loads: New Process will need to be developed to integrate data from the ECC systems into the new Consolidations Tool. Consolidation & Intercompany Elimination: Consolidation & Elimination rules to be developed for ECC systems during the transition period. Reporting: New Reports will need to be built in Release 1. The above mentioned will require addition training for the transition period. |
Data Conversion Ease | Pro Easier data conversation taking the historical data at one point in time. A later deployment allows more time to manage\test\rehearse the historical data conversion. | Con Data conversion required earlier. Less opportunity to test, rehearse, run in parallel. |
Testing - Additional Parallel Testing Option | Pro Allows the possibility of more robust parallel testing utilising actual data. Parallel testing entails testing consolidated results in the new system against the like for like results in BFC. This is relevant for the base consolidation as well as reports. | Con Parallel Testing is not an Option, continue with Conventional Testing (Eg. Unit, Integration & User Acceptance Testing) |
| Benefits Realisation | Con Benefits from the new Consolidation Tool to be realised at a later stage. | Pro Benefits (eg. integrated data, streamlined processes) from the new Consolidation Tool to be realised earlier. |
| Criteria | Weighting | Option A Deferred Deployment | Option B Upfront Deployment |
|---|---|---|---|
| Risk | VH | Low | High |
| Stabilization at Deployment | H | Medium | Low |
| Simplicity | H | High | Low |
| Data Conversion Ease | H | Medium | Low |
| Testing - Additional Parallel Testing Option | M | High | Low |
| Benefits Realisation Timing (Earlier Vs Later) | H | Low | High |
| Overall Rating | High | Low |
Preferred Option
Option A - Deferred Deployment is the recommended approach.
Option A is a lower risk option for reporting financial results for the organisation, along with an easier transition period. Although the benefits coming from the new Consolidation system are deferred, they will still be realised, albeit at later date.
See also
Change log
Workflow history
| Title | Last Updated By | Updated | Status | |
|---|---|---|---|---|
| There are no pages at the moment. | ||||


