Modzilla!
Why modifying your ERP system might hatch monstrous problems
By Dave Turbide, contributing editor -- Manufacturing Business Technology, 6/1/2003 12:00:00 AM
It's a much-warned about, but not unheard of horror story. A manufacturer purchases a state-of-the art enterprise software suite and implements the system.
But almost immediately, users begin to complain that the new system isn't as good as the one it replaced. Bowing to user demands, the company's information technology (IT) department begins programming a series of modifications to make the system's processes mirror the way business had always been done, and make its reports look like the old ones.
Predictably, perhaps, the entire project costs more than expected, and the business fails to gain the anticipated results used to justify the project. Moreover, a year later the software vendor released a new version of the suite that contained some important new features, but the release couldn't be installed because of the large number of modifications that would need to be re-applied to the new code.
While your company may have been fortunate enough to avoid this kind of disappointment, you've probably heard of others that fell into this trap. Why do companies continue to make this same critical mistake?
Here's a summation of the reasoning:
-
Packaged software is, at best, an 85-percent "fit" to a company's needs.
-
Today's packaged software is far more flexible and adaptable than previous generations, but still cannot be molded into an exact fit for any given company.
-
A company's competitive edge is destroyed if forced to adapt to the processes embedded within standard packaged software functionality.
The short answer to all these concerns, quite simply, is that modifying packaged software is not a good idea. It is an expensive and time-consuming process, and delays the benefits of the new system.
Packaged software embodies industry "best practices," or at least the software developer's interpretation of how companies should be doing business. Many companies do well by adopting the practices embedded in their enterprise resources planning (ERP) systems.
"We have enhanced our ERP system, but we have not modified it," says Dale Gindlesperger, IT manager for Somerset, Pa.-based Fleetwood Folding Trailers, a user of the MAPICS XA ERP suite from Atlanta-based MAPICS. "There's no reason to do it [modify the software] because MAPICS supports the 'standard' way of doing business right down the line. Why would anyone want to change it? It works."
Gindlesperger makes a clear distinction between relatively benign add-ons and changing the programs delivered by the software vendor. This is a major point, in that a customized system may have a few tweaks to its look and feel, but the core code of the system hasn't been changed. While this distinction remains important to the issue of modifications, it's also true that software vendors have introduced more powerful mechanisms for customization that minimize the need for modifications.
Big distinction
At Fleetwood, which manufactures the Coleman pop-up tent camper, the company had a high level of confidence in the design and completeness of the XA software package, yet it has added a number of custom programs and third-party add-ons to accommodate some additional needs. But the company follows the proper procedures and use of application programming interfaces (APIs) to ensure the changes are manageable. "We make good use of APIs and user exits to adapt the software for unique requirements that are important to our business," says Gindlesperger.
APIs are built-in connections that can be used to add functionality without changing the underlying vendor-supplied programs. One add-on at Fleetwood produces some additional paperwork needed to accurately assemble the camper-trailers the company makes.
Actually changing vendor-provided code is another matter entirely. Source code—the original, human-readable program code—is nearly always available to ERP user companies, albeit sometimes at extra cost. A talented programmer, familiar with the programming language and the conventions used by the vendor, can easily "open" a vendor-provided program, make changes to accommodate company needs, then recompile and insert the modified program into the mix. But it's not quite that simple to manage such changes over time.
A change in one area of a program might yield unexpected effects elsewhere in that program, or in another area of the application altogether. Today's application suites are large, complex, and tightly integrated. Changing vendor-provided programs also brings the integrity of the applications into question, from an auditability standpoint, and makes it difficult to get support from the original vendor. When a software vendor's support organization learns that there is modified code present, some simply refuse to help, while others are severely impacted by the presence of unknown code within their programs.
Once a company has modified programs, they have assumed responsibility for validating and maintaining those applications. One of the most important advantages of packaged software is centralized support and upgrades offered by the vendor for a modest annual fee—typically 12 percent to 16 percent of the purchase price.
The vendor uses this revenue to support help desks, online knowledge bases, bug fixes, and continuing enhancements to the product. When a fix or an enhancement is shipped to current customers, it is most often in the form of replacement programs. If the user has modified vendor programs, the replacements will override the previous changes and the user must re-apply the changes. Most software vendors provide such updates once per year.
Extensively modified packages become difficult and expensive to keep current, since any program changes must be re-applied every time an update is received. As a result, these user companies often "freeze" their system at a given release level and ignore future releases.
If you must
If you decide to modify packaged software, it pays to know what you are doing and take advantage of some of the tools that are available. Companies like Fleetwood establish internal policies and controls that isolate non-vendor-supplied programs and maintain the integrity of the application software suite.
"We put all custom, third-party, and modified programs in a separate library and keep the MAPICS-supplied programs clean," Gindlesperger explains. The IBM i-Series computer the MAPICS XA suite runs on employs a library-list structure that allows Gindlesperger to keep program versions (modified and unmodified) that share the same name in separate groups, and direct the system to run the modified programs and ignore the originals. In that way, system updates can be installed over the originals and the modified programs compared, tested, and validated without losing track of what the vendor supplied and will support.
Software companies such as San Mateo, Calif.-based Serena Software make change-management tools that provide a structure to control program development and modification. "You have to keep track of who did the modification, and exactly what was done. You also have to keep a history for impact analysis, so as to be able to re-apply a modification if the need arises," says Chuck Henderson, Serena's director of product marketing.
Serena's change-management infrastructure tracks all the changes, stores the different versions of the programs, and stores the processes that were used in making the changes. In this way, the whole change process becomes systematic so that it can be undone or redone if necessary. "If you're going to make changes to software, keep the process in control," Henderson emphasizes. "Make sure it's done by the right people, following a defined process, and that it's done the same way every time, with every action logged to provide an audit trail."
The design of packaged software has always allowed some level of tailoring. This includes the ability to pre-set defaults, process sequences, and the kinds of information that is passed from one part of the system to another. In recent years, the extent of that tailorability has increased dramatically, with some systems offering literally thousands of choices.
Most systems today are built around a workflow engine that automates processes and enhances communication throughout the system, and beyond. Web services promises to take process automation and inter-system interaction to a whole new level. Today's Web-oriented designs also lend flexibility, especially with portal user interfaces that can be configured to more closely match the information needs of users. Finally, configurable object repositories and component-based design also contribute to the adaptability of enterprise software by making it possible to tweak a system via utilities that configure and manage a "middle tier" of software components.
Must you?
The question still remains as to whether modifications are truly necessary. The Colorcon division of Berwind Pharmaceutical Services believes you shouldn't change packaged enterprise applications. The West Point, Pa.-based manufacturer of film coatings for pills and nutritional supplements uses the 11i ERP suite from Redwood Shores, Calif.-based Oracle Corp. "We kept our enterprise software plain vanilla, except for a small addition to handle sub-lots that took two man-days to complete," says Perry Cozzone, CIO.
Colorcon made a conscious decision not to change the package. "We ask, 'Why is it designed to work that way?' and compare that [process] to what we are doing today," says Cozzone. "If there's a gap, we try to understand how the software's procedure may be better than the way we currently do things."
Colorcon also stays in close touch with Oracle to let the developers know how the software could be improved. "We leverage our partnership with Oracle; we participate in an advisory board to help shape the product," Cozzone says.
Cozzone emphasizes that this influencing of future development cannot be self-serving. "We are willing to wait for 'x' number of months to get enhancements because it is a better choice than changing the software ourselves," he says. "But we understand that the changes we lobby for must be of benefit to other similar manufacturers for it to make sense for Oracle to make the change."
Even with vendor advances in making systems more flexible, a willingness to adopt embedded processes remains key to avoiding disastrous modifications. The desire to cling to the familiar is understandable, but changing a new package to make it resemble its predecessor is a good way to cancel out any value from the system investment. The way to overcome this tendency is to provide adequate user education. Users will naturally cling to the familiar if they are not taught what the new system does.
As to the issue of competitive advantage, the factors that make a difference typically are not to be found in the core processes embedded within ERP systems. The true advantage comes from how those processes are executed in support of well-defined strategies.
| Who's inside | ||
| MAPICS: www.mapics.com | Oracle Corp.: www.oracle.com | Serena Software: www.serena.com |
Change from Inside or Outside of the System
10/23/2009A distinct possibility
05/31/2003
