This is the name given to software that’s “outside of the main enterprise software suite or legacy system”, typically coming from a third-party software supplier. Companies usually add bolt-on to the main system to perform specific functions because the existing Enterprise Software or legacy systems don’t do them well or don’t do them at all. Many bolt-on software packages are considered “best of breed” because they are seen as so superior to their counterpart modules within the Enterprise System suite.
Davenport, in his book on Enterprise Systems II identifies supply chain support tools for demand and supply planning, plant scheduling, and logistics systems as being primary candidates for bolt-on:
Given the existence of best-of-breed packaged solutions in so many of these areas, the favored approach for most firms has been to go with a major vendor for core ES and then bolt on supply chain software developed by multiple other vendors.
Downsides to bolt-on include a degradation in the ability of enterprise system to integrate information and process, the need for additional files not linked to the central database, the effort required to integrate the bolt-on, and a maintenance task over time as changes occur to the enterprise system and/or to the bolt-on. These negatives are not insignificant, and we feel that bolt-on should be used judiciously and only when clearly needed.
The good news is that bolt-on typically do provide users with a superior tool (If not, why use a bolt-on?). Sometimes these packages are brought forward from the legacy environment and get bolted onto the new enterprise software, because it’s so obviously the right thing to do for the users. More on this in a bit…
When we talk about pockets of excellence, most bolt-on we’ve seen in ERP environments come in 3 (three) typical categories:
- Resource planning enablers – This is the type of thing we’ve just been talking about: getting outside software (for Master Scheduling, MRP, etc.) and plugging it in to your existing system.
- Front-end/back end – These are applications that focus on the front end of the resource planning process (sales forecasting, Sales & Operations Planning, vendor-managed inventories) or back end, such as finite scheduling packages for the plants. Bolt-on generally cause the least difficulty when they’re at the front or the back. For example, there are several excellent forecasting packages on the market, which do a far better job than most ES vendor’s offerings. For companies where forecasting is a problem—and there are more than a few of these—a forecasting bolt-on might make a lot of sense.
- Supply chain optimization/advanced planning systems – This category of packages attempts a better fine-tuning of the detailed demand–supply relationships addressed by master scheduling, Material Requirements Planning, and so forth. When used properly, these packages typically can do a superior job. Through advanced logic and strong simulation capabilities, they can give superior recommendations to demand managers, planners, and schedulers regarding the best fit between customer demands and resource utilization.
In summary, bolt-on can be quite valuable, but they come at a cost—not only in dollars of course, but in loss of integration and increase in maintenance. Using them indiscriminately will cause more trouble than they’re worth. Using them on a very specific basis, to do a superior job in one or another given function, is frequently the way to go.
Selecting Bolt-on Software For ERP Company
Here are some thoughts about selecting bolt-on software, whether it is a resource planning enabler, a front-end or back-end module, or a supply chain optimization package (These may also have relevance in selecting an ES for those of you who’ll be doing a combined ERP/ES project) Here goes:
- Don’t be premature – Some companies’ first exposure to a given set of software is through the software salesman who sells them the package. Often, these people regret having made the purchase after they have gone to early education and learned about ERP and its better tools. The right way is to learn about ERP first, and get the software shortly after the company has made an informed decision and commitment to ERP.
- Don’t procrastinate – This isn’t as contradictory as it sounds. Don’t make the mistake of trying to find the perfect software package. That’s like searching for the Holy Grail or the perfect wave. There is no best software package. The correct approach, after learning about ERP and deciding to do it, is to decide which bolt-on packages, if any, you’ll need for phase I. Go after those and get a good workable set of software. Then repeat the process for phase II. It’s important to move through these selection phases with deliberate haste, so the company can get on with implementing ERP and getting paybacks.
- Don’t pioneer. People who get too far out in front, pioneers, often get arrows in their backs. This certainly applies to software for ERP. Why buy untested, unproven software? You have enough change underway with people systems to worry about software glitches. Insist on seeing the package working in a company that operates at a Class A or high Class B level. If the prospective software supplier can’t name a Class A or B user of their product, we recommend that you look elsewhere.
- Save the pockets of excellence. Many companies do some things very well. An example of this would be a company with an excellent shop floor or work unit control system, but little else. The computer part of this system may have been programmed in-house, and may contain some excellent features for the users. Let’s assume that the supply chain software package selected by this company contains a shop floor control module that’s workable, but not as good as the current system. This company should not blindly replace its superior system with the new, inferior one. Save the good stuff. Don’t throw the baby out with the bath water.