100% agree. Good luck finding a partner who can strike a balance between blocking and enabling implementation though. My impression through it all has been that they *just don’t care about your business * enough to strike that balance. The integrators - and prof svc - really need a framework for understanding a business before they advise you, but you get “maximize module uptake” or “adapt to the system” or “customize everything to your processes” or “this is best practice” or some other unconsidered, broad-brush approach. It’s not good enough, and sadly all that’s missing is intent, a framework, and being focused on customer value.
3 Likes
I am fully guilty of this. However in my defense, I learned the approach from our integration partner, who was exceedingly guilty of this.
1 Like
Please do not encourage my users!!! 
2 Likes
We’ve all done this a time or two..
Devil’s advocate says does the company even know what they want? Most implementations that I am involved with, the business does not even know what they currently do, let alone can provide requirements for what they want to do. Most of the time it is just “tell us what the system does” and when you do they say “well, that’s not going to work”.
In my opinion, blame is squarely in the middle. Implementors want to provide a solution based on the business’ requirements, but the business does not know what they want.
5 Likes
1 Like
HAHA.. I just realized that I can put my “customer hat” back on, and answer this the way I would have for my very first Epicor implementation.
Decisions we made in April 1998 after our 60+ man-days of training:
- Training & Implementation: We decided to spend more time on our training than was in our budget. Initial budget was 20-30 man-days. We spent 60… WHAT CHANGES? my only regret was that we didn’t spend another 10 days, adding a few more people into the training. Training was the biggest money saver in our project. As a result of our decision to spend more on training is that we cut our consulting costs by 50-75%, overall saving money.
- Product Costing: We were a 100% lot costed shop. 100% lot tracked. What Changes? after everything I have learned about product costing over the years, I realize that we could have gone to Standard Costing, and used the variances to track where things went wrong. You can still see the “actual” cost at the job level, even when standard cost. This was something we simply didn’t realize.
- No customizations (except a few reports). we were going to run a vanilla as possible. No Changes here. This was a perfect decision. it helped us in so many ways and as the IT manager, I was no longer a liability if I left the company later (which I did do when I came to Epicor). FYI, this company is still using Epicor today.
- No changes to our part structure, no changes to our BOM structure… we didnt have a computerized routing, so we needed to invent that as we were building our data. What Changes? Probably would have made the same decision. Since we had so much “invention” to do, we decided to only create the BOM/BOO job structure for those items with active sales order demands. This reduced the amount of items to build from the 6000 finished goods times down to about 150 active parts. as new orders came in, we put any new parts on the list to be built and input. Our team was amazing!
- Minimal Data Imports: The only data we would actually import from the old system was the list of part numbers and quantities at go-live - EVERYTHING else was hand typed into the system. What Changes? Probably would have made the same decision. We used manual data entry as a training exercise. Our former system’s data fields didn’t align perfectly with the new system. Also, our orders (the many data entry) were hyper complex with many line items and in some cases hundreds of deliveries… determining which ones were still open and which ones were closed, and reviewing each one was something best left to a human. We had something like 1200 sales orders to enter, and 12 people… each person got to enter 100 orders, and it took them one day. Same story for Purchasing and Job Management. Accounting manually entered AR and AP Invoices (after one month to allow the bulk of them to be paid with the old system). NOTE that the ONLY problem we had was with the data that was imported. We had to repair lots of the data import for part quantity after it arrived.
Even though I would have changed a few things, I still call this project (My first Epicor implementation) “the most successful” I ever did, even though, I later became an Epicor Employee, and spent 16 years implementing customers. The result of “overspending” on training was that we went live in four months, under-spending the entire project budget by $100k. One month after going live, I took a one week vacation, the first one in two years.
9 Likes
Not messing up the UOM conversions…not once, but twice
2 Likes
Go for 3!!
3 Likes
Curious, meaning pulling the trigger in UOM Conversion Maintenance caused more hardship than help? Or something else?
My very first boss when I became a consultant told me, “You have to know the software. But if you’re not 80% psychologist you’re going to fail at this.”
Consulting is a relationship business.
6 Likes
1 Like
Well put @Ernie
EDIT:
And I have met a great bunch of people here, which just emphasizes it… and that’s one of the reasons I go to Insights, and damn the cost!
2 Likes
No just getting the divide mixed up with the multiply… That’s all.
2 Likes
we did a pseudo fresh install when we jumped from 8 to 10. Exported data from 8 and DMT’d it into 10. Primary reason was to purge all the garbage by not bringing it over.
Best laid plans …
All the people responsible for determining what data (parts, suppliers, customers, part classes,etc…) basically said “we need them all”
2 Likes
While not a hard rule, one should really avoid the letters O and I (that’s a capital i) for their easy confusion with 0 and 1.
And a somewhat unrelated rant …
Part numbers for electronic parts are almost always “intelligent”, with multiple parameters (value, power, tolerance, temperature, device package, grade, etc…) right in the P/N.
And to make things even worse, the packaging (how the parts are packed) are often included. And not just as a suffix, but sometimes in the middle of the P/N.
For example, a part might have a 5 or more fields with the 3rd field being packaging like:
257 - 250 pieces on 7" reel
1K7 - 1000 pieces on 7" reel
48T - 48 pieces in a tube
2R3 - 2000 pieces on a 13" reel
The problem arrises when I have to specify the part on a BOM (not a BOM in our system, but the BOM provided to a contract manufacturer)
It’s akin to having part numbers for like
LRG-WHT-DZ-ORG - 12 Large white organic eggs
LRG-WHT-GR-ORG - 144 Large white organic eggs
LRG-WHT-FL-ORG - 288 Large white organic eggs
It’s understood that the recipe (our BOM) should specify individual qtys, not fractions of the qty per package. So we’d say:
Qty Description Mfgr Mfgr PN
2 EGG, LARGE, WHITE,ORGANIC Acme LRG-WHT-DZ-ORG
I’ve gotten emails saying, there’s a long lead time on LRG-WHT-FL-ORG, and want to know if they can use LRG-WHT-GR-ORG instead. Not every contract manufacturer knows (or can be trusted) to make that call themselves.
End rambling rant.
3 Likes
This is very helpful ! Thanks ! We are just starting on our implementation!
2 Likes
3 Likes
2 Likes