As an alternative to developing additional functionality within their base ERP offering, many ERP software vendors purchase third-party applications (from another vendor), and sell the software as a “bolt-on” module.
ERP history has shown that vendors often push bolt-ons once their clients discover during the software evaluation that their base package does not address their needs in specific areas.
Next, vendors get their clients excited about the additional functionality that can be provided with a bolt-on, without explaining the potential downside risks. That is, in the end, bolt-ons can be a perfect example of software as an afterthought.
Integration vs. Interfaced
While all vendors claim their bolt-ons are seamlessly integrated with the rest of the ERP system, it is wise to get a clarification of what “integration” actually means. The truth is most bolt-on modules are not integrated, but interfaced instead. There is a difference.
The term integration implies that application programs utilize a common database, with minimal file duplication, and the data is update across the systems in a real-time mode.
On the other hand, an interface is defined as programs that physically extract, transfer, and load data between separate databases (on a less than real-time basis). Interfaces are necessary since the systems were not designed to work together in the first place.
Beyond separate database areas, in many cases bolt-ons are built on a different technology platform than the ERP software. This makes interfaces even more difficult to design, develop, test, and support. This is one reason interfaces are never fail-proof. When an important interface fails, it can affect the business, users and customers in a significant way.
Worse yet, there are many ERP package constructed mainly of third party bolt-ons, even to support the basic ERP modules! In this case, there are likely data redundancies and integration issues everywhere. During a software evaluation, do not expect the vendor to disclose this type of information unless you specifically ask.
Bolt-ons in the base software is never a good thing. It could be a sign that their package is in a state of decline within its product life cycle. When this occurs, the vendor is reacting to market needs by purchasing a quick unintegrated solution versus investing internal resources in a dying ERP product.
When is a Bolt-on Application Appropriate?
When considering a bolt-on package, the key is to understand the degree of real-time information required by the business in the application area in question.
For example, bolt-ons can be a good solution when providing a specialized functionality, requiring only a loose handshake with the rest of the ERP package. In this case, the lack of real-time integration is not a hindrance to usability.
In search of more ERP insights? Learn more about ERP software by checking out our exclusive Top 20 ERP Software report. You can also take a look at to the Business-Software.com ERP software resource page, our hub for ERP-related content.