manages the change board, leads issue resolution, SLA exception resolution, and financial close compliance.
IT Application Owner: The IT Application Owner ensures smooth running of the system, ownership of the Support Model, upgrades and improvement execution, issue resolution and testing, maintenance of SLAs, and reporting performance to other teams
Finance Processing: The responsibilities include initiating intercompany transactions, compliance, reference data setup, assisting with issue resolution, and testing by shared ser vice centers, accounting units, and subsidiaries.
IT Support Team: IT Support Team’s responsibilities include issue tracking and resolution, performance monitoring, system tuning, integration, and interface management. This element of the organization could be delivered as an offshored managed service.
Other IT Support: This can include providing assistance with issue resolution, upgrades, and testing.
Pain Point: Transaction values are expected to be very high and there can be realized gains or losses even with intercompany transactions (for example, missed hedging settlement dates). It is also likely that this application will feed directly into group reporting. Consequently, the entire support network must agree to the priority given to issue resolution and blackout dates for changes.
There are two basic assumptions that must be acknowledged. The first, as we stated previously, is that no off-the-shelf application can satisfy a multi-national company’s unique process, organization, and information requirements, so a custom solution is required. The second is that because reconciliation and settlement is a basic accounting function, performed by all multi-nationals, the objective is to have accurate, efficient processing at low cost with no product or strategically sensitive information being shared. With these as givens, technology must be developed that effectively, economically, and discretely fulfills specific business requirements.
At a high level, there are two key non-technology questions to be decided that will require technology solutions:
1. How will the solution be delivered?
2. How do we accommodate the multiple subsidiary systems and data formats?
The delivery options that follow will help determine the highlevel design and the full-life cost of the solution:
- Organization-Specific: Invest in a custom solution that is specific to the needs of the organization and precisely delivers against the exact requirements, but with an initial development cost and ongoing support.
- Generic Model: Recognise that there are other organizations facing similar challenges and create a joint venture to select a solution integrator to develop a generic solution with shared development and ownership costs.
- SaaS Model: Convince a solution integrator to develop a generic solution that can be offered via the cloud to multiple clients (with the appropriate security) without the ownership risk or investment, effectively outsourcing the operation.
The approach for normalizing subsidiary data and extraction to avoid secondary processing includes the following, which will help determine the implementation and support costs of the solution:
1. The technology selected for this solution (Java, HANA, Oracle, etc.) does not need to match the current or future corporate IT strategy, but does need to match the capabilities of the subsidiaries within each organization.
2. Subsidiaries may use alternate ERP systems or previous releases of ‘core’ systems. The solution should be able to overcome the need for widespread system and data rationalization but should support that change, if selected.
Pain Point: It is unlikely that a single method of sharing transactions will suit all subsidiaries due to development plans, system and data constraints, and the like. Consequently, three different methods are recommended to create options that should reduce resistance to adoption:
1. Manual entry directly into the application
2. Semi-automatic transaction extract and posting to a mailbox
3. Fully automated extract and data load with controls and exception reporting
3. Intercompany vendor and customer IDs may also be different among subsidiaries, which may require either:
a. A prerequisite Master Data Management project to establish and maintain standard intercompany vendor IDs in all subsidiaries or
b. Include mapping tables to be maintained in each subsidiary.
Regardless of the above variables, because the solution requires global access, we believe a resilient web or cloud-based solution would be most appropriate. Such a solution would require three layers:
Application Layer: Including security, user profiles, transaction processing and controls, reporting, and so forth
Web Layer: Including GUI, security, communications, interface processing, and controls
Database Layer: Including data management, data integrity and other controls, as well as reporting
Data and Reporting Requirements
Because the data integrity and accurate reporting are at the crux of reconciliation and settlement, and because they are the primary drivers for the business process and technology design, as well as organization roles and responsibilities, information requirements should be established at the start of the design stage and reviewed throughout the implementation.
The data requirements include:
- Intercompany vendor and customer settlement bank details
- Intercompany transactions
- Payment currency and terms The reporting requirements should be assessed early to ensure most can be extracted as a by-product of the design without additional effort:
- Accounting integrity and materiality
- Settlement format and rules
- Treasury/cash planning and operations
- Regulatory reporting
- Liquidity reporting
- Process and data compliance
Pain Point: Failure to involve all information providers and users and failure to agree on requirements in the design stages will result in expensive rework and reimplementation at a later date.
The Target Operating Model is your basic schematic for your solution. But how do you implement it for your organization? A program of this magnitude will require the involvement of multiple stakeholders and changes to business processes and roles. To launch your solution effectively, you need a roadmap that details key steps and the people and teams involved.
Before considering the Target Operating Model, a small senior team should be convened to identify the fundamental shape of the proposed program. It should address:
- Top-level sponsorship with an ongoing commitment to success
- The program goals, scope, quality regime, and success criteria and aligning it with corporate strategy
- The appointment of the responsible stakeholder and Program Board
- The production of a program brief outlining the objectives, benefits, risks, indicative costs, and timetable
- An assessment of the current status and the implications of doing nothing, plus a comparison with the future vision
- Establishment of an independent review process
- A plan to get approval to proceed
With these basics established, you then need to dig deeper and make several strategic decisions before the program roadmap can be defined in detail. These decisions include:
Internal or Hosted Solution:The solution is going to operate in a similar way to UK BACS, processing payments between corporate entities. Would you want a similar solution for managing your organization’s intercompany payments? What is your organization’s risk response for outsourcing payment processes, especially to processes that will transact billions annually?
Internal or Outsourced Development: Do you have a development team with scope in the near future to develop a solution? Do you have the organizational capacity to lead and staff a project of this magnitude?
Availability of Existing Functionality: Some components required for the reconciliation and settlement of intercompany transactions may already be available in the organization, such as auto-reconciliation tools like Chesapeake and Blackline or Treasury and payment applications. These assets can be utilized to perform specific functions and can be integrated into an overall solution.
Once these major decisions have been made, your senior team should appoint a program management team to define the program as shown in the roadmap below.
Pain Point: There will be a step change in knowledge, skills and experience required when the program moves from Identifying to Defining. It is a common error for inexperienced program teams to underestimate the resource requirements as well as the level of detail required in the Target Operating Model and in the project plan. Failure to address the full project lifecycle and prepare a detailed vision of the future will result in unexpected over-runs, cost increases and solution gaps.
One option is to hire a Solution Integrator with experience of both the business process and largescale development and business change programs.