By RUSS HARRIS
Corporate Director of Materials Systems EFTC Corp.
Denver, Colo.
Most off-the-shelf Enterprise Resource Planning (ERP) software packages do not meet the precise needs of most manufacturing operations. Generic ERP software often lacks key components needed in many manufacturing operations, such as the ability to gracefully handle several different approved manufacturer's lists (AML), or to seamlessly exchange documents with B2B (business-to-business) trading partners. Although companies the size of General Electric and Ford can afford to fully integrate all their operations across a common platform, smaller companies would be priced out of the market if software was only offered as a "one size fits all" and could not be customized.
Manufacturing managers naturally prefer a system similar to a well-tailored suit, or a brand-new, factory-ordered car with all the requisite whistles and bells. Their counterparts in the information technology world, however, dread the word "customization" and all the development costs, testing, and upgrade difficulties that come with it. Changes are required sometimes, but they should be avoided unless they are critical to business.
Why customize?
Even with a myriad of software choices in the marketplace, most applications are sold in one flavor — vanilla. Software companies cannot afford to develop packages for every industry. The time needed to develop programs that accommodated all the idiosyncrasies of a specific industry would, again, price smaller companies out of the market.
There is some vertical integration in which programs designed for a few industries are offered by a single software supplier. WebPLAN Inc., for example, offers planning and scheduling tools for e-supply chains which are tailored to the aerospace, industrial equipment, and electronics manufacturing industries, to name a few. And Oracle has specific offerings aimed at consumer products, energy, and telecommunication sectors.
Still, industry-specific offerings are rare. In most cases, companies turning out teddy bears or computer games will use the same ERP software as companies building hundreds of different electronics assemblies for dozens of different companies. The two types of businesses are quite different, yet their software packages are exactly the same. This is where customization comes in.
"ERP software can remain generic or vanilla, but it is rare," says Ray Schnulle, a technical manager for Oracle Corp. "Gener-ally, only startups and distribution businesses can use ERP software without customization. But I have not been on an implementation in the last five years that did not have some customization, although most involved only changing the reports."
That's not unusual since the most common customization to ERP software concerns reports. Changing the report format, adding a column, or calculating additional fields of information, is quite common and usually the first modification made. But reports can tax system and human resources if they need too much information that is buried deep in the underlying database. Many midsize and larger companies have data warehouses on a different server, and data may be "refreshed," or renewed every so often, perhaps once per week. This takes the reporting load off the main system. Data-mining tools, which are basically ad hoc query tools, let users generate an endless variety of "what if" reports to suit their needs. Specific reports that are large enough or used often enough can be "tuned" by Information Technology personnel to run faster and use fewer resources.
Some complex customizations are business requirements. Adding additional data fields to a database and developing a custom report to extract that data is probably the most innocuous form of customization. Specialized processes, or reports, can be set to run "be-hind the scenes" automatically to update certain pieces of the software or underlying database information. Triggers, which start a custom process whenever a user enters data or accesses a specific form, are a higher-level of customization. Customizing a "form" or what the user sees, generally requires much more technical skills. Changing a program's underlying applications code, while possible, should be avoided. Even if the source code is available from the software vendor and an IT person with enough technical prowess can be found, customizing at this level is generally costly and time consuming.
Pitfalls of customizing
The complexity and expense of customizations is naturally a downfall, according to Schnulle. "Many customizations do not provide any cost benefits. They are basic requirements for doing business in certain industries."
Rewriting or changing software calls for a software developer or programmer, a scarce resource at companies suffering critical shortages of skilled IT workers. And in today's employment marketplace, that can be just about any company. Another common problem with rewriting code in off-the-shelf software is that it could cause problems elsewhere. Screwing up a key software link in a program, for example, could fatally flaw data the company relies on to make timely and accurate decisions.
Then there are the problems with patches and upgrades to fix bugs. Software suppliers regularly release patches, best described as "baby upgrades," to these large, complex ERP programs. And sometimes, the baby is pretty big. These patches, like the original software, are often written "for the masses." Companies have been known to haphazardly implement a patch only to discover it replaced customized code which took week and thousands of dollars to develop. Oops. Time to start over.
Full product upgrades, such as Oracle's latest 11I release, require that all customizations done at an installation be retested, and if necessary, rewritten. Again, this can expensive and time consuming.
Choosing an ERP package
Firms often mistakenly implement new ERP applications believing that standardized software will standardize their business processes. The software might complement standardized practices, even help facilitate them, but it will not bring about standardization on its own.
Once business practices and standard operations are understood, it is time to study the packages under consideration, and what custom features they will require, if any. Determine if one supplier's offerings are more closely suited to your business processes before investing hundreds of thousands, if not millions of dollars in new software. Remember, software that will needs extensive modifications will be expensive to implement and difficult to maintain and upgrade.
Each required modification should be decided upon ahead of the installation. Companies should estimate the impact each modification will have on the final price. According to Slavko Cvencek, president of Boulder, Colo.based NBI Technical Services, "Each customization is based on the level of complexity and 'downwind' ramifications pertaining to the changes. It is quite difficult to standardize a cost/benefit policy for customizations, although ballpark figures are usually generated after initial investigation of the scope of the work to be performed."
Document, document, document
After making a "go/no go" decision as to what ERP package to purchase and put in place, document the reasons and file them away. You can be sure the question as to why the project was canceled or why it went forward will be asked again.
Code used for modifications should also be carefully documented as it is developed. If one programmer's work cannot be modified or understood by another, the company could be in trouble, especially if it finds itself at odds with the original programmer down the road. User manuals should be modified or created as the program is developed.
Before customized software is put on the company's hardware for employee use, it should undergo extensive testing, in a test system if possible. It should be tested by the developer, system analysts from the IT department, people well-versed in the processes of the department requesting the modification, and, finally, the end users — in that order. The change should be clearly announced within the company and released on schedule after all potential users have been trained. Nobody likes software "surprises."
Change control, after making upgrades or enhancements, is another critical function. This is a "gotcha" for many organizations. There are many off-the-shelf systems designed to help companies handle revisions. At a minimum, a log of what was changed, by whom and why, should be archived along with copies of the premodification program code and the new code. This makes it possible to revert to previous "known-to-work" software in case the new software doesn't work or there is a systems catastrophe.
Managing the modifications
Another challenging area for many companies is to smoothly manage the transition to ERP. Many firms get the software snarled up with needless changes because the people making them do not understand the firm's business practices or the approval process, if there is one. For example, if a single user, even an executive, believes a modification would help him or her do a job, the modification might be counterproductive for the rest of the company. A change request process should have a filter up front to catch these "bad" ideas.
Employees who want specific modifications should be prepared to cost-justify the expense. In the case of limited resources, these costs should include "opportunity costs," or the benefits the company will lose if resources assigned to customizing the software are unavailable for other projects.
Cross-functional teams are especially useful in managing software customizations. The group should consist of IT technical resources, representatives of departments requesting changes, representatives from any other areas of the business that will be affected by the change, and appropriate management personnel. The team should first determine: Who is requesting the change? Why is it necessary? Who will benefit? Where could it cause problems? Who can make the change? How do we do it? And last, but not least, Is it really necessary?
Systems users may withdraw their change request once they are aware of how their proposed change could hurt another area of the business, or they come to understand the complexity and expense of what they want. Then again, maybe they won't. The transition team therefore needs at least one executive-level decision maker to refuse unwarranted changes.
Striking a balance between customized and standard ERP systems is a difficult proposition at best. With all the different interests at stake, it is virtually impossible to satisfy everyone. But, with careful consideration of the alternatives, a thorough understanding of the company's business processes, and concentrated effort at documenting, testing, and controlling the modifications, benefits can be realized by almost any organization. Customization can enhance the value of off-the-shelf software, letting the company add more value for their customers — both internal and external.