Fair enough. Didn’t want to start a howl especially now that I’m out of it.
Just been a really rough 7 years getting sense out of support and justifying the horrific cost of getting help. In my time Epicor has “come a long way” but I’ll never be able to understand how anyone thought what we originally bought was market-ready, especially at the shocking price. And how being sold a product based on its customizability isn’t incompatible with having to disable customizations to get support. Our integration partner hasn’t been much help either, and 3rd-party contractors were 10x more helpful. And our account managers have been completely uninterested in our company - spending time asking good questions and then giving generic quotes and disinterested generic work afterwards. Doesn’t fool anyone. It’s obviously a sales/upsell process.
The product would hardly be viable without the dedication of the Epicor employees giving their time on forums such as this one. You’re a perfect example, and many others we all know. Why should that be required? At the prices we pay, we should have a perfect product that has infaillible documentation to guide us on any questions, and easy access to significant on-demamd training both for technical and for functional details.
It’s a powerful, amazing platform - but it’s constantly ahead of its ability and readiness, and for the price that should not be the case. Create an excellent set of documentation and training, and teach your integration partners the basics of customer service in the modern age, and be a little more open-minded about drawing the line between support and paid service, and if I could start over I’d go with epicor all over again.
I ran into this with consultants, too. They said we were free to ask “how do I do this” questions, but when I did, they said it was too complicated and they would have to do it themselves and need a SOW, etc.
There’s really only room in the world for two kinds of people - those that outsource all IT work, and those that come out of the womb knowing assembly language.
If you are a weirdo like me that can learn some stuff but actually need some human guidance beyond just a blog post, it’s a tough uphill road.
TLDR But some days I wish I just stayed in the Defence Force and ditched my whole degree. No doubt would have ended up with a whole host of different issues. At least I have EpiUsers to keep me sane.
2+ years into a ‘9 month’ implementation with no go-live date and this describes our experience exactly.
Advanced Units of Measure is a perfect example Ticks all boxes: half-baked, no-docs, untrained partners, over-priced prof svcs required.
How many customers paid good money for a module, then also paid services to train and configure identical sheet metal conversions, yet no one published how-to?
As others have said - make your processes fit the system way of working, and only customise when absolutely essential.
The biggest thing for us - Find a good partner/consultant from the get go, and set aside a budget for them. Our original implementation stalled for six months trying to work with Epicor direct, it wasn’t until we found an excellent partner that we succeeded. Even after years of experience in Epicor I’d still do this if I was to re-implement. And having worked with them for some time, they know our system and are still a go to resource when we are looking to make significant changes.
I guess this may be different if you have a large in-house team with Epicor experience, but for us its essential.
I disagree with the sentiment of changing your processes to the system’s way of working. I think if that’s the goal, there are better ERPs. I think the beauty of Epicor was the ability to completely customize the system to work with your processes. Being a relatively small company that makes a specialized product that is unique to every job, it is extremely helpful that we can customize the software to do what we need it to without needing a giant team of programmers. That being said, I think every deviation from the software needs to be highly planned out beforehand. So if I could start over, there would be a lot more discussions as to what high end goals are work backwards from there as a lot of times what hurts us is when we did things one way and then decide that it needs to be done a different way later because of some new functionality we want to add. So plan, plan, plan, then implement.
Yes, I think a more accurate statement is don’t make a custom process for something until you fully understand Epicors way of doing it and you have a real list of reasons its not suitable besides “well thats not the way we have always done it”
Epicor is a very generic software, sometimes the flow isn’t what is needed. I think what people are pointing out is that the “sometimes” is a lot less often than most Epicor Newbies will think, hence why they would do it differently. For the most part, we don’t have much excess customization because we didn’t have the resources for that, so it was self limiting. We are looking to shed any unneeded customization during the migration to kinetic, and its not gonna be that much. Maybe 10%.
But I can see how people with a dedicated Epicor team end up with too many customizations
I’d do the 100% emoji if I could… That’s it in a nutshell
Process vs Customisation is a fine line. But if you have to custom then make sure you have very good patterns and practices in place for designing, maintaining and keeping track of them.
so much agree… in fact, I have found that some customizations are created because people didn’t understand the purpose for some features… or even sometimes they create a customization that is unnecessary because there is another way already inside Kinetic that they were not educated on.
Going into the Wayback machine, I had a customization that I created and put on the menu… we also had hid a standard menu option, which later Epicor improved, but we didn’t look at for another year.. found out that I could eliminate my customization and adopt the new feature which was a better option. Knowing the software really does help.
To be fair to those people, Epicor documentation is spotty and hard to follow on a lot of subjects and on some there’s outright errors due to documentation being based on the way things used to work, rather than how it works now.
I cannot speak to any new documentation for the Kinetic UI as I have not used it much at all, but I know when I started working with Epicor and I read through the documentation and went through the courses online, it was subpar and only through this forum that I know as much as I do now. Hopefully the new documentation is much better.
Kinetic field help is not as good and that’ll make our jobs just all the harder.
