Preface
Chapter 7: Implementing Successive Releases of ERP Systems
7.1 Distributed Processing Increases the Challenge of Implementing New Releases
example is the need to incorporate into the package support for the Product Markup Language (PML), which is an extension of the Extensible Markup Language (XML) — itself a development of the Web's HTML.[1] PML is discussed in Chapter 7.6; its functionality serves in handling smart materials, as it is on its way to becoming the standard language for describing physical objects. Smart materials is the theme of Section II.
[1]D.N. Chorafas, Visual Programming Technology, McGraw-Hill, New York, 1996.
7.1 Distributed Processing Increases the Challenge of Implementing New Releases
Implementing a new release was somewhat simpler when computer processing was centralized in huge hospital-looking buildings, with large internal glass windows to permit visitors to see the marvels of a machine with attendants wearing long white robes. While it had many other defects, particularly in downgrading efficiency and reliability, this concentration of data processing somehow simplified the change of a release. But in the 1950s and 1960s, new releases were scarce.
Today, it is different in many ways; the pace of releases and upgrades has accelerated while in the same user organization there may be multiple sites, and some of these IT sites are largely independent of the others. Therefore, a significant amount of coordination is necessary. Sometimes, release changes
at one site limit the available choices or affect the performance of the system at another site. User organizations are therefore well-advised to plan multi-site ERP and CRM implementations very thoroughly. They should do so before committing themselves to a given commodity software solution and its successive releases.
The main handicaps in implementing successive ERP releases concern background technical reasons, ranging from heterogeneous hardware platforms and OS/DBMS choices at user organization premises, to limited skill for keeping the system up-to-date at each site. Even if in the past years or months, the problems of heterogeneity of platforms and basic software were temporarily solved, they resurface with a new release, leaving companies to perceive migration as difficult, time-consuming, and costly.
New releases of commodity programming products, whether basic software or applications, are in fact a double-edged sword. One reason why the migration process takes so long to execute is the attention that needs to be paid to each existing heterogeneous platform. Another reason is wanting coordination and the traditional policy of many IT shops to move at slow pace. Indeed, the latter reason, more than any other, sees to it that some migrations to a new release receive bad reviews.
Whether one is talking about ERP, CRM, or any other programming product, multi-site coordination is the keyword. Keep in mind that many ERP-supported business functions are increasingly executed simultaneously, interactively, and in real-time. This requires business and systems staff to work in close collaboration with both the vendor and the different implementation sites, and to address all types of implementation issues in a rigorous way, including problems surfacing in one site but not in others.
People who have, on a number of occasions, gone through the experience of implementing new releases are commenting that, in their judgment, some of the complexities in ERP software releases emanate from the highly generalized nature of the off-the-shelf applications and from the fact that user organizations move to personalize these routines. This sees to it that diversity and therefore complexity increases, the more so if instead of a parametric customization, the user company alters some of the software. Good systems sense suggests that such alteration should not be made. Off-the-shelf software should be used as is, subject only to parametric customization, and the latter should take place only if such a facility is available by the vendor.
To help in evaluating the wisdom of adopting a new release, Exhibit 7.1 suggests a selection procedure for off-the-shelf programming products. Typically, a company has a list of top-ten functions it would like to see supported in a more efficient way than the one currently available. These come first in the evaluation. They are followed by key performance criteria.
Exhibit 7.1: A Radar Chart for Evaluating Five Different Sites of ERP Packages and Their Upgrades, Based on Four Factors
The ERP package, whose most recent upgrade is mapped in terms of effectiveness in the radar chart, was installed at five major sites of the EPSILON company (a ficticious name, but a real entity). Each site, identified I to V, tested the aftermath of the upgrade and came up with a rating reflected in Exhibit 7.1.
As the reader can appreciate, these ratings were diverse. At sites IV and V, for example, the cost of installing the new release hardly broke even with expected benefits. The question was therefore posed:
should EPSILON install this new release or forego its benefits?
The change of a release has significant costs associated with it.
These should be justified by an increase in functionality and performance.
Notice that this method is also applicable in the original selection of an ERP package and not only in evaluation of adopting successive releases. In original selection, the cost/benefit comparison will be against the current method.
Management should appreciate that migration between successive releases of ERP software is often a challenge. Even if one of the aims of new releases is that of improving business processes, one should have evidence that the upgrade is indeed benefiting the organization. Such evidence is obtained by pinpointing important business processes for which measurable results can be obtained.
By being careful with regard to cost-effectiveness, users can influence ERP vendors to add more functionality or to improve the efficiency of their releases. At the same time, vendors should be keen to test projected upgrades with user organizations. It is appropriate that the evolution of ERP solutions is influenced by changing market conditions, but there is a whole list of criteria to be observed, including better service-oriented approaches. Even if many organizations do not migrate the moment a new version becomes available, in the longer run they are motivated to adopt the new release for technical reasons and business opportunities.
At the level of user organization, not only does the current application's complexity need to be evaluated through benchmarks addressing the new release, along with expected benefits at each site, but future requirements must also be taken into account, given the evolution of demand for products and services.
For cost/benefit reasons, it is my policy to track the cost of the initial installation of an ERP system and of its subsequent releases. This can be done through a simple chart similar to the one presented in Exhibit 7.2.
Exhibit 7.2: Characteristic Features of Commodity Software Should be Analyzed Prior to Its Selection, and the Same Is True of Subsequent Releases
Functionality and performance criteria of the new release should be established by the company already implementing the programming product.
What the vendor says may be indicative, but it is not the bible. Both criteria and benchmarks should be the company's own.
It should as well be appreciated that an open architecture (see Chapter 6) presents better opportunities for an evolutionary process that is easy to implement and assists in establishing a business
differentiation. Not only does an open architecture ease the original integration task of commodity ERP software, but it also, other things being equal, simplifies the installation and operation of new releases.
Notice as well that with practically every new release, ERP, CRM, and other programming products can be configured through conceptual models linked with the repository of the system currently in use. That is why, to a very significant extent, rigid concepts customary with mainframe solutions are no longer welcome. What is needed is flexible targeting concepts that fit well with new releases and parametric customizing techniques.
The use of modeling tools can help in migration to a new release because they can assist in functional definition and in setting performance criteria. The existence of a development database makes it possible to have detailed documentation both at the business and technical levels. It also provides a good linkage to further upgrades.
I insist on these issues because the problem of upgrading is scheduled to become even more
pronounced in the coming years because a significant number of ERP and CRM application users are moving out of their current monolithic releases to take advantage of new functionality as it becomes available. While one is not obliged to adopt them, new releases are part of the natural evolution of ERP applications and aim to incorporate Internet enabling techniques that drive the requirements for
continuous integration of new routines. They also help in substituting aged in-house legacy applications, which should have been weeded out 10 or 20 years ago.