The truth about ERP bolt-ons: Know the good, the bad and the ugly
Sometimes, key benefits a company wants from an ERP implementation are not part of the purchased ERP package at implementation. Business requirements may have changed for an existing system or the organization could benefit from specific new functionality. A business can get missing capabilities and extend the value of their ERP with an additional application or module, fondly referred to as a “bolt-on”.
ERP bolt-ons provide very specific functionality or technology to complement ERP systems. CRM, advanced supply chain management, vendor relationship management and HR are typical examples of bolt-ons.
Here are a few basic concepts to understand about ERP bolt-ons in general:
- Not all ERP bolt-ons are equal. Like so many things about ERP, simplicity is elusive and things can get complicated fast if you’re not prepared.
- Interfaces may be needed since the systems may not have been designed to work together in the first place. These programs physically extract, transfer, and load data between separate databases, on a less than real-time basis.
- Integration implies that application programs utilize a common database, with minimal file duplication, and the data is update across the system in real time. Understand what your provider means when they say their bolt-on application is “fully integrated” with the ERP system.
- Know the degree of real-time information your business requires in the application area in question. For some functions, lack of real-time integration is a hindrance to usability.
There are basically four ways to add specific functionality with an ERP bolt-on, and each has its own makeup of good, bad, and potentially ugly risks:
- Implement an add-on module from your ERP provider: Usually pretty good A bolt-on developed by your ERP provider to add value to their core product will most likely be fully integrated, use the same platform, and have good support. To reduce implementation risk, some ERP consultants advise new customers to become competent with a core ERP package first, and later circle back and implement a bolt-on. However, if a very substantial part of your ERP justification results from a bolt-on module, you need to either implement the bolt-on at original go-live or find an ERP package with the desired capabilities built into the core functionality.
- Install a module your ERP company has acquired: Not quite as good As an alternative to developing additional functionality within their base ERP offering, many vendors purchase third-party applications and sell the acquired software as a bolt-on module. During the integration period, acquired applications can be klugey; consider waiting for the dust to settle before jumping in. Beware of ERP packages constructed mainly of third party bolt-ons – they tend to have data redundancies and integration issues. When an ERP vendor routinely uses optional bolt-ons to provide “point solutions,” it could be a sign that their package is in a state of decline. During a software evaluation, ask vendors about this.
- Implement a product from your ERP vendor’s partner: Not too bad Reliable ERP providers and implementation consultants offer their customers bolt-ons developed by partners to help their customers get more out of their ERP systems. This approach can be very successful for all parties when there is a harmonic convergence of platform, interface and integration. Third-party bolt-ons can have connectivity complications, unfriendly user interfaces, and may even have conflicts with other benefits of the core ERP. In cases where bolt-ons are built on a different technology platform than the ERP software, it makes interfaces even more difficult to design, develop, test, and support. When an important interface fails, it can affect the business and users in a significant way. Always ask to speak with reference customers during evaluation.
- Unsupported bolt on from a non-partner: Could get ugly Think twice, and then one more time before implementing or integrating any unsupported solution!