PLM Implementation Engagement Process

Tweet

 

This posting describes an approach to PLM implementations when an OOTB approach is not feasible and following this process leads to the characteristics a first rate PLM implementation.  The engagement should be run in an agile manner with frequent deliverables that can be signed-off.  The deliverables start as light-weight easily refined components of a Paper Prototype (PP) and evolve with feedback to a Demo Prototype (DP) and finally to a Conference Room Pilot Prototype (CRP) that shows the total solution.  Each prototype is signed off by the business users.  The purpose of the prototype refinement is to gradually transition the user from a paper-based world into an understanding of a PLM-based solution.

There are several Software Engineering methodologies behind this approach.  Without going deeply into the rationale they are:

• ISO 10746-1, Open Distributed Processing - Reference Model (RM-ODP)
• Unified Modeling Language (UML)
• Principles from The Mythical Man-Month book by Frederick Brooks
• The Volere Requirements Management Process

A key to making the prototype refinement process flow smoothly is the order in which requirements are gathered.  Experience has shown that the business information and data model of the PLM solution is the first area to start getting closure on.  The main reason for this is that the business information units are easy to gather.  They can be harvested by reviewing existing documents like the DHF, technical reports, and current products.  As the information is gathered it is reviewed with the business users.  Modeling techniques are used in the paper prototype to unambiguously define the information units and the relationships.  For internal purposes UML is used, but a softer display technique might be needed for business users.  This is the RM-ODP Information Viewpoint.

As the information model begins to stabilize the Business Flow of the paper prototype can be started.  The Business Flow is a process that shows the important business steps in starting from nothing and ending with the completed Information Model, for example a DHF, a Regulatory Submission, or a Clinical Study.  In the Business Flow the work tasks that create and refine parts of the information model are listed in the proper order.  Interleaved with the work tasks are decision tasks for (partial) approval or review.  The states that indicate the stability and completeness of the information are identified.  Refining the Business Flow will often cause iterations in the information model.  The Business Model is the RM-ODP Enterprise Viewpoint.

There are several other important parts of the requirements as expressed in the Paper Prototype that emerge from refining the Business Flow and Information Model.  The Organization Model appears as who does each task is discussed.  The details of review and approval workflows expressed as UML Activity Models are defined.  The most valuable meta-data from the information model for searching is identified.  The last step is to map the Business Flow tasks to the main Use Cases that will be implemented on the PLM platform.  Not every task from the Business Flow will be directly supported by the PLM platform.

The experience from more than a dozen solution development projects has show that developing the draft Information Model first results in a faster engagement.  The business processes used in a paper-based world often undergo a radical redefinition when implemented in a PLM system.  I have observed that after a usage the business will have improvements to the first set of processes implemented, but hardly any extensions to the Information Model.

The Paper Prototype identifies the business requirements graphically in UML Class Models, State Machine Models and Activity Models.  From the models a Demo Prototype can be easily constructed.  The Demo Prototype is built using out-of-the-box configuration mechanisms on a throw away instance.  Further refinement is made to the Demo Prototype until understanding is reached with the business users on the solution behavior and appearance.  At this point a requirements specification that is 95% stable can be created.  The requirements and the design are reflected in the various prototypes and the actual specifications for sign off are incrementally developed in parallel.

The CRP Prototype is created from the Demo configurations and any missing details are filled in to match the requirements specification.  In the CRP meetings the business users drive the system by going through the main Use Cases and all review/approval workflows.  The CRP prototype is the final refinement point before creating the deployable solution.

The three levels of prototype allow for fast correction of misunderstanding in the requirements of the solution.  The Paper Prototype can be modified in minutes during a review meeting.  The Demo Prototype can be modified within hours to a day.  On average the corrections coming out of the CRP have been made with a couple of engineering days of effort.  The deployed validated solution is done within 3 to 6 months of starting to gather requirements.

Dan Matheson

Senior Architect, Integware