Switching from QuickBooks to ERP: 3 Requirements Gathering Pitfalls

Effective requirements gathering offers the ability to define finite differences between elements that are ‘assumed’, versus practical ‘reality.’ Consequently, when considering the enterprise migration from a QuickBooks platform to a more sophisticated ERP system, the execution of a solid requirements process allows a migration manager to avoid many of the minefields present in any QuickBooks to ERP upgrade.

However, simply acknowledging the necessity of an efficient requirements process is not enough. Before one can actually execute a requirements round, one must, first, develop a structure that directly supports success at the most elemental level. In the case of a requirements gathering process for any ERP migration, this can be achieved by inverting one’s thinking, by considering the impacts of what can go south if one doesn’t do the right thing at the right time.

Producing Incomplete Requirements

The First Law of Holes states that, “if you find yourself in a hole, stop digging.” However, when it comes to systems requirement development, the proverb is rarely considered, let alone applied effectively at an Enterprise level. The practical impact here is a considerable loss of time and increased costs while recovering and/or creating information that ‘should have already been known’ at the outset of the Quickbooks to ERP migration process.

The practical impact here is a considerable loss of time and increased costs while recovering and/or creating information that ‘should have already been known’

For example, let’s take a look at a simple General Ledger migration from QuickBooks to SAP Business One; the ERP brand’s small business accounting module. In this event, while QuickBooks offers typical general accounting processes, it does not allow for flexible G/L account segmentation where, on the other hand, Business One allows up to 10 account segments to be applied.

Consequently, should a user simply move his/her QuickBooks data to SAP, without first considering the latter’s extended structural capability, it is likely that time and monetary costs will increase because the enterprise’s entire G/L ledger structure will have to change. Now, granted this is not a direct technical issue per se, but from a financial management standpoint, the point of migrating to a pure ERP system from QuickBooks in the first place *is typically based on manipulating more data, rather than less, going forward.

Incorrectly Identifying Requirements

This mistake is the most typical of all requirements development failures. To be frank, most individuals don’t enjoy the tedious and often highly invasive process of drilling-down into ‘how and why’ things work at an enterprise level. These people tend to ‘assume’ accuracies that do not exist. However, if one doesn’t spend the necessary investigatory time at the front-end of a requirement, there will be an 80% greater chance that *when it comes to flipping the light switch for the first time, a QuickBooks to ERP migration will offer inaccurate information leading to operational failures.

To be frank, most individuals don’t enjoy the tedious and often highly invasive process of drilling-down into ‘how and why’ things work at an enterprise level.

For example, and again working off a QuickBooks to Business One scenario, consider the necessary requirement for reconciliation of QuickBooks between its sub-ledgers and final G/L balances. In this case, if a user does not insure that all sub-ledgers balance to QuickBooks internal G/L before moving the data across the bridge, subsequent errors will extend forward, and ultimately face fixes after the fact or worse.

Losing Requirements During Migration

Believe it or not, this happens regularly, and can be particularly bad for the continued employment of any enterprise manager. The impact of ‘losing requirements’ during a QuickBooks to ERP migration is bad enough when it applies to the failed movement or integration of data that leads to inaccurate reporting. However, enterprise migration managers can even be guilty of the complete loss of a non-data based requirement during the migration process. The negative impact of this will be keenly felt during any QuickBooks to ERP migration as many processes will need to be translated across the system divide.

At the end of the day, if a manager takes a strategic view of the entire process of requirements-building, on top of taking the time to ensure that completely transparent migration requirements apply throughout, the migration should be successful. This, in turn, *leads to a host of increased ROIs well beyond what one might typically expect from a QuickBooks to ERP migration. These include but are not limited to; faster enterprise time-to-market response, enhances in overall systems and business productivity, the expansion of team efficiencies throughout the company, an ability to leverage real-time visibility, and control of current and future requirements, and finally, the creation of additional products and services that typically lead to extended revenue over time.