In a WhichPLM exclusive article, originally running in our Annual Review 2014, PLM integration and implementation consultant Brion Carroll II introduces retailers, brands and manufacturers to the tentative preparatory steps that follow their selection of a PLM solution. With multiple implementations to his name, Brion draws upon his experience to set out what he calls the “1-2-3” of PLM.
You did it! You took the plunge. Made the leap. After educating yourself on the ins and outs of PLM, listening to seminars and webinars, searching the likes of WhichPLM for information, advocating for your department at conferences, you made your selection and took the first step on your PLM journey.
But now what? After all the time and effort spent on quantifying your need for PLM, and discovering the right software and long-term partner for your business, you have your figurative bags packed and are ready to begin marching towards your PLM goals in earnest, but you may not know quite where to begin.
Once the selection is made, there are a series of best practice preparatory steps that retailers and brands can take to get what I call the “1-2- 3” of their business ready for PLM. Step 1 refers to the business itself, step 2 references the full scope of business data, and step 3 concerns that organisation’s system architecture.
Typically, these steps will be followed in a situation where a business is moving from a non-PLM environment (potentially from PDM, or from mountains of Excel spreadsheets) but it’s important to note early on that they are as applicable to the extension of an existing system as they are to the implementation of a new one. The unifying thread between both projects is the desire to take a practical and sustainable approach to what will be a significant and far-reaching business transformation.
Just like a child unwrapping that prized present at Christmas time, with a PLM solution chosen, everyone wants to purchase and install their new software right away. But it can be easy to forget that the project team who have worked diligently on the process of mapping, shortlisting and selection are not the entire PLM team. So rather than focus on getting that new user interface up and running as rapidly as possible, these first tentative steps into PLM should be taken as an opportunity to bring all business participants together – turning a small occasion for showing off into a rallying cry for new business processes.
Exploring step 1 a little further, the intention is to prepare the business as a whole for the change that is about to come everyone’s way; whether they work directly with the new solution or not, virtually every job role will be touched in some way by the implementation. By obtaining cross-departmental buy-in at the earliest possible stage, an implementation is much more likely to retain its forward momentum into the later stages of the project, and achieve what experts call “continual phased improvement”.
It is also a good idea to appoint an executive champion that is just as passionate about the initiative as your project team lead had to be in order to get things off the ground. This figurehead can then help to communicate to departmental champions, ensuring that everyone from the designer to the CIO possesses a good understanding of the vision for the project, as well as how it affects their day to day role. By establishing this sense of direction and ownership, a business can also create departmental focus groups for the purposes of surveying and tracking acceptance and adoption.
Internal expertise and education, however, can only take us so far. To help reduce your exposure to risk during your PLM project, it’s advisable to bring in a knowledgeable PLM subject matter expert – somehow who is unbiased, and intimately familiar with your chosen vendor’s quirks and capabilities – as early as possible. The right independent expert can help to ensure that your business is able to leverage as many of your PLM solution’s out of the box capabilities as possible, helping to reduce or eliminate roadblocks later on.
I once worked with a large European designer brand, where a very competent and multidisciplinary PLM project team had been put in place before I arrived. I was invited in as the PLM subject matter expert (SME), and began working with a group that included everyone from the IT Director to departmental Line Managers.
The first thing that struck me was just how invested each and every team member was in the vision of the project. Unlike some large project teams, where in-fighting and conflicting priorities can actually work against the end goals, everyone in this team was united behind a desire to shorten cycle time and improve the process of producing and communicating tech packs.
Because of the sheer number of different interests represented in that project team – and them all having been educated on the strategic objectives of the project – we discovered through our meetings that creating costing and materials information for vendors was having a significant impact on the development calendar. Initially the assumption had been that the workflow between the designer and technical designer was to blame, so had our project group not included the VP of Sourcing (who was also a project champion) we would have been ignorant of a vital piece of information which ended up delivering a major cycle time and cost improvement – one that was not even contained in the original PLM scope.
Given this example, it is clear to see how any PLM implementation is bound to impact multiple areas of that company’s infrastructure, and why champions from within those areas can add so much value to these initial stages – the (1) in our 1-2-3 of PLM.
Almost invariably, the goals of any PLM implementation are to moderate product costs, reduce cycle times, minimise supply risks, and safeguard quality and compliance. All of this scope is baked right into the name: product lifecycle management. And needless to say, it will by definition affect various divisions and departments. Let’s just take line planning and product development functionality as an example. For this, the project goal would be to share illustrations, patterns and samples so that designers, technical designers, line managers etc. can achieve a standard process and leverage the same information at different stages of the design and development lifecycle. Input once; use many times. This example alone shows how a seemingly simple and selflimiting goal can in fact touch many areas of the business, which is why the second entry in our 1-2-3 requires the organisation to take stock and inventory of its business and application environments.
Prior to embarking on a PLM project proper, it is always wise to understand the topology of the existing systems that are in place, as well as what needs they currently fulfil for the business. Sometimes this assessment – or “as-is” – process is a meticulous and time-consuming effort, but it remains vital for practically every implementation, since it allows the organisation in question to get at fundamental information such as: which systems support which process functions; what information or data is stored in each system and for how long; how accessible the information is, and how complex the data structure is.
In order to build an understanding of this second step, a team will typically design a map or flow diagram encompassing the full scope of business data, and documenting the layout of every application in use within the extended enterprise. These applications can range from the seemingly-trivial and non-connected right through to the cloud-based and offsite. Without this understanding of where business-critical data resides, it can be extremely difficult to try and understand where PLM fits in context, what redundant applications it is capable of replacing, and how it will communicate with those solutions that are retained, and that now need to be integrated into a cohesive whole.
I conducted one of these second step processes on behalf of a multi-brand fashion designer that had purchased PLM with only one specific product development target in mind. Whilst we were mapping their business environment – specifically with the goal of on-boarding material libraries in a phased deployment – we discovered that central product data was, in its current state, stored in a host of different, disconnected systems – often in duplicate. Even more importantly, this state of affairs was not limited to material libraries: digital images, colourways, vendor information and so on was all similarly fragmented.
We realised at this point that a complete data cleansing and staging effort was required. We coded an Extraction Transformation and Loading (ETL) tool in Java that allowed us to capture other areas of business data more effectively, and to repeat the data cleansing results we had by then seen in material libraries. In the end, all brands within the organisation used the same ETL to achieve organisational readiness and map out the true extent of their second step on the PLM journey.
I mentioned the concept of “phased deployments” in a previous paragraph, and I want to add a little more context to that. Implementation professionals will typically talk about “phased” or “big bang” approaches to putting PLM in place: the first refers to a gradual and segmented roll-out offering potentially greater control, while the second is a more aggressive strategy, aimed at getting as many (if not all) departments as possible on board in one fell swoop.
The choice of phased or big bang approaches must take a number of different factors into account: company size, business drivers, resource capacity to name just a few. Steps (1) and (2) on the journey should help any retailer or brand to accurately determine which approach will best suit their needs – I have personally seen both be effective – and the experience and competency of your project team (as a team and as individuals) will ultimately secure the success of your project.
With your business challenges understood, and the scope of your business data determined, the final in our series of three initial steps lies in understanding how PLM should be integrated to your existing business technology framework.
As we covered in step (2), PLM will always be implemented in context: very rarely will the implementation of a new system coincide with the effective re-engineering of every business function, and nor will it typically be able to replace the functionality of every other enterprise system. With this being the case, integrating your new PLM solution to your broader business environment is a sensible step, and one that can bring together the many different facets of your product lifecycles in a common enterprise framework – the third step on our PLM journey.
Integrations can take a huge number of different forms, and will be dictated by the specifics of your business environment. Generally speaking, though, the most common integration methods are based on web services allowing a “just-in-time” collaboration between PLM and contributing systems. And while some organisations will balk at the idea of “customising” their new PLM environment so early in the process, integrations of this type are both commonplace and effective, allowing the right extended-PLM solutions to continue serving as the arteries that feed the heart of product lifecycle management: PLM itself.
Once the concept of integration has been broached, the specifics can then be explored. In the case of CAD integrations, design teams can be certain that they are always working with the latest file revisions, with workflow automation allowing them to modify attributes in existing designs – and these attributes then being pushed to the technical teams – without compromising security.
From a technical perspective, various mapping solutions will offer combined network mapping to provide real-time views and performance monitoring of all services, systems and traffic patterns. Using a combination of exposed vendor API’s and IT resources, these types of architectures are much simpler to implement than they might sound, and can deliver potentially significant results across the extended enterprise.
Throughout this article, I have treated PLM adoption as something that can be handled (and handled well) through simple, piecemeal steps, but it is important to remember that selecting and implementing PLM is a huge undertaking and an overall leap that should not be taken lightly.
A motivated and engaged team is certainly a terrific asset, but actually assembling the right champions can prove difficult if any number of departments do not understand how PLM might benefit them. Similarly, carving out a home for PLM amongst your extended and integrated systems architecture is best practice, but the actual development of middleware (not to mention the audit required to understand its scope) is something typically best handled by an experienced third party.
Whether it’s in these initial preparatory steps or later in the implementation, the adoption of PLM will take a considerable amount of effort. But with the correct foundations in place, the journey can have an extremely worthwhile endpoint – assuming you begin by following logical and proven methods from the beginning.