INTRODUCTION

What is bolt-on?

Bolt-on is an artificially intelligent, comprehensive execution system providing very specific functionality
or technology to complement ERP systems. Bolt-ons employ client-specific business rules to meet
unique needs. There are many useful applications of this type. The usual means of connection to other
organizations with ERP systems is through software components.

Most software has historically been delivered as inflexible code focusing on its originally intended
application. A much easier approach is the idea of components where separate, encapsulated software
code is written that is easier to manage, upgrade and connect to host systems. Open systems can easily
accept modifications, additions or linkages to external software. Components make open systems
possible.

Since the underlying philosophy in early ERP systems was internal integration, there was initially little
apparent value in developing open systems. However, the ERP user market soon identified the benefits
of best-of-breed selection of modules, sometimes across vendors. Vendors then realized the need to
offer applications components. The focus shifted from internal design coherence to the ability to
communicate with external software. Service-based architectures were created enabling business
transactions and data transfer from outside the core applications.

Some examples where bolt-on software is used are product data management, product life cycle
management, customer relations, e-procurement, order tracking, warehouse management, data mining
systems, etc.

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:

1. 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.

2. 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.

3. 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.

4. Unsupported bolt on from a non-partner: Could get ugly Think twice, and then one more time
before implementing or integrating any unsupported solution!

Note:- The third-party vendor of the bolt-on is responsible for quality assurance and maintenance,
reducing the burden on the adopter. On the other hand, bolt-ons introduce complexity. The quality of
the bolt-on may depend on the quality of the communication between the ERP vendor and the bolt-on
developer. Further, there may be a “release lag”, where the bolt-on vendor is supporting an older
release of ERP system that the one the ERP vendor is currently offering to customers. This is likely to be
an issue during ERP system upgrading. Thus, the “weight” assigned to the bolt-on type of tailoring is a
matter of some debate.
When we talk about pockets of excellence, most bolt-on we’ve seen in ERP
environments come in 3 (three) typical categories:
1. 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.
2. 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.
3. 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.

Effect on Business Partner:-

Transactions can be posted using new trading partner 1153

Effect on System(s)

New trading partner 1153 will be configured in the system

Description of Change

Need a new Trading Partner created in SAP for netting affiliate vendor/customer
creation with the following details:

Trading Partner: 1153

Name: Actelion Pharmaceuticals US

Street: 5000 Shoreline Court

City: South San Francisco

Postal Code: 94080

Country: US

Transactional Currency: USD

Reason for Change

Business Transactions need to be posted with new Trading Partner 2111