At ProcurePro we have implemented a number of financial systems (FinSys) for our mid-sized clients as either a stand-alone system or combined with other modules in an enterprise resource planning system (ERP). Last year we wrote an article on Implementing an ERP System – 10 Things to Consider First which we hope you found useful. An ERP system includes multiple systems such as Finance, HR, Payroll, Inventory, Purchasing etc. For this particular article let’s narrow that down to just the implementation of a financial system … how hard can that be? In our experience, if your organization does not do the appropriate preparation ahead of time, it can be a very long, arduous process that may end up costing your organization thousands in time and money!
So, you’ve chosen your financial system, how can you prepare for the implementation? What are the things you and your team must do before the implementation team even hits the ground … well, let us tell you!
1. Establish the Executive Sponsor & Their Role
The Executive Sponsor should be a senior financial executive, ideally the Chief Financial Officer (CFO). The more senior the more likely they will be able to prioritize project activities over other conflicting priorities within the organization. The Executive Sponsor needs to be able to commit their time to the project and will be the person who updates, gains buy-in and support from the C-level executives within the company. The Executive Sponsor should be the final decision maker and can ensure that the project and Core team remain on track and can adjust other priorities and activities of the team members if needed. For the sake of the implementation, we recommend that your Core team members report to this individual.
2. Assign or hire a dedicated Project Manager
Someone MUST be assigned and dedicated to lead the overall project for your company and to liaise with the vendor. This can be someone who has a project management background from your finance or IT teams, if you have one. If not, hire a Project Manager (PM) from a company who has sufficient and proven experience implementing Finance Systems such as ProcurePro. The PM should report directly to the Executive Sponsor, oversee the entire project, assist in coordinating company resources, actions, priorities, identifying risks, issues and documenting decisions. They should also act as the primary contact and advocate for your company with the vendor.
3. Assign a Business Lead
The Business Lead, reports directly to the Executive Sponsor, works very closely with the Project Manager (PM) and the Core Team. This resource is ideally dedicated to the project, is a member of and understands the Finance function in detail and acts as a centralized, hands-on leadership resource for the Core Team. The PM act as the eyes and ears of the Executive Sponsor and has a strategic view of the project and objectives. Often, they are called upon to recommend how best to balance priorities for the overall success of the project and ultimately the finance system implementation.
4. Establish the Core Team & Their Roles
This team should be comprised of resources who are responsible for various functions within your organization such as Finance, Procurement, Communications and or IT and are likely managers or subject matter experts. This is the team that will be on the ground meeting each day, defining requirements, testing, training and working closely with the vendor’s implementation team. They themselves, may be subject matter experts but they may also determine who the subject matter experts are in their respective departments or functional areas and delegate tasks when necessary. This team needs to be dedicated to the project to ensure it’s success, they should not be part-time or remote (if possible) and should not be pulled away from the project for other conflicting priorities, as this will cause unnecessary stress and constraint on the resource, cause delays in the project and significantly put implementation at risk. If possible, your organization should consider putting dedicated resources onto the project full-time and backfilling their roles for the duration of the project through to Go Live. The Executive Sponsor, Project Manager and Business Lead are all members of the Core Team. It is critical to understand, if you overwhelm your Core team, the schedule will ultimately be delayed, add significant cost to the project and your team will absolutely burnout, putting the project at significant risk.
Another important core team consideration is hiring an experienced technical administrator or business systems analyst, for the new financial system. You will quickly see the benefit of having a technical resource who can take the lead in defining roles and responsibilities, workflows and act as a technical lead to manage issues with the vendor, perform additional configuration and assist in data migration.
5. Define Your Requirements:
It is strongly advised that you go through the process of defining your requirements BEFORE selecting the vendor solution. Fortunately, if you haven’t, there’s still time. In order for implementation to go smoothly you need to know what your organization needs, the requirements, for your financial system and the functionality it should have. Your requirements should be clear, they should be documented, and you should have alignment and approval across your Core team and Sponsor. It’s a good practice to categorize your requirements as must-have, nice-to-have and future requirements. Once documented, your requirements should only be updated with clarification points and shared with the Core team and the vendor. Additionally, have your Core team start documenting their workflow stories i.e., how do you recognize revenue, how are your contracts handled today and what are your expectations of the system. Without clear requirements and workflows, you will spend time repeating yourself in meetings with the supplier, there may be confusion and competing priorities among the Core team as to what you need, your requirements may be left to guesswork, misinterpreted, implemented incorrectly by the vendor or worst of all, it may not have the “must have” functionality that is critical to your business.
6. Negotiating the Vendor’s Time & Resources
In a digital world it seems everyone is available remotely and most vendors will push for a large portion of the implementation to be completed offsite by their team. For some organizations with very standard, straight-forward, out-of-the-box requirements (little to no customization or configuration) this may work well. If you have unique requirements that will need configuration or customization, having the vendor on-site, as much as practical, may help ensure greater success. Minimally, it may be key to have the vendor on-site for the first phase, personalization; walking them through and helping them understand your requirements, walk-through the initial vendor configuration, seeing and testing their understanding of those requirements in the new financial system.
A key resource to ensure your success from the vendor side is a hands-on Project Manager or Functional Lead who would take over all accountability for the implementation of the solution. Avoid scenarios where there are multiple vendor functional leads, and it is left to the client or client’s Project Manager to coordinate the interaction among the vendor functional leads. This will result in an inappropriate reliance on the client, an inconsistent solution and ultimately delays in the personalization phase. There is always interaction and dependencies among system functionality, and it requires a strong vendor lead to drive overall consistency, quality and adherence to timelines. The vendor may suggest their PM take on this coordination role however, often the PM does not understand the technical system configuration, or dependencies at a detailed design level. If the responsibility is left to the PM, they must be hands on and have a sufficient knowledge of the technical design.
Watch for signs that the vendor lead is not understanding requirements and escalate as early as possible. It will be easier to escalate if you have documented requirements as recommended above and track any concerns as they arise. The vendor will resist resource changes but keep pressing if necessary. It will save unnecessary costs and delays in the long run.
7. Things to Prepare before the Vendor Arrives:
If you prepare the following information before the vendor starts the implementation, you will save time and energy and ensure your implementation happens on time and on budget. Core teams can lead the gathering of the information and ensure its correct up front so you’re ready to kick-off on day one.
Chart of Accounts (COA) Structure: Define the new structure of General Ledger accounts that your company has identified for recording transactions in the new system.
Subsidiary Structure: Collect all parent and subsidiary legal names, addresses, business numbers, functional currencies, fiscal and tax year ends and hierarchy.
Tax Requirements: Identify and document all sales and purchase tax jurisdictions, codes/rates and remittance agencies.
Regulatory Requirements: Identify all regulatory requirements that must be complied with for each geography the system will be used in such as Financial, Privacy etc.
User Information: Determine who the users of the system will be and collect a complete list of usernames, email, current title, and organizational reporting structure. This will used for role definition, training and user acceptance test planning.
User Roles: Based on user information gathered above, begin to define a set of expected user roles. This can be done independently of how these roles will be implemented. Conceptually define clerks; managers/approvers; tax specialists; view & report; etc.
Controls: Define where you will require transaction approvals (i.e., PO setup, bill payment, journal entry, etc. and separation of duties). Having this up front will support setup of approval flows and roles.
Data Cleanup: Data cleanup will take longer than you expect. Study your data, identify cleanup areas and begin the cleanup as soon as practically possible. Avoid “garbage in, garbage out”. Since you may not have made decisions about the scope of your data migration history, focus on current transactional data (i.e. new AR and AP data etc.)
Data Migration: Data migration will take longer than you expect. Review existing customer and vendor lists with a focus on customers and vendors you have had business with in the last two to three years. Decide whether you will create a central master list for all subsidiaries to use or maintain lists by subsidiary. Collect name, ship to/bill to addresses, sale tax numbers, currencies, contacts etc.
8. Establish a Data Migration Team
Assign a dedicated data Migration Lead to sit on the Core team. Ideally, the Migration Lead will define and recommend data migration scope and approach, will identify and recommend data cleanup challenges and act as quarterback for all data from the respective Core Team members, Finance and functional Leads.
Data migration scope tends to be ambitious at project start (i.e., history, detail) and is scaled back as Go Live approaches (i.e. no history, no detail, opening balance only). This is because the scale and complexity of data migration becomes more apparent the further into the project and teams realize that even simple trial balance with subledger loads are challenging enough.
Also consider, assigning a technical data migration resource with experience in design and development of scripts for data extraction, transformation, and load processes.
9. User Acceptance Testing (UAT)
It is critical to use the workflows from the personalization phase to create a Test Plan. The plan should be well established in advance of testing, identify the specific functionality to be tested, include clear instructions and steps to sufficiently test and sufficient time to test, report errors/issues, remediate and test again. As much as possible, when an error occurs, work concurrently with the vendor to test, correct and retest the entire test case. This will avoid unnecessary back and forth between testers and the vendor which can significantly delay testing and the overall project.
When it comes to UAT your first instinct may be to involve as many users in testing as possible. However, it is likely the only users who will have sufficient experience with the newly configured system are part of your Core team. Keep this in mind when identifying your Test Team. Limit testing to the Core team plus a few additional users and SME’s but avoid extending to a large user test team. Plan for the core team to train and support the additional testers and to act as primary contacts during post Go Live.
10. Set-Up Project Documentation:
A good Project Manager will setup a (RAID) Log; Risks, Actions, Issues and Decision. This will act as the central source of truth, should be updated regularly and accessible by the entire Project team.
Risks Log: The central log where all risks, real or potential impacts, likelihood of occurring, along with plans for mitigation are tracked.
Action Log: Maintain an action log as part of regular team meetings, who’s doing what and when. Review these items at each team meeting to ensure everyone is staying on track.
Issues Log: Issues are different from actions in that they are issues that were unforeseen and need to be resolved.
Decision Log: The project decision log is a critical piece of documentation and should be maintained by the PM. Document decisions made throughout the project and continually review them in the team meetings to ensure agreement from the entire team.
It’s key during an implementation of any kind that your Core team stay focused and on track. Projects run into problems when they become delayed because team members are pulled in various directions across the organization, requirements have not been defined and the appropriate prep work hasn’t been completed. If you are implementing a financial system in the coming months, we hope this article helps you organize your teams to ensure a timely and successful implementation.