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.