Fans of 1970’s sitcoms and syndicated late-night television know the scene too well. The show was the long-running strip of analog nostalgia known as “Happy Days.” The episode was the Season 5 premiere. The setting was new: after four seasons of teenage angst centered around Arnold’s Drive-in, the show briefly moved its location to the beaches of California. The plot was abysmal: on some silly pretext, its standout character, Arthur “Fonzie” Fonzarelli, clad in a leather jacket and Bermuda shorts, water-ski-jumps a tiger shark, proving his tropical machismo for all to see. In retrospect, results were understandable; the show went on for many seasons, but never with the same pop and sizzle of the greasy diner days. The narrative had broached the limits of its own heuristic, and the damage was irreparable—the show had “jumped the shark.”
“Jumping the shark” has come to take on a broad meaning, extending beyond popular culture. Wikipedia defines the term jumping the shark to refer to the moment when a brand, design, franchise, or creative effort’s evolution declines, or when it changes notably in style into something unwelcome. Jumping the shark is the moment where an entity has reached its proverbial apogee and thereafter inevitably and irrevocably begins its downward slope. This happens with TV shows, with athletes, and, unfortunately, with ERP applications when you don’t get an ERP software upgrade. So why update your software?
I once worked for a company that implemented a hip and snazzy Tier 1 ERP system in 1999. Over the next ten years, the package implemented was resold, re-branded, and reworked multiple times; to such an extent that it no longer resembled its antecedent. Moreover, the company had done little to keep up with these changes, and after ten years, the system it implemented had essentially jumped the shark. In 2009, the company moved to an equally hip and snazzy ERP system, but with upgrades—now it had a Microsoft .Net user interface and a SQL Server database. There was this iffy Progress OpenEdge middle layer, but even still, the overall package seemed bright and beaming, compared to the dim hue of the application it replaced. The application implemented in 2009 was Epicor’s Vantage 8.03 ERP system.
Now, as we near 2018, companies continue to question the systems implemented in the first decade of our new millennium. No longer the strategic advantage that it was at cut-over, companies’ enterprise systems have slowly morphed into liabilities when trying to reconcile ERP structure vs. company structure. And as digital transformation increasingly becomes the norm, companies can greatly benefit from understanding whether its ERP system has outlived its usefulness to the organization. Below are a number of ways to know whether your ERP system has jumped the shark, and the reasons why you need an ERP system upgrade:
- You’ve lost track of the number of major releases between the current software version and the version you are currently on; or the number of service packs outnumber your fingers and toes. Does your current application have a suffix in the range of 6.0 or 8.0, while the vendor is peddling products with a moniker broaching double digits? That might be a problem.
- The ERP vendor from whom you purchased the software has since been acquired by another ERP vendor. When vendors merge, application consolidation often follows. Typically this involves the sun-setting of certain applications in favor of others, which means that customers of discontinued applications may find themselves tied to a dwindling thread of support. When mergers or acquisitions happen, understand the implications to your enterprise application—it may involve new investments.
- The ERP product being used has since been re-branded. Epicor’s Vantage 803 has been re-branded twice—first to the Epicor 904/905 series, and now to the ERP 10 platform. Vendors generally offer migration paths for existing customers when re-branding products. Often, this is because application re-branding generally coincides with significant infrastructural and functional changes to the application itself. Explore the migration path options—perhaps it will take you somewhere.
- Is your current application written in a propriety language that is no longer supported? Or was it built on a server platform that you no longer want to support? Or does it use a database that you are no longer comfortable with? Perhaps it’s time to find a better fit.
- Your company’s direction relating to application, database, or operating system architecture has changed dramatically since the original implementation. Sometimes the software has kept up but the business has changed. In these cases, a re-implementation might be in order.