A Common Virtual Product Model as a Lighthouse for Business Processes
By Klaus Brettschneider
What if the product lifecycle management (PLM) system in an organization is working, the implementation is complete, the team even paid attention to user experience, aligning the UI to optimize the process steps a user has to perform? What if all this is done correctly, yet the system is still not accepted by the user community, especially in departments outside of the focus implementation?From time to time we get called into struggling PLM implementation projects to offer feedback or an additional opinion. The variety of challenges is very broad, and the same advice can seldom be applied to different customer situations. In the last couple of months, we were involved in two projects with customers from different industries and saw a third one from the sidelines with the same struggle.
The system implementations were well done; the collected requirements were met with sufficient functionality, and the system worked as expected. The implementation teams had paid attention to the adoption challenge. In one case, a plant owner with a focus on plant maintenance provided a specially developed workbench for the user. In the other case, a manufacturer of machine components customized the system to support CAD-specific functionalities. Be that as it may, both customers were not able to get their PLM system to fly. Yes, the required functionality was available, and the PLM projects were overall successful, but a lack of acceptance in departments outside of the PLM core process limited the utilization of the system and didn’t break down the information silos as expected.
We spent time looking into the reasons why the departments didn’t adopt the system, watched the users over their shoulders, and listened to the leaders of the affected departments. As it turns out, the challenge was not related to the functionality of the PLM system, but to the method of how documents and information were being organized and stored.
“Similar to a lighthouse serving as a navigational aid to mariners at sea, a common product structure will give everyone involved a point of reference and simplify the information exchange between departments.”
A lot is written about whether or not documents are better organized in a structured or unstructured way, and it often looks as if the dispute lies between Millennials and older generations (strange thing to say if you fall into the second category). However, in businesses where processes are dominating, a structured approach is established and a virtual product model is often used to provide the structure as an organizational frame. This virtual product model may be referred to by another name in different industries with varying granulations or characteristics, but it is ultimately a structure representing the product that has to be manufactured or a plant that has to be maintained and so on. Here are few examples of how the structures can be referred to:
- Bill of material (BOM) in the manufacturing industry
- Building information model (BIM) in the civil engineering industry
- Plant data model for plant manufacturer, owner and maintainer
There are two challenges to consider in regards to these structures.
Challenge #1: Finding a common product structure
The department that initiates the implementation very often defines the structures that are used in the IT system. When logistic processes found their way into ERP systems, the product structures represented therein were logistic-driven BOMs, and the ERP systems manifested the structure in that way. When the manufacturer started to plan production in the manufacturing planning systems (MPS), the BOMs there were driven by the manufacturing process and found their manifestation there. The same manifestation happened in these PLM projects, where the design department in the one case and the plant maintenance planner in the other, had defined the virtual product structure for the system without consulting other departments.
It is very important for the acceptance of a system that uses structures to come to a common understanding of the Virtual Product Model. Yes, the system also has to provide its users the functionality to view the model, but if an organization is not able to find common ground for such a fundamental element of the implementation then no system can fix it in hindsight. Building a common Virtual Product Model can be like building a lighthouse to give everyone orientation. A common approach to organizing information has a lot of advantages beyond the PLM system. Similar to a lighthouse serving as a navigational aid to mariners at sea, a common product structure will give everyone involved a point of reference and simplify the information exchange between departments.
Challenge #2: Establishing user acceptance with 3D models
A key aspect of this challenge is the question of how such information can be consumed easily. With the engineering-driven approach where designers often know their part numbers offhand or where “smart” numbers provide insiders the right information, even a common virtual product model does not always help. Companies with variant configurators can end up with such complex structures that even the senior design engineer can have trouble keeping the overview. In such situations, we have to look into other options to visualize products, for example, SAP Visual Enterprise, where ERP information can be accessed via the 3D model and where the 3D model can be used to see if a chosen configuration will work. I will dive further into 3D visualization in my webcast “SAP Visual Enterprise. See the ROI.” on April 21, 2016.
The second approach to implementing better 3D visualization for the downstream process isn’t something that we could get in place quickly enough to help the projects we reviewed, but a few consensus-building workshops with the affected departments helped to define a common virtual product model structure. A few adjustments in the PLM system improved the user acceptance tremendously and also helped to straighten out some “structural” process issues. It’s always better to be on the same page in an organization even if it is a complex structure. A lighthouse may give the organization some orientation in an otherwise stormy time.
