Change. Did you shudder at that word? If not, then congratulations you are certainly in the minority, as unfortunately most people seem positively allergic, if not to the word, then certainly to the actual practise of change. The problem with a PLM implementation, or any other enterprise level project for that matter, is CHANGE is abundant by the bucket load and certainly deserves the capitalisation I’ve applied for emphasis there.
So why change? The very fact you are considering investing in PLM is probably because you are aware of the fact that what you are doing today is not working. You need to be more efficient, you need more transparency, to be quicker to market, more agile within the season, and ultimately to be more profitable. Well, that’s not going to happen if you keep doing exactly what you are doing today now is it? In that respect change is inevitable. You probably already realise that, convincing everyone else in the business, particularly the users, is another matter.
You recognise the need for change, but just how much change will the implementation of PLM bring and what is the likely scale of the impact? Unfortunately that is the proverbial length of string. There are many determining factors, but we’ll try to look at the ones that are typically the most impactful:
Scope of PLM modules to implement
The breadth of most PLM systems nowadays is vast. They, to varying degrees of depth, cover almost all aspects of the pre-production product development process from line planning and storyboarding, through to material management, sourcing and workflow. Perhaps stating the obvious, but the more processes your implementation touches, then the more change to the business will be involved.
Current working methods / process maturity
There is no point in shoe-horning your current processes into PLM. That will not deliver any benefit. Your end-to end processes will need to be redesigned and streamlined, utilising the new powers of PLM at your disposal. The level of impact to each part of the business will be greatly determined by the current ways of working and existing process maturity. Some departments may pretty much continue doing what they are doing today but will just use PLM as the new data repository. The main change they will encounter is the learning curve for using the new software. Other departments may not only face the PLM application learning curve but will also be required to adapt to completely new ways of working as well. Two user groups that are often heavily impacted by this are Designers and Suppliers. In the case of the former they may well be required to move from hand drawn sketches to Adobe Illustrator, from limited data entry in Excel to expanded data entry in PLM. In the case of the latter, then it will be a completely new way of working to use PLM to receive and manage technical specifications, rather than via email, particularly if they have not been exposed to PLM through other retailers they may work with.
Departments and roles affected
If you are implementing the full suite of modules, then it is likely that all departments and roles that the product development process touches will be affected to some degree, though some more than others. With the introduction of the new business process you may find that some roles may encounter an increased workload, particularly in preparation for season one and you may even find that entirely new roles have been created, especially around data administration.
Even during the implementation you will need to take key people away from their day jobs for regular input into process workshops. In this respect, the business users will encounter change to their day to day lives from the moment the project starts.
Goals and deliverables
Your approach to the implementation will determine the severity of the change. If you choose to go live with the full suite of modules from the get go this will obviously have more impact than going for a phrased approach. Rolling out across all your business units at once will be a more drastic change than staging the roll out. Your decision will largely be based upon the size of your operation, the problems you are trying to address, the scope of the modules you are implementing and the return on investment you are looking to realise. Different methods suit different companies and there are pros and cons for each approach, but whichever you choose you need to be prepared for the change that the business will have to overcome. This could range from severe but over more quickly or less painful but more prolonged.
Integrations / dual implementations
If you are planning to integrate PLM into existing systems, you may find that more processes are impacted with change than you originally anticipated. Due to unforeseen factors, such as system functional limitations on either side, you may find that existing processes and subsequent systems have to adapt to join the end to end process and integrate with PLM. Perhaps PLM will now be the master data repository, taking over from a legacy system so there will be a change of process for users of that system as well.
It may be that you plan to revamp your entire process landscape and are planning to implement other systems such as Planning and ERP. Whether you decide to implement these simultaneously or consecutively will affect the impact of change. The end-to-end process and subsequent system design is easier if the multiple systems are implemented together, but planning and execution of such a project is a mammoth task and the change impact for the business and the users may be just too overwhelming.
One of the biggest barriers to a successful PLM implementation and the change that it entails is user adoption. Users are human beings and will all react to change in their own unique way, some will embrace it, others will fight it as much as possible. Others may have the will but will lack the capacity.
It can be extremely difficult for all users to see understand the need for change, and some will undoubtedly benefit personally more than others.
So now that you are a little clearer on what to expect, let’s examine the checklist for PLM change survival….
Plan, plan, plan
Consider every aspect of the business that will be affected by change, from the business process itself, though to the IT infrastructure and the users. Identify your risk points and anticipate how you will manage them and have a plan for overcoming the challenges.
This needs to be done as soon as you know you are going forward with a PLM project. This can be quite tricky as you may not have anyone in the business that has had experience with a PLM implementation project before and planning for scenarios you are not even aware exist is downright impossible. This is where utilizing an independent PLM consultant can be worth their weight in gold. I say independent for two reasons: 1) You may not have even chosen a PLM provider at this stage and 2) even if you have, consultants provided by your chosen PLM provider may not necessarily be relied upon to give you the warts-n-all version of what to expect.
Document, document, document
You probably have a strategic vision of the direction you want to be taking and the benefits you are looking to achieve. However getting from A to B can be a murky and confusing journey and it is not always clear exactly what you need to change in order to reach your destination. One of the most important tasks you can do is to meticulously understand and document your as-is processes. It is only in doing this that you will clearly be able to see which processes need to be streamlined and subjected to change. This is another area where an independent PLM consultant can come in useful. By analysing your as-is documentation they can help identity the key functionality you should be looking for in a potential PLM system. The results of this exercise can then be used to formulate your RFP (refer for proposal) to issue to potential PLM providers.
Following on from your as-is process analysis and after you have selected your PLM provider you will be in a position to formulate a to-be process map and implementation plan. You should be able to identify what must change and distinguish this from what would be nice to change, incorporating this into a phased approach for the implementation – changing everything at once is usually a recipe for disaster. Go for the critical and quick wins first and move the nice to change into a long term strategic plan for the future.
Remember when you are documenting the to-be process it may be necessary to split this into documentation for the business and documentation for the functional design of the PLM system. Too often the to-be is written in a way that clearly explains how the functional capabilities of PLM will be used to streamline the business processes. This is great for the PLM consultants designing the configuration, but can completely alienate business users with PLM specific jargon. Providing the business with easy to understand documentation with familiar terminology detailing the proposed changes to their roles and tasks will help them understand not only how they will individually benefit, but how jigsaw fits together in the wider business picture. Knowing why you are changing really helps you to accept it.
Towards the end of your implementation you will be thinking about user training. It is imperative that you build in time and resource to produce comprehensive training manuals. A common mistake is to believe that the training materials provided with your PLM system will be adequate. They are not and this is not the fault of the PLM provider. A PLM system is a tool box. Sure, you may be going for an out-the-box (or as much is realistically possible) implementation but the way you use the functionality and tools available in PLM is unique to every company and is intrinsically tied to your business process. Sure, you can look at the default documentation to see which buttons to press to add a new row to the BOM, but expecting users to trawl through hundreds of pages of functional instructions to find the elements relevant to their role is unrealistic. Users need to be trained on the new process as much as the functionality and you should produce role based documentation that seamlessly guides them through their process and the functionality they will be using.
Manage, manage, manage
A common project buster that you need to look out for is the dreaded scope creep. It is critical that key business stakeholders are involved in your as-is and to-be analysis workshops so that you are identifying changes that are actually relevant and valuable to the business, rather than just strategic or “best-practise”. However the involvement of multiple participants comes with the unfortunate downside that everyone will also have a great long list of changes they see as essential. Once the change process starts people tend to get a bit change happy.
To minimise the risk of scope creep, the first thing to do is to identify just one or two key stakeholders that represent each specific area of the business i.e. design, merch, tech and so forth. They should be people that know their business area inside out and can communicate the challenges that they face. Having representatives rather then the whole team involved in the process workshops helps filter out the essentials from the nice to haves. Too many cooks spoil the broth and all that.
Of course some change will be necessary throughout the course of the project as new information comes to light and the project team become more familiar with the PLM solution. The key is to manage changes to the plan efficiently. Changes should always be channelled through one key person responsible, their value to the business assessed and if the change is appropriate, fully documented.
Resource, resource, resource
Anticipating the resource you will need for the project in advance and allocating it accordingly will pay off dividends in surviving the change. This comes in the form of obvious and not so obvious resource. Let me explain…
Obviously, you need to identify a project team. This will include a project manager, someone to manage the project plan , coordinate workshops and liase between the other project stakeholders and be the lead in change management. You will then have key stakeholders from each business area the implementation touches, the business process experts that will input into your process workshops. There will be IT resource needed to configure hardware, install software and liaise with the technical team from your PLM supplier. Higher up the chain you will need project sponsors, the people that control the budget, drive the strategic vision, sign off the project phases and authorise changes. You may employ the services of an independent PLM consultant as mentioned earlier.
Then comes the not so obvious resources that many people overlook but are usually critical to the success of the project. What many people fail to realise is the scale of the commitment required from the key stakeholders for the business process workshops and follow on tasks. Whilst not quite a full time commitment, the time required from them will be significant and ongoing throughout the project. They need to be involved in both the as-is and to-be process mapping workshops, the system configuration design, the system testing and the training. Without them the project will fail. But how do you take such key personnel away from their day jobs for so long? This needs to be anticipated before the project even starts and additional resource needs to be secured and trained so that the rest of the team in the affected business areas are not just left to pick up the slack unaided, hence building resentment to the project.
The other not so obvious resource is around administration. As the old saying goes, no pain, no gain and unfortunately things have to get worse before they get better and there is going to be a lot of data administration that needs to be done, particularly before go live but also during season one. Planning extra resource for this will save a lot of ill will from your users! Before go live there will be a lot of cleaning of data that needs to done in order to build the PLM data libraries, and quite often a lot of data entry along with it, despite the fact you can usually upload a proportion of it. Employing temporary data support for season one, particularly for Designers who can find the changes in their data input responsibilities overwhelming can be very beneficial in easing them into the change.
Finally, identifying a couple of ‘super users’ from each business area who can support the rest of the team is a great way to help users adjust to the change. Typically as the project progresses you will easily identify the people who seem really keen and are picking up the system quickly and easily. These people should go on to be your system champions after go live, people the rest of the team can call upon when they are struggling to get to grips with the new functionality or business process. Make sure they are particularly available to users that you have identified as resistant to change or not technically savvy that may struggle with a new system.
Test, test, test
Before you go live and let the whole business loose on the new system you need to test the living daylights out of it. Nothing kills enthusiasm for the change a new system brings than bugs and tea break long screen refreshes. Every part of the new process for every business area needs to be meticulously tested before go live, using real life scenarios and any issues ironed out before the business users ever see it.
And finally… don’t go live half cocked
Nobody likes to be thrown in the deep end not knowing what they are doing. Not only is it stressful but it can add hours to your working day – a sure fire way for users to go back to the old way of doing things. Training is the key. Training needs to be devised so that is teaching both the new process and the system functionality, using real life scenarios so that it is as familiar as possible. Provide plenty of clear and concise supporting documentation as mentioned earlier. Don’t train a month before go live. Training needs to be done as close to your go live season as possible so that it remains fresh in the mind. Your training system should be an exact replica of your production system – not just in the configuration but also in the hardware set up – it needs to be a as close to real life as possible.
Make sure your system is data rich before go live, that all the supporting data is available to users from the get go, including all the PLM data libraries. If data is not easily available users tend to drift back into the old way of doing things.
Change is never easy, but following the advice detailed in this article you are in with a fighting chance of surviving the PLM change challenge.