Pursuing the Promise of Product Lifecycle Management
The Practical PLM Newsletter - Issue 8, August 2016

IN THIS ISSUE

Introduction - Configure, Price and Quote (CPQ) and How it Works
Business - The Business of Engineering and CPQ
Best Practices - Matching CPQ with “To-Order” Operations
Application - Design Automation, An Interview with Scott Heide
Learning - Upcoming Webinar: CPQ and PLM in Practice

INTRODUCTION

Configure, Price and Quote (CPQ) and How it Works

Part 2 of a 3 Part Series - Mapping CPQ Functionality to the Mode of Your Business Operation

Last month, we published Part 1 of this series with an introduction to CPQ. We talked about what it is, identified its value proposition and asserted, “Why PLM would be the ideal foundation for CPQ.”

For Part 2 of this series, we dig a bit further and talk about the workings of CPQ. We received a question in response to our first part that serves a great lead-in to the next section entitled “CPQ and the Business of Engineering.” The question was “why not run CPQ as a standalone application?” STOP. Add yet another application? That’s what we are urging companies to reconsider. In this section, we weave the topic of CPQ into the spirit of Business of Engineering.

To help you position CPQ capabilities within the “To-Order” spectrum, Dick Bourke wrote a brief for the Best Practices section addressed, “Matching CPQ with the “To-Order” Spectrum.” What we hope to illuminate here is that there is NOT a “one-size-fits-all” solution.

The term “design automation” is often attached to characterizing an aspect of CPQ. To shed some light on the topic, we were able to conduct an informative interview with Scott Heide, a leading industry expert on the topic.

We have explored CPQ, looked at various vendor offerings, reviewed numerous case studies and talked to knowledgeable folks like Scott Heide. Clearly, CPQ applications provide one of the greatest opportunities for business excellence today. For those that aren’t leveraging CPQ, we would be so bold as to declare: “you’re leaving money on the table . . . spending more on cost of goods then you need to . . . and will be challenged to compete effectively.”

The evolving trend to customized products and services continues to affect the strategic planning of companies eager to gain competitive differentiation. Thus, within the evolving spirit of “the Business of Engineering,” CPQ can play a vital role.

BUSINESS

The Business of Engineering and CPQ

Avoiding another Point Solution

The spirit of the Business of Engineering is to focus on broader strategic issues. The steadily increasing complexity of product development fuels the need for coping with products developed across multiple disciplines while driving profitable outcomes. So when we received the question, “why not run CPQ as a standalone application?” it seemed like an ideal time to integrate CPQ considerations into the Business of Engineering theme.

As we argued earlier, we believe PLM is ideally suited as a platform for CPQ. As we have seen in many standalone solutions, existing parts are exported from the ERP environment. Of course, this makes sense if all the parts are released. As we discuss in the next section, this lifecycle status is viable for assemble-to-order (ATO) operations. It’s like ordering your sandwich at Subway. All the “parts” are “released” and sitting in front of you. There is no “engineering” going on.

Moreover, in the ATO environment, the CPQ solution builds a unique BOM. The sales person identifies the available released parts and sub-assemblies that are eventually assembled. Hence, leveraging data from the ERP platform makes great sense.

But, what happens when one or more of the parts for an order have yet to be designed and built? The part(s) aren’t released and may not even exist. Additional engineering, manufacturing planning, tooling, etc. still need to be done. That’s where there is no substitute for a product lifecycle management (PLM) platform.

CIMdata, the PLM industry analyst group, recently published an article, “The Business of Engineering.” You can read it here. They point out that, “We rarely see companies that have implemented a complete end-to-end solution that achieves their PLM vision.” Rather, companies get focused on bringing in specific vertical functionality without considering the broader impact to their product lifecycle management activities.

So what does CPQ have to do with the Business of Engineering? CPQ could be treated just like a CAD application that is looking for a way to control CAD drawings. But, therein is the potential Achilles heel. The Business of Engineering encourages that organizations look at the end-to-end product related activities. And, at one end of this spectrum is the sales and quoting process.

For organizations that allow one or more unreleased parts to exist in an order, a repeatable process is vital such that those parts can be evaluated, planned, engineered, ordered, manufactured, etc. This is the very heart of PLM.

If CPQ is not yet implemented in your organization, then this is a great opportunity to embrace the Business of Engineering and look beyond just acquiring another point solution.

BEST PRACTICES

Matching CPQ with the “To-Order” Spectrum

The “To-Order” Mode of your Business will Determine the Needed CPQ Capabilities

By Dick Bourke

CPQ can be implemented in a range of product configuration options. As a starter for your strategic planning, here’s a generally accepted definition of “To-Order” options that will be your strategic choices.

Assemble-to-Order (ATO) – products with standard sets of predefined features and options. The customer selects specific features and options to develop the unique product configurations. Orders are typically processed by an ERP system, for example, computers ordered over the Internet.

Build/Configure-to-Order (B/CTO) – products have been predesigned in CAD models or parameterized documents, but not predefined with specific part numbers. The CPQ process is based on consultative dialogue with the customer, through the Web interface, to identify specific requirements. For example, products with dimensional and spatial requirements, such as kitchen cabinets and hydraulic actuators.

Engineer-to-Order (ETO) – the most complex and sophisticated products. Configuring requires interfacing with product development activities and tools, such as CAD software, design rules and other expert IT systems to produce complete documentation such as drawings and associated geometries for all downstream activities. Typically, the proposal cycle is iterative, for example, electrical distribution systems.

You may wish to tailor these definitions for your specific circumstances. Certainly, there are variations you could consider. European consultant, Jos Voskuil, offers some ideas in What is Digital PLM?

CPQ application is not a “one size fits all” matter. The individual processes must accommodate various product configuration environments, levels of design sophistication, product complexity, inventory, delivery modes and lead time management.

For some companies, a significant strategic shift will be from Make-to-Stock to an ATO environment. The rationale? Competition and customer expectations – unique configurations and fast delivery – may well force this decision to regain competitive differentiation.

APPLICATION

Design Automation

An Interview with Scott Heide, CEO of Engineering Intent

PPLM: Welcome, Scott. Thank you for spending some time with us. We are happy to have you bring additional perspective to our topic of CPQ. Before we start, give us a quick backgrounder as well as what you are doing today.

Scott: I started out with an interesting educational combination, both engineering and computer science degrees. After I graduated with a master’s in science from MIT in the mid-80s, I immediately joined a company that was a pioneer in engineering automation called ICAD. They developed the concept of what was then called “knowledge-based engineering,” now more often called “engineering automation,” and were able to deliver some eye-opening applications to a wide variety of high-end customers.

In the mid-90s, I started a company called Engineering Intent that developed a PC-based technology that was more accessible to users. It was also far more accessible prices, bringing the technology to a broader range of customers and applications.

At one point, I sold the technology under Intent’s hood to what was then Unigraphics, now Siemens PLM, who sells that product as Knowledge Fusion within their NX product. Later, I sold the company to Autodesk in 2005 to become what is their Inventor ETO (engineering-to-order) product.

About five years ago, I started a new incarnation of Engineering Intent, focused more on the services side of the business. We work directly with customers to help them implement successful enterprise engineering automation applications.

PPLM: Sounds as if the terminology has evolved. So our readers can connect based on their earlier experience, clarify terms that are being used today.

Scott: Back in the mid-80s, the hot term was “artificial intelligence.” This technology grew out of the Artificial Intelligence Lab at MIT. At the time, it was really the hot thing. Then people realized that AI was a little too blue sky. The technologies that fell under that umbrella often were exciting in concept, but disappointing in reality.

“Knowledge-based engineering.” That term was used thru the 90s and focussed on helping companies that designed very complex products, like airplanes and cars, to do the job. With Intent, when we started pushing the automation of engineering tasks, I used the term “engineering automation.” Autodesk uses the term ETO; that term is mirrored in the Siemens Rulestream ETO product

Today, Engineering Intent focuses on companies that follow an ETO business strategy and process. They sell a product that has to be engineered on a per customer basis – engineering has to touch almost every sale.

Design Automation is a common term. We call the total process “enterprise engineering automation.”

PPLM: Scott, what type of challenges prompt an organization to reach out to you?

Scott: Unfortunately, engineering is a limiting factor in the entire configure, price, quote and deliver processes. Whether they are making a custom window or custom elevator or custom steam turbine the challenges are the same: you have to do engineering to sell it and you are not paid for that engineering. But, if you don’t do that engineering right, you are not going to make the sale—or you make the sale and potentially lose any profit margin in it.

An ETO business may have anywhere from two to two hundred personnel doing manual follow-on, per-order engineering, trying to get good information to the factory to make that custom product. Unfortunately, there are mistakes made in this manual mode, and it usually takes a lot of time.

Also, often you are limited in how often and to whom you can quote because there are only a few people in the company that have the expertise to do it. If you can put their expertise into an automated system, then a person that may not have had the expertise to do a quote can now do it and be assured that the engineering is done properly. And, they can respond quickly to their customers and rest easy that what is being quoted is what is being sold, with the right price and right margin.

Automating as much of this process as possible helps them respond to the customer more quickly, and it gets the customer what they want quickly, accurately and as inexpensively as possible.

So, if you can automate that process for creating a quote, you can have much better control over what business you go after, as well as more solid knowledge of the pricing and margins you are going to get. And, if you can automate, you can grow the number of people who can do a quote.

PPLM: Sounds like you’re talking about “rules.” What are those rules and where would we find them?

Scott: It depends on the system that you are talking about. But, generically, rules are similar to an expression in a spreadsheet. I call them rules – not programming – because development is more like using a spreadsheet than they are like writing C-Sharp, .net or something like that.

When you say in a spreadsheet column C = the sum of A and B, then if A or B change, C updates, in effect, you’ve written a little program that will keep track of A, B and C in the proper relationship. You’ve made a declaration about that relationship between those components of that spreadsheet.

These systems work the same way; they just take that concept into the engineering world. Instead of saying column C equals the sum of column A and column B, you’re saying that the length of this component is the space between that component and this component, minus the space needed for connectors, something like that.

You are making a declaration about a property of an object and that property is calculated based on the values of other properties in the model. You’re making a spreadsheet-like declaration, so you are not really programming. That makes it much easier to create and manage the rules.

When I am giving a presentation, I ask programmers to raise their hands. Up go one or two hands in the corner. When I ask, who can make a spreadsheet everybody in the room raises their hand.

A big risk factor that accompanies programming projects is trying to marry programmers and engineers. You don’t have to take programmers and have them do an engineering project. Real programmers don’t talk to engineers very well; they don’t understand the engineering problem. They are thinking like programmers, and that’s a formula for six months of work that’s far from anything you thought you were going to get.

With an engineering automation system, the people who typically are creating and maintaining rules are the engineers. That’s a huge benefit.

PPLM: I can imagine some of these rules might be in Metadata, but are some of these rules embedded in the geometry of the CAD system that you would be using to create the results and designs?

Scott: Indeed, they can be. Rules span a wide variety of tasks: a simple mathematical calculation, look-up in a database or an online catalog and a reference that depends on other rules and properties, some proportional relationship to other properties. But, it also can be directly linked to the geometry, or reference the geometry. That is a big benefit of the systems—they allow you to generate custom geometry specific to the application that you require, whether it is 3D geometry or drawings.

These systems combine the ability to do configuration with engineering and geometry. That combination with engineering and geometry is incredibly important.

On the other hand, engineering automation configurators are powerful, handling all three aspects—configuration, engineering and geometry. Depending on which specific engineering automation platform you choose, they will talk to different CAD systems specific to what’s required.

PPLM: Where does PLM play? ERP? Are there any other platforms that would contribute to the efficiency and the setup and maintenance of all this data?

Scott: There are a couple of good questions there. One of them is, “where does one of these engineering automation systems fit in?” They usually fit behind a customer response management system, when there’s a CRM system upfront. They typically talk to analysis programs, whether those are homegrown programs or packaged finite element analysis or simulation programs. They also talk to resource management systems, PLM and or ERP systems, to get access to availability, pricing and the specifics of individual components, standard components and so on.

They interact with the PLM system and/or the ERP system to tell them what the bill of material is, or pass on drawings, routings, plant floor routing, directions, and information like that. Even CNC data can be sent downstream. So, these systems typically are traffic cops. They sit between several different systems.

“Enterprising engineering automation” is my emphasis because clearly, they have to fit into the enterprise systems that are available and are used for any given customer.

PPLM: Scott, tell us about some of the documented value that has resulted from these implementation activities.

Scott: We have customers that have documented taking processes that would take 200 hours per customer and reduced that to 20 hours. We have other customers who have documented improvements and quality about 80 to 90% over what was done by hand. After all, if you automate an activity, you can pretty much assure you are not going to make data entry mistakes, and you eliminate human error. When you automate, you can get a big reduction in the cost of quality.

My favorite one was a 35 million dollar a year company at the time. Previously, an order had to go back in-house after the dealer’s initial contact, where the company had a team of 12 to 15 people who put together the quotes. After that, the quote went back to the dealer and the end customer. With the process improvement, they were able to give the new application to their dealers, who then could do quotes on site with relatively little expertise.

A very important follow-on was that they were able to expand their dealer network rapidly because the tool allowed them to add dealers without subjecting them to years of training to get them to be able to do a quote. Last I heard, and this was several years ago, they were going past $120 million, and the person who owned them was looking to get really rich by selling the company. We should have charged them more for our service.

PPLM: Finally Scott, are there any other insights you would want to share that we didn’t capture in earlier questions?

Scott: Yes, many companies that are in the market or should be in the market for engineering automation have homegrown tools. In some cases, these are pretty good, but more often they are hard to maintain, hard to expand, hairballs of programs to take care of and they don’t deliver all the efficiencies.

We often go into companies that are aware that automation would transform their business. Maybe they have even tried something before, so that we are replacing an existing attempt to automate that didn’t work out well. Yet, it’s not always green field.

Often these companies know what they want to do, they just don’t know how best to do it. And that’s the difference between twenty years ago and now. Twenty years ago we, had to evangelize the fact that you could automate at all. Today, most companies in the ETO realm at least have some awareness of what can be done.

LEARNING

Upcoming Webinar

CPQ Integrated with Aras PLM

Save the date for September 23, 2016

We’ve made the argument for running CPQ with PLM. Now, what does it look like?

This webinar will illustrate a BOM configuration process. We will go through the complete sequence involved in developing and producing a valid quote, including the initial capture process and the workflow to solicit input from engineering, planning, manufacturing, and purchasing.

Also, we’ll show you what went into making this process possible. We’ll describe the part and bill data structures, CPQ parameters and relationship variables.

CONTACT

This Practical PLM newsletter is authored and edited by The vdR Group, Inc. along with contributions from selected partners. It is scheduled to be published the second Tuesday of every month. Delivery dates may vary.

Your editors are Martin van der Roest and Dick Bourke. We welcome your comments/questions. You can direct them to martin@vdr.com or dickb@bourkeconsulting.com. If applicable, we will respond in a following newsletter.

Mission
Our mission is to help engineering/manufacturing companies achieve the promise of product lifecycle management (PLM). We do this by exploring practical action steps that drive business value and that yield measurable revenue contributions and reduced expenses.

PLM is a combination of business strategies, best practices and technology. Hence, this monthly newsletter looks at the business drivers, best practices, applications and education.

Aras is the PLM technology vehicle of choice for The vdR Group.

The vdR Group, Inc.
1592 North Batavia
Orange, CA92867

You can opt-out of this newsletter here.

Practical PLM Newsletter Archive