The Business Logic
Ultimately your ERP
system must do its number crunching. Programs must be written that
will accept data supplied by input from the keyboard or through
interface with other intelligent devices and add, subtract,
multiply, divide, collate, sort, slice, and dice your data and then
update the appropriate files. This set of internal application
programs comprises your business logic layer.
By and large, this
layer, like the RDBMS layer upon which it rests, is invisible to the
end user. It goes about its work quietly and generally very
reliably. Of course, it depends upon the successful entry or
transmission of data and is subject to the old information systems
maxim, "garbage in, garbage out."
The ERP business
logic layer might include the programs that will perform such varied
tasks as exploding your bill of materials to depreciating your
fixed assets. It also goes about the business of relieving and
replenishing inventory and checking credit limits for your
customers as a sales order entry clerk provides the raw data. As
the ERP definition indicates, the business logic layer drives the
functionality to "identify and plan for the enterprise-wide
resources necessary to take, make, ship, and account for customer
orders or services."
We believe that the
strategic qualifiers for the business logic layer are suitability
For your ERP
application to be viable, it must be suitable for your business
processing needs. While this sounds very basic, you would be
surprised at the number of software selections that are made without
a rigorous business case analysis. A complete discussion of how to
determine the suitability of ERP application is far beyond the
scope of this paper. However, we do offer the following basic
• Create an
empowered group of cross-functional users to formulate the key
business requirements (business logic).
• Focus on those activities that add value to the company, and
encourage creative thinking to reengineer old procedures and
assumptions that are no longer valid.
• Create a list of detailed functional requirements and allow
potential ERP vendors ample time to respond.
• For select vendors, create key business scenarios, and ask for
product demonstrations to focus on these areas (again with ample
• Validate your ERP selection with a comprehensive conference room
pilot early on in the implementation process.
The last step is
critical to ensuring the success of your ERP implementation. The
purpose of the conference room pilot is not only to validate the
software selection, but also to identify the inevitable gaps between
the requirements and the software that must be filled by
workarounds, process reengineering, or software modifications. In
some instances, your preferred ERP provider may be willing to
participate in the conference room pilot before the final funding
has been executed.
For your ERP
application to be durable, it must be flexible enough to accommodate
changes to incorporate current and future business process
requirements. It is important that you gain an understanding of your
ERP vendor's approach to modifications, particularly to the
business logic layer. We encourage modifications only when they are
necessary to capture a business process that is key to your
company's unique source of competitive advantage (for example, to
capture a pricing algorithm that is critical to gaining and
We offer the
following key considerations when making modifications to the
business logic layer:
Can the required
business logic be attained by altering parameter
• Can the required
business logic be captured in modifications outside of the core
code and implemented by triggers within the code? (Many ERP systems
are adopting this approach.)
• Are there other, best-of-breed solutions that could be integrated
with the ERP package to provide the business logic? If so, does the
ERP package provide a stable and secure integration path?
• If core code modifications are required, what steps will ensure
the application will not become "rev-locked"?
The last point is
very important to the durability of your system. "Rev-locked" (or
revision locked) refers to a condition in which your software has
been modified to such a degree that upgrades to a new version are
impossible or cost prohibitive. While the software may perform
adequately for you using the existing version in current
conditions, changing business conditions may mandate the need for
additional functionality, Y2K fixes, etc., that are only available
in later versions.
As always, there are costs associated with changes to the business
logic layer, and in some cases these may exceed the initial
investment in the software itself! It is important that these costs
are identified early on and are included in the business case
To Be Continued