For many organizations, PLM system implementation projects are not yielding the intended results of improved business efficiency and information management. From our experience, one possible reason is that some projects might not have been set on a course for success. For example, did the project team begin by delving into software demonstrations or with cross-functional process development? Was the project budget based on assumptions or was it created after planner understood all business requirements?
Answers to these questions likely will determine whether the outcome of the PLM implementation project is successful. We believe using a process-centric approach is critical to a successful implementation.
By embracing a process-centric approach, cross-functional owners define the business processes up front. Bringing people together to describe the ways they work and what they deliver before discussing software likely will result in streamlined work with reduced complexities.
Another result of empowering the business to own its processes should be a movement away from organizational firefighting and toward becoming proactive knowledge workers. This should be a natural outcome of establishing flexible, robust processes.
Management-benchmarking surveys generally show that top-performing organizations are highly process focused and strive for continuous improvement, compared to laggards that still embrace fire fighting as standard practice. Organizations in which lean practices have matured within the office environment may experience better success reaching this point.
Putting a business in charge of processes empowers it and increases its involvement with the PLM project, which also helps ensure the deployment will succeed. Giving process ownership to the business user should yield continuous system improvements over time because users enthusiastically control their destiny.
For this to work, there must be a fundamental understanding by all levels of the organization that these cross-functional processes are “owned” by the business users, not IT or the technical group responsible for implementing PLM.
As part of the process-definition approach, the business team should gather requirements for the PLM system while developing the processes and cross-functional touch points. It is generally recommended to involve a business analyst accustomed to managing conflicting priorities and needs, as well as requirements documentation techniques to facilitate these sessions.
In conjunction with process owners, the analyst should use priority matrices to manage requirements and establish development phases, as well as obtaining requirement approval from stakeholders to proceed. It is recommended to use tools such as 5-why, fish bone, RACI, use cases, traceability techniques, etc., during requirement gathering to make the activity as objective as possible.
Requirements should be traceable and measurable for all levels of the business:
- Management – requirements must demonstrate business value, key to obtaining resources and support
- End Users – requirements must satisfy for adoption and sustainable success
Finally, the requirements document should capture the proposed process and requirements in detail. It is critically important to provide clear, unambiguous communication to the implementation team and potential off-shore resources involved with system configuration and testing.
Once “To Be” processes and requirements are defined by the business team, budgets for purchasing licenses and configuration resources for the implementation can be established. At that point, the business should understand what modules will enable processes, as well as how many author or consumer licenses are necessary. With this information, and phased requirements, a scalable deployment becomes available because the licensing and configuration costs can be budgeted.
After processes are defined, the business can create a cross-functional “core team” composed of one critical user from each functional area for each phase of the PLM implementation. This core team is ultimately responsible for final process definition/refinement, application scope, and managing customer requirements.
This team takes input from the organization-wide future process and makes final tweaks for system consumption. The core team must be empowered to make decisions for the entire organization within the bounds of its PLM project phase.
After processes are defined, bring in software configuration experts to review what the business has created and to provide technical feedback. Generally speaking, most experienced configuration experts can make the processes work within the PLM tool of choice.
However, there are some exceptions where customization may be required, or the PLM system simply cannot perform what has been requested. If this occurs, the business should weigh whether to adjust its process or embark on the customization. Be aware the customization may make installing patches or upgrades for the core system difficult.
Core team business involvement must continue during final PLM system configuration and testing. Ideally, the implementation team will embrace an Agile or Rapid Application Development (RAD) methodology. These iterative approaches tend to provide a faster deployment through time-boxed work packages and increased business involvement during system configuration. Quick team decisions and frequent prototype reviews are also characteristics of these methodologies.
During solution development, it is recommended that the Core Team holds organization-wide communication town hall sessions. Updates at functional staff meetings are also useful, along with Sharepoint/intranet sites as communication mediums.
In addition, the core team members are active in all prototype review sessions, as well as final sign-off approval during User Acceptance Tests (UAT).
To complete the project lifecycle, the business should be heavily involved with shaping the end-user training experience. Ideally, the business representative from each function will attend the training sessions held for their constituents along with the configuration team. This accomplishes two goals:
- The individual who shaped the solution is answering process-related questions from his or her functional user base instead of an implementation person.
- Core team members make excellent change-communication agents within their functions and across all levels of the organization. This is a key to implementation success.
Finally, trainers should consider traveling to all remote sites for face-to-face interaction. If this is not feasible, make remote sessions as interactive as possible.
It is also recommended to define the internal and/or external ongoing administrative support required by the chosen process implemented, which will help establish a plan for growing a PLM support team.
Following are some general guidelines for a successful PLM deployment:
- Involve the business upfront in all PLM initiatives as follows:
- Business-owned processes enabled by PLM
- Requirements gathering and project resource loading
- Invest time to understand current processes and drivers for change
- Solicit feedback and suggestions from process owners and user community
- Form a core team of process owners and cross-functional users to participate in the project
- Use core team to clarify, group, and rank requirements and determine measures
- Provide user training and super-user support when required
- Establish point of contact within PLM team for all initiatives
- Stay in front of functional leaders
- Business approves annual PLM projects
- Regular “report outs” on project progress
- Conduct cross-functional communication sessions as required
Business ownership must continue after the PLM system is implemented. All future system continuous improvement activities should involve business users. A sure sign of success is when the business initiates and leads those activities.
For more information or help implementing a business-ownership approach to processes and the PLM initiative, contact us at www.mercuryplm.com or 920-929-5555.
Mercury PLM Services Unique Perspective
Our differing approach concentrates on understanding your process as a must for success. A process-centric approach requires businesses to review and question existing work streams to understand “why,” “what,” and “how” work should be accomplished to establish efficient cross-functional work flows that are consistent, repeatable and scalable for growth.
We also offer a unique perspective for helping organizations considering a Product Lifecycle Management implementation because we view PLM from a manufacturing business-user’s vantage point because we live and breathe it daily.
Because we work in a dynamic, global product-development environment that supports a worldwide manufacturing footprint, we have a user’s perspective that helps drive results and realize improvements. Several of our experts also have been deeply involved with our ISO 9000 certification effort, as well as configuration management, and engineering document-management practices. Mercury PLM Services is a Siemens Zone SI Partner.