There are a number of different techniques for using option filters, so how does one decide the best technique for the task at hand? Here's one approach to help you turn requirements into a working prototype. This is part of a series of help documents on how to use option filters. For the full list, see the "Related Articles" section below.
Before you begin...
- You should be generally familiar with all the option filter techniques.
Table of Contents
When you begin constructing your configurator, you'll need to:
Consider the scope of your configuration
Usually, this is fairly straightforward: you probably have a specific product with clearly-defined boundaries. For example, we could be selling a car, and want to offer that discrete object in various configurations. It's easy to tell where your configurator for the car should stop: the car is a stand-alone object. Its configuration is not related to other products being purchased at the same time.
However, the scope may be a grey area when selling other products. For example, you may be selling a product which is a sub-component of another, larger product. Or maybe an attribute of your product changes, depending on how many you order. How far do you go in following these relationships to other things?
The best thing to do:
-
Start small.
Begin your work with a tightly-focused scope, so you can start your design without overthinking things. Because developing in Epicor CPQ is easier than many other systems, try using Rapid Application Development techniques to get at least a draft configurator up and working. Even if this won't be your final design, you're still learning about how to configure the product and gathering consensus from colleagues in the process.
-
Build iteratively.
With each version you work on, add features that answer to a clearly-defined, narrow scope. You can always add onto it later in the next round.
-
Stay close to your subject matter experts.
Align with the product manager in charge of this configured product: at least in your initial build, respect the "edges" of the product as described by that person.
-
Think in modules.
Keep in mind the nested configurator feature, which can help you decompose a complex configuration into smaller, more manageable parts.
Scope Example
In our example of a car configurator, we will be focused on the properties of the car itself
- color
- towing capacity
- number of passengers
- mileage
- etc.
We won't be considering any add-ons like warranties, service plans, or special considerations based on geography, date, or whom we want to sell the car to. We're focusing on the object itself in this first pass.
List the parameters that fall within that scope
So you've defined your scope. Given the scope of the item, what is configurable about the item within that scope? In this walkthrough, we'll call these the "parameters" of the configured product. Usually, these parameters become fields in the Epicor CPQ UI – some of which your users can see and edit, others which may be hidden to them. Don't worry about how you will store or show those parameters yet. Just think about what information is logically necessary to build the item:
- What parameters help your customer decide which configuration is best for them?
- type of task your product helps them complete
- conveniences your product offers to them while they perform that task
- attributes that differentiate your product in the marketplace
- What parameters guide your manufacturing/production teams to build the product?
- dimensions
- optional features that must be added to the assembly
- materials that may need different manufacturing steps
You may focus first on the manufacturing/production parameters of your product, but design with the customer in mind. Another article can help you learn this perspective.
Parameter List Example
In this first version of our car configurator example, we'll design with the customer in mind and start with these parameters. Note how a "notes" field helps capture reasons or examples as they come up. We might use this information later. Here's the first draft of our table:
| Parameter for | Name | notes |
|---|---|---|
| customer | purpose | Towing/hauling (truck). Commuting (sedan). Large families (minivan or SUV). |
| customer | upgrade options | WiFi hot spot, heated seats, Bluetooth sound, collision detection |
| customer | number of passengers | 2, 3, 4, 6, 8 |
| customer | mileage | very efficient, somewhat efficient, not efficient at all (inverse of towing capacity) |
| customer | paint color | sky blue, cherry red, sandy beige, graphite black?? (Confirm with Samantha) |
| manufacturing | towing capacity | (meeting scheduled for next week) |
| manufacturing | engine size | 4 cylinder, V6 cylinder? |
State some of the possible values of those parameters
Given these parameters, you may have some of the values already, like we do in our notes above. Now's the time to flesh out that list, and describe at least the first set of the options each of these parameters have. Accept that this list will change: that's part of business! But gather the current info to define it, at least as it stands today. Let the product manager and others know that changes are OK, but having a fairly accurate understanding early in the process is key.
Parameter Values Example
In our car example, a few meetings and emails have given us this updated version of our parameters table:
| Parameter for | Parameter | Option Value | Option Display |
|---|---|---|---|
| customer | purpose | Truck/Lorry | Freight Hauling/2 persons max |
| Sedan | Commuting/5 person max | ||
| Smart Car | Commuting/2 persons max | ||
| SUV | 7 person max/towing | ||
| customer | upgrade options | WIFI | WiFi hot spot |
| HotSeat | heated seats | ||
| Bluetooth | Bluetooth sound | ||
| SideCam | Collision detection | ||
| customer | number of passengers | 2-3 | Two or three |
| 4 | Four | ||
| 6 | up to six | ||
| 7 | Up to seven | ||
| customer | mileage | low | very powerful |
| med | balanced | ||
| high | very efficient | ||
| customer | paint color | P010 | sky blue |
| P237 | cherry red | ||
| P176 | sandy beige | ||
| P122 | graphite black | ||
| manufacturing | towing capacity | tow option A | (meeting with Joe on Thursday) |
| tow option B | |||
| manufacturing | engine size | 4 | 4 cylinder |
| 6 | V6 cylinder, without turbocharger. | ||
| 6T | V6 cylinder, with turbocharger. |
Some things to note:
- if you don't have information yet, just mock in some options. We've done this on towing capacity.
- remember that the value of any option can be different from the display name you show your customers. We've set up two columns to store the internal value and the public-facing display text, simply because we were getting this information already at this early stage. It's not necessary to spell this out now, but you'll find it makes your design work easier.
Map any dependencies between the parameters
Use the various option filter techniques to implement the dependencies
Related articles
Dependency Map Example
This is an important step. Working with the product manager, discover all the relationships between parameters. Is "towing capacity - tow option A" always available? Or does it depend on engine size? Or other fields?
Be sure to separate out the dependencies which are part of the structural design of the product, and the dependencies which are only part of your current business rules, and are not based on physics, safety considerations, or engineering constraints. For example, "towing capacity - tow option A" may only be available if the engine is 6 cylinder or larger, because the vehicle will break with smaller engines. This is a design dependency of the product. Another dependency, such as "paint color - sky blue" depends on the region where the car is sold, is not related to the product, but more a marketing or legal constraint.
All types of constraints are important! But as you trace through the dependencies, it may be worthwhile to know where the constraint comes from: engineering, legal, marketing, or other sources.
As you map dependencies, you should start to see a dependency tree develop. In our example, let's say we have documented the following high-level dependencies with this sketch on a whiteboard:
Your sketch can help you decide which option filter approach would be best for your application.
-
A series of parameters in a row, like beads on a string? Try the simple option filter table.
The simplest of dependencies – parameter C depends on parameter B depends on parameter A – can be easily answered with a simple option filter. Learn more about the simple option filter.
-
Two-headed arrows? Try a megatable.
If parameter A depends on parameter B, and at the same time parameter B depends on parameter A, your sketch will show a two-headed arrow. If you have a few of these clustered together, a megatable can be a fine way to isolate and resolve these interdependencies. Learn more about megatables.
-
Many arrows leading to one place? Try a truth table.
If you see many lines all leading to one parameter, then you can anticipate complex relationships between all those parameters working together. A truth table can be a great way to summarize all the possibilities, and specify which of those are allowed. Learn more about truth tables.
Implementation Techniques Example
Let's go back to our example sketch of dependencies. First, note the reciprocal depdendencies (arrows pointing both ways) in the first three fields: number of passengers and engine size depend on each other, as do number of passengers and purpose. These reciprocal relationships are best solved with a megatable technique.
Note another cluster of relationships: towing capacity is dependent on two or more other fields (engine size and mileage). A truth table could be useful here.
Keep the strengths and weaknesses of each technique in mind as you begin developing your prototype.
To continue your development, see the specifics in each of the option filter documents mentioned here. Those will guide you the rest of the way.