ERP Implementation Best Practices: Closing the Gaps

by Brad Feakes | Dec 3, 2020 | Epicor 10, ERP Consulting, ERP Implementation, ERP Selection

ERP Implementation Challenges

Bridging functionality gaps in ERP is one of the great challenges in an Epicor implementation, or of any enterprise resource planning project. There are often visible gaps between a company’s business requirements and the system’s ability to address them. In a perfect world, the needs of the company perfectly match the capabilities of the system they are implementing. In practice, the gaps between an organization and its ERP application can be significant, and closing these gaps can take significant effort. The inability to successfully close these gaps is a leading cause of project failure. This guide will help you understand a few ERP implementation best practices to help address the great challenge of closing the gaps.

ERP Customization

Find creative ways to use the system’s standard configurations to address the needs of your business.
Adjust your business processes to conform to the system’s recommended best practices.
Tailor the software in one form or another to provide needed functionality.
Combine the above methods to achieve a hybrid solution.

So why do businesses feel the need to tailor the applications they implement? ERP software customization is a means of closing gaps. Sometimes, it is the preferred means of addressing challenges before they start. Often, gap closure will involve some form of customization. The overall level of ERP project complexity will expand with increasing challenges and risks. In general, the different types of obstacles encountered in an ERP project can be grouped under one of a few headings. Customizing an ERP application allows you to do a number of things and to circumvent a number of issues:

Automate tasks. The standard system is too transactional and user-intensive.
Prevent errors. The standard system allows for too many points of failure as a function of user entry.
Integrate with third-party systems. The standard system does not provide specific functionality, necessitating a tertiary application. Similarly, the standard system does not integrate with the third-party module in question.
Extract and display data. The standard system’s out-of-the-box reports do not present the necessary information needed by the business.
Add business logic. The standard system does not possess logic needed by the implementing company.

The Total Cost of Ownership of an ERP Solution

The rule of thumb that came out of the first generation of ERP systems was simple: avoid customizing the ERP system at all costs. Fit the business to the software, not the software to the business. Considering the comparatively rigid systems of the era, this recommendation seemed valid. Earlier-generation ERP systems contained limited toolsets for tailoring the application to meet the needs of the implementing organization. As such, customization essentially implied a source code modification, and such changes were detrimental to the long-term maintainability of the systems involved.

ERP Implementation Best Practices Evolving

Next-generation ERP systems contained improved toolsets to provide non-source-code customizations that were upgradable and maintainable, but the disruptive effects of customization on the implementation projects nevertheless continued unabated. Why do ERP customizations continue to create challenges to organizations?

Customizations are disruptive—they introduce logic to the application that is not native to the core system. They may also behave in ways that are unlike the rest of the system, and tend to be less comprehensive than the source code that they are layered upon.

As they are developed and refined, they often contain bugs. For example, the custom business logic may be invoked at times when it isn’t expected, or may not be invoked in all cases that require it. Working though these bugs can be challenging. Moreover, when customizations run into bugs or undocumented features of the core application, an abundance of unexpected behaviors can result.

ERP Toolsets & Project Success

Everything said, how do companies successfully leverage the customization toolsets available? How do they provide the necessary functionality to their organizations without compromising project success? Consider the following observations:

On one hand, we’ve seen companies significantly customize their application in an organized and methodical fashion. Therefore, the customizations produced a limited disruption to the implementation.
On the other hand, we’ve encountered other companies that only modestly customized their application. The modest number of customizations significantly disrupted the implementation. Why?

Organize to Optimize Your ERP Software

The level of customization and the level of organization of a project are closely tied. Therefore, companies that organize their customization efforts carefully are much less likely to experience problems caused by customizations. Conversely, poorly organized customization efforts will create additional issues that will add complexity and disruption to an implementation that is already, by its very nature, complicated.

Quantifying the impact of these two variables (customization and organization) can be difficult, but a simple mathematical model might help to model their interaction.

Assume that a project’s level of disorganization can be scored on a scale from 1 to 10, with 1 being highly organized and 10 being highly disorganized.
Similarly, assume that a project’s level of customization can be scored on a scale from 1 to 10, with 1 being lightly customized and 10 being highly customized.
Additionally, assume that a project’s success can be scored on a scale of 1 to 100, and anything over a score of 20 is a bad thing. For example, the project could be over budget, behind schedule, or low in scope or quality. In this context, a score of 30 might imply a project that went live late, or had to cut scope, or exceeded the budget, while a ruination score of 100 might represent a project that is years late, millions over budget, and so poorly designed that it will fail to go live.

A score of 1 (very low customization, very low disorganization) represents a very low risk score and a score of 100 (very high customization, very high disorganization) represents immense and catastrophic risk to your ERP and to your business:

The simple lesson to be learned here is that an organization can perform reasonable amounts of customization to their ERP application without destroying an implementation. A company needs to take steps to utilize an organized approach to customizing their application.

ERP Risks

A challenge with this dilemma is the reality that most companies do not launch an ERP implementation project believing that they will customize the application significantly. As a result, when these change requests surface, they are normally ill-equipped to handle them, and things soon spin out of control. As such, many customers come to us asking the simple question: What does it mean when one’s customization methodology is highly organized?

ERP Project Risk Management

There are a number of characteristics that an organized implementation possesses. They include the following:

First and foremost, governance is in place, to control when customizations occur. Governance is the best way to keep the degree of customization from spinning out of control.
Solutions are tracked. The implementing company understands which modules have been customized and which reports have been altered. They have identified all truly custom entry screens, reports, and dashboards. This information is put to use whenever an ERP upgrade occurs or a new site goes live.
Business requirements and functional specifications are developed as solutions are developed, and these solutions are constructed using these specifications.
Guidelines are defined ahead of time. These are conventions that describe how custom solutions are to be constructed, organized, and named.
Solutions go through careful testing. They receive a unit test to ensure that the basic requirements have been met, and then a regression test, to ensure that they function appropriately within the overall application, and don’t break anything else.
Solutions go through careful deployments to the production environment. When old solutions replace new solutions, the old solutions are removed from the environment as part of the deployment, to prevent the environment from getting cluttered with old, inactive solutions.
When an ERP module is customized, the developers take into account the full suite of new and pre-existing customizations, as to ensure that new elements are optimized to efficiently work in concert with existing custom solutions.
Environments are constructed as to segment various activities such as functional design, custom solution development, and upgrade verification. When these activities overlap, conflicts invariably arise, and these can slow down the progress of a project and create needless confusion.

The Goal of an ERP Implementation is Twofold

How do you implement a system that satisfies the needs of your business? How do you stay scalable and maintainable and also support the future requirements of your organization?

The future of your business is always unknown, and often unpredictable. Therefore, cutover will surely present new unknowns. Heavy system customization often results in the achievement of the goals of business needs. Unfortunately, this can risk the long-term maintainability of your ERP system. An organized and methodical approach to system customization supports a more successful implementation. Moreover, it provides easier long-term maintenance of your application. Likewise, it holds the ability to support the business requirements of the future.

After the ERP Vendor, the Software

Are you trying to improve your manufacturing processes? Do you need user training to empower your ERP project team? Are you looking for the competitive advantage that cloud ERP offers? Do you need help with data migration to an ERP hosting environment for a complex enterprise resource planning software like Prophet 21, E10, or Sage? We have experts for everything ERP, whether you need Epicor consulting assistance or QuickBooks hosting guidance.

For 17 years, EstesGroup has served clients at every step of the ERP implementation process. We offer real-time support 24/7/365 for your implementation team. We optimize your technology, and we lighten the burden on the precious human resources that make your company unique. Your team can work according to their talents, while we do the routine work involved in managing your ERP software and the technology that supports it.

Learn More About ERP Implementation Best Practices for Cloud

A good ERP balances your budget, opens your resources to new possibilities and opportunities, and improves everything from customer relationship management to industry-specific compliance and cybersecurity. ERP cloud hosting provides an ideal platform for your work. Request an ECHO demo today to see how EstesCloud managed services can help your business.

An End User’s ERP History – from Baan IV to E10

by Brad Feakes | May 21, 2020 | Epicor 10, ERP, ERP Implementation, ERP Selection

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. 

Brad Feakes

SVP, ERP & Professional Services, EstesGroup

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.

Interested in having us help your business?

What Are My ERP Private Cloud Options

by Brad Feakes | Feb 10, 2020 | Cloud, Epicor, Epicor 10, ERP Risks and Challenges, ERP Selection, Hosting, Managed IT Services, Prophet 21, Security

Not All Clouds are Created Equal: Reviewing Your ERP Private Cloud Options

It’s no secret that cloud computing has been increasingly finding its way into businesses by providing reliable solutions to increasingly challenging problems. But for ERP customers with complex environment maps, an unmitigated move to the cloud might feel risky. For this reason, some customers look for middle options between full cloud deployments and on-premise installations. Private cloud hosting is one such midpoint, and it’s not uncommon for customers to approach the opportunities of cloud computing in search of a private solution. But will this option leverage the obvious benefits of the cloud, while effectively providing the necessary support for your complex ERP ecosystem?

Your ERP installation is rarely an isolated entity—it is part of an integrated ecosystem of applications and processes, with various third parties, bolt-ons, and in-house applications interacting with the core ERP system. As such, an ERP system is not always easily extracted from its ecosystem, as such an extraction is something akin to major surgery. If you’re looking at handling this complexity with private cloud ERP deployment options, there are basically two management directions you can take. You can build a private cloud using AWS, Azure, or Google, or you can work with an already established team of experts in private cloud hosting. Let’s explore these options in greater detail.

Private Cloud in AWS/Azure/Google

The big players in cloud computing entered the application hosting game a while ago – Amazon, Azure, and now Google. The option here would be to build out your virtual machine architecture within one of these clouds, and install your applications within this architecture, while working in turn to integrate your company-specific application ecosystem with the new ERP infrastructure.

While this eliminates the hardware investment of an on-premise install, you are still responsible for all the administration activities, at the server, application, and database levels. And if your Epicor Admin should win the lottery, you are left scrambling for options. If you lack the internal resources and need to bring in assistance in the administration of the application, you are now adding another party to work within this ecosystem. Moreover, to your monolithic cloud provider, you are still just a number, and the service levels you can expect to receive will indicate as much. Will the hosting company be responsive and listen to your apps and your business needs? Is there a human voice to reach out to when issues occur?

Private Cloud Through the Estes Group’s ECHO Managed Hosting

EstesGroup’s EstesCloud Hosting, or ECHO for short, is our hosting platform. For one monthly price, we include all the functionality and support you need to keep your hosted applications running properly for your business. While providing the access level that companies look for in private cloud solutions, we also provide the support and expertise that a big box store cloud partner can’t provide. One phone call puts you in touch with our support team. Well-versed in Microsoft’s full stack, we cover your servers with 24x7x365 EstesCloud Monitoring. We cover the backups and disaster recovery, and we protect your users with EstesCloud identity management under the security of EstesCloud-managed Firewalls.

We have experience in moving many customers to a private cloud environment, while working with them to integrate their hosted ERP platform with their family of related applications. With this experience comes the knowledge in working with protocols, networks, VPNs, and database connections, and we leverage this knowledge when engaging a customer.

In summary, some of the benefits of the EstesGroup’s ECHO Private Cloud Hosting solution include:

Known monthly expense, with no large capital expenses
Growth with your business supported by continual and customized service
Proven backup and disaster recovery playbooks
Easy, secure access from anywhere you wish
No Server Maintenance
No need to upgrade or repair hardware

When it comes to deploying your ERP architecture, there are clearly a number of different options, and the implications of the decisions made will have a lasting effect on your company’s future. Are you considering spinning up your own private cloud to host your ERP application? Drop us a line first, and let us help you explore your options.

Interested in learning more about Managed Hosting for Epicor ERP or Prophet 21 ERP?

Visit our Managed Epicor ERP Hosting page

Visit our Managed Prophet 21 ERP Hosting page

Epicor MRP Keeps You On-Time and Customers Happy

by Rory Kling | Feb 5, 2020 | Cloud, Epicor, Epicor 10, ERP Risks and Challenges, ERP Selection, Hosting, Managed IT Services, Prophet 21, Security

ERP! ERP! How do I love thee? Let me Count the Ways: A Robust Materials Resource Planning ( MRP ) Engine

One of my favorite movies growing up was The Wizard of Oz. One of my favorite scenes was when the “Wizard” was exposed as the “man behind the curtain,” pulling levers and revealing the secrets of the kingdom. In the business world, this phrase has morphed into meaning a person who elusively controls the intricacies of a large enterprise—and no one really knows the who, what, when, or how of the magic behind the success. MRP (Materials Resource Planning) is like this “man behind the curtain.” Incredibly powerful, MRP manages the forces of supply and demand, keeping everything under control.

There are basically three questions that a manufacturer has, and MRP answers:

What does the customer want?
How many do they want?
When do they want it?

While those three questions seem relatively simple in nature, executing them in an efficient and profitable manner can become an extremely daunting, or even impossible task if you don’t have the correct tools. Fortunately, the Epicor MRP Engine is a highly sophisticated but user-friendly process that can help companies increase on-time performance, lower inventory and improve efficiency. MRP takes all three of these questions and looks at them holistically, to manage all variables that can occur on a shop floor.

What product does the customer want?

To answer this, MRP first looks to see if the part is purchased or manufactured. At the core of the system is the type-attribute of the part. Epicor defines a part in three ways: purchased, manufactured or sales kit. Purchased Parts can have a defined lead-time and are used in determining when product can be available if stock is not available. Manufactured Parts are built-up with routings and bills of materials. MRP will take into account the time it takes for each operation, dependent on the quantity and material availability, to determine when the product will be available to ship, based on capacity on the shop floor. Sales kits can be a combination of purchased and manufactured Parts and will use either or both types of logic to determine availability.

What quantity does the customer need?

Based on demand from forecasts or actual Sales Orders, the system looks at the current inventory level. If there is insufficient inventory, it will suggest to the Purchasing Department to buy some if it’s purchased or will suggest to the Planning Department to create a job to make some, if it’s manufactured.

What is the customer’s timeline?

This is where the Epicor MRP logic will take the first two questions and analyze two things: If we don’t have it in stock, can we buy it in time to deliver it, or do we have enough material and resources available to build how many they want? And it does this by taking into account not just one particular Sales Order, but all of the Sales Orders, and all of the inventory stocking levels and Job demands within a plant. Obviously, this is a very tall order, and in a dynamic manufacturing environment, things are often changing on a daily, if not hourly, basis. Because the MRP process can be such an intensive hardware resource demand, Epicor can be configured to run on a schedule (often times at night), either by looking at net change (to only work on those things that have changed since MRP was last run) or by being regenerative (to recalculate all demand).

Epicor also has the ability to run MRP for a specific part. Have a customer that needs a part ASAP? Now instead of having to wait for MRP to run, management has the ability to see the potential status of a job in a matter of minutes, and not hours, as MRP only has a single part to analyze. The MRP process can also be limited to a plant, product family, or commodity class—reducing the time and resources required to generate the needed supply records. Epicor MRP also supports multi-level pegging, which gives users the ability to trace the supply to each discrete source of demand. This process also drives the projected Sales Order shortages and is an incredibly powerful tool to manage customer satisfaction.

The Epicor ERP system, in conjunction with its versatile and powerful MRP process, allows your organization to “see behind the curtain” at an organizational level, revealing what the current demands for your products are and if you have the necessary supply to meet demand in a timely and profitable fashion.

There are lots of things to love about Epicor’s E10 ERP application.

Want to know a few more? Read our “ERP! How do I love thee?” series and give us a call with any questions you may have.

Manufacturers are in Love with Epicor ERP

by Brad Feakes | Feb 3, 2020 | Epicor 10, ERP, ERP Benefits & Features, ERP Risks and Challenges, ERP Selection

ERP! ERP! How do I love thee? Let me count the ways!

I’ve often remarked that the best way to get a company to fall in love with their legacy ERP (Enterprise Resource Planning) system is to implement a new one. When I was a customer, we moved from one of Baan’s flagship products to Epicor’s Vantage 803. ERP implementation is an exercise in nostalgia… With uh or ah or awe, does anyone out there remember Baan, or Vantage, for that matter?

I do remember the end user community at cutover: “Well, back in the Baan days we could do this, and we could that, and oh, I miss the Baan days…”— Folks who had never had a good thing to say about their enterprise system were suddenly swooning over it, now that it was on the outs.

Having heard nothing but complaints about our legacy ERP up until cutover, I didn’t know what to tell them. At a loss for words, I found myself quoting Lord Alfred Tennyson: “’Tis better to have loved and lost than never to have loved at all.”

I soon discovered that most end users in your average manufacturing company are not especially fond of nineteenth century British Romanticism, especially at cutover weekend.

Most companies don’t exactly love their ERP systems, even in a friendlies sort of way. I knew one fellow who had the source code of his ERP heavily modified to suit his exact needs. Of course, he loved his ERP—every time he used it, he was looking in a mirror.

For the rest of us, ERP is more like finding a roommate rather than a soulmate.

Even still, there are a lot of things about Epicor ERP’s Epicor 10 platform that can spur admiration—even affection. Last year, I wrote an article about Epicor’s E10 platform, looking to answer the question: “what’s it good for anyway?” It turns out that E10 is good for a lot of things:

Support for deep bills of materials.
A robust quoting module.
A well-integrated and fully functional product configurator module.
The ability to handle true Engineer-to-Order.
Support of mixed mode manufacturing.
The ability to combine discrete and project-based manufacturing.
A fully-featured Manufacturing Execution System.
A Robust Material Resource Planning (MRP) engine.
Integrated analytics, to provide operational metrics and KPIs.

In this series, we will further expound on the core capabilities mentioned above, and work to explain how these capabilities distinguish Epicor E10 from its competitors.

What’s it good for anyway?

Companies in the midst of a software selection cycle are looking for things to love about a given system—things that will differentiate an ERP system from its competitors and that will ultimately help raise the business to greater levels of performance. With the New Year moving right along and Valentine’s Day on the horizon, are you ready to love your ERP in 2020 style? Whether you’re looking for some new Epicor E10 roomies or looking for someone to draw hearts around a new flame of a system, the EstesGroup team is ready to help you love the ERP you’re with.

Interested in learning more about Epicor ERP 10 customizations and how good consultants can help manufacturing companies? Give us a call.

Why on Earth Do I Need an ERP System?

by Brad Feakes | Apr 22, 2019 | Epicor, ERP, ERP Benefits & Features, ERP Consulting, ERP Implementation, ERP Selection

My boss once said to me that nobody wakes up in the morning and cries “I’m going to implement an ERP system!”

It’s a fair point. Apart from a few business process masochists that I’ve met over the years, few people out there really go out of their way to implement an enterprise system. Enterprise systems are costly and they drain a lot of time and energy from key resources within a company. They can be generally…painful to implement. And yet I’ve seen so many companies make the move to enterprise systems and benefit greatly from the transition, in spite of the challenges. This raises a question that I’ve had more than a few prospects ask me: “Why on earth do I need an ERP system?”

Pundits have long noted that the “E” in “ERP” is the most important of the three letters. The value in an ERP system comes in its applicability to the entire enterprise and not just to a few selective functions within the organization. And while ERP has been around now for many decades, there continues to be ample opportunity for better enterprise-level integration among companies. Quite often, the “why” of ERP comes in a quick analysis of a Company’s current-state application architecture.

With many of the customers that I’ve helped migrate to Epicor’s ERP platform, I’ve observed a current state application map to include one or more of the following:

The utilization of stand-alone financial modules such as QuickBooks for financial management. Such systems are good for counting waves, but not for making them.
The use of manufacturing oriented work order systems for managing the shop floor. Job Shop-oriented systems can be effective in defining product structures and working them through the shop-floor, but are less effective in managing the selling and shipping of manufactured products and in comparing the resultant revenues to costs.
1980s-era ERP systems, with one or more bolt-ons for managing product configuration and/or the shop floor. First-generation ERP systems are generally solid when it comes to inventory management, and basic order-to-cash cycles, but are limited in many areas, and are a burden to maintain.
Paper-based systems for inventory management & time card entry—some customers are still pounding the paper when it comes to basic warehouse and shop floor transactions.
Varieties of macro-enhanced spreadsheets for doing one of many things. Spreadsheets are a great gap-filling tool, but their limitations quickly become apparent as multi-user capabilities and large data requirements become a necessity.

Based on the above, it is no surprise that companies come to us looking to implement Epicor because their current state is a drafty quilt of poorly-stitched and poorly-patched legacy applications, homegrown boondoggles, and siloed modules. Customers come to us believing that there must be a better answer, and in most cases there is. The problem is, most companies took a lifetime to grow into their patchy ponchos. At certain early stages in their relative existence, most companies can get away with the above scattershot array of systems and pseudo-systems. But these same systems become hindrances as the company looks to scale up, expand its offerings, ramp up its output, or better integrate with customers, suppliers or best-of-breed applications. As these challenges become clear, the “why” of ERP begins to take shape.

Our work as Epicor partners quite often has to do with explaining the “why” of ERP. My own “why” came to me many years ago. At the time, I was still a customer and still quite naive regarding the ERP space. Working on a process-improvement project with my company’s Vice President of IT, I asked him point blank whether our recent ERP implementation had been a success. “Yes!” he replied, emphatically. “Why?” I responded. I was a Lean Six Sigma Black Belt at the time and was practicing my “5-Whys” methodology. I only needed one of them, for his answer changed the way I’ve seen enterprise systems ever since. By implementing an ERP system, we were laying the foundation for everything that was to come. In our case it was configurability—we were an engineer-to-order company, living in an increasingly configure-to-order market, and needed to make moves toward configurability before our old methodologies priced us out of that market. By implementing an ERP system, we set in place the building blocks for product configurability, and our subsequent initiatives took these building blocks and reshaped the way the company did business. Fifteen years and an ERP system later, my old company is still successfully competing in its target markets, proffering configured products, and doing so profitably.

Now every company owns its own specific point in time, and faces its own set of unique challenges, as it tries to grow and thrive in changing markets. I’ve seen a lot of good reasons for moving away from a patchwork of solutions to a more integrated and comprehensive system. My own story may resonate with some, or there may be other stories that better answer the question as to why a company might make the move to an enterprise system. This is all to say that there are a lot of reasons for implementing an ERP system. And everyone here at the EstesGroup would love to hear your story. And if you don’t think you have a reason for implementing ERP, we’d love to talk to you about that as well.

Have a question for our consultants? Trying to determine if your company needs an ERP system? Chat with us now! We have ERP consultants ready to answer your questions!