To develop a product and ultimately maintain an asset you need to manage a number of product definitions going through the lifecycle from inception to disposal. Some product definitions are critical as part of EAM/MRO.
In this post I’ll talk about product definitions in general an then specifically those that are input to EAM/MRO. Literature may refer to these product definitions as BOM’s. I oppose this generalization as there is more ‘bom to a bom’. A ‘decomposition’ would be more appropriate and this decomposition consists of Assemblies. I once referred to these as bom-lets, in fact that is exactly what it is, small structures of sub-assemblies with components.

Read the rest of this entry »


Hardware-oriented MRO systems need to cope with the accelerating complexity and velocity of change found within hardware embedded (and loaded) software on today’s aircraft, cars, ships, industrial products etc.. One of the most critical aspects that PLM can address is the coupling of hardware and its certified software. PLM Configuration Managed software can nicely sit next to an EAM/MRO application. Integration of applications concerned with management of requirements, configurations and maintenance statuses captures all of the critical information needed to assure that the software status of an asset is known at any point in time. From the MRO perspective all relevant information regarding the ‘master record’ configurations are available (See also Enterprise Asset Management category) across specific aircraft categories for example, but also the  individualized real-time status information of the current configuration for every managed tail number. We all remember the stories of software problems in cars, here the same link can be established between the Vehicle Identification Number and its software status. When integrated with problem reports, a complete closed loop failure record and action system can be operated and this would provide a full accountability from discrepancy till resolution.

Read the rest of this entry »

As discussed in ‘Schedule Management your smart Project Engine’ and considering new product development, WBS templates will be synchronous with a product breakdown structure. The military Def.Std 0060 and Mil.Std. 13882b define functional and physical product breakdown structures. The focus of the first is the requirements definition whereas the second is the resulting physical product as it will be certified for operational usage according to the ‘V’ model. Both approaches support top-down engineering principles where you start with the product schematics that gets detailed and populated with assemblies, sub-assemblies and parts. This approach is an ideal mechanism for front-loading.

Obviously it is not necessary to front-load a complete product, the ability to just complete this for certain product areas is by itself a major advantage. The prove that this works can be found in the automotive industry. Today’s turn around time for vehicle development is the result of being able to front load specific disciplines with placeholder product breakdown structure (PBS) and to drive the engineering process with the linked work ‘Requests’. As the industry works with product platforms and initiating such a PBS, specific assemblies and sub-assemblies and component items are carried across/over. It must be realized that those items Carried-over and -across are in fact technically and commercially certified and the certification management may extend to certification across multiple model years or multiple vehicle lines. The downstream benefits of such approaches are enormous.