That is the question our managing partner, Eric A. Hiller is asking, as a new father. Maybe it’s just the sleep deprivation, 
but Eric has analyzed the processes of caring for a newborn and thinks he has found a ways he (and you) can use Lean and Agile to make the chaotic process of fatherhood and motherhood a little more predictable and easy.
IndustryWeek apparently agrees, because they just published his article. Click here to read and see if you agree!
We received the following question about Bills of Material (BOMs) from a product development manager:
QUESTION: “How does one balance the need of a BOM to be expedient and fast for real world use, while still trying to make an investment in a universal and reusable bomb?”
That’s a great question for product development teams. Our answer is a series of steps:
It may sound like the trite stuff of a 12-step program, but the first step to recovery is admitting you have a problem! There’s nothing wrong with having a problem, and in fact, solving problems is what we went to engineering school to do, didn’t we? Some people will tell you that you can have it all (usability and re-usability) in your BOM structure instantly and without conflict. That’s delusional, but we can make incremental progress over time.
Going back to our school days, the first thing we would do in our statics or dynamics homework would be to list the forces that are active. There are at least two forces in play, and for the most part they are directly opposed to one another:
Where we start out on our journey of practicality vs. universality in the BOM is not where those forces may end up in the future. The equilibrium point between those forces will change over time.
In Figure 1, we see that initially the force of expediency/practicality is stronger. Therefore, at first our BOM will mostly focus on the needs of today, rather than the needs of tomorrow. However, over time we can reduce some of the immediate pressure to ship product, because we have invested in the bill of material. The equilibrium point is driven to the right on Figure 1 toward a more universal BOM, which is still practical and expedient for our daily use.
Figure 1 Balancing BOM Usability vs. RE-usability
Click to ENLARGE
How do we know how to balance the two forces at any given point in time? The recognition of a third force may actually help us simplify the problem. That force is the needs and goals of our management team in the company.
The management team is certainly interested in shipping the product for immediate revenue and profit. However, they are also responsible for stable growth of the company over time. Management needs are a downward pressure that we can use to our advantage, just like the Romans did with their brilliant discovery of the arch.
Figure 2 represents such an idealized arch. The forces of the needs for universality vs. practicality are pushing against one another. Without a third force, certainly the structure would tumble. However, with the third force of management needs, it’s much easier to balance the two forces and know where that equilibrium point is at a given point in time.
Figure 2 Balancing BOM Usability vs. RE-usability with Management Pressure
CLICK to ENLARGE
Figure 2 – The down force of management decision making
What is the keystone in the arch? The keystone bears the pressure of all three forces and balances them. The keystone in our process is a thoughtful and dynamic owner of the bill of material structure. This might be a consultant, a specific person who specializes in product lifecycle management, or the product development manager. Whoever it is, this person or team should be able to view the opposing forces not as forces that will crush them, but as forces that will help them balance each other.
As with any problem in the real world, unfortunately we’re not dealing with a precise science here. However, hopefully this expansion of our framework will be a way to think about making progress, as you balance usability vs. re-usability in your bill of material structure.
=====================================
This post is 3rd in a series of posts on ENGINEERING.com about Bills of Materials (BOMs). The first outlines the importance of managing the BOM: Dr. Strangepart: How I Learned to Stop Worrying and Love the BOM. Next is a framework of how to build re-usability into the BOM: Form, Fit, and Function – A Framework for your Bill of Material.
Continuing , the series on the Bill of Material we began with the article Dr. Strangepart: How I Learned to Stop Worrying and Love the BOM, here is a full re-print of the next in the series. You can find the original at ENGINEERING.com here:
=======================
In my post Dr. Strangepart: How I Learned to Stop Worrying and Love the BOM, we began talking about the extremely complex process of managing the bill of material (BOM). That discussion focused on intelligent part numbers, but today I want to move to the question of whether the BOM is primarily keyed off of the functional use of a part or the specific part number itself. This is a tension that has existed since bills of material were created, when man married an axle to a wheel.
Why do people care whether the BOM is driven by part numbers or the part’s function? The answer is that each has certain advantages. Driving the BOM by actual part numbers is very useful for purchasing and manufacturing, and when an engineer is focusing on an individual piece of hardware. However, when the engineer or a product manager moves from one product to another, a function driven BOM allows him to compare components more easily.
The ability to compare BOMs has huge implications for the ability of engineering to successfully re-use parts. Re-use lowers both the cost of the hardware itself (by re-using tooling and increasing production volumes) while also reducing the engineering time needed to design a new part. Re-use has been the great white hope of the engineering community from time immemorial, but it is very challenging.
Although Product Lifecycle Management software vendors talk about re-use, most companies do a very poor job. Trying to manage re-use without intelligent part numbers and a functional way to look at the BOM is like searching for a single item in a hoarder’s basement that’s jammed full of boxes with no labels. Eventually you give up, go to the store, and buy a new one! That’s one of the big reasons why re-use has struggled in the engineering community.
So, how do we balance the tension between these two things? Here is a simple framework for thinking about the BOM that I call Form, Fit, and Function.
Figure 1 CLICK to ENLARGE
By function, I mean what the part is actually doing, what its purpose in life is. By form I mean the specific piece of hardware or part that we’re dealing with. In Figure 1 there is a simple example of how function and form relate to each other. Typically, the superset will be function. The function in this case is to provide rear vision to a driver of a vehicle. The function is the result of the part operating correctly. The part itself is the form that “delivers” that function. In this case, we might provide rear vision by designing a mirror, a camera, or some sort of sensor.
The third part of the framework is the fit of the part. However, by fit I don’t mean the actual geometric tolerances or real estate that the part occupies. What I mean is, “What are the unique attributes of the part that make it “fit” the function, i.e. accomplish the function?”
Figure 2 shows another example of a functionally controlled BOM. In this case, we’re using an example of the propulsion of a vehicle, perhaps a jet aircraft. In this case we show propulsion as a top level Function, along with sub-levels of the powerplant, how the power is transferred, and the cooling system.
Figure 2 Hiller Associates Form & Fit Functional BOM Example
CLICK to ENLARGE!
The coolant is the Form that satisfies the Function of the cooling system. We assign an intelligent part number for the specific coolant. One might ask, when do I move from a Function to a part number (Form)? The answer to that is, whenever it is convenient. It will take a little bit of time for your team to develop a functional BOM that has a manageable level of hierarchy in it.
TIP: Any more than three or four levels of hierarchy can be very difficult to manage.
There is a many-to-many relationship between the Function and the Form (part). Depending on how far down the Function tree we go, we may need to attach more than one Form (part) to satisfy a function. On the other hand, if our functional tree is deeper, on certain products there may be one assembly (Form) that satisfies more than one Function on the functional tree.
Moving to Fit, we see that each Form may have multiple attributes (ways of fitting the function). The coolant “fits” our functional need by the attributes that it has. In general there will be a one-to-many relationship between Form (part) and Fit (attributes) respectively.
Form, Fit, and Function is a simple way to look at how we structure our products. It lends itself well to re-use of parts, but also for the re-use of work break down structures that are used in aerospace and defense.
Some companies are now working on constructing skeleton “Starter” or “Universal” BOMs that they re-use for each new product. The idea is to start with a generic BOM, and then add and delete to match the needs of a new product. The goal is for the company to have one universal BOM, or one for each unique product group.
This is a great idea in theory, but it’s not trivial to execute. To do this in your own company will likely take your engineering team, product management, and a consultant a year or more to find a structure that suits your needs. However, once this is done, the speed and re-use advantages should be significant. Hopefully, the Form, Fit, and Function BOM Framework will give you a simple way to think about it!
IndustryWeek.com has just published a new article authored by Hiller Associates title:
The process of product selection that people do in their personal lives (e.g. shopping on Amazon) is strikingly similar to the process of product development that people encounter in their professional lives. Interestingly, people are often better at making the complex decisions associated with product selection than they are at similar decisions in product development.
There are three things we can learn professionally from our product selection experience on Amazon:
To read the whole article, simply click on the link above to go to www.IndustryWeek.com, or simply continue reading the full text below.
—————————————————————————————————————————————————————————-
We just finished the biggest shopping season of the year from Thanksgiving to Christmas. A lot of people were making a lot of decisions about where to spend their hard earned money – mostly for the benefit of others with gifts. During that same period design engineers around the world were rushing to finish up pressing projects – and, probably as fast as possible, because they had a lot of vacation left to use, before the end of the year.
We make decisions every day in our personal and professional lives. But, do we make decisions the same way in both worlds? I don’t believe so. People might argue that decisions made at work involve much more complexity. After all, how much product development is really going on in most homes? However, a lot of product selection is going on in people’s personal lives. When considering complex product purchases, product selection starts to resemble product development in many ways. Let’s take a look at how people (including design engineers) make decisions when shopping (product selection) vs. how they make decisions in the corporate world (product development).
Consider the ubiquitous Amazon.com. Customers’ product selection experience on Amazon is overwhelmingly positive: Amazon scores 89 out of 100 in customer satisfaction, the top online retailer score in 2012. But product selection is *easy* right? Wrong. Look at Figure 1. Product Selectors on Amazon must consider multiple product attributes and, moreover, these attributes mirror the considerations of a product developer very closely. Product Selectors must consider performance, cost, delivery time, quality, capital investment, etc., without any salesman or other expert to guide them. But the really amazing thing is that the Product Selectors using Amazon are able to both prioritize these product attributes and consider them simultaneously.
CLICK ON PICTURE TO ENLARGE
So, how do the same people who are Amazon customers typically consider product attributes in the corporate world? Very differently is the short answer, as we see in Figure 2. First of all, people at work do not tend to trade-off product attributes simultaneously, but in series. Moreover, often each functional group in a product company (marketing, engineering, manufacturing, etc.), tends to be concerned with one dominating attribute, almost to the exclusion of other product attributes. How does the typical series-based consideration of product attributes that is common in the corporate world compare to the simultaneous trade-off approach that the customers of Amazon use? Exact numbers are difficult to find, but some sources say only 60% of products are successful. While not a precise comparison, the difference seems meaningful: Amazon scores 89 of 100 on the customer satisfaction index, whereas product companies have 60% successful products.
CLICK ON PICTURE TO ENLARGE
Why is this? Don’t people get college degrees to be great product engineers, buyers, etc.? Don’t they get paid well to do these jobs? In contrast, most people have limited knowledge of the products they select on Amazon and spend hundreds or thousands of their own dollars to buy them.
There are at least three reasons why the product selection and product development processes differ, and the corporation can learn from all three.
Which product attribute is more important: time-to-market, product cost, or performance? There’s no right or wrong answer, in general, but there is a right answer for any given situation. The question is: does the product developer KNOW the priorities of different attributes. As an individual shopper, you may not explicitly write down the prioritization, but you know it. Your preferences and value system are welded into your DNA, so it is clear. However, companies are not individuals, but collectives of them. It is the responsibility of the product line executive to make these priorities clear to everyone.
This is similar to requirements engineering, but at a strategic level. Requirements are typically specific and only apply to a narrow aspect of the product. I am talking about the high level product attribute priority. Ask your product line executive: “In general, as we go through our development, what should typically ‘win’ in a trade-off decision.” If the executive cannot give you a concise and simple answer, he has some work to do to earn his big salary. For example, he should be able to say something, such as “We must meet all minimum requirements of the product, but we need to get to market as fast as possible, so we meet or beat our delivery date. Oh, and we need to keep an eye on product cost.”
The product executive needs to write the priorities down and share them with all. In this case, he might write:
This doesn’t mean the product executive will not change the priority later as the conditions change, but for now, the whole organization is clear on the priorities. This sounds very simple, but most people in product development are unsure of what the clear priorities are. Therefore, they make up their own.
The second thing that we learn from Amazon shopping is to consider all the constraints and targets for product attributes simultaneously. As we see looking at Figure 1 versus Figure 2, people naturally do this on Amazon, but organizations typically let a different priority dominate by functional silo. There are often arbitrage points (optimums in the design space) that will allow excellent results in one attribute, by only sacrificing minimally on another attribute. For example, the product executive may have said time-to-market is first priority, but he is likely to be happy to sacrifice one unit of time-to-market for an increase of 10 units of performance. This doesn’t mean that the organization is changing their priorities, but that the strategic priorities discussed above simply function as a guiding light that the product development team pivots around to find the point of maximum value for the customer.
Recent research is revealing the dangerous downsides of our always-on, always-new, always-more information society. To be sure, social media, like all technologies has the potential for adding a lot value. The question is: do you control the information or does it control you. The research featured in Newsweek shows three problems that have grown in importance over the last decades:
To answer this, let’s first ask how Amazon is able to overcome these challenge. To overcome the Recency vs. Relevancy challenge, Amazon ensures that recency is not the default option for the display of Amazon customer reviews. Instead, helpfulness of the review (relevance), as judged by other customers, is the default order. Amazon does not push immediacy. There are no annoying pop-ups offering a deal, if you buy in ten minutes. Certainly, Amazon does make buying easy and fast, but shopping at Amazon from the comfort of one’s home is a relaxing experience that promotes thoughtfulness. Finally, Amazon does not overload the customer with information. This is no small task, given that Amazon may offer literally hundreds of items to the customer among which he must decide. Amazon does this by presenting the information on a huge variety of products in a standard way, and by providing simple and powerful filters that discard large amounts of extraneous information.
In order to overcome these new information challenges in your own product development work, ask yourself these three questions:
CLICK ON PICTURE TO ENLARGE
The world of online journals, social media, corporate social networks, and interconnected supply-chain applications is here to stay. It brings a world of new opportunity for better and more up to date information for product development. It also brings a deluge of extraneous information, and we need to accept this and learn to manage this. Amazon.com manages these challenges well. Your product development team can manage these challenges too using the principles outlined above.
One of my fellows in the world of product cost and design, Mike Shipulski, just posted the following:
The general synopsis of it is:
Mike is right. The short term thinking kills companies and actually wastes a lot of time and money – paradoxically.
I would offer the following addition: Short, Medium, and Long term all have their places, but there has to a be a thoughtful and maintained plan for each. You just can’t make a plan today and then look at it in a year. Every 2-3 months, you should be re-assessing and moving the plan accordingly. However, you should not see whipsawing, but just gentle, organic fine tuning as you gain more information.
I also would like for Mike to define the Short, Medium, and Long term. I realize that this changes product to product, but a general guideline would be helpful.
I just read an article on the site “Strategy + Business” called Building Cars by Design. It caught my eye for two reasons. First, the fact that a strategy site would deign to talk about engineering concepts was a pleasant surprise. Second, the article discussed Design-to-Cost and Design-to-Value.
If we strip off the automotive context, the main premises of the article from a Product Cost Management point of view are as follows:
I applaud the authors for opening up a discussion on these topics. However, I feel this article is incomplete and does not tell the whole story about these concepts. It also doesn’t really say how to do any of these things or point the reader to somewhere he can further learn how. Here’s my specific suggestions for improvement.
Regarding the last point, I will do my best to illustrate the problem. Take a look at the figure below in which I graph the value the customer gets from the product versus the price the customer pays for the product. Presumably, the authors in the article are saying that customers would be willing to pay up to the point that the slope of the value/price decreases substantially (the curve flattens). But, that assumes the customer has the money to spend – kind of a Field of Dreams Strategy, i.e. “If you build in value, they will pay.”
Click on picture to ENLARGE!
But, what if the customer truly does value a set of features, but he just doesn’t have the funds to purchase all of the value? In this case, we have to concede that there is a Minimum Viable Product (MVP) needed for the customer to purchase. This term, MVP, is most often used in software development and start-ups. It is the minimum set of features and functionality that a product must have to have ANY value to the customer. If you can’t master design-to-cost in your product so that it both includes the MVP features the customer needs and allows you make adequate profit under the price ceiling of your customer, the product will not be successful.
If the customer has less funds than the MVP to deliver in your product, they can’t afford it. Similarly, even if the customer has more funds than the MVP requires, but less than when the value/cost curve flattens, you cannot employ a blind strategy of maximizing value to the flattening point of the curve and price near it. You are still going to have to set your price below your customer’s funds to succeed.
So, are the authors of the article talking about design-to-value to the point that the value/price flattens or to the point where the price ceiling of the customer intersects the curve?
Anyone? Anyone? Bueller? Bueller? Bueller?
