Embedded Configurator Insight

Kinetic ERP
1

Good morning everyone!

This may be a bit of a long-winded post, but myself and a few colleagues have been spinning our wheels on this subject for a couple of weeks, and I am hoping all of you awesome folks here will be able to provide some insight that will put some of our concerns to rest.

We are concerned the amount of work needed to set up all of our product configurations is going to be a large roadblock in our implementation process.

Firstly, some background information regarding our implementation:

  • We are about 4.5 months away from our go live date, and are still actively working on implementation across a spread of different modules. (DocStar,Quickship etc.)

  • Initially, we were going the route of CPQ for Phase 1 of our implementation, but decided to go the route of the Embedded Configurator for the time being after determining it better suited our needs on our current timeline based on what we’ve learned about it so far, and that we don’t currently need 3D modeling/eCommerce.

  • We are first time Epicor users, and are learning as we go and do not have previous experience with ERP10 or Kinetic.

  • The configurator we are using for our current ERP is very basic, and does not offer nearly as much as Epicor CPQ/Embedded Configurator.

  • About 90% of the products we make in our company are configurable and customizable.

With that out of the way, on to my main questions…

**What has your experience been with the embedded configurator? **

And in regards to that experience, how difficult was the initial set up process when you were in your implementation phase?

Do you have a person that specializes solely in working with the configurator, or do they become more automated/self sufficient as you became more comfortable with the program and had your baseline configurations set up?

Pros/Cons of the Embedded Configurator vs. CPQ?

My biggest concern is that since we change processes and materials on the fly so often, that we are going to spending a large amount of time with configurations day in and day out. A lot of those fears could be attributed to our inexperience with the platform however.

We have some sessions scheduled in the next week or so with a configurator consultant after many weeks of back and forth since we decided to table CPQ for the time being and just work with the embedded configurator in Phase 1.

I have been learning all I can about the Configurator from the material that Epicor provides, as well as the Configurator Technical Reference Guide.

While I have been able to build out a lot of test configurations for our products and learn a ton about it, until we are using it actively once we go live I am uncertain of what we are getting ourselves into.

Any insight is very much appreciated, and thanks for reading. I have been digging into all the configurator related content available here the past few months, and I have learned a ton as a result. I wanted to get some thoughts from those here who have been using it for a long time or were in a similar position as us once upon a time.

Special shout out to @CSmith for getting me on the right track back when I first found myself in Configuration Station and had no idea what I was getting myself into. :rofl:

2

Very welcome! Initial difficulty is determining how to structure the data to fit into the configurator and get the desired results output in the MoM template. Once that was accomplished other item was converting many flat BOMs for the Custom Division into datasets to be fed into the DMT. Biggest issue was really the amount of free time others had to devote to testing and learning. TEST LOTS! In hindsight, more testing would have saved lots of time in the future.

1 Like
3

All of our MFG parts are 100% configurable. And our ‘critical path’ involves changing operations based on configured options, it sounds like we’re in the same boat.

The 50k ft view is that we created a Q&A/Math configurator and use the rules to substitute parts and operation codes as needed into a mom/bom filled with placeholders. We set the OP codes/part #'s, times/quantities, capabilities and resources, all from the logic built into the code.

We do all this, and get the bonus of being able to determine ACTUAL cost to manufacture right inside the configurator, which allows us to determine price/margin and feed the correct values to the quote once the Salesperson has reviewed it all. Plus some BPMs and things make sure we have met the minimum order values (margins, qty, dates, etc.)

I’ve spoken to a lot of people who use the CFG and we are one of the most complicates users. We also looked at CPQ and found that doing all of what we do would be nearly impossible in their system, plus we don’t need #d images either.

Implementing is a long road of constant editing/tweaking because our engineers and production team are constantly changing things. We have a dedicated programmer, and she is “the Law” when it comes to the CFG, and we have a decent change management process in place.

We’re not Kinetic yet, and we have some fear about it, but the added capabilities of the event editor in the Kinetic UI look like we can perhaps do some things better/simpler.

Hope that helps answer your questions.

2 Likes
4

One thing I would change if I was starting over would be no message boxes. The Verify Existing Configurations process cannot update any existing configurations if a single messagebox is used, and they don’t warn you.

Don’t use PC lookups, use BAQ’s and UD tables instead. Much faster.

The tools for writing method rules are awful, so try to keep them as simple as possible and keep as much of the complex logic in UD methods as possible.

If you are creating a classic configurator but plan to move to kinetic configurators, I would see if you can put as much as possible into Epicor Functions, it will make the move a lot easier I think.

2 Likes
5

^^----- All of this. Could not agree more.

2 Likes
6

In my classic configurator days, I would download the lookup table(s) (filtered if possible) as delimited strings, and use text parsing in client UD Functions to speed up the lookups. Reduce the number of calls on the wire. Way, way faster. Functions were not yet available but that would have been a big improvement.

7

Determining correct mom structure is the biggest key if your current configurator is poor. Our old one was so poor that engineering had no involvement and models did not match the needed structure at all. This meant that for epicor you were starting pretty much from scratch with the bom and boo.

I would agree with Evan that BAQ’s are the way to go. I would warn you that our experience with the Kinetic configurator and BAQ’s specifically has had problems. They do work great in classic but some functionality with them is broken with advanced configurators in kinetic currently. Also, user defined methods have to be written twice in kinetic currently once in the user defined method tool if needed for rules and in ap studio for the gui if needed on the front side. In our experience many of the ap studio tools are not working as well in the configurator as they are outside of it.

1 Like
8

Thanks for the reply Mike! It is very much appreciated.

I had remembered seeing in some previous threads you explaining your company’s process, and it sounded very similar to ours, so I had been hoping you would comment!!

Yep, we are largely in the same boat. There isn’t a day that goes by where we aren’t making changes in engineering or on the production floor to fit the needs of a specific unit/customer.

1 Like
9

Thanks Evan. I had been wondering what the most efficient lookup method would be, and we had been leaning toward UD tables and BAQ’s based on a lot of the experiences I had been seeing here when initially researching the configurator.

I appreciate the heads up, as this will save us a lot of headache down the road. We’re going to have a pretty large number of configurators with a lot of materials and parts shared amongst them, and knowing that the message boxes could potentially break the verification of them is good to know ahead of time.

Thanks for your honest reply, this discussion has been great so far and really what I was hoping for.

10

Thanks Clint.

We have a training session scheduled for first thing next week, so I’m excited to get a better look under the hood so I can find my way around a bit better in all of the Configurator related screens.

We’ve been able to figure out a lot so far just through our own trial and error and using the materials that Epicor provides, but the training should answer a lot of outstanding questions we still have regarding the general setup and tying configurations to the BOM as well as utilizing C# and Epicor functions a bit better. I want to really understand them the best I can so we can use the most efficient methods earlier to save time in the long run.

I am hoping to dedicate a good bit of time to testing each week until we go live and continue to build up our configurations as we go along. I appreciate your insight.

I’m having a discussion with our team today regarding all of the responses in this thread and I think all of this information is going to benefit us greatly, as it answers a lot of the questions we have had that Epicor couldn’t really give us a “real life perspective” on.

11

Thanks David. This is a good summation of how the switch feels for us so far. Our current configurator is very limited compared to the capabilities (or lack thereof) of the Embedded Configurator. That said though, we are excited to see what we will be able to achieve in the long term with Epicor’s. It’s a daunting transition but one that I think is going to benefit us in the long run once we understand it better and the tools we have at our disposal now. I’m trying to remain cautiously optimistic!

BAQ’s have been referenced in almost every reply to this thread, so I am going to follow the word of the wise and start experimenting with integrating them into our current configurators soon. You guys rock!