Just like Mark.
This is what every company gets wrong. Itās hard to believe that it is 2025 and most processes companies use were developed without a computer system! If you have someone who can make senior management understand that it is smart to rethink how the company operates, that will solve just about everything.
(jumping onto my soapbox).
I have said this too many times to count:
it is cheeper to train your employees one time how to use the system than to train the system (ie⦠customize) how to do your processes.
I also said this back in 1988 when implementing Epicor at my former employer:
What makes us so special, that we need to customize something in a way that nobody else is doing it?
Some companies think that they have something really new and novel, but in reality, they are simply not employing ābest practiceā.
(ok⦠i am off my soapbox again).
Why? Because transposition may occur?
Our challenge as well.
For basic operations, agree 100%. Adapt your existing processes to fit the softwareā¦who knows, it might actually be more efficient!
BUTā¦once you cross the bridge into Complianceville (retailers with EDI, specific labeling/shipping/billing needs)ā¦thatās where the mods come in. The bulk of our implementationās ādevelopmentā time went here - to either tweak or outright create the functionality we needed to support specific high-profile customers.
We are, but the part wasnāt specific, so wth lol.
You say poTAYto
I say poTAHto
-
Clean up Customers. We have the same customer multiple times because of other addresses. Utilize Ship To and Bill To properly.
-
NO custom warehouse location set up. Use the out of box warehouse and bins. I am forcing this clean up when we upgrade and move to cloud.
-
Fix my Ship Viaās and set up Quick Ship cleaner with this.
You know, when you buy a new appliance, and thereās a big red piece of tape over the carton flap that says āRead xxx before opening!ā, well in my opinion, the warning on the Epicor box should say āStudy your Unit Of Measure well before opening!ā. I think this is the one area that needs to be the most thought out and the most deliberate, and is most times too granular. Counted Units-Each, Length-Feet and/or Inches, Volume-Gallon and/or Cubic Inches (only if you have such things going into your product). Donāt get carried away. Check, double check, and triple check UoM Conversion factors before setting them up. Donāt get cute, keep it simple.
K.I.S.S. not just for UOM but for many other aspects of implementing.
I would change our part numbers.
We implemented with a semi-logical part numbering format (e.g., one section defines the type of part, another section is sequential but groups like parts together, and another section defines the size), but Epicor has many different fields to define part attributes, the ability to search on those attributes, UD fields that can be added, etc.
The semi-logical numbering was already incorrect when we went Live with some parts being missed in audits and numbered incorrectly. A fully ārandomā/ sequential approach would have been much better and cleaner.
This. After years of being on Epicor it would have been cheaper and easier to change our process rather than changing Epicor. We tried to make Epicor like our old ERP from 20 years ago. Big mistake. A mistake we are stuck with now forever.
You could always re-implement?
Iāll just get in myself.
I would add UD Columns to my UD tables instead of using the standard provided columns. Iām going to do it going forward, but I never thought about doing that early on. I have a few tables that I just canāt bring myself to re-map and re-create all the BAQās, reports, etc. that are referencing them.
Wish we would have done this too. Rather than trying to work around the standard columns. Trying to remember years later what column something is in is annoying.
Me three
Call me