‘Face book’ and the professional network LinkedIn are examples of an interactive way to keep in touch with people you know. In a business context these people may be colleagues or persons you may have worked with in the past or even ‘supplier’ connections.
I suppose we all know Face Book (FB), for those who do not, just google it. In this short post I will NOT be talking about the social side of FB rather the business side/potential.
Social Networks the Backbone of Integrated Product Teams
June 9th, 2009Enterprise Asset Management (EAM) meets PLM
May 26th, 2009According to Wikipedia EAM is: the whole life optimal management of the physical assets to maximize value. It covers such things as the design, construction, commissioning, operations, maintenance and decommissioning/replacement of plant, equipment and facilities. “Enterprise” refers to the management of the assets across departments, locations, facilities and, in some cases business units.
The Product Definition Challenge
May 25th, 2009To 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.
Integrated Product Teams (IPT)
May 15th, 2009IPT are made up of multi-functional stakeholders that collaborate with a product-oriented focus. IPT is an evolution of Concurrent Engineering. IPT is an evolving form of collaboration. Product development activities change and evolve over its life, team composition and leadership will evolve likewise. While marketing personnel, acquisition planners, project managers and design engineers may be the most prominent members early in the life cycle, provisioners and item managers gain a bigger voice during engineering and manufacturing development. Equipment specialists and mechanics may be the lead members during the operations and maintenance phase, with the design engineers returning once again if a major modification is needed.
Software Configuration Management
May 6th, 2009Many high tech products these days cannot work without software that controls specific (user) functions of the product. Take your car; engine functions that were traditionally mechanically controlled have now been replaced by devices and capabilities that are managed by software. Also when you travel to your vacation destination by air the very plane you are flying in is loaded with software to control for example the avionics or the (glass) cockpit instrument panel. Recently I was asked to consult for a client that had configuration management issues regarding software installed in their product. They had challenges to manage the appropriate version of the software in relation to the hardware configuration and also assuring that certification results were correctly captured. A further challenge was the collaboration with partners that actually does the software development and the maintenance. Our recommendation consisted of the following set of improvement initiatives and functions.
Software Management and the link with EAM/MRO
May 6th, 2009Hardware-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.
Integrated Software Requirement Management
May 5th, 2009In the previous post I talked about Software Configuration Management. This post is about management of software requirements and the link to software configuration management.
Although I did not specifically discuss management of software requirements in the previous post, it is evident that managing the configuration includes the specification sources i.e. the requirements. In the first recommendation of the previous post I touched on the object Work Request and example supporting materials e.g. specifications that may be attached. Ideally requirements are decomposed to individual requirement line items, i.e. similar to a tree. Each such line item would then specify the desired function but also instructions essential to developers but also test scenarios and the required end results that must be met.
In the requirements set you also find the actual failure mode and effect analysis i.e. if this function fails; what would be the effect and what would would need to be implemented that this failure would not occur. Obviously this is not just the software itself but the complete integration with the hardware it may need to control. As pointed out earlier, this level of detail is critical to also manage the prototype test process and also the actual life test i.e. the software as it is installed onto the product. The myriad of interconnections considering this level of detail and also combined with Change management records makes data management a daunting task without the right PLM capabilities.
The Ideation and Requirement Management connection
May 4th, 2009In general companies do a good job recording problems and issues about their products. In specific industries elaborate problem records, trend analysis and resolutions are mandated by regulators. They may operate a Failure Record and Corrective Action - Preventative Action register. However what commonly fails is a formal register regarding Ideas for improvement i.e. not driven from failures. Ideation as a process is more than a box for personnel to deposit their thoughts about products. I once worked with producer/retailer company that claimed that out of the 1000 innovations per year 70% of their new product introductions flopped and failed to yield results they had planned for. Can you imagine the revenue potential this represents. If there was a way to half this flop rate, it would make a big difference to the bottom line. How much would this equate to.., take for example the lost aggregate potential revenue of specific products or categories that failed to reach the sales ramp-up phase in the last two years.
What would be the solution…. Today companies, with little effort and cost, can introduce a collaboration platform that would register ideas. Suppose you could populate this platform with (process-to-follow) templates i.e. how to move this idea further, see what earlier projects had similar patterns and above all can you imagine the potential that you could reports an internal ideation pipeline the same as you do with your sales forecasting.
Not to embark on Microsoft marketing, but SharePoint is an example of a capability of such collaboration technology. With again little effort companies can build a complete (hosted) ‘environment’ around the Ideation process. Personnel that generate these ideas can be those directly involved with marketing or product (sustainment) engineering or even those that are in the field, for example trend scouts, all would find a single source of information to record their observations but also share opinions regarding marketing potential. Operating such Ideation framework, you can would support the formal innovation process from internal surveying, reviewing and analyzing the potential and challenges and risks you may encounter and need to consider. Some level of Quality Function Deployment may be completed and recorded also. So basically you can easily address the information management needs and establish a foundation to drive a Structured Ideation process.
As companies hit a specific Ideation maturity stage/gate, more personnel and financial resources may be allocated and a formal ‘gated project’ may be decided. Here comes Schedule Management into the equation that I talked about in other posts. Companies may want to operate specific new product introduction work breakdown structures and schedules for specific product categories. And here is the crux, these ‘standardized’ gated schedules then become success teamplates and the base for continuous improvement. It would make new production introduction process structured and predictable which should ultimately have a positive influence on the right product for the right market and corresponding sale success.
Lastly, as an idea move forward and reaches maturity, marketing and product development start to exchange product requirements causing ‘requirements engineering’ to kick in. As more requirement information is generated, the need for requirements management is imperative and as more aspects of the product are being defined (project brief) we then gradually transition into the formal Product Lifecycle Management defined processes.
The About page has a form to contact us should you like to know more about these concepts and how this may apply to your operations.
Front-loading a smart way to managing your product development budgets.
March 20th, 2009As 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.
The About page has a form to contact us should you like to know more about these concepts and how this may apply to your operations.
To Work Flow or not to Work Flow
February 17th, 2009Many companies implementing PLM consider workflow to be the panacea to many process related challenges. In the past when PLM was a relative new phenomena we tried to model company process in a series of workflows. The abstraction that was needed was a far cry from the real processes and engineers were by-passing the implemented workflow functions. Also we found, specific processes for specific categories of products were needed and further that specific ‘organic’ processes were common regardless of these different product categories.
We ‘flowed’ deliverables through these workflows rather then the triggers that define the items that are expected from the process. The abstracted trigger objects are in fact different types of ‘Requests’ for example; work request, change request etc.. Requests regarding a task may have supporting items… you may call these requirements or specifications, in fact to which the deliverables need to comply with. Now.., how do you structure the right flow of events to trigger the execution: A schedule…, not a workflow. Yes; you would use the workflow to route the schedule trigger items but the schedule in itself is a Work Breakdown Structure.
The schedule assures that the right disciplines at the right time receive the Request (and authorization) to commence with the work (task). You may call it the engineering variant of the kind of functions that are common in manufacturing i.e. the Manufacturing Execution System (MES) and in this engineering case the Engineering Execution System (EES). It is my experience that the maturity of EES’s that companies operate is low. Usually it is a combination of enterprise and desktop applications. Consistent usage across projects/programs, process integration and technological interoperability are major challenges.
The About page has a form to contact us should you like to know more about these concepts and how this may apply to your operations.