How many ECO groups?

Epicor ERP 10
1

I am new to Epicor and we are in the implementation stage. I am trying to get a handle on ECO groups. Are there any best practices for this? Like how many ECO groups should you create? Do some companies use just one? Or create one for each user?

thanks

2

You don’t really Create any upfront. They are working groups, and you only create one when you have to work on a Revision. For Every New Revision (A to B) you could create a New Working Group.

Now what you can come up with is a naming standard such as:
XXX-181031

XXX = First Name Initial, Middle Name Initial, Last Name Initial - YYMMDD

kinda like AR Invoice Group; it’s there today, its gone tomorrow - but ECO Group’s remain

We don’t even let our Users generate the name… We use ARAS → Service Connect → Epicor and they do their ECO Stuff in ARAS.

https://www.aras.com/plm-software/?n=aras-innovator-overview-plm-software

2 Likes
3

I’m not sure there really is a best practice.
I’ve seen groups used in multiple ways.
Added a few things below you might think about.
And I’m guessing users will have some more ideas for you too.

How many?

  • 1 per each user/group, added as needed
  • 1 per each ECO/project, added for every new project or set of changes
  • i.e. some sites reuse a limited number of groups while others are continually adding new groups

Maintenance, closing, deleting, etc…

  • Sites that have many groups may or may not close/delete their groups.
    — I saw one location that close groups when a project is finished, and they never delete groups. i.e. they use their ECO groups as their product change history.

Purpose
At least one group will be required for modifying your part “methods”.
It is just a workspace where you can checked revisions out, modified and then checked them back in.

1 Like
4

Kind of two paths you can take (two and a half).

  1. Make the ECOGroup ID meaningfull - like tied to your ECR/ECO/ECN system if your company uses one.

  2. Go free form, and make the ECOGroupID meaningless.

2b. Use the “Fast ECO” system where the Users ID is the ECO Group ID.

5

Thanks everybody for the good suggestions!

6

We just create an ECOGroupID per Engineering. They use that ID to update the Revs and any PN.

7

One “bad” thing about E10 (and prior versions) is that the ECO Group ID can be re-used.

Good for people that don’t tie it to an external system like Engineering generated Engineering Change Numbers (ECN’s). But bad that a later change can be made when it’s not tied to the original ECN

8

HA, I didn’t know you could delete them! We’ve got a bunch of old groups out there that were used when we imported BOM’s with service connect that are useless now. That list just got shorter!

9

What a great topic! Another use case that seems to make sense is to make a group based on the type of part being updated. For my company, we have different “workflow groups” (as Epicor calls them) based on the type of part being affected. Has anyone tried to do this?

We recently went live and we use an external ECO management system. However, I am considering/brainstorming how we could merge it into Epicor to achieve more automation, consistency, and cut down on the potential for user errors when entering data. I can see many advantages to keeping as much within Epicor as possible. We aren’t going to be buying a fancy PLM system anytime soon so I am looking for a pragmatic way to use the OOTB functionality.

The use case to create a new group for each new ECO/ECN seems to makes sense as a place to hold the notes associated with the group of revisions that were edited. But I can’t help but feel like it’s wasteful to keep a bunch of empty “folders” that used to contain work in them. The ECO field will keep a record of each revision and what ECO # it was tied to and that lives with the part revision, not the ECO group. Would it make more sense to use a UD table to keep ECO # metadata instead of keeping a bunch of ECO groups?