Assessing Epicor Product Configurator

Kinetic ERP
1

Hi all,

Our company is in the process of implementing Epicor Kinetic ERP (SaaS). I’m evaluating whether to go ahead with Epicor’s Product Configurator module. One of our aims is to standardise our product BOMs, so that they can be generated (at least in part) at Quote/Order stage.

Currently, most of our Assembly BOMs are bespoke and created per project. However, within these assemblies, there are some sub-assemblies and parts that are standard, based on type of product etc. We therefore want the Configurator to create partial BOMs containing these standard parts, with dummy records for the ‘bespoke’ parts that need to be designed by our Engineering team.

The alternative we demo’d was Driveworks, which also has a Configurator module. However, using Epicor Configurator for the front-end forms means that our Sales people can use one system for quoting configured products and ‘new designs’.

For those of you using the Epicor Product Configurator (or have integrated with Driveworks configurators):

  • What ‘gotchas’ have you come across in setup/usage?
  • Does the tool have any limitations for your needs?

Any advice/experience you can share would be fantastic - thanks!

2

@ZanebK We use the CFG for almost everything we make- and we Quote everything. Orders only get created when we get a PO - and then it’s basically straight to a job and scheduling.

Background - We make custom metal/plastic conveyor belts for the food industry. Every customer has different requirements, and we make about 50 different products (most are variations on a design but are grouped into ‘families’) that have multiple options. We are multi-company, multi-UOM, multi-currency, and are cost+ for pricing. And we use the Enterprise Configurator across those companies.

Setup - we have real part #'s for materials and generic part #'s for the manufactured belts. We have a complicated configurator for each belt ‘family’ where the specific logic exists for calculating everything. We also mathematically represent the MOM/BOM inside the CFG so we can calculate the actual cost inside the CFG and present multiple cost/option/price models to the Sales Person without having to exit the CFG and start over again to change one small detail. (I don’t like it, but I’m just the IT guy)

So I see where you are going with your questions, and my simple answer is that the Epicor CFG will do what you want. Without having more details I cant’ be sure of course.

I think the biggest thing is to make sure your manufacturing model can be built inside Epicor. Once that structure is there, the Configurator’s purpose can be well defined within that context. You cannot affect other parts of the system from within the CFG (not really, but there are some things you can do) so you will need to know about Method and Data directives to make some things happen. I guess I’m saying that the overall customizability of Kinetic is such that almost anything can be done - be it with custom code or right in the standard MOM/BOM model.

There are some of course - mostly based on C# code restraints and the architecture of how the CFG runs ‘inside’ the client. Certain things (like direct DB access) can be done from within the CFG right now but only a certain way. The new Kinetic interface will require a re-write and hopefully we will gain a lot of functionality and flexibility with that. Also - cloud based folks have a few more limitations (we’re on-site). The real answer to this question could take hours - but make sure you realize that the CFG is undergoing a transformation right now - and we are expecting a new tool set in the spring (hopefully!!) to start the re-write.

I hope that helps!

2 Likes
3

If you’re single-site, it should be a breeze. Configurators in a multi-site environment are complicated by two major limitations: the UI won’t let you run Get Details on a revision from another site (though you can hack around that with a BPM) and transfer orders cannot carry configuration. After three years of hitting walls, we may finally have a solution in the form of configurators that create non-configurable, transferable parts. We’ll probably create a million parts a year, but it’s the only option left. Multi-company is a non-starter. We were forced to abandon multi-company and restart our entire implementation from scratch because enterprising configurators kept crashing, bringing all other background processes to a halt. Epicor could not explain why it was happening, so we had no assurance that it wouldn’t bring us down in production.

2 Likes
4

Main limitation is Configurator is a subtractive configurator in that it can only work on what is already there. It can modify something or delete something, can’t add more. So if you have 10 material inputs the configurator can’t add an 11th. It can change any of the 10 material inputs to any part number or delete one or more. For most clients I have worked with this isn’t a show stopper.

Epicor does have interface to CAD packages that can utilize data from the configurator.

Depending on your product you might also look at KBMax (aka CPQ) which Epicor recently acquired. Much more options, also means more involved to implement.

2 Likes
5

Jim,

What do you mean “what is already there?”

6

I think he’s referring to the fact that the MOM and BOM cannot be added to, only subtracted from using the Keep…When rules. A lot of folks will pad the methods with placeholder parts and operations to account for variations in process and then use the keep-when rules to remove the unnecessary bits. We do a bit of this as well just because we have some custom bit and pieces that can be part of our belts.

2 Likes
7

Thanks a lot for the insight Mike, this is really helpful.

Did you have to write custom C# code to achieve this? Can you clarify on having to start from the beginning to change a detail - does this mean you can’t go back to a previous field or page and update the input value?

(Apologies for my inexperience. I’ve requested a temporary license to trial Configurators and run through the courses on ELC).

8

Couldn’t you nest the subconfigurators to add as many as you want?

9

Nested CFG’s work for subassemblies - but eventually you find a bottom level assembly that has options and those options may need a raw material or another assembly that is in inventory and has a part number. the CFG doesn’t allow you to add that part # to the BOM unless there is a spot for it already - hence the placeholder idea.

10

I see now what you are saying.

11

If the bottom level assembly has options, wouldn’t it have a configurator inside of it that would have those options in it?

12

You absolutely can go backwards and change values - but it is 100% dependent on your business logic and when you want/need the CFG to do. Some folks just use it to make a comment string, or smart part number, or set a few values so the ‘Rules’ can do the real work. We’re not that simple, but you might be.

Absolutely. The CFG is basically all custom code. And you definitely need some background on the CFG to fully understand what I’m going to describe but I’ll try the best I can :slight_smile:

We do custom work - it’s all pretty much length by width by material plus a bunch of options. Those options all contribute to cost - either by material or by time - and we are Cost+ so we need cost to be correct before we can determine margin and price. Normally, you go through the configurator until it finishes, ‘Get Details’ (you’ll learn about this), allow the CFG ‘Rules’ to run, and let the core Epicor code get your cost and price calculated using all the other bits and pieces from the Part and Customer records (Price lists, discounts tables, min order qty, etc.). But if you have to change something, then you have to do it all over again. Any number of changes during the negotiation phase with the customer can be very time consuming.

This is one of the business process ‘gotchas’ that the customer service person faces, so we represent the MOM, BOM, and Rules and other stuff like tariffs and surcharges inside the CFG, as C# Code and data in user-defined tables, and that allows us to remain inside the CFG and make changes very quickly and use a very complicated rule set that the standard ‘rules’ really cannot handle.

EDIT - To add to this, there are BPMs, data directives, and custom code options all over the system to allow you to do even more things and manipulate/replace/recalculate data outside of the CFG. So you really need to clearly understand the whole process as Epicor has defined it, and fully understand and architect what you want the CFG to do (or not do). Once you are there, building it is usually a bit easier.

There are a couple of great consultants out there to help with all of this. I’ll let you do it, but if you ask nicely, I’m sure some of them may message you privately. :slight_smile:

13

Yes - but you still have to start with a non-expandable MOM/BOM. You could have many levels of subassemblies - all with their own CFGs and MOM/BOMs. And each of those can have placeholders and the rules associated with them.

It really comes down to the overall design in the end - and how the CFG compliments the Part and it’s MOM/BOM. But the one rule still holds - you cannot use the CFG to ADD a new row to the MOM/BOM. You can only subtract or hide a row.

@Jkinneman - I’m getting this correct right? I’m not as up-to-date as I should be, so let me know if I’m full of :poop:

1 Like
14

@MikeGross Correct, the configurator starts with a MOM (BOM/BOO) with a fixed number of operations and materials. The configurator can change any of these items to something else or delete it. A part within the MOM can have its own configurator, this is called cascading configurators. For example a water heater system has a configurator and the water tank has its own configurator. The tank can be sold on its own or as part of a system. The parent “system” configurator would launch first and then when done launches the configurator for the tank. The tank could also have a part that is configurable and so on.

2 Likes
15

The starting MOM (BOO/BOM) has a set number of operations and materials, the configurator can manipulate these existing operations and materials but can’t add to them. So if the starting MOM has 5 operations that is the most we can ever have, the configurator can change an operation or delete it but not add operations. Same for materials.

16

That’s where I would argue that if you are adding more operations to a part it’s a different part and therefore should be a different configurator - using a cascading configurator approach.

17

@utaylor Do you mean “I need more operations to start with” when you say “adding more operations”, if that is the case then yes you would need a part with the required maximum number of operations.

In theory and I have never tested it you could change a part within an item to a configurable item and then within that item change an item to a configurable item and so on creating an endless number of levels of subassemblies. In effect creating a recursion of configurable parts. Each item would be at a lower level from the one above so the structure would be a mess.

18

that goes right along with “Do not cross the streams!”