Hi all,
Long time Epicor user with my previous company.
Current company just went live with Epicor 10 and we are making progress.
My question is, how long did implementation take for other companies? Our Pilot was almost non-existent since none of our data was migrated until just before go-live. We are in a situation now where management wants full MRP planning like yesterday and we are just getting our feet wet with the basics of the system.
Any reply is greatly appreciated, just trying to baseline what the effort should take.
Thanks!
Jim, having been on the customer and consulting side of implementations, I will tell you every project is different. Project complexity and resource availability will determine the project time frame.
I will repeat something a wise person once told me - you will do a conference room pilot, itās you up if you do this before or after your go-live.
Epicorās signature methodology can lead to a successful implementation and I recommend all customers understand their suggested process.
5 Likes
Noice.
āHow longā is a loaded questionā¦ it all depends on āHow Vanillaā you plan to use the software, and how well trained your team isā¦
If you just want a scoop of vanilla, then delivery is fast, but if you want a Banana Split, it takes longer. 
As a customer (21 years ago) the timing between Signing (November) the contract to Go-Live was 7 months. but we were REALLY trained (Months of February & March we had over 70 person-days in classroom), AND we chose to go totally vanillaā¦ only thing that was ācustomā was the external forms (logos on PO, SOAck, Invoice, Packslip, Checks, etc). Our software was not installed on our server until 1st week of April, and we went live July 1st.
I have helped many companies go liveā¦ everything from a āOne Day Implementationā (it was an upgrade where they abandoned 100% of their data and started over on the new version), to several years. The longer go-lives are almost always due to customizations, BUT in many cases, it is due to the lack of dedication of an implementation team.
3 Likes
Iām with @timshuwyā¦ Poor planning leads to P!$$ poor performance. Speaking from experience, of the last 18 months of lack of leadership, planning, communication, and total denial that the Signature methodology actually does work if you follow itā¦RANT over :). Just donāt let people confuse proof of concept with end user testing, and for the love of Godā¦Get a project manager if you donāt have the in house skills or cannot release them full time to manage the project.
1 Like
If you have the backing of the executives and they are willing to support your effort to remove roadblocks. In addition give you the financial backing needed. Then the project may just go smooth and faster than usual.
If there is friction and doubt from execs, you will be fighting a uphill war.
VERY IMPORTANT: Customize for the process, not the user. I know companies that have been implementing Epicor for 8yrs, and some even gave-up and went to a different ERP System, in each case it was because it was over-customized, they said YES to everything. If they said No, someone complained to a manager and ultimately everyone got their way 
Heres 1 Example:
Overall it depends, make sure you have a great framework in place wether its ITIL or Scrum - have a process in place that can be documented and have daily if not weekly meetings. We have a ERP Implementation team who meets 2x daily, and we present to each other our progress, daily stand-up meetings - a dedicated project manager etcā¦ Also Epicor is first priority, if Epicor needs IT Resources, they get them period.
The hardest part is when you have no dedicated resources and you are assuming that BIll from Shipping and Bob from Production and Simon from Engineering can give you all the time in the world and continue their daily duties. Itās best to leave those folks alone, and if you must build a implementation team to knock it out, wether its consultants or new-hires. Perhaps even Epicor.
Remember its not just getting the software up and running, but also re-writing some Processes, Teaching Processes, Getting Sign Offs from Department Heads, Teaching Usersā¦ You can get tools like Epicor Knowledge Mentor to help with EUPs.
2 Likes
Can you give us a quick overview of your site. Kinds of products, inventory, jobs & the planning you desire?
There are so just so many possible permutations and depending on your environment, MRP can be failry straightforward or involvesome pretty long learnig curves.
My opinion it can also bean āinterestingā journey as you figure out how to manage your Suggestions.
Even moreso to get a good handle on Scheduling.
If you have done no testing or real validation of your data - implied in your op - then nobody can answer but you as I would imagine that lots of MRP modifiers are not checked and a whole load of other supporting data will not be setup - as an example out the box MRP will have material arriving the day it is needed - so is that at 9am when you actually need it or 4pm when the supplier actually gets to you.
Your business wants this working yesterday so you copy live to test and you get the relevant folks in a room to do pilot testing of MRP - work with them to come up with the test scripts scenarios. Also work with them to understand what modifiers/data fields need to be set and transactional discipline that is required - likely to be a significant gap between what they want and what you can pragmatically deliver - we want the āsystemā to manage all the material with no intervention by us.
If they are unwilling to spend the time on this then pick a product type/group that wonāt break the business with limited modifiers/parameters and test yourself/with someone else and then put into live, then do another one and you can do MRP in increments.
That is a pitfall in our caseā¦dedication I mean the hours you need to spend besides your everyday work, into learning, understanding testing the new softwareā¦so when the go live comes up we are all ready to go! We had a few key people that did not put the necessary efforts and the rest of the implementation team had to get involvedā¦
One thing to note: We have an IT dept of 4. But the project was never an IT project, but a management project. We were not involved into the processes (as before it was kind of our responsibilityā¦) Management wanted to responsibilize the departments more into their respective processesā¦
So from the start, there were the Implementation team which comprised of each head of departments. They were the ones responsible to know at their fingertips all what was needed to know about Epicor in their department. That team was meeting twice a week to convey about progress.
When they felt comfortable, the next stage was to train the users under themā¦etcā¦
The result: If someone had an issue, we directed them to their department head to answerā¦ (heckā¦we could not know everything!!! 
) This allowed us to persue into much needed customizations (reports, Sales Order, shippingā¦etcā¦ )
After 4 years of use of Epicorā¦ it proved it was not a bad way to implement.
For us it took about over a year to implementā¦with the help of our VAR. (we started with v9ā¦and ended up implementing v10ā¦)
Pierre
1 Like
Thanks Bruce, we build and test electronic assemblies, specifically amplifiers with multiple circuit boards and subassemblies. We are make to order and our builds last anywhere from 3 months to 1.5 years. Material availability is always a moving target in electronics and since we try to maintain JIT for incoming materials, it is always challenging.
For go-live, we were able to have our customer, suppliers, and Parts List migrated to E10. I came from a manufacturing environment where we built 1-of custom assemblies, now I am building hundreds or thousands of the same assembly. Same ERP, different methodology I suppose.
Now that we have completely replaced our old ERP with Epicor, I am now trying to pull other systems in so we have one robust solution. For example, assembly instructions, inspection docs, scheduling have all been maintained in systems outside of ERP and my challenge is getting those all rolled in.
That should be an interesting change of pace for you.
Otherwiseā¦ all of you users are new to Epicor, and I assume you have a mix of stock and direct parts? If so, Iām wondering how your non-stock settings on part masters are going so far? This always seemed like one of the important parts of the learning curve for new users to get thru, setting definntions and consistent practices . Another area where Iāve seen some issues with new users is in not understanding the consequence of changing of due dates( vs. using promise dates) in purchasingā¦e.g. duplicate suggestions, excess inventory.
The DMT will be your friend, hopefully you can export/map from your old system(s).
This will be your big one" (my opinion). Scheduling is the one area where I suggest users plan on setting aside (a lot of) extra time for studying and/or taking class(es). You might also want to consider looking for consultant who specializes in scheduling. I think itās easy to find a consultant you trust/like for every areaā¦ except scheduling. . Itās just a complicated beast and I know of some sites that have been using Epicor for decades that are still struggling to realize all of their scheduling desires.
My implementation team back in 1998 was comprised of a team of 8ā¦
- I was the IT Managerā¦ also the Project manager. This however was NOT an IT Projectā¦ I was simply a facilitator. I wanted each department to work together to make coordinated decisions. (although I did play a heavy hand in keeping things on track).
- Tom was Production Control manager.
- Bruce was Purchasing Manager - handled Shipping, Inventory, Purchasing and Transfer order setup.
- Pam was Sales Supervisor - anything to do with Sales
- Sherry was Engineering Secretary (thatās rightā¦ the secretary)ā¦ she knew more about how BOMs and BOOs were loaded into our old system, than anyone else in the company. (this was the most controversial decision, because the Engineering Manager āwantedā to be on the team, but didnāt have the operational knowledgeā¦ he was a very good engineer however, and we needed him to engineer products.
- Gaylan was the CFO and handled all things accounting (except for Subject matter experts for AP and AR when needed).
- Jim was Quality Supervisor (from the shop floor)ā¦ he handled all Manufacturing interfaces, labor reporting, etc.
- Finally, we had Roseā¦ she was the presidentās Secretaryā¦ her official duty was āThe Scribeā. This was one of the most important positions.
We did all prototyping with everyone in the roomā¦ we all knew how everything worked. But the real test came when we did our āPilotā walk-though of all our processes. Each discipline was supposed to have written instructions for their procedures. We started with Sales, then production, purchasing, etcā¦ I was a mean PMā¦ when we arrived in the room, I had everyone pass their instructions to the person on the rightā¦ This was to prove that there were real instructions.
I had strong support from upper managementā¦ the steering committee was Richard, the President, Mark, and myself. When Tom arrived to the āPilotā without his written instructions (āno time to completeā), Rose reported this back to the Presidentā¦ Tom suddenly found time and had them done the next day.
3 Likes
We came from Sage MAS 90 7 years ago. Just last year we finally got to implementing MRP properly. Coming from no ERP in a company to having ERP has been a ride. I think the experience of your users with āreal systemsā will have a lot to do with how long it takes.
Probably not too helpful, since everybody will accord that the implementation project depends entirely on the resources allocated and the level of customization(both real and process adherence only), but here are my two cents.
Since you are already on LIVE(as I understood) I would say that 3 months to stable operation would be a good time frame. From my experience(sadly) most of this projects get the real boost from key users only when it really hits them, so then is when they really test and review the processs to adhere more efficently.
Our last project was just like that, we had issues with the partner assigned so the total implementation got behind schedule, also we needed some CSF functionality that was legally required and Epicor didnāt delivered it(we had to buy a customization from them).
In any case, the message is that even with all those delays that should have prepared better the key users, the effect was the opposite. They lost focus and considered it a less important activity. So, the āfullā testing of the software against our process was actually done while in LIVE. Three hard months, and also we had a lot of customization along with the fact that all our products are configured and every one of them is different. Of course, we keep discovering things after 1 year, but completely managable and non critical.
Still I consider it quite a successful project, since there were many issues affecting it.
As I said before, no particular insights here, but hope that it helps.