The CFO's Guide to ERP Implementation

By Adam Bluemner • Updated on December 20th, 2013

As a financial executive, you bring a wealth of relevant experience to evaluating ERP software. But for a variety of organizational reasons, you may also find yourself taking on the daunting task of considering the technical elements of the decision.

Install. Configure. Customize. Convert. Integrate. Fuzzy on where one starts and another begins? Don't worry, in a few minutes you won't be.

With a quick brush-up on some key terminology and concepts, you’ll be in a stronger position to answer critical questions related to software implementation, such as:

  • What parts of implementation can we handle ourselves?
  • What parts of implementation will we require outside help with?
  • How do we evaluate implementation providers and what their proposals cover?
  • How can we tell if a product will integrate with our information system environment?
  • How do we account for all the implementation factors that will lead to a successful rollout?

5 Key Software Implementation Concepts to Understand

“Implementation.” A lot is suggested by that single noun. Let’s unpack it a bit. When you talk about “implementation,” you are talking about the entire process of bringing a new software product into the work environment. That means deploying it on to your servers, customizing it, setting it up in a way that makes sense for your unique processes, loading in your data, ensuring proper functioning, and training users. There’s quite a lot there. Let’s take a look at each step along the way.

1. Installation

Once the software has been loaded on to your hardware it can be considered “installed.” Sounds simple enough, right? Not quite. There are some requirements along the way that need to be handled just to simply install the software.

First, you need the right hardware. Your ERP provider will help scope server specifications for you. In fact, most ERP providers will publish precise minimum hardware requirements documentation. But remember, you’ll want to leave room for growth. Scoping system requirements is a bit of a science in and of itself. In a white paper describing best practices for Java Enterprise system deployment planning (which is equally relevant for any type of software implementation) Oracle described seven different hardware system qualities which should be considered when scoping system requirements: availability, latent capacity, performance, scalability, security, and serviceability. Its these factors which determine things like whether the server should have 16GB or 32GB of RAM, for instance.

Second, your hardware must be properly prepped. This means ensuring that there is adequate disk space, making sure the network is configured to handle the required server availability, backing up the server before making changes, and addressing the required operating system level settings.

2. Configuration

Configuration is the process of adapting the raw functionality of the software to your specific security requirements, workflows, and preferences.

Consider the set-up of security requirements. You may not want a warehouse employee who needs to check inventory levels to be able to make changes to annual corporate forecasts–to give an extreme, but illustrative example.

Overall, the process of configuration is about making your software support your workflows, rather than the other way around. But in order to bend your software to your will, an investment of time will be required.

Think about something as fundamental as defining a new company in an ERP software program. It seems very basic. But there’s more to it than meets the eye. It’s going to require a multi-step process–such as the one described in this technical documentation from SAP for their Business One product. In any system set up there are dozens, or more likely hundreds, of these kind of system configurations.

3. Customization

In a technical sense, customization does not simply refer to “changing” the way a program operates. Many modifications can be made through settings and configurations and would not be considered “customization.” In programming, “customization” truly refers to instances where you are augmenting or altering the underlying software code. When it comes to ERP and accounting software, customization tends to be more limited than in other types of software systems.

Generally, software providers handle most customization since the vast majority of accounting and ERP software is not open source. With the significant growth of open source across a number of software platforms (think: Linux, Apache, Eclipse, Mozilla, OpenStack, Drupal) one might expect more activity, but commercial software continues to rule the roost in the business accounting and ERP space.

In certain situations where base system setting modifications and configurations do not provide the necessary functionality to meet requirements, it can be worthwhile to make the investment in customization.

Customizing Versus Configuring Software

Customizing and configuring Only configuring
Frequently creates reliance on original programmers Easier to source external support
Often leads to pockets of undocumented code Predeveloped documentation generally available
Can be relatively expensive Economies of scale can lower cost
Highly tailored May not fully provide optimal functionality

4. Data Conversion

ERP software is only as good as the data it holds. Importing your existing financial data is a necessary step in any ERP implementation–unless you have the good fortune of starting from scratch with a new business. Here’s the challenge though: There is no single standardized format for financial data. The underlying database tables that track, say, the accounts receivable records in one system will differ from those in another.

Manually inputting data–or even reformatting exported data dumps to the new format–can be tedious and cost prohibitive. That being said, your provider may have ported existing data in the past and already developed software utilities to speed the process. In fact, there are even companies (such as CloverETL) who specialize exclusively in converting and migrating data.

Data migration diagram

Examples of business data that will need to be imported can include the chart of accounts, inventory records, job summaries, invoice histories, financial statements, balance sheets, and so on.

5. Integration

Integration refers to establishing how your new software will communicate with your existing software platforms. For instance, let’s say you decide to maintain a legacy CRM module when implementing new ERP software. You’ll naturally want updates to customer data made within the CRM system to be reflected in the accounts receivable module. That’s integration.

Will you need integration that functions in real-time? With real-time integration, changes in one system are reflected immediately in the other. Frequently, this is accomplished through the use of a common database. Alternatively, many programs provide APIs (application programming interfaces). An API pre-configures a set of usable instructions that allow for changes in one program’s database to be triggered by actions in another. (The number of APIs is exploding. lists hundreds of APIs in their web services directory enterprise category, alone.)

From a functionality perspective, real-time integration is always better, but it may not always be technically feasible or cost-justified. As another option, you could generate reports and load updated data from one system to the other. While potentially less expensive to set up, batch integration can create issues where different data exists in two different systems until the reconciliation has been triggered. If the batches are executed regularly enough or the underlying data is infrequently changed, this may be supportable, but there will certainly be instances where this can be a major limitation.

A Quick Word on Training and Testing

Once the system has been installed, configured, customized, converted, and integrated, the lion’s share of the implementation work has been completed. But let’s not overlook the two “t’s”: testing and training. The post-implementation activities of training and testing are critical to ensure that your organization will get the most out of the new software.


Proper testing of an ERP system will ensure that a number of conditions are met, including:

  • Full workstation and/or remote access,
  • Adequate data throughput to assure responsive performance,
  • An audit of all security measures,
  • Proper definitions of all user profiles and privileges,
  • Correct configurations for continuous data-backup, and
  • Seamless performance of all core operational tasks.


ERP programs are complex, wide-ranging business information systems. Unfortunately, a lack of training is common on ERP projects.

In fact, an infographic compiled by the IT company TekSystems identified that 29% of the ERP consultants surveyed felt that training and education represented the biggest skill gap in projects they worked on.

Infographic surveying the biggest skill gaps ERP projects

As you evaluate providers, it may be useful to consider which of the following training resources they offer:

  • One on one individual training,
  • Train the trainer sessions,
  • Video tutorials,
  • Live web training sessions,
  • Access to a product user community or forum, or
  • Collected best practices documentation.

Putting Your New Found Grasp of Implementation Jargon to Work

So if you’re the"financial guy" who got stuck evaluating the technical side of ERP implementation proposals, don’t worry. It’s not uncommon. In fact, it happens all the time. The good news, though, is many others in your shoes have overseen successful implementations. Armed with a stronger understanding of the jargon describing the steps involved in implementation, you should be in a better position to guide your ERP project to a successful outcome.