Applied PLM: 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.