Customizations Part 2: Requirements, Design, and Testing

In part 1 of our customizations post, Customizations: Why, When and What to Look For we discussed how to research customization alternatives, secure and manage executive project support and stay within your company’s capabilities.

Sometimes, after researching all customization alternatives, you might find that none are sufficient to meet your needs. At this point, a customization may be needed.

Customizations run the range from simple to very complex. For this reason, accurate requirements gathering, and design documentation are critical to the customization’s success. After completion, the customization needs to be carefully tested from both a user acceptance testing (UAT) and data reconciliation perspective.

Methodology

ERP implementations are controlled using a specific methodology.  Customization needs are usually identified in the pre-sale discovery phase and documented in the requirements gathering phase. The actual customization is coded in the configure and data load phase, and tested in the training and testing phase.

Best practices

This post discusses some best practices that help ensure a successful customization. It also identifies some “pitfalls” which often result in a less than optimal outcome.

Over the course of many projects, four top best practices have emerged that can positively impact a customization:

• Understand customizations
• Control the process
• Build a Functional design
• Test and reconcile

Understand customizations

In the ERP world, “customization” is a blanket term attached to many different initiatives.

• Customization- The development of custom code to modify an existing system process or create a new system process within the base application. An example would be, building a process where inventory items can be reserved, then assigned to a specific project and billed, in a system that doesn’t support this functionality “out of the box”.
• Integration- The close and seamless coordination between systems including data and functionality. An integration example would be setting up employees in a non ERP HR system, which then automatically updates the ERP payroll application.
• Interface- An interface is the transfer of data from one system to another typically by using a file import and export process. An interface is usually not an automated data transfer process. An example of an interface would be exporting budget data from a budgeting application (or spreadsheet), creating a file and importing it into the ERP budget functionality. After importing, the data is reviewed, reconciled then posted.
• ERP tools- The use of ERP “out of the box” tools, such as exposing user fields and field label customization. An example of an ERP tool customization would be to expose an additional field (e.g. for data capture) in an ERP screen and label it to the customer’s specifications.

Be sure to keep customization requirements consistent with their value. For example, some companies make extensive modifications just to keep legacy processes in place before really understanding how the new system works. Unless the issue is critical, out of the box functionality should be used for at least 6 months before considering major customizations. Once system users become familiar with the ERP, many modifications are rarely requested.

Control the process

Customization and integrations

Customization and integrations are the most complex initiatives of the customization types described above. Due to their complexity, they need to be supported with a set of requirements and a detailed design document.

These initiatives can become quite expensive. Controlling the process is key to keeping the everything on track. Be sure the initiative is supported with a detailed budget, including testing and bug fix costs. If you can, try to negotiate a fixed price.

In addition to direct costs, be sure you understand any associated on-going costs. For example, custom code development may require a re-do of the coding each time the system is upgraded. These costs can be significant. Essentially, you’re paying multiple times for the same effort. Also, include ongoing soft costs such as reconciliation and error handling.

Be sure you know who’s doing the actual development. Many VAR’s are not large enough to have full time developers on staff, and they regularly outsource this work. While not necessarily an issue, just be sure that you complete an adequate level of due diligence. Meet with the developer, interview them and ask for references on prior development projects. At a minimum, get a signed non-disclosure agreement and review the developer’s experience and certifications.

Be sure to get the VAR to agree to stand behind the work and assume liability for any issues such as processing errors and data irregularities. Also address the completed customization’s ownership. You paid for it, so you own the rights to it. Ensure that these issues are addressed in the SOW.

Interfaces

Interfaces are much less difficult to control. In most cases they really don’t need a requirements or design document. Usually, a simple mapping document is sufficient. The mapping document should detail where the data is coming from (source system) and where the data is going to (destination system). The mapping document example below, reflects a positive pay file interface from AP to the processing bank.

Interface danger points, are error handling and the reconciliation between the source and destination systems. Prompt, efficient error handling and reconciliation are an important part of maintaining interface accuracy.

ERP Tools

System tools use the ERP’s “out of the box” tools such as user fields and field label customization. This is the easiest customization to control. Usually, the need is identified, in the ERP requirements meetings. Many times, simple tasks using the tools can be priced or “thrown in” as a part of the ERP implementation. If needed post implementation, the VAR will write up a simple SOW (Statement of Work) and complete.

Build A Functional Design

Building a functional design for customizations and integrations, is a task usually completed by an IT or SME (Subject Matter Expert) resource. This can be an internal employee, an outside contractor or a VAR team member.

Since the functional design is used by the developer to write the technical design and actual code, it’s important that the design’s author is reasonably familiar with both the functionality desired, technical terms and can build the design document in a manner easily understood by the developer. These tasks require a resource with a lot of prior experience, and the ability to write in a clear and precise manner.

Be sure that you complete an adequate level of due diligence before deciding on an author. Meet with the authors, interview them and ask for references. Have them show you some prior designs they’ve completed, even if you have to sign a non-disclosure agreement.

Don’t shortcut this, its very important to a successful project. Finally, don’t forget to get a signed non-disclosure agreement from the author, even if it’s a company employee.

In addition to creating the document, the author usually acts as the developer’s liaison during the development, testing and training phases. Additionally, assign an employee from your company to act as the “project lead” (from the user side) to work with the author to ensure that all requirements are included and functioning properly after completion.

In terms of the document itself, start with a general outline and have the author review it with the project lead. Be sure that the outline includes all requirements, and that it’s well written, organized and understandable. Once the general outline is finalized, continue by drilling down and building out the detail until you’re satisfied with the end product.

I personally like to use Word documents for this. If you prefer a spreadsheet, that’s ok too. Schedule regular meetings between the author and the project lead to keep thinks on track.

Test and Reconcile

Testing and reconciliation are absolutely critical to success. Short cutting or using a haphazard testing approach without pre-defined testing scripts and expected results is risky. Not reconciling test results, is an accident waiting to happen.

Customization testing should be based on two testing types:

• User Acceptance Testing- Ensures that the customization functionality described in the requirements and design is operating, from the user perspective, as expected.
• Data Testing- Ensures that all customization transactions and their supporting data sources, are processed and recorded accurately.

A lot of time and effort goes into identifying requirements and building the customization design. Use the requirement and design documents to build your test scripts. Prepare a set of test transactions including the expected outcomes to be sure your test efforts are systematic and can effectively identify issues. If you can, use similar transactions from your current system as a base. Using current system transactions provide the ability to know what the expected results should be. Use the test scripts as the basis of any training documentation.

A sample of a test script is displayed below:

Run your testing and reconciliation plans past your auditors to be sure that they are satisfied, and will accept the work papers and testing process. You don’t want to complete the implementation, then get to year end and have to incur additional audit labor to get a set of audited financials.

Remember, there are few things that erode an accountant’s credibility and career faster than providing inaccurate information, especially if it builds over time and becomes a material issue, so be very careful here.

Conclusion

Customizations are an expensive proposition, and they can quickly spiral out of control. Plan carefully about testing and reconciliation, as these tasks can take a very long time to complete. Be sure your company can handle what you’re going to be getting into.

In my mind’s eye, a customization should be used as a last resort, and the customization should be only as complex as needed to achieve its intended goal.