If your current enterprise systems are not meeting your needs (don’t have the functions, or can’t handle your volume), who needs an article to decide to replace them? But what if you are reasonably pleased with the systems you have in place? Is this a bonus — one less thing to worry about — or is your complacency a dangerous mirage, with your business likely headed for some kind of systems quicksand?
Going by the book, replacing a legacy enterprise system has certain well-defined trigger points defined by costs, vendor relationships, and technology obsolescence. The real deal on upgrading and replacing major applications like a WMS or order management system is often a very different story, however. Some companies happily coast along on third-party systems much more than ten years old, quite content to maintain them in-house without support from the original vendor, who has long since gone out of business.
Such examples refer only to systems run by companies with a small IT department. If an organization has made a major investment in supporting a system in-house (whether written from scratch or adopted for development in-house), the tendency to hold on is even stronger.
THE KJM STRATEGY
Before we get to those “by the book” issues of technology and ROI, let’s stay a bit longer in the real world, where the priorities are most often people-related. Namely, “Do I have the people I need to maintain my current application?” and “How much would it cost me to replace those people, if I needed to?”
Some executives approach those questions with a harsh calculus that says, “The only thing computer science graduates know these days is Microsoft technology; if my systems are based on something else, in a few years, when my current [read “aging”] staff retires, I won’t be able to find anyone else to run them.”
That’s the KJM, or “knee-jerk Microsoft” reaction. There is a grain of truth in it, but the “retirement” or “replacement” horizon is often five, ten, or more years in the future. Microsoft will most likely be an even bigger player then, but will the current tools — Visual Basic, SQL/Server, and .Net — still be mainstream? Pursuing the KJM strategy today may be a sounder strategy than staying on a Cobol system running on an obsolete or expensive hardware platform, but it may not be the nirvana of safety the KJM strategy implies. After all, ten years ago PowerBuilder was all the rage, and Visual Basic was barely on the radar screen. PowerBuilder remains a fine development platform, but hardly one that equates to readily available, generic programming support from new computer school grads.
LEGACY LOVE
The KJM perspective emanates from the executive suite. Over in the IT department, there’s a whole different story. It’s partly “Don’t rock the boat,” partly “We know the legacy system inside out and can do anything we want with it,” partly “The devil we know vs. the devil we don’t,” and, of course, partly good old job preservation.
These leitmotifs are no less valid than the KJM approach. In fact, they are often a lot more valid.
For instance, one of the industry’s major order management systems, written in Cobol and running on the HP 3000 platform, is facing the imminent departure of Hewlett-Packard’s support for the HP 3000 and its native Image database in 2006. However, there has been no great rush for the exits on the part of the user base, which numbers several hundred. Instead, third-party companies have sprung up to support both the application and the HP 3000, and are reportedly doing an outstanding job on both counts. Says one user, “The support we get from a third-party outfit on our HP stuff is the best we’ve ever had. And we have a complete inventory of spare boards and drives here on consignment should we ever need them.”
This is not at all atypical. There is life after death (LAD) for many a popular package and platform. If the spirit is there, along with a true support network for both hardware and software, there is nothing at all crazy about the LAD strategy. In fact, the above quote is not from the IT department but from the CEO.
RITES OF PASSAGE
The traditional model of systems maintenance assumes that a company is undergoing steady growth. With this growth come new agendas, new managers, new ideas, new locations, new challenges, and new priorities.
Does all this newness equate to new systems, as well? That’s the rub. As we said at the outset, if you have outgrown your legacy applications, you obviously need to take some kind of action. Even if you haven’t outgrown them, you may wish to plan an orderly transition to another application, rather than waiting until the transition has to be rushed and thus almost certainly compromised.
To simplify matters, here’s a summary of the variables you need to consider:
Functionality
Do the current system and the vendor’s foreseeable upgrade plans support a broad enough range of features and functions for you? If not, can you get cost-effective customization that will still support future upgrades? (Be sure to do a careful audit of usage, too; sometimes the system can do things you don’t believe it can.)
Support
Is the vendor’s support adequate? If not, can you get good third-party support? What about support for features that you have already customized?
Scalability
What volume of transactions can the system eventually support, and at what cost for hardware and licenses?
Interoperability
A big issue in today’s Web-enabled world — how well can the system be integrated with your e-commerce site, your supply chain, and with other support systems (such as merchandise forecasting or database marketing solutions)?
Extensibility
Does the vendor have plans to broaden the scope of the system, add new modules (such as content management), or support new protocols such as XML, .Net, or hand-held devices?
Ease of use
How easy is the system to use? How long does it take to train new users? On an order management system, can you configure a simplified interface for temporary operators or newcomers? Does the vendor offer refresher training?
Database access/reporting
How clean is the system’s data? How accessible? How easy is it to export data for external analysis? Are the reporting options adequate? How easy is it to create and recreate ad hoc reports?
Cost
Are costs reasonable for ongoing support, refresher training, modifications, and other services?
PAIN/GAIN
And finally, you need to factor in all the true costs of making a transition, including some form of enterprise systems plan, a thorough needs analysis, a business process reengineering check-up, and a change management team that will spend approximately at least 400 person-hours from start to finish on the systems replacement process. Otherwise, you may be creating more problems than you solve.
Ernie Schell is president of Marketing Systems Analysis Inc. in Southampton, PA. He can be reached at (215) 396-0660 or [email protected].
WMS Classics
ACT 1 from Rigden
(303) 442-8190
www.rigden.com
Assist from AssistCornerstone
(801) 355-7744
www.assistcornerstone.com
Controller+ from Sigma-Micro
(317) 631-0907
www.sigma-micro.com
CWDirect from CommercialWare
Commercialware Inc., (508) 655-7500
www.commercialware.com
Directions from Peppler
(847) 382-6866
www.peppler.com
Ecometry from Ecometry
(561) 265-2700
www.ecometry.com
OrderPower! from Computer Solutions Inc.
(305) 558-7000
www.csiflorida.com
MACH 2K from Data Management Assoc.
(513) 563-7300
www.mach2k.com
MOSP from Datamann
(802) 295-6600
www.datamann.com
Synaro from Island Pacific
(800) 569-1122
www.synaro.co