What Does “Out-of-the-Box” Mean?
In recent conversations with several prospects, we learned that they are implementing (or just implemented) an “out-of-the-box SaaS AP automation solution.” Actually, the vendors involved represented their AP automation solution as being “out-of-the-box.” However, the reality of their implementation turned out quite different. By the end of the first week, the customers learned that extensive customization was required to address their stated requirements. “The demonstration we viewed in the sales process turned out to be a highly configured version of their software that was designed for a specific customer,” according to one customer. “Fourteen weeks of heavy IT involvement does not sound like out-of-the-box to me,” said a second.
SaaS Revisited
Somewhere along the way, some software companies forgot what SaaS (software-as-a-service) is all about. SaaS is based on the concept of a shared code set running in the cloud across a diverse set of customers. The key words here are “shared code set.” No longer would each customer run their own instance of software. Instead, best practices are embedded into the application, allowing for rapid implementation and deployment, and a lower cost of ownership.
Configure versus Customize
Shared code set does not imply rigidity. The best SaaS solutions can tailor the application to meet the needs of the organization. They refer to this as “configuration.” Configuration is different than customization. Configuration is done during the implementation process, typically through a GUI designed for the system administrator. For instance, AP Express has dozens of configuration options that can dramatically change the way the system operates. For example, by checking a box in the setup screen, an administrator can:
- Automatically assign an invoice to a processor by first letter (or group of first letters) of the vendor name
- Bypass the approval workflow if the invoice is matched to a purchase order
- Allow an invoice process to select specific general ledger accounts
No coding is required. Customization, on the other hand, is done in the guts of the application. Code is altered to meet a specific customer’s requirement and routines are built to move data between systems. The anticipated “out-of-the-box” implementation quickly goes “out-the-window,” and responsibility for maintaining the customized code is offloaded from the vendor to the customer…forever.
The Disruptors
Early SaaS entrants were consummate disruptors. In the span of just a few years, they overtook established software vendors and plundered their customer base, and for several reasons. First the cost of implementing the solution was dramatically lower, and so was the risk of failure. Secondly, SaaS vendors leveraged cloud computing platforms with significant economies of scale.
Thirdly, the ongoing cost to maintain the solution became the responsibility of the vendor, not the customer. Finally, vendors were able to quickly enhance and extend their software applications. They were completely unencumbered and free to focus on performance and building innovative features for everyone. SaaS applications were continually patched and improved, and vendors no longer had to worry about upgrade paths for earlier versions. Upgrades were essentially automatic. As a result, the total cost of ownership of SaaS applications was an order of magnitude less expensive than a typical on-premise software solution.
The Best Out-of-the-Box AP Automation Vendors
“We only realized after we signed the contract what we were getting into.” That’s the refrain we commonly hear from customers jilted by vendors promising “out-of-the-box.” How can you guard against this? Here are the steps you can take in determining the best “out-of-the-box (OOTB)” AP automation vendors.
| Get Smart About | Why? | How? |
| Solution Architecture | The best out-of-the-box AP automation solutions provide native integration with the underlying ERP system. AP automation solutions require tight integration with the ERP system. Master data located in the ERP system form the foundation of the AP automation experience. In a typical implementation, data from more than 20 separate tables must be mapped between the two systems, including the chart of accounts, sub-ledger, address book, supplier master, company master, business unit master, purchase order header and detail, PO receipts and user-defined codes. AP automation solution systems also push data back to the ERP system. The process of defining, building, and testing a file-based integration is complicated, time consuming, and expensive. The better option is native integration. It communicates using web services and understands both the structure of the ERP system and the required data elements. Moreover, it is maintained by the AP automation vendor, eliminating the need for ongoing support from IT. | – Ask the vendor how their solution communicates with your ERP platform. If they say “flat files” it’s not OOTB. Essentially, they are hard wiring their AP Automation solution to your ERP. Changes in either product will likely cause the system to stop working. – Ask to see a project plan. OOTB solutions can connect to your ERP and move data back and forth with just a few hours of effort. – Ask the vendor what will happen if you add a new company or organization to your ERP. Native integration ensures this is totally seamless. Ask the vendor how much IT time is required to implement their solution. OOTB products require very little IT involvement (usually just a few days up front). Most of the time is spent working with the end users, configuring the system to match the business process and training end users. |
| Configure or Customize | OOTB vendors provide tools that allow the system to be configured to match the customer’s business process. This typically includes establishing roles and rights, approval levels, workflow rules, messaging, and various other options. Configuration is different than customization. Configuration is done during the implementation process, typically through a GUI designed for the system administrator. Customization, on the other hand, is done in the guts of the application. Code is altered to meet a specific customer’s requirement and routines are built to move data between systems. The resulting work product is the responsibility of the customer in perpetuity. | – Don’t settle for a demonstration that caters just to the needs of the users. Ask to see the administrator user interface. Review the list of options available that change the way the system operates. A robust OOTB solution will have dozens of check box/radio buttons/drop down lists that enable the system to adapt to the way you run your business. – Ask the vendor to show how to change the system to (a) enable GL segment coding; (b) enable project accounting; (c) allow an invoice process to select specific general ledger accounts. These (and dozens more) will all be switch-selectable in an OOTB AP automation solution. |
| Implementation Timeline | For all the reasons mentioned above, OOTB vendors can get their solution up and running very quickly. They rely on native integration and they have an extensive set of configuration options that enable the system to mirror the way a company does business. | – Ask to see a project plan. An OOTB product should be up and running in 30 business days or less. – Drill down into resource requirements for each step. Does the implementation require a large commitment of IT resources (i.e., more than just a few days)? If so, it’s not OOTB. |
| Customer Experience | Vendors do their best to represent their solutions fairly and accurately to prospective customers. Not doing so undermines the integrity of both the sales person and the company she/he represents. What’s most important, however, is the customer experience. That’s why the right reference is critical. | – Ask the vendor whether the demonstration is the OOTB product. “Is everything you are showing me in this demo available out-of-the-box?” Drill down and reconfirm if there is any hesitancy. – A vendor will typically provide a reference from the end user community. An end user reference is important, but not sufficient. End users may be unaware of the technical complexity on the back end. More often than not, they are ecstatic because they are no longer processing invoices manually! Ask to speak with an IT resource from a recent project. The IT team will have a better appreciation of the total effort involved. |
