If you want to have a usable bill of materials that is practical enough for the high pressure, tight time constraints of real product development, and you want to have a universal BOM that is reusable between products, you should expect major conflicts. The conflict between universality in the BOM and practicality is not a question of "if," but "when," "how often, and "how badly." Sadly, the answer to when is: immediately; the answer to how often is: all the time; and the answer to how badly is: brutal.
We resolve conflict, hopefully without having bloodshed, by having a government. So, who are the people who have the will and authority to make the call on what is allowed in the BOM structure? A good place to start might be mimicking the three branch government that, in general although we may not see it every day, has served America quite well. Why? Because of checks and balances. Although a dictatorship is a more efficient form of government, it doesn't have staying power and degenerates to abuse very quickly.
Checks and balances, if they stop short of grinding bureaucracy, can help provide a stable governance structure while still providing needed flexibility on a day to day basis. Let's go over the three branches for a BOM, shown in Figure 1.
Figure 1 – The Three Branches of BOM Governance
Executive Branch of BOM Governance
The purpose of the executive branch of BOM Governance is to create the initial functional structure of the universal BOM. The groups that are most suited to do this are likely the actual core engineering teams (e.g. the hydraulics team, the engine team, etc). Obviously, as we move up or down the BOM tree, there will be interfaces between the structures that each team controls. This can be worked out directly between the core engineering teams, or by the leader that is appointed or elected by the team.
Legislative Branch of BOM Governance
The Legislature should be made up of 2-3 representatives from each functional group in the company (engineering, purchasing, manufacturing, supply chain, etc.).
The executive branch has defined the functional hierarchy, but the legislature needs to define the Fit (attributes) the engineer must define when a part is specified, and the standard screen views that are built. Here is a more detailed discussion on Form (Part), Fit (attributes), and Function . Attributes are what other people in the organization need to know about each part that uniquely define why that Form (part) "fits" the function.
Different groups within the organization have needs for different attributes. For example, the engineering team has very different attributes it wants to see (weight, performance stats, etc.) than manufacturing does (quality specs or tolerance) or purchasing (e.g. supplier). All these attributes need to be present, and they also need to be consistent across parts. For example, for a two piece driveshaft the engineer may have to specify the length of each piece, the connection type at each end, and the tube material.
The legislative branch also specifies views. The way engineering wants to see the BOM presented might be very different from the way that purchasing would like to see the parts displayed. The organization should only have 3 to 5 main views of the BOM, so that everyone in the organization can learn each one and understand them. The legislative branch can define what those 3 to 5 computer views of the BOM will look like.
Judicial Branch of BOM Governance
Unlike our US Government Judicial Branch, in our BOM governance framework the judicial branch really will be the one that is most active from day to day. The judiciary decides when an exception is allowed to the BOM rules that have been set up by the executive and legislative branches. Individual programs will have unique needs, but all products live in the same company, like citizens in a society. When will we allow an individual product BOM to violate the rules laid down by the executive and legislative branches? When can the hierarchy of the BOM be overwritten? That is the job of the judicial branch.
Our recommendation is that the organization establishes a board of not more than 10 representatives to act as this judiciary. This group should include people that represent the breath of the programs of the organization delivers. For example, you don't want all 10 of the people on the judiciary to be from large, high-volume programs. Then the needs of the small specialty programs will get overwritten every time. You want a group of people who will balance one another's viewpoints.
Taking a lesson from the world of software development, the judicial review process should be something that happens on a daily or weekly basis, very similar to reviewing bugs or enhancement requests in a software company.
Teeth and resolve in your vision
When the judiciary makes its decisions on exceptions, it needs to be reasonable and discerning in doing so. However, it cannot roll over on every request or the organization will never make any progress toward having a universal and reusable bill of material. One of the ways to balance reality with vision is for the judiciary to have a written list of acceptable reasons for asking for an exception. If the product program wanting an exception cannot directly and simply link their request to one of these reasons, the standard the judges apply to authorize an exception should be very high.
Exceptions over time
The good news is that the number of exception requests will decline over time. Figure 2 starts when the organization first decides it wants to commit to having a universal BOM structure or at least one universal structure for each product category. At first there will be a tremendous amount of exception requests. This is shown in the blue line on Figure 2. These exceptions will continue to decrease over time until the point that a shock occurs.
Figure 2 – Exceptions to universal BOM structure over time
What is a shock? It is something that challenges the system. For example, when a new program is introduced into the company, especially a major new product line, there will be disruption to the organization's universal functional BOM. However, the number of exceptions needed will go down after the shock. Why do exceptions to the universal structure decline over time? There are at least two reasons.
- People Learning – The first is that over time the engineering teams will start to better understand the functional structure and how they can work within it. They will become comfortable with these universal starter BOMS, and know how to accomplish what they need to do without an exception.
- BOM Learning – The orange line on the top of Figure 2 reflects changes made to the universal BOM. Many of the requested exceptions will highlight deficiencies and mistakes in the initial functional structure designed by the executive team and attributes and views specified by the legislative team. They will not get it right the first, second, or third time, but over time the structure that they mandate will start to meet more and more of the needs of the organization.
In Conclusion
Bill of material governance? Some people will view this as being about as interesting as watching paint dry. Other people who are lovers of product lifecycle management will see this as very fun work. Regardless of your point of view, it is necessary if your organization hopes to achieve the dream of a reusable universal BOM structure.