An End User’s ERP History – from Baan IV to E10
Back when I still worked for a manufacturing company, in a magnificent sprawl of factory and office buildings, I had a reputation for being a fast walker. I’d bustle through the labyrinthine hallways of the office and scale the grand aisles of the factory. With my head down in a shoegazer’s stride, I’d often come into near collisions with whiteboards or drill presses. At the time, I was shaped roughly like a college linebacker, and my coworkers would clear the path when they saw me coming. “Slow mind, fast feet,” one of my supervisors once remarked. When people asked why I walked so fast, I replied, “It’s hard to hit a moving target.” In a company that had a reputation for random layoffs, this was a sufficient answer — an insider’s aphorism.
ERP systems are rarely a moving target. A stationary target is usually either a soon-to-be-victim or a roadside misfortune. When I first entered the business world, my company was replacing its mishmash of homegrown systems with Baan’s flagship ERP solution, Baan IV, well before the panic of Y2K. New to the company, and still learning what I could do to get by, it was no big deal to me. But to my wiser, more experienced coworkers, it was an all-out affront to their sensibilities. These were folks accustomed to the keyword-laden world of green screens and shortcuts, for whom the art of the double-click was still a work in process. So, the transition took a while, in spite of the new software being pretty solid.
Baan, as the company proper, went into a tailspin shortly thereafter, and its software was absorbed into countless versions of other applications. I once sat down with a veteran consultant who had been with SSA Global and then with Infor during these transitions. He gave me the entire evolutionary history of the Baan product over a burger and fries. It was quite a mouthful coming from one of the application’s dedicants.
When it came time to replace our own ERP system, the manufacturing company I was with opted to move to Epicor’s Vantage ERP system. Compared to Baan’s Unix-based architecture, Vantage’s look and feel seemed pretty modern and user-friendly, especially in the mid-to-late 2000s. Now, Epicor’s manufacturing ERP product had its own special evolutionary history, and we happened to hitch a ride to its moving train while it was plowing forward at full speed, but still halfway from its destination. Vantage had originally been architected using the Progress 4GL business language, both at an application and database level. But as Microsoft became the dominant application platform, the company opted to begin a migration process to a fully Microsoft-centric stack. And a long strange trip it’s been.
From my own starting point, I’ve been able to watch other customers navigate the challenges of simplicity and performance vs. currency and maintainability, all the way through to the challenges of new functionality vs. platform stability.
Epicor’s Vantage 8.0 version was the first step in this evolution. Being a client-server application, they replaced the Progress client with a Windows-based client, while retaining the Progress business logic layer on the server. Better still, they now provided the option for a SQL Server database. The initial results were… bumpy. One can imagine why combining so many architectural layers would certainly be a veritable middleware nightmare. Earnest effort went into remedying these issues, and the result was Vantage 8.03, a more stable version of 8.0.
A major functionality uplift had been teased for a number of years, under the guise of “Version 9.” While still possessing the same basic backend architecture, the features and capabilities of the new version were to be a real advance from the current release. The first installment of this promise was Epicor version 9.04, and the results were less than optimal. Sure, the functionality was there, but the performance was abysmal. At my own company, we never got so far as to implement 9.04, given that 9.05 was released on its tail in short order and addressed some of the issues that plagued its antecedent. But at some point, it became known that 905 itself was going to be the last major release on the current architecture, that the next major release would be devoid of the Progress-based 4GL backend, and that in its place would reside an entirely Microsoft-centric server-side stack.
This finally came to fruition with Epicor’s version 10. And the challenges experienced by the user community were similar to the previous versions. In moving to E10, Epicor essentially rewrote much of the application’s backend, turning those in the end-user community on the bleeding edge essentially into beta testers. The challenges of working through the kinks involved were significant. Now a consultant and no longer a customer, I experienced the application from a new perspective as I tried to confirm just which of the legacy version’s features could and could not be supported by the new version. Working in some of the more complex areas of the application, such as product configuration and MRP, I’ve encountered many show-stopping issues that put customer implementations in holding patterns. As with 904, a relatively small subset of Epicor customers went live on 10.0, many opting to wait until 10.1’s more stable version was released. Since 10.1, the version has been remarkably stable, with each new version offering more and more capabilities without undermining previous functionality.
My ERP journey over the past 20 years has been a long, strange trip indeed. From my own starting point, I’ve been able to watch other customers navigate the challenges of simplicity and performance vs. currency and maintainability, all the way through to the challenges of new functionality vs. platform stability. Looking back, I’ve wondered if I’ve learned anything from my IT travels. Though I won’t scribe any hard-and-fast rules into marble, there are a few things that are worth mentioning:
- Software goes through cycles. The stability, capabilities, and performance of an application all vary over time. Understand this and plan accordingly.
- A company’s success with an ERP implementation varies according the point in the cycle where they enter the fray. Entering on a stable version might not give you all the bells and whistles you desire but will likely make for a more successful implementation.
- Stability applies to an ERP vendor as much as it does to their software. When you engage an ERP vendor, it’s good to understand the company’s stability.
- An unstable vendor may quickly devolve into an unstable platform or, worse, into an unsupported platform.
- When upgrading an application to a more recent version, be leery of the “bleeding edge” syndrome. All other things being equal, it’s good to let the major version of an application settle down before taking it on. Premature adoption can lead to catastrophic implementation.
