Showing results for 
Search instead for 
Did you mean: 

ETO w/o W-H-Y is not G-O-O-D

Community Manager Community Manager
Community Manager

Engineer-to-Order (ETO) automation, if you’ve never seen it in action, is actually quite impressive.  Capturing all of the process elements needed to bring a unique product variant to a customer – from the 3D model to the Bill of Materials and an accurate Quote – into a computer system is unbelievable.   With tools designed specifically to make this automation easier, such as Rulestream engineer-to-order software, you can automate your unique processes faster than ever.   But since all the focus is on that fun part of creating the automation I want to take a moment to shine a light on an equally important but typically over-looked aspect:  The retention of “why?” and what we can do about it. 


In a recent blog series Beyond Product Configurator: Total Variability Management, we took a look at how your Engineer to Order (ETO) processes play a major role in reducing lead times. In this discussion, my colleague, Tony Boucher looks at the critical role of ETO from a different perspective...


Every time I jump in car I take it for granted that all the engineers, all the safety inspectors, all the component suppliers, did their job right.  My job is to focus on getting to the grocery store and buying the correct items on my wife's shopping list.  I don't need to concern myself with how an internal combustion engine works, what triggers the airbags in an accident, nor how the wiper blades were designed to snap into the wiper arms on my car.  The experts worried about all of this so that I don't have to.   Using powerful tools to capture and reuse their knowledge they continue to improve their products in our digital world.




This struck me on a recent trip to the Lemay Car Museum in Tacoma, WA.  Laid out before me was a visual history of the evolution of the automobile over the last 100 years.  We go from the first gas powered automobile invented by Karl Benz to Elon Musk's Tesla.  The evolution of every component of the automobile is on display as I walked down the aisle and through time, building upon past success and discarding the failures.  You can literally see the thinking as it evolved over time. 


eto-auto-evolution.jpgThe last 100 years from which the automobile, as well as most common products we use today, grew at a steady, methodical rate.  Drawing boards, notes, meetings, phone calls, three martini lunches and some very smart and motivated people made things happen.  But that environment has evolved as well and much more rapidly since the dawning of the Digital Age. 


At the cutting edge of the technological revolution that supports the design and innovation of our more complex products is engineering automation.  Engineer-to-Order (ETO) solutions such as Rulestream have been developed specifically for capturing the design process of products that are engineered to order so that variants within our current knowledge can be created automatically, saving time and money while improving quality.  The idea that you can somehow encapsulate the ideas of your experts so that anyone can create a new variant of the product by hitting a few keys on a keyboard is truly amazing.  Imagine what Henry Ford would think if you could place him in front of a computer, bring up a 3D model of his Model T and then allow him to play with the design parameters.  Maybe extend the wheelbase.  Raise the cabin's ceiling.  Add a 6-cylinder engine rather than the base 4.  We know he wouldn’t play with color alternatives.  He would surely think it’s magic, and in a way he would be correct.



 eto-sharks.jpgWith this magic that goes by industry names such as Rule-Based Engineering or Knowledge-Based Engineering, comes some overhead I'm afraid we may not realize we need until it’s too late.  Like the digital age, this world of automation is maturing from adolescence into adulthood at a rapid pace. When things change that quickly we tend to miss or overlook opportunities that offer a longer-term payback. That overhead I feel is missing is the retention of the knowledge that was needed to create that automation in the first place and is therefore essential for improving it.

I worry that we're so excited to capture rules about how to automate the creation of a product that we don't recognize that the knowledge and insight of that automation still only exists in the heads of our experts and scattered throughout the digital ether in the form of emails, files, folders and text messages.  This makes our investment in engineering automation vulnerable when it comes time to evolve.


We’re so busy charging forward to automate wtha we currently know that we don't take the time to properly retain the information required to build upon the past.  That's just our nature.  Whether building a bookshelf, cooking a meal or automating your engineering process, the fun is in the creation not in the clean-up.  And unlike the other items where you can pay your kids a few bucks to clean up the mess you made, your kids can't be used to organize, categorize and store the design intent that went into your ETO system.  Also, unlike the other items I mentioned that have tangible debris, the digital world of ETO has no such thing.  There are no chunks of scrap wood to trip over when done automating the design of your boiler. There are no egg shells lying on the counter after completing the automation of your Progressive Cavity Pump.  No.  In the digital world we can just walk away when we finish a project.  And therein lies the opportunity for improvement.


Simple Example 

eto-simple-example.jpgLet's say we automate the design of a widget and as part of the automation capture a rule that says the length is always twice the width (Length = 2 x Width).  In day-to-day operation of our system, whenever a width is provided, our rule determines that the length is twice this value.  It can be argued that we captured the knowledge of the relationship between length and width for all to see and understand.  Life is good as long as nothing changes. 


But the world doesn’t sit still. 


Let’s say our supplier of raw material for our widget is no longer able to provide stock of infinite length but instead is maxed out at 36".  How do we modify our system so that when a width greater than 18" is requested a length of 36" isn't exceeded?  Do we simply truncate at 36"?  We could limit the width to 16" I guess, but our best customer always orders with widths around 17”.  Why is Length always double the Width anyway?


It's not enough to know that the rule exists -- that only tells me the "what?" -- I need to know the "why?”  And there's that vulnerability.  What if that expert is no longer around to ask?  Now what should be a quick upgrade to the system either gets drawn out or may lead to issues due to incorrect assumptions.


Typically nobody will have taken the time to write an explanation of this 2x rule in the system, but it is likely that a meeting or email thread took place where a discussion culminated in the establishment of this rule.  It may have been covered in a larger meeting and jotted down as a bullet-point in some meeting minutes.  If those notes were at least retained in a manner that could be searched you'd stand a much better chance of understanding the “why?” of the rule in order to update the system to handle this needed update.


It Happened To Me

eto-happened-to-me.jpgI worked for General Motors many years ago creating an automation system for In-Tank Fuel pumps.  In the process of gathering the rules for one of the components I ran across a fillet of a given radius.  As the design was being automated it was important to know how that radius was to behave should the surrounding features change.  It was a critical fillet as well because special machining was required to obtain the radius on that particular part.


After quite a bit of research it was found that the original radius was established 15 years earlier.  This was before CAD was mainstream and drawing boards still ruled.  The designer had simply used the largest circle available on his template when creating the drawing.  GM was using expensive machinery for this component as a result of that decision ever since.


We had the “what” clearly visible -- Radius = 3.527 -- but lost the knowledge of “why.


For Your Consideration  

eto-laptop.jpgFear not for there is hope.  We have a couple of things working in our favor:

  • Almost everything we do in product development is created in a digital form
  • There are tools designed specifically to store, organize and search across digital collateral with minimal effort.

With regards to the tools, my personal favorite is Microsoft OneNote.  I can store information in any structure I like and search across it quickly.  Using a shared drive I can even collaborate with others.  It installs as a printer so anything I would have sent to paper I now save in a notebook.  Items can be tagged for rapid collection.  A notebook can be placed on a shared drive and accessed by multiple users.  Emails may be sent directly to its pages.  Files may be attached or referenced.  And if I don’t take the time to organize it?  The powerful search engine can help you find what you’re looking for.


Using OneNote or similar tools effectively requires the development of a habit that takes some practice, but once you get the hang of it becomes second nature.  Without much more effort than what you've already been doing, you can create a treasure trove of the knowledge behind your rules.  With Rulestream you can even add links to pages in the Notebook so that as the knowledge evolves the view from the automation system is updated.


As a driver I will continue to marvel at the complexity of the automobile as well as how it's evolved just in my lifetime.  It makes me wonder what's in store for my cars in the future.  I trust that the experts will continue to build upon their past successes to keep me happy, although I’m still waiting for affordable hover conversions to become available.


Insurance for Growth

 eto-growth.jpgThe experts must be reminded to leave behind a legacy upon which others can build.  When the pace of change was slower this was not as big a concern, but at the break-neck speed at which we’re growing today we need to take steps to support that growth.  It takes some effort, true, but not a lot in the grand scheme of things.  But by doing this not only can the genius that went into the system be recorded for posterity, it can be used as a competitive advantage for when the next product design requires the system to be updated, which, if I'm not mistaken, is coming up sooner than we think.




About the Author

Ttony.jpgony Boucher has worked in the field Knowledge-Based Engineering for over 20 years helping clients around the world define and automate their ETO processes.  He brings a passion for practical application of technologies based on this experience to his work with Rulestream at Siemens PLM Software.   



As I was documenting rules for my project I received this email with this article.  It was ironic and is so very true!  Automating items in Rulestream is fun and exciting, but documenting rules is so painful and you have to constantly remind yourself (and others) how important it is!  Especially when you're not the content expert and you have to extract the rules from the expert.  Very painful for everyone.  BUT IT IS SO IMPORTANT, for the exact reasons you described!  I use Word to document rules but I like your suggestion to use OneNote.  Another thing I try to do while putting together this information is to imagine the documentation will be used to create something from scratch.  And if there are questions not answered by the rules documents, I have failed.  Now you can't be perfect (all the time any way) so when these holes are found you at least have documented rules you can amend to get to a more complete rules package.


I will be passing this article to my managers to remind them the importance of the time we spend on rules documentation.



Mark Rogers

KBE Manager - Price Industries

Community Manager

Hi Mark,


When I first tried documenting the KBE systems I was creating, or the portions for which I was responsible, I used MS Word.  I found that the linear nature of the document and the tendency to try and keep everything formatted neatly (my issue, I know, but hard not to notice when, for instance, you generate a Table of Contents) added too much overhead.  When push came to shove and deadlines had to be met the effort in maintaining formal documents fell by the wayside.


It has taken me a few years of conscious effort to use OneNote.  I'm not sure why that is.  Maybe because it's different?  And by the way, there are other, similar tools out there:  Evernote, Google Keep, Zim, Laverna and Simplenote to name a few.  What really became apparent to me is that OneNote becomes a junk drawer.  Anything I think might be of use goes into it, but in particular structure nor order.  I think this is what makes it difficult to use at first as the tendency is to try and create structure.  The beauty of these archival systems is that structure is created dynamically by using the search and tagging tools.  Tags, Text, OCR all allow you to get to the items in the junk drawer in a fashion that supports your current need -- something much more in line with knowledge than a linear document.


I've experimented with adding OneNote documentation to Rulestream.  Under the "Documentation" tab you can insert a page or notebook into your Part Family.  This is nice and clean, but I don't like how it breaks the link to the notebook by creating a snapshot in the PF.  Now you have two copies to maintain.  Ideally you'd want to provide a link under "Documentation" that takes you to the sole source found in OneNote, but this can't be done at this time.  What I do to get around this is create a Word document that explains what I'm doing and contains the link(s) to the locations in OneNote.  I attach this document to the Part Family.  This way I only setup things once in Rulestream while the knowledge in OneNote continues to grow and transform.


I will be working with Rulestream to have URLs, with a description, added to the "Documentation" tab so that we can avoid this Word-with-Links workaround.


Best of Luck!

- Tony

Siemens PLM Software


Does Rulestream have the functionality to translate the engineering knowledge into a content management system?  Can XML, DocBook, or other tools be integrated to it to capture the documentation within?

Community Manager

Rulestream does not have an integration with a content management system nor the APIs to allow others to integrate with the data strucure for extracting the knowledge inherent in the product design.  At least at this time anyway.  From what I understand, several years back we had some capabilities to generate such reports, but they fell unto disuse and there was no demand for them to be revived. 

Valued Contributor

@MrRogers- although there is no direct documentation report that Rulestream exports, I would argue that if developers used the documentation fields (there is a field available for the spec and another for the constraint), then there is the potential of developing a side tool (maybe by an intern) that just creates a pretty report - after all, this data is also stored in the database so creating a good documentation (including XML or DocBook) would be absolutely a feasible idea. With developers following a standardized documentating method for these fields, I can see one creating a fairly useful document that contains only relevant items.