How do you develop and maintain an integrated PLM system efficiently and cost-effectively?” That is the question raised by CIO and Engineering leaders throughout the globe, shortly before a call goes into the software vendor to see how other organisations run their teams. Of course, the answer is that every organisation has different constraints and priorities, so there is not one perfect way to answer this question. But, by exploring what they need as an outcome and the boldness of their strategy, should indicate the best method to progress.
Some companies keep all development and administration of PLM in-house, developing and training staff with the intention of retaining them for suitable time periods. Typically these organisations have constraints, such as not being able to use foreign nationals or requirements for security clearance. Possibly the company is not experienced in working with consultants or system integrators and just tend to avoid them. The risks to this approach are that PLM is so broad in reach, that training up in-house staff in all functional areas can be expensive. Also to retain the staff, there generally needs to be a large rolling programme of work to provide variety and ongoing staff engagement.
Many organisations use a model of utilising consultants, system integrators or vendors to complete an outcome based project. This model does not require the company to keep the expertise in-house, therefore they buy-in the best skills at the point of delivery. Benefits are typically, the avoidance of taking on staff headcount and the assumed cutting edge consultant skills and experience. One of the disadvantages often seen with this approach is the reaction from the engineering/manufacturing employees at the company, they can often feel a culture clash in that the external consultants; “do not understand our ways of working”, or resentment of “why are the managers wasting all this money when we could do it just as well in-house?”. Leadership and strong Change Management techniques are key to integrating the two parties and working towards a successful delivery. Organisations must also work as an intelligent customer, with the experience to ensure project risks, decisions and scope creep are fully evaluated and managed.
The other model tends to be a complete out-sourcing arrangement. Often companies have already outsourced the entire IT department, with possibly one contract for hardware provision, another for system administration and yet more for other functions such as helpdesk support and business administration. These companies must rely on consultants, system integrators or vendors to complete the project, but agreeing on delivery and support can become a marathon in contractual negotiations. Strong management with a strategic vision and an excellent PMO are required to make these PLM projects a continued success.
In reality, the delivery models are never this clear-cut, it is likely that every organisation will use a mix of the above three approaches at some stage. The PLM toolsets are very broad and far-reaching in functionality, even the vendors don’t expect their workflow experts to have an in-depth knowledge of integrating Manufacturing Execution Systems (MES). So the use of specialist resource from an external provider in delivering a PLM project is far more common now, than 5 years ago. Hence the large increase in PLM consultancy and integration firms, with a recent trend in targeted industry verticals or functional areas such as Digital Production Planning.
I have used the terms “project” and “outcome-based” in the paragraphs above, but anyone that has delivered an enterprise IT system will understand that initial delivery is only half the story. The administration and maintenance of the system is an ongoing requirement that often is not sufficiently planned for, or understood. Managers like to think in terms of projects, where there is a clear end to the effort and the company can celebrate their success in delivery. PLM should really be recognised as a continuous improvement programme, which starts with a grand vision and must be run as a continuous delivery framework, as in my experience, the vision/strategy will always be amended to add additional initiatives as the benefit of PLM is realised.
A constant maintenance and delivery rhythm is key to meeting the needs of all PLM system stakeholders. Many companies plan to upgrade their PLM system every two years, firstly to stay within the vendor software support window, and secondly to minimise the complexity of upgrading related software (CAD, ECAD, Simulation software) at the same time. This allows the cadence of upgrading PLM one year and the corresponding authoring tools the next, theoretically separating and indicating which software is responsible for any upgrade issues. Unfortunately, many organisations have not been able to maintain this schedule and fall behind maintained versions of PLM software resulting in a more involved and expensive upgrade process
Wikipedia defines Continuous Delivery as “a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently”. PLM delivery projects need to stop trying to ‘boil the ocean’ and deliver in a big-bang, the successes can be hard fought using that approach. Using a continuous, more agile method, I won’t prescribe any one tool, but SCRUM, Design Thinking, DevOp’s, etc. all lead to a delivery culture that gives a better focus on the needs of the customer. Agility is no longer a buzzword, it is a reality, many PLM development teams are running smaller, more incremental development releases, more frequently and with excellent user and executive feedback.
So in conclusion, if you plan to deliver your PLM system in the most cost-efficient way, you need to plan for continuous delivery ensuring the team can respond to a variety of projects, challenges and upgrades. This must be achieved through pulling together manager’s, configuration developers, process experts, testers, change managers, trainers and end users for maximum efficiency. Dedicated teams make sense, project teams seem like a terrible idea (on reflection), as just when you have progressed past the Forming, Storming, Norming and Performing stage, and people are starting to function as a well-drilled team, the project ends and they get disbanded. Sure these teams can be made up from consultants and system integrator staff, but you must plan for the long-term and manage rotation effectively.