My father is one of those few remaining American heroes who can build and/or fix pretty much anything. A masterful engineer without the degree. A man of necessity, not of waste. I remember distinctly as a child when my dad was planning to replace his 15-year-old truck with a new one. I remember the excitement surrounding the new ride, and the disappointment when he came home with a functional, but by no means fancy, new truck. In particular, I was underwhelmed with the stereo. In his calm, deep, southern drawl, Dad stated, “Son, you don’t buy a truck for the stereo, you buy it for the engine. Don’t let the bells and whistles distract you from what’s most important. What good is a fancy radio if you can’t haul what you need from point A to point B.” I knew better than to argue. Not because he was tough (which he is), but because I knew he was right (he usually is). Lately, this lesson and its implication on today’s product complexity has continued to resurface in my mind. Would you use the same truck to move your buddy’s TV across town that you would to move his entire house across town? Not if you wanted the move to be fast and efficient. Yet many organizations today are using the same engine to haul dramatically different types of loads – and it’s weighing them down. The first step to effectively moving your load is to understand how heavy it is. A product with 10 variants bears a much lighter load than a product with 10,000,000,000,000 variants (1012). For example, a pencil has very few variants (color, lead type, width, eraser type) and therefore would be an easy load for a 4-cylinder truck. A globally-sold luxury SUV, however, could have 1021 buildable variants. The load of the SUV is going to need something substantially stronger than a 4-cylinder engine truck. Once you’ve determined your load size, it’s time to evaluate the engine.
The Engine Matters
You don’t buy a truck for the stereo, you buy it for the engine.
Evaluating the Engine
At the heart of any product configuration and/or complexity management system is a rules engine: the part of the code that controls what happens whenever the user and/or interface makes a product selection. There are several different approaches to a rules engine dating back to the late 1970s. Just like truck engines, they are not all created equal in either approach or ability. A 4-cylinder and a V8 are both engines, but I certainly would not call them equal. Unfortunately, I’ve observed many organizations assume all rules engine are the same, so during the evaluation and purchasing process, they quickly move on to “playing with the radio and NAV system” – or as my dad would call them, the bells and whistles. In this analogy, the bells and whistles are all the additional features often stacked on top of the configuration engine. Examples include:
- Price Optimization
- Up-selling, suggested add-ons
- Workflow capabilities
- Visualization
- User Interface options
That is not to say these options aren’t important. There are non-engine, must have features when I go to buy a vehicle. I live in Atlanta, Georgia. A powerful Air Con system is a must-have feature to survive Georgia summers. However, the importance of these features need to be weighed against the load put upon the engine. In my example, while the Air Con is an add-on feature, it puts an additional load on the engine. So do many of the “bells and whistles” of our configuration solutions. Organizations that get this right take the time to understand their product complexity load and balance it against the features (“bells and whistles”) their organization considers most important. The tricky part is that the load of product complexity can be deceptive, especially if organizations operate in silos regarding their product complexity. Sales and marketing might buy a truck that adequately carries the load they perceive for their product with all the bells and whistles they consider most important. However, once they try to start centralizing their product configuration rules and knowledge into a single truck as a part of the Digital Transformation journey, the engine that worked great driving from the lot is suddenly struggling under the additional load.
The Impact of Being Underpowered
So, what is the impact of an underpowered engine in the realm of product configuration solutions? Time. The most obvious evidence a configuration engine is struggling under the load is the amount of time it takes the solution customer to complete the configuration. In the most extreme cases, the engine just fails altogether, and the organization is “left of the side of the road.” Impatient customers move on to other websites and impatient resellers use the competition’s tools. These missed opportunities are bad enough, but if the configuration engine has a more central role in your Digital Transformation journey, the impact could be a business-critical system (for example, ERP or PLM) cannot complete its job. The ERP system can’t process the order. The PLM system cannot render the BOM. These are not missed opportunities, these are failures. Due to my father’s influence, I’m a pretty low risk guy. I refuse to drive an underpowered vehicle. I want to have confidence I can carry all my stuff and still climb every hill at speed. I want to know my engine can handle my load. In my 10+ years in the configuration space, I’ve applied the same mentality. I want to know the engine can handle the load – not hope. So how can you be confident that your engine can handle the load? By adopting the right tool. Configit’s compilation approach and Virtual Tabulation® storage mechanisms are unique to the industry and have a proven track record of handling massively complex product models with superior performance.
Configit has seen many companies attempt a Configuration Lifecycle Management transformation by gambling on the foundation of a lesser rules engine, only to struggle to make it up the hill or worse, stranded on the side of the road. The engine matters. And Configit has the best engine on the market. Interested in learning more? Download Configit’s white paper to find out how Virtual Tabulation® offers significant improvement in the way configuration solutions are created, maintained, deployed, and used.