As smaller companies grow and expand their businesses, an area which is typically overlooked or neglected is implementing a new ERP system. A financial system for a small business is often put on the backburner behind day-to-day business and strategizing growth opportunities. If an ERP system is considered a low priority, gaps or holes in the current system will tend to be patched with band-aids or workarounds. While these gaps or holes may be workable in the short term, as a company grows, they will develop into areas of risk, which may include errors in data input, data migration issues or accuracy.
In this article, we’ll focus on two common scenarios:
- The first is a smaller company (Company A) that is about to be acquired, and as such should plan and organize for the impending implementation of the acquiring company’s ERP.
- The second is another smaller company (Company B) that has scaled and grown their business to the point where implementing a more stable and sustainable ERP system is a necessity.
The following discussion will provide five areas to keep in mind in both scenarios: assessment, documentation, data availability, user roles and implementation planning.
Assessment of Existing Processes and Future Opportunities
Early in the process of implementation of a financial system for a small business or target company, the entity (Company A or B) should assess the current ERP and subledger system inefficiencies, limitations, etc., which would be addressed with the new ERP system. Such limitations or inefficiencies might include lack of controls, access limitations depending on the role of staff members or the inability to feed various subledger systems to the main ERP.
This assessment can be done in-house if management is experienced and have dealt with prior implementations in their prior experience. If not, and there is capability to bring in an outside consultant, it would be best to do so early, in this stage of the implementation process.
For Company A, this assessment will help to alert the Implementation Team to the need state as well as potential improvements to be created within a new system.
For Company B, this assessment step serves as the starting point for shifting perspectives and redesigning and optimizing processes to maximize the impact of a new ERP, rather than simply utilizing their current system as-is. For example, Company B might note an existing inability to feed Trade Payables from its subledger system, QuickBooks. But a system such as Oracle or SAP would have the capability to effectively feed Trade Payables from a subledger system. This offers an opportunity to reduce errors and create efficiencies by automating the process.
Detailed assessment may also expose limitations in a new system, which would need to be managed so that all processes are addressed. These limitations may include industry-specific transactions that may not be compatible with the new ERP system. For example, in the ever-evolving tech industry, a static, established system may not take in the data cleanly without custom-designing the new ERP system to fit business needs. By talking through the business and how transactions are structured, stakeholders might find the new, as-is ERP isn’t the final solution. They might decide making it more customized would better suit the company.
Learn more translatable principles of assessment and system selection in our whitepaper:
Documentation of Processes
Proper documentation of all processes (for both Company A & B) will encourage more efficiency in the blueprint phase of the implementation. Each area of the Balance Sheet and Income Statement that is handled by specific members of the Accounting Department should have desktop procedures prepared, and each cycle should be documented to show process and workflow (e.g., the Revenue cycle).
When documentation is requested ahead of the blueprint phase of an implementation, it’d be best for Company A to have documentation ready. This can avoid organizational stress and the risks of hastily putting documentation together last-minute, which can lead to the omission of critical steps or uninformed deficiencies in the new system. For Company B, the documentation can create consistency and inform an optimal implementation of the new ERP by allowing clarity in the translation of processes into the new environment.
Your documentation should be reviewed and updated every two to three months to ensure changes in steps or processes are reflected. It can also be helpful to have new team members review the documentation as they would have a fresh set of eyes to make thoughtful edits.
Learn more about documentation: “The Unnecessary Risk of Poor Accounting Process Documentation”
Data Availability
Before implementing a financial system for a small business or target company, it is also important to gather and organize data that needs to be ingested as a part of the implementation (e.g., vendor data, customer information or chart of accounts), so that it is easier to ingest when the time comes.
For example, let’s say Company A’s position is to reduce the number of general ledger accounts in the new system and to map against the parent company’s chart of accounts. Company A should first place a current list of accounts against the more-condensed list to weed out redundancies, misnamed accounts and so on. Once a draft of the list of accounts is created, vet this list with senior management for their approval, and then finalize the list beforehand so the ingestion is smooth.
Once a chart of accounts is transitioned to the new ERP system, it becomes difficult to amend the list, especially once transactions are generated as unraveling them would be messy.
For Company B, as the business expands and grows, vendor data may be constantly changing. As such, it would be best to collect and organize the vendor data up until the time of implementation, so that the data would not have to be updated in the new system. Changes that would need to be made after the vendor detail is ingested would cause a disruption in normal day-to-day business and potentially cause delays in invoices being paid.
User Roles
Understand who the current users of the ERP/subledger systems are versus the future-state users. For example, a user list for the current financial system for a small business may only include people in the Accounting and Finance functions. Post-implementation, a user list might include users who are from other business areas. In this case, it is useful to understand what system roles and access levels these business users will have, the training needed to use the system and who to reach out to for access, system issues, troubleshooting or support—aside from Accounting and Finance team members.
For example, let’s say Company A is a small media technology company that is acquired by a global media company, and they transition from QuickBooks to SAP. In QuickBooks, the sole users of the system are from the Accounting and Finance departments. In SAP, the role of the Accounting and Finance departments is focused on areas specific to these two functions (e.g., Journal Entry creation, consolidations or data warehouse retrieval). In SAP, users in Marketing, Sales, IT and other departments have access to create POs, create Customer Invoices and perform other tasks relevant to their function. As such, gathering all potential users of the new system and identifying what functions they should have going forward (e.g., read or write access) makes the transition smoother. They can be included in appropriate training sessions, can test their access and will be capable of performing their duties appropriately once the system has gone live.
For Company B, where there may not be a structured user list, some users may have multiple roles and user access may not be tightly controlled. This would need to be revised as the business grows. Implementing a new system provides an opportunity to firm up the controls via a revised user list. This would be done by limiting access depending on the activity in the new system (e.g., posting journal entries versus a read-only user). This can also be done by creating a preparer, reviewer and secondary reviewer hierarchy, so junior staff cannot perform approvals within the system. By taking a step back and making sure this list is revised ahead of an implementation, you can ensure that the list does not need to be amended afterwards and there is no disruption to daily activity.
Implementation Planning
As one of the last steps prior to implementation, it is helpful for Company A to determine the core Team to handle the implementation from the perspective of the entity being acquired. The core Team should be assembled based on an understanding of current workload, future system needs, experience level and other relevant factors. The Team should gather the needs for the future system(s) by conducting interviews with the Team and Leadership to understand expectations of the system (e.g., potential useful outputs, reporting needs). This will allow Company A to interface thoughtfully with the Implementation Team (both business and technical sides) of the acquiring company. The Team should set up a meeting cadence with the Implementation Team to address tangible deadlines, create action items and work to address these items and meet the deadlines. This will enable the entire organization to understand the implementation timeline and any deviations, hopefully before they arise, so they can be addressed properly.
In the case of Company B, this planning should be guided by management with the greatest expertise and knowledge of system implementations—and who can facilitate this process with the ERP Vendor. If there is no such in-house expertise and there is a budget in place for the implementation, it would be a good choice to utilize an external consulting firm to assist with this massive undertaking.
Learn more about systems implementations:
Implementing a Financial System for a Small Business or Target Company? Experience Matters.
As a company grows and/or is nearing an acquisition, keeping in mind the areas discussed above will help ensure a smoother ERP implementation as the Team approaches the User Acceptance Testing (UAT), Go Live, parallel testing, support and optimize phases.
It’s common that companies will attempt to perform a financial systems implementation with in-house resources, who add this responsibility onto their day-to-day duties. Due to the complexity and workload inherent in systems implementations, it’s our firm’s view that engaging an external project manager, who can focus on the implementation 100% of the time, substantially reduces the risk of implementation failure. If you’d like to learn more about how 8020 Consulting can help your business, visit our financial systems consulting page. You can also learn more about ERP implementation stages and phases in our downloadable guide:
About the Author
Radha has 15+ years of finance and accounting experience in various industries, with a specialty in Entertainment. Prior to consulting, she was a Sr. Manager of Financial Reporting at Paramount Pictures, where she managed the consolidated GAAP and cash reporting to DreamWorks Animation and Marvel Studios. As a consultant, Radha has performed financial system implementations, provided accounting services for month-end, quarter-end and year-end close processes, business process re-engineering, created forecasting and budgeting models, and managed the forecast and budget cycles and deliverables within various large clients. Radha is also an alumnus of PwC in Los Angeles, where she was on engagements spanning various industries of varying sizes, such as Valeant Pharmaceuticals, Tetra Tech, Disney, Arbonne and Morgan Creek Productions. Radha holds a B.A. in Business Administration with a concentration in Accounting from California State University, Fullerton.
