Change is a permanent organizational challenge and it does not matter what industry, size of enterprise or organizational structure. Complex collaboration models, the shorter product lifecycles, the variety of products that require attention, the increased product complexity, the advancing information technology and lastly the economic situation. These are some examples of the reasons and accelerators of change.
What is the ability of organizations to execute change, what are the drivers, what are the impediments behind the need, how well do companies execute operational initiatives. Specifically this last topic is the reason to work with experienced consultants. What are the enablers of success?

Read the rest of this entry »

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 »

Many 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.

So basically the schedule is the structure of events that need to take place.. you could call it a work breakdown structure (WBS). So for different product categories there are different ‘project’ schedules and WBS’s. In principle you would have schedules for new product development and its introduction, change schedules initiated by ‘change introduction boards’ as well as ‘product sustainment’ schedules.

What they all have in common are these ‘organic’ processes, for argument sake let’s call these verification and release processes and surprise….; these are the processes that are usually regulated per industry or defined as best practices for example your internal procedures as defined by regulators or derived from ISO standards or better CMII.

In highly regulated environments you may see these implemented even as ‘V-models’. The WBS, going down on the V,  determines the full design process by the different disciplines i.e. the product system breakdown from low to high fidelity. Going up the V the verification and the release processes.

As stated earlier there will be different WBS’s for different purposes. Probably defining the first set of WBS’s are a challenge but the reward will be huge. As it becomes a standard approach for doing specific things, it would then form the basis to gradually apply Kaizen and the 5S’s campaign you would apply to Gemba i.e. the (work) place where it all happens. As companies get smarter defining and optimizing these processes the cost and schedule outcome would also be better predicable and it would provide an opportunity to ‘front load’ such WBS structures with all product related system engineering templates and required documents. Lastly these WBS’s would also form the basis of your project management with or without your management approaches such as earned value management.

The Value of Value

January 23, 2009

Implementing PLM solution components should not only focus on the transition of As-Is processes to To-Bo. Many companies forget that the real improvement drivers should be ‘Business Value’. In converting As-Is processes, Business Value must be the key driver. Too many we times we observe companies that embark on a journey of which there is no end. The project just lacks focus on business value and without this focus you end up with ‘improved’ processes that help you do the same things faster (or faster wrong). It is my experience that an initiative without a value focus will at some point in time become a discussion what this new PLM technology and its implementation effort actually brought.

To overcome this sub-optimal start, companies should really do an assessment to discover drivers and motives to implementing different PLM solution components. I would call this a kind of Solution Value Discovery (SVD). This SVD basically is the discovery of motives and goals for…. for example PLM. Working with companies you discover many areas of improvement potential. A category of areas may not benefit from PLM per se, because it is concerned with doing the right things right. Let me give an example.

A Company we worked with had a series of ‘Stove Pipe’ processes. Its operational goal concerned a better integration of these processes as it would reduce the risk of program slippage. A single source of information for all key disciplines would enable a more lean process and at the same time an increased  ‘group’ effectiveness. Also better management of schedules was identified a key benefit. A single PLM solution component on its own would not solve process silo challenges. Our recommendation was also the installation of a corporate ‘processes owner’ and for this official to define the ideal ‘To-Be’ starting point and from that point onward start to plan for specific PLM solution components to driving the operational goal….. ‘Reduce Program slippage risk’.

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.