Introduction

Do!

Do establish unambiguous vendor accountability

Your vendor must play a substantial role in the implementation, with significant responsibilities for the expected results. We recommend you to be as exhaustive as possible when preparing the final vendor contract for the implementation of the acquired system. Obtain clarity on at least the following topics:

• Applications and systems acquired, plotted on your financial accounting and reporting E2E chain.
• Scope of implementation services provided by vendor team. Responsibilities on:
▲ Project Management of the technical implementation including planning, progress reporting, budgeting and resourcing vendor employees/ consultants.
▲Functional and technical management during implementation.
▲Functional and technical architecture design.
▲Data integration architecture design.
▲Integrations across the financial accounting and reporting chain in scope.
▲Configuration of the system and applications.
▲Implementation of integrations.
▲Data migration and tooling supporting data migration.
▲Testing and tooling supporting testing across the various stages.
▲Performance and security of the technical solutions.
▲Environment set-up for development, acceptance & testing and production.
▲Hypercare: Functional and technical management after implementation including handover to client’s teams.

Do engage your stakeholders in the benefits case

We recommend sharing a clear vision on the future of your finance function, as part of the companies’ mission as a (global) financial services institution. The vision must be extended with the strategic objectives of your companies’ finance function, cascaded from the enterprise-wide strategic objectives.
Provide your stakeholders with the rationale of the transformation before starting it. From the perspective of the vision and strategic objectives:

• the problem statement with underlying pain points and inefficiencies.
• the foreseen steps to take solving the problems including milestones.
• the key guiding principles as a response to the problem statement.

They must be shared and promoted intensively. As part of a campaign, kicked off by the Group CFO. This message, and the need for transformation, must be reinforced by an explicit business case with concrete business change drivers, addressing the benefits of standardization and one harmonized IT landscape for Finance, and Accounting & Reporting specifically. Benefits realization must be measured from the transformation phase up to the ending period as defined in your benefits case. Results must be shared with all stakeholders.

Do walk the talk

We recommend senior management within the Finance domain to involve all stakeholders in the transformation by ongoing communication and information sharing. This requires more than an obligatory newsletter or pictures of celebrating people at the intranet. Keep addressing the objectives of the transformation and the underlying arguments, its benefits and the connecting deliverables, both realized as well as upcoming, and the resulting changes effecting the day-to-day operations of the employees across the E2E financial accounting & reporting chain. Keep emphasizing on what is expected from all stakeholders for a successful transformation.

For example, if the transformation aims to enable daily accounting, senior management must ensure that the stakeholders within the financial accounting & reporting chain do understand the benefits of daily accounting as well as the required changes enabling daily accounting.

The stakeholders directly affected by the new systems and changing processes in their daily activities must be guided through these changes. We recommend organising process playback sessions providing stakeholders the opportunity to challenge process design and initial build of the system where needed.

Do define requirements before defining solutions

Your vendor – depending on who that might be of course – might stress that you’ve bought a best practice based off-the-shelf system that enforces the desired standardization. Hence, the entire exercise of requirements gathering and definition is not needed and even not wanted.

We strongly disagree. Yes, it’s important that stakeholders do realize what an off-the-shelf system means and why it has been acquired. And yes, it’s important to avoid getting bogged down in a solution overflowing with customization. But it is naive and unwanted that requirements gathering can be ignored.

Requirements gathering – business as well as data – creates a common understanding of the detailed needs for an effective and streamlined process and set of functionalities. It forces stakeholders to be explicit on the functionalities and features required. Only than the effect of functionalities that will not be enabled or enabled differently by the new system will become transparent. Only then can stakeholders proactively manage the impact of the required changes.

Do master data management

Effective master data management is crucial for a smooth implementation of the system. You must mitigate – from the start of the implementation – the risk that Chart of Accounts (‘CoA’), dimensions, finance data model, mapping tables, and reference data (value) tables, are designed too late or too loosely. Failure in proper master data management will cause upstream issues when migrating data to the new systems.

We recommend applying a prototype accounting engine to test CoA design including dimensions, and mapping and reference data value tables by simulating the posting in the ledgers. As such, incomplete and incorrect design, and failing mapping tables and reference data value tables have been detected before data migration and testing start

Don’t!

Don’t preserve systems for isolated exceptions

Your benefits case will partly be sustained by the disposal of systems being replaced by the new IT landscape. For sure there will be arguments not to switch off a system or application because ‘Marie’ or ‘Pete’ is using that system for their calculations or data enrichments as part of the financial accounting and reporting chain. Don’t provide that option. Apply the new landscape to sustain these specific functionalities, or even better, redesign your process so these specific functionalities will be covered in the standardized process.

Don’t accept your vendor saying ‘no’

Most vendors aren’t keen on deviating from their standard, on-the-shelf, solutions. They keep repeating the message that you’ve bought on-the-shelf products to enforce standardization and applying best practices. Therefore, requirements gathering is irrelevant. It’s just about adopting to the solutions.

That’s partly true. Yes, in most cases, the transformation must enforce standardization. But there is definitely room for customization. And in most cases, it might not even be customization but enrichment or further development of the solution bought. So, keep stressing on vendor flexibility, of course in line with your fit-to-standard strategy and not jeopardizing the maintainability of the system.

Don’t preserve systems for isolated exceptions

Your benefits case will partly be sustained by the disposal of systems being replaced by the new IT landscape. For sure there will be arguments not to switch off a system or application because ‘Marie’ or ‘Pete’ is using that system for their calculations or data enrichments as part of the financial accounting and reporting chain. Don’t provide that option. Apply the new landscape to sustain these specific functionalities, or even better, redesign your process so these specific functionalities will be covered in the standardized process.

Don’t start without a clear and approved target architecture

Start with a clear target architecture, substantiated with concrete, transparent, and enterprise-wide assessments of the as-is architecture, the upcoming market and regulatory developments, and material pain points. The target architecture must be confirmed by the vendor as part of the vendor selection process.

At the start of the implementation/build, the vendor must translate the target architecture into a solution based functional design, as a translation of your initial functional design, and a technical design or technical solution architecture. The Functional Design must be prepared by the vendor’s architects and translates the initial design into process-level and functional behaviour that the vendor’s solutions must support. The technical design translates the functional design into an implementable solution architecture and build specification.

We recommend delivering your initial functional design in a set of design packages per component (i.e. CoA, dimensions and hierarchy, data model and master data management processes, target operating model, controls and exception handling, integration and interfacing, and security, identity & access management).

Don’t test before operating model readiness

Preferably functional acceptance and user acceptance testing must be executed by the employees that fulfil the roles in the solution supporting process of the test. For most effective as well as efficient testing, the respective employees must be aware of the redesigned processes and workflows and roles and responsibilities and the underlying changes.

We recommend having the TOM (Target Operating Model) documentation and the process, control and workflow documentation ready and being consumed by the testers, before starting testing. As such, the risk that the testers will apply the ‘old’ workflows and technical features as reference when testing the new solutions can be mitigated.

Final thoughts

How can Mount help you