Check out my latest article on LinkedIn. Why ERP Projects Succeed When the Business Decides to Learn
The @JenTrifty and @timshuwy Show…
Great article; I completely agree. The mandate though must flow from the top. Senior Management has to back the team by giving them explicit permission to leave legacy items behind. Ironically, Senior leadership is often the biggest hurdle when it comes to letting go.
The number one reason ERP projects fail is Senior Management, every other issue is simply fallout from their level of support.
The worst implementations I’ve been hired to fix was due to an organizational belief that their business was too unique for standard ERP data flows… in addition to not learning how to properly pull data from the correct tables (most importantly not understanding how to properly adjust RDD’s or customize to pull information from another table) and so they begin pushing data throughout the system in a manner that contradicts the underlying data flow and business objects instead of complementing the base dataflow. The data flow literally ends up looking like a spaghetti map, and performance takes a major hit.
The worst of the worst decided direct SQL Writes and Deletes was the appropriate way to go… without realizing that just because they are in one application when doing something, that in the background Epicor is writing data to multiple tables… and so they were getting fatal errors, the entire server was crashing every 2-3 days, and they couldn’t understand why.
They ultimately fired the entire implementation team, and I was brought onboard (it was our local Epicor CAM at the time who reached out to me directly to see if I would be interested in helping them). It took me 2 months to stabilize everything, and a full year to completely fix everything. It didn’t help that they went live on one of the most bug-filled versions of E-9, and so once everything was fixed, we upgraded to E-10.2 and I worked with the users to eliminate the workarounds for the previous bugs that were incorporated to their procedures.
At the end of the day, they didn’t actually need any of those extensive customizations. The base functionality worked in a manner that was perfectly capable of allowing them to manage their business. They just needed their reports modified to pull some information that wasn’t readily available “out of the box” in the RDD’s… but was available in them without having to add additional tables (by simply using the already existing Linked Tables).
Instead of creating 100’s of additional UD Fields to copy data, it was simply a matter of querying the data from the relevant table to add into the interface screens.
Their other problem was not knowing how to properly create BAQ’s or SQL Reports. They had dashboards and reports that took up to an hour to populate. I reduced the number of custom reports and dashboards from the 100’s down to a few dozen, and the slowest one took about 15 seconds to run.
And the root cause was a complete disregard for learning how the ERP and the tools all function. It “had to mirror” their legacy system… and that ended up being a complete disaster from the get go. More often than not, it comes down to key individuals believing they know more than everyone else in the world.
That’s just been my personal experience, and about a third of my career was coming in after the fact to fix implementations gone wrong.
I can’t imagine getting to that point.
Tim
this whole time I’m thinking 10 or Kinetic… to make matters worse it was e9!
This one is giving me flashbacks. Literally every job I’ve had in tech involved me sunsetting some Access-based custom app hooked into the ERP. In each case, the person building that app had no idea that you could link multiple tables in a single query. 90 minute runtimes reduced down to a single 2 second query.

My very first Epicor Implementation was in 1998… we were transitioning from “ShoemakerWare” to Epicor. I had authority from the TOP Management to implement the new software WITHOUT customizations. TOP Managment had my back, and gave the TEAM authority to make decisions. We had to give a weekly report back to Executive team on the decisions that were made, and they only had a short window (less than one week) to deny any of those decisions. This allowed the implementation team to move quickly through the setups.
In the end, we only had 2-3 decisions altered, and those were light adjustments. I only had to go to the President one time to report one of the team players not getting their work done (and risking the project). The next day, we were back on track.
It was amazing to have a leadership team that supported our process. I still say to this day that this first project (out of the 100s i was involved with) was one of the most successful projects I did… we DOUBLED our original training budget ($10k budget went to $20k), but that caused our CONSULTING budget to be cut in half… this resulted in a total net savings of over $50k (back in 1998 dollars). AND we went live in 3 months after the software was installeld on our system.
On a soapbox roll here agreeing. The first thing I tried to get through to clients that they are not that special. A fancy customized GL or AP isn’t what differentiate your product or service from your competitors
I encountered that once… and I never want to see anything done in Access ever again. It was twenty times more complex than just doing it properly inside of Epicor.
I wonder if the person I was hired to replace isn’t the same person whose work you also had to fix? ![]()
What was it that Friedrich Nietzsche said? “Don’t touch! - There are terrible people who, instead of solving a problem, bungle it and make it more difficult for all who come after. Whoever can’t hit the nail on the head should, please, not hit it at all.”
You have no idea as to what it took to fix it. By default, Epicor wasn’t going to assist or support, and since our only other alternative was a fresh implementation, I figured I had nothing to lose by finding all the errors throughout the database (by comparing records done properly and comparing them to the records done wrong, and fixing them on every table the errors existed). It took me eight months to accomplish (and provided me a deep dive into the underlying dataflow throughout the database - which has proven really useful in creating dashboards and reports)… I will NEVER teach anyone those skills and understandings… for fear that they might get some bright idea that direct SQL is the way to go, for some ungodly reason.
I know people are upset by the announcement of Epicor ending support for On-Prem environments… but a part of me is actually happy to see them go that route, and eliminate everyone’s direct access to the Live database!
The very reason I am now with the company I am with is because they are implementing Epicor in SaaS, and top management wants the absolute minimal amount of customizing possible (Their decision before I even interviewed with them, and one of the primary reasons I accepted the offer). It feels so good to again be working with a team that’s dedicated to learning how to do things correctly in Epicor!

