Select Page
Fonzie Schemes: Has Your ERP System Jumped the Shark?

Fonzie Schemes: Has Your ERP System Jumped the Shark?

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.

 

To customers of Epicor’s legacy 803 and 905 platforms, the answer is clear: the shark has been jumped—it’s time to change the channel and upgrade. Are you ready to upgrade? Download our Upgrade toolset to help you get ready to make that jump.

Epicor Configurator Upgrade: Some Reassembly Required

All About Epicor 10.2 Product Configurator

With the festive season charging forward like a white-tailed deer dodging a hunter’s shot, I began to reflect on some of the holiday gifts I had received as a child. I remember finding my brightly colored box named for me, ripping through the wrapping paper with glee, anxious to find just what was bottled up inside the cardboard box of the year—normally some elaborate plastic play-thing, composed of more components than angels on a pin. Pulling open the cardboard gates, I routinely discovered that the contents of a box never quite resembled the shiny images on its outer face. That is, there was one pivotal phrase that stood between the receipt of a gift and its actual usage: “Some assembly required.”

That single phrase was as impassible and looming as the Sphinx. Upon reading this riddle, I would rush to my father and beg him to figure it out for me, and in typical holiday spirits, he would lay his eggnog aside and curse his way through the necessary assembly. The lessons learned through these experiences stayed with me into adulthood. Now, as I’ve perused the aisles of the local box shop, looking for a suitable gift for my own, I’ve quickly learned to spot the familiar warning—and move on. I’ve become known as the parent who has bequeathed gifts like modeling clay for the holidays. It encourages the imagination, I’ve claimed. Moreover, there is no way for a parent to botch its assembly!

With Epicor’s version 10.2 similarly cresting the horizon like a jolly old man in a flying toboggan, I’ve come to notice how customers utilizing Epicor’s legacy Product Configurator react to the idea of an upgrade in much the same way I’ve reacted to a 600-piece dollhouse—they duck into the next aisle. In any version, Epicor’s Product Configurator is a complex module—it is part functional setup, part development toolkit. And companies spend a lot of work in developing the configurators that will support their business requirements. That is, there is a lot of assemblies required, once this gift is unwrapped. And the idea of reimplementing Epicor 10 configurator for a new version feels, to some customers, like their dollhouse just got smashed, and they are required to reassemble it again, only now with a new set of assembly instructions.

In spite of these understandable concerns, I believe Epicor’s 10.X configurator platform is a tremendous improvement to its previous iterations: it is more scalable, more flexible, and allows for better-designed solutions that yield a better end-user experiences. And try as I might, I can find no CPQ solutions made of modeling clay…

While there are no easy instructions when it comes to upgrading Epicor 10 configurators, I have found, in working with customers, that there are a few lessons that we’ve learned, lessons that could be thought of as “reassembly instructions.”

A few might include the following:

I have found that it benefits customers to run an early initial trial upgrade of their existing Epicor database, strictly for purposes of reviewing the upgraded configurators. With each new version of 10.X.XXX, the upgrade process gets tweaked and improved, so issues upgrading configurators in one version may be resolved in another, and the upgraded configurators may be sufficiently intact, as to constitute a decent starting point from which to begin their efforts.

In terms of business logic, companies benefit when they look for opportunities to utilize UD methods in lieu of the on-leave event handlers in legacy versions. These can be a helpful way of centralizing code, and even a nice way just to pull it out and give it a clear and distinct definition, which allows for more logical designs and greater maintainability.
In terms of Method Rules, companies should look to consolidate the many individual rules from legacy versions into single statements in 10. In the Epicor 10 configurator rule designer, the option to “execute specified expression” allows for great freedom in developing blocks of code to update multiple fields at once. This allows customers to consolidate all of their efforts into a single place, which usually makes for better maintainability.

In most cases, the development of a solid C# skillset is a must for working in configurator 10.X, in much the same way that Progress ABL/4GL skills were central to Epicor’s legacy configurators, particularly if the configurator being upgraded has a lot of custom code to manage its business logic.

Converting code need not require a .net savant. There is the web page for converting 4GL to C#–that can get you in the ballpark, one block at a time. But for the absolute novice to C#, it helps to have someone available who has worked in C# and Progress-based configurator environments.

C# has a few particularities that are critical to handle right away, as they will prevent a block of code from passing syntax check. These include:

The use of a semicolon: all statements end with a semicolon.

Braces: multi-line blocks of code (such as if-then blocks, switch statements, or for each blocks) are wrapped in braces (“{}”).

Case Sensitivity: C# is a case-sensitive language. That is, the .net compiler will interpret “cmbPartNum” to be something other than “cmbpartnum.” This is an infuriating peculiarity for someone coming from a Progress environment, where the case did not matter.

Object Orientation: in the .net platform, interaction with any program involves the use of object properties and methods. This involves commands that differ somewhat from the legacy design. For instance, a command to update a field in 10.X, you might look like ‘Inputs.chrPartDesc.Value = “lalala”’ whereas the same command in the progress-based configurator would look like “chrPartDesc = ‘lalala’”. Understanding these small differences can go a long way in making steady progress in configurator conversion.

I find it a good approach to have a customer review their existing configurator code base prior to the upgrade, and identify each unique king of logical activity they perform. This might include, but is not limited to the following:

  1. For each loops
  2. Switch Statements
  3. If then else logic
  4. Reading UD tables
  5. Writing to UD Tables

From there, the customer can develop a solution catalogue for addressing each unique code construct—how the each unique activities performed in Progress 4GL would be performed in C#. The idea here is to document each code conversion best practice, so you don’t have to reinvent the wheel the next time you encounter the same construct in another configurator.

 

So, with the festive season approaching, consider giving yourself the gift of an Epicor upgrade. Yes, there is some assembly required, but not as much as you might think, and once assembled, it will keep the kids busy for the next ten years. Moreover, have you ever tried to pick modeling clay out of your carpet?

 

Gift yourself our Epicor Upgrade Tool Kit download to help get your Epicor Upgrade up and going with the new year.

Running on Old Drumsticks – Moving Beyond Epicor’s Legacy Versions

Running on Old Drumsticks – Moving Beyond Epicor’s Legacy Versions

In some ways, enterprise applications are like professional athletes.

There is a period of promise. There is a period of inconsistent, but incremental growth, which culminates in a period of eminence and excellence. Then, there is the period of slow decline, of lowered expectations, and eventually, the time for a replacement. For every Joe Montana, there is a Steve Young, for every Brett Favre, an Aaron Rogers. But ERP vendors have one advantage that us mere mortals lack. While it’s terribly difficult to reprogram a creaky knee or a sore arch, it is possible to reprogram an enterprise system.

To paraphrase Marcellus Wallace,

Some athletes think their bodies will age like wine. If you mean it turns to vinegar, it does. If you mean it gets better with age, it doesn’t.

As an Epicor ERP implementation consultant, I’ve stepped into many organizations whose business systems, to keep with the culinary motif, have more gristle on them than a bucket of secret recipe chicken. Their basic structure is like a freezer-burnt fry hen. And since it takes more spice to make an old bird taste good, their aged systems have become harder to maintain, harder to support, harder to extend or reconfigure.

The secret recipe I recommend to these Epicor ERP implementation clients is to begin with a new bird. It is possible to take an aging platform and replace it with a more current, more robust platform, one fit for future endeavors.

It is also possible to do all of this while still retaining the original flavor—competencies, and capabilities of the application that have differentiated it from its competitors. Epicor spent the last few years doing just that—replacing its aged legacy architecture with its version 10 application: a full-stack Microsoft platform, a platform that makes it more scalable, maintainable, and versatile than it ever was. For Epicor customers who haven’t made an ERP software upgrade and are living on its legacy versions, a migration path has provided them with the programmatic equivalent to a Canterbury spring—the fountain of youth.

Still, many Epicor customers are hesitant to make the jump from their legacy 803 or 905 version of the software to its new version 10 manifestation. In working with customers, I’ve found that companies often have a few distinct challenges preventing them from making the jump:

Epicor ERP Customizations:

  • Companies that have significantly customized the application in its legacy version fear that it will be impossible to bring them up to version 10 without chaos. They fear that Humpty Dumpty will not come together in 10, as he had in the legacy version.

Epicor ERP Product Configurators:

  • Epicor’s Product Configurator module is a challenging and complex module to master, in any version. With the advent of version 10, the architecture of Epicor’s Product Configurator module changed dramatically. Companies that have dialed in their legacy configurators may shirk from the effort to redesign the wheel in a new version.

Epicor ERP Crystal Reports:

  • With the move to a Microsoft-centric stack, Epicor moved from the Crystal Reports to SQL Server Reporting Services (SSRS) as its reporting platform. Customers comfortable with Crystal may be hesitant to go through the effort to replace their suite of custom Crystal reports with their SSRS concomitant.

But the challenges in moving to version 10 are not insurmountable. In a recent webinar, we discussed some of the methods that one could employ to overcome these challenges. In subsequent posts, I will further discuss these methods. Our goal at the Estes Group is to make it such that the benefits of moving to Epicor’s version 10 platform outweigh the risks and the costs.

So if you’re on a legacy version of the application, and if you’re tired of running on an old set of drummies, come check us out—we’d love to talk with you, and help get your company running again.

 

Watch Our Webinar “De-Risk Your Epicor Upgrade” for Useful Tips and Tricks. 

 

Have a question? Ask us any question you have about Epicor and your legacy version. Let’s see what lies on the other side of your ERP upgrade.

Epicor ERP Data Management Tool, The Tool That Keeps On Giving

Epicor ERP Data Management Tool, The Tool That Keeps On Giving

I like to peruse the Epicor-related message boards on a semi-regular basis. Usually, I’ll find something nice, and occasionally I can help someone with a problem they’re having.

Sometimes, a poster will suggest using DMT to solve a problem and the person says, “We don’t have DMT licensed.” It usually takes me a while to get over the shock.

Well, shock is a strong word. Dismay, disbelief, incredulity, maybe.

Epicor’s Data Management Tool is just too handy an appliance for a customer not to have. Sure, there are ways to get data into the ERP system without it.

First, there’s the manual way: put your fingers on the keyboard and get cracking. Your great-great-grandchildren will be colonizing Alpha Ceti 6 before you get done.

Paste insert/paste update is a good way to get certain lists entered. Units of measure, FOB, AR terms, etc. are good uses for this handy functionality.

But for crunching in the big stuff like customers, vendors, parts, and manufacturing methods, you must have it.

Consider that a typical manufacturer might have 10,000 – 20,000 parts, 25,000 operations and 100,000 bill of material records. This data management software makes this possible in a reasonable time frame.

And it handles the complexity so you don’t have to.

Here’s an example. When you enter the bill of operations, it’s one Excel sheet. Epicor ERP’s Data Management Tool in the Epicor 10 upgrade sets up the main record, plus all the default resources, etc. in several tables.
 You don’t have to worry about it.

DMT interfaces with Epicor’s “business objects” to make sure your data follows the rules.

Try to enter a BOM record without its related operation? No can do. Operation without a part revision? Customer with no sales person set up? Uh-uh. The data has to go in its natural order, just as if you were manually typing away.

With direct SQL updates (just say no), you can unintentionally corrupt your database. While you can add or delete records you don’t mean to (it’s a powerful tool, after all), it’s really hard to damage your database with DMT.

Some folks use the DMT as a part of their daily business processing. You can load transactions up in an Excel file, and away you go.

It has great utility “utility,” too. I’ve seen a bad inventory part record where you couldn’t open it in Part Maintenance. Just load it into DMT and update something, the part description maybe. It doesn’t even have to change. Boop! Problem fixed.

When was the last time you made a significant change to the systems that run your business? I’m talking about the type of change that set you up to run your business in new and different ways. For many, it’s been too long. Forrester tells us that half of all ERP systems are at least 2 versions behind. That’s about 5 years, and in today’s business climate that may as well be the stone age. Top three challenges cited for holding off include: -Product Configurators that need to be rebuilt -Customizations that need to be uplifted -Reporting that needs to be transitioned from crystal to SRSS Don’t let upgrade challenges hold you back from the latest functionality you know you need to move your business forward. You can de-risk ERP upgrades using the right process and Epicor tools. Join us on Nov. 9, 1:00 ET, where Brad Feakes, Dir. Technical Consulting at the EstesGroup will show you a systematic process to: -Analyze your existing functionality -Extract any unnecessary elements -Identify problematic items Use the right process and Epicor toolset to migrate your organization to the latest code, with no disruption to your businessNot sure you need DMT? Think it’s too difficult to master? Give us a shout. We’ll walk you through its benefits and operation.

Learn from our Webinar Replay:

De-Risk Your Epicor ERP upgrade

 

Author Bio

Joe Trent is a Senior Consultant with The Estes Group. He has over 35 years of experience in manufacturing and distribution systems, in software development,
implementation and use.

Digital Transformation Warming up to Change and Change Management

Digital transformation is a term that has received a lot of air time lately, and not surprisingly, it has also received a fair amount of suspicion. This should not be surprising, from the dawn of the written word, people have been suspicious of change.

In the Roman era, Ovid’s metamorphoses cataloged various characters of ancient myth, characters who, for one reason or another, were transformed by circumstance: The changing of a young man into a deer, for instance, or the turning of a young woman into a tree.

An in Ovid’s work, the transformation invariably was from a higher form to a lower form—radical change, for Ovid was essentially a bad thing. I wouldn’t mind being a tree, for instance, at least until the nearest roman tree surgeon came lumbering by.

In the 20th century Kafka’s own metamorphosis chronicled a similar transformation—this time, of one individual from an everyday man to a monstrous hideous beetle. One day you’re squelching the bugs underfoot, and the next day you’re the squelch! I see now why Kafka had such a hard time finding dates on Saturday evenings.

In this way, writers and thinkers over the years have been suspicious of change. Such types are often in search of the timeless, the eternal, the constant, and transformation has no place to stand among these pillars of persistence. It should also be noted too that Socrates was a lousy businessman. Just ask Asclepius about the rooster he had coming to him.

Now business rarely fit neatly into a literary narrative—businesses can be rough, and jumbled, sometimes tedious, sometimes unpredictable. But what businesses understand is that they cannot afford the stability and stasis that our literati longed for. Stasis just does keep the lights on for long

I met once with a small company in the mist of expanding its operations and they said to me that they were trying to move from being a big-little company to a little big company. That they had to change the way they did business, in order to sale up its operations and grow, and was making adjustments to its ERP system configuration to support these changes.

Another company I met was in the middle of a rocky new ERP system implementation, as it worked to replace the decades of paper-based processes that just didn’t work in the digital age. The processes and procedures that they had developed just no longer could support the work they needed to do. Their world had changed—their suppliers, their customers, and they knew that they needed to undergo a similar conversion.

For these companies, ERP digital transformation isn’t a literary reflection—it’s a simple necessity. What they’ve been doing up until now just cant support what they need to do, in order to hold onto what they have, or reach out for new opportunities. And our work at the Estes group was to support their reinventions utilizing the new ERP system implementation and the fine-tuning of their enterprise systems as the catalysts.

At the Estes group, we realize that the necessity of change comes with technical and organizational challenges, and we work with our clients to blend different approaches to ERP digital transformation in order to help our clients reshape themselves to better compete with an ever changing landscape.

A new ERP system implementation or changing your application architecture, surprisingly, is a lot like a caterpillar sewing itself up in a cocoon. There is a period of quiet but intense effort, and then the hope is that what emerges out of this effort is a butterfly, an not just another beetle.

I’m Brad Feakes, with the Estes Group and I look forward to talking with you.