Cancel
Showing results for 
Search instead for 
Did you mean: 

Beyond Product Configurator Software: Total Variability Management

Enthusiast
Enthusiast

product-configurator-concept.png

When you hear the words “configurator software”, what do you think of? How about "product configurator" or “product configuration”? “Product planning”? “Feature management”?  “Configure-to-Order” or “Engineer-to-Order”? Broadly speaking, there are 3 sets of activities that come into play when we talk about defining and managing variability across a suite of products: first, the upfront planning of your product suite and the features that you want to offer to the market; second, all of the product development activities that together define what that product will be, how it will be produced and assembled; third, delivering the product and the ability to make individual choices about product features to the marketplace.

 

Today, variability planning is often disconnected from the actual product development and configuration.This leads to a gap between how product management and product marketing conceive of what the product will “look like” to the marketplace and how the different contributing engineers develop solutions to support this marketing vision for the product.

What if you could tie variability planning to actual product development? With Teamcenter, we’re extending the boundaries of a traditional product configurator software to do just that. We’ve been talking a lot about our Integrated Product Definition  and BOM management, including conversations about  BOM configuration management and configuration management best practices. In a previous article, I talked about product variant management.  In that article, I discussed the different factors and actors involved in defining and managing the variability you wish to offer to your customer base as well as the corresponding bill of material definitions for all product variants.  In another article, my colleague Sanjay Kulkarni focused more closely on Guided Product Configuration. Now I’d like to explore “product” configuration as a topic that plays a key role in the overall product definition strategy of your company.  I put quotations around the word ‘product’ because in this case we are talking about configuration as it applies to the whole product definition lifecycle—not just the physical or engineering product definition information.

 

Compared to all other solutions available in the marketplace, Teamcenter uniquely supports variability introduction and management seamlessly tied to product definition and visual configuration.

 

Teamcenter Configurator

                                                                                                               

I’d like to focus more on specifically on how Teamcenter supports defining and managing the variability across a product suite from early conception, requirements and system definition, market analysis and determination of product offerings, engineering, and manufacturing planning. Users are guided through the process of making product selections in a clear, informative way that is seamlessly tied to the visual product definition, so the user can see their selected product variant at any stage of the configuration process.

 

Configurator Software in Teamcenter: Benefits Reach Far Beyond Engineering

Often when we think about offering the flexibility of different product options to the market, we think about how this is reflected in the physical product or the bill of materials.  Ultimately, it is a specific physical product variant that gets delivered to the customer or dealer or distribution center. However, the whole process of deciding and defining product options for a product line reaches far beyond engineering.  In fact, much of the business value of building product variability into your product definition starts well before the engineering process even begins.

 

configurator impact across roles

 

Specializing the Variability that’s Relevant for Different Roles

The scope of people involved in defining variability and delivering products against that definition is quite broad – and so is the range of information each role requires. The product manager thinks in terms of the options that will be offered to the market (i.e. the features that will make a customer buy their product).  These are usually referred to as Sales or Marketing options.  These options may have information captured against them like a picture to show what the option looks like, a marketing description to explain what this feature offers and why the customer may want it, and other information that will be market-facing. 

 

Engineers, in turn, will take this input from the Product Manager and decide what it means in engineering terms—what solutions will they design or reuse from their parts library to offer this option for the product(s) they are working on?  Engineers may have their own technical options that they need to introduce to be able to design a range of similar solutions all derived from the same variable assembly.

 

Likewise, documentation specialists, systems engineers, manufacturing engineers, all may have different options that capture the variability that is relevant for their needs. 

 

For example, a documentation specialist will produce user manuals for the products in different languages.  No other user group cares about “Language” specifically as a point of variation.  Product management may have defined an option called “Market” which captures the country of sale.  Engineering may not care about this option at all, as it will not directly impact the function of the product.  However, manufacturing execution will care a great deal about market as this directly impacts what plants and procurement / assembly methods they employ for the product.  Documentation will also care about “Market” because they will use this sales option to drive what languages are needed for the user manuals they provide to that market.  This and similar examples illustrated below.

 

configurator shared and unique options across domains

 

Configurator software capabilities in Teamcenter will support specializing and subsetting options to meet the needs of these different user communities.  With this approach, both options and rules can be specialized with different metadata, behaviors, access controls and solve characteristics to support the communities they are relevant for.

 

This illustrates some of the key Teamcenter principles of variability management: scoping, reuse, separating variability definition from content / BOM definition, and supporting the needs of multiple user communities without duplication.

 

Configurator software in Teamcenter: Benefits Reach Far Beyond Engineering

An effective configurator software strategy needs to address the scope of product configuration and variability management far beyond the scope of engineering. You need to support variability introduction and management seamlessly tied to product definition and visual configuration. I’ve touched on that scope of people involved here, but realize there is so much more to talk about! Over the next several weeks, I’d like to continue this discussion. Let’s explore some of the key user communities and their role in helping to define and deliver configured products to market.

 

Other discussions in this series include:

Configurator for Product Management and Planning

Configurator for Engineering and Manufacturing

 Configurator for Enabling Customer Choice

 After-sales BOM and Configuration

Configurator for Service Organizations

Accelerating Lead Times for Engineer to Order (ETO) Processes