If There's One Thing CRM Tells Us: Don't Do PLM the Same Way

Introduction: What Has CRM Got to Do with PLM?

Product lifecycle management (PLM) doesn't work, but it should. Fundamentally, the idea that we can design better products and bring them to market more quickly by leveraging knowledge and experience from our own value chain and our customers and suppliers is a sound one.

It's just that buying PLM doesn't always make that happen. In my view, industry's general approach and attitude to PLM very much mimics the early days of customer relationship management (CRM), and lessons abound from that experience that should help when tackling the "ifs" and "hows" of PLM investment.

What CRM is actually about can be summarized in four points

• collecting all the data concerning the customer to enable and empower individuals—the so-called "single view of the customer";
  
  
• presenting that data in a way that is meaningful to different users;
  
  
• delivering specific "customer care" functionality, such as sales management, support, and call management; and
  
  
• actually using the collected information to adjust processes and product offerings to deliver more value to the customer.

Okay, now bear with me. It is not as easy as it sounds to find an intelligent and intelligible definition for PLM, despite it being the new "must have" in manufacturing and engineering, but I'll have a go at defining it myself:

Product lifecycle management takes place when a company controls the design and delivery of a product from conception to retirement; reduces product and process costs through effective collaboration internally and with the supply chain; and can learn from its experiences.

.which is too much of a mouthful. Breaking the definition in to points, PLM is about

• collecting all the data concerning a product to enable and empower individuals—you could call it "single view of the product";
  
  
• presenting that data in a way that is meaningful to different users of it, and allowing collaboration and contribution with third-parties;
  
  
• delivering specific design management functionality, such as revision management of models' (particularly in three dimensional [3D] parametric systems where component designs are re-used, so understanding cross-references is key) workflow to drive processes; and
  
  
• actually using that information to adjust processes and product offerings to deliver more value to the customer.

Now you begin to see where I'm going with this . . . PLM is to products what CRM is to customers.

So what can we learn from CRM to make PLM work?

Challenge 1: Understand the Importance of Integration

First and foremost, CRM is an integration issue. To present a single view of the customer, we have to collate all the relevant electronic data from existing systems, and put in place processes and procedures to collect data that does not currently exist in any formal systems.

So, what CRM first required was the existence of an enterprise resource planning (ERP) solution, or at least some joined-up applications, possibly aided by extra middleware for systems integration, in order to feed it.

Something similar is true of PLM, except that it is in the middle of two very different, and very important, pieces of the architecture: the computer aided design (CAD) system and the ERP system. It's not, therefore, a simple single interface—it's at least two. The data flow is iterative and bi-directional. The integration needs to account for structured data (such as bills of materials and parts data), unstructured data (including descriptions, narratives, and multi-media), and workflow.

Oddly, integrating the workflow is the biggest challenge. Workflow is particularly beneficial for controlling interdepartmental processes, yet the CRM and the ERP systems each have workflow engines. The PLM system will often add its own system to this. The issue is which should be used, or how to make them talk. (We will talk about workflow again later).

Challenge 2: Choosing between the CAD and ERP Vendor

Both CAD and ERP vendors will attempt to sell you PLM—the "middle piece" between CAD and ERP—using similar fear, uncertainty, and doubt arguments.

ERP vendors will argue that you should choose their PLM because their ERP controls the commercial data, and is also the system that has the largest user population; users who are going to provide the valuable feedback and input to the design process.

CAD vendors, on the other hand, will argue that they control the actual geometry of the design, its physical properties, analysis tools, and the bill of material. They would argue (and I have some sympathy for this) that their provision of sophisticated links between the CAD system and the design database is more important than ERP-type data, which is mostly text.

The challenge then is to choose between them—to make a sort of King Solomon-type decision that most information technology (IT) directors should be wary of.

Challenge 3: Killing the Golden Goose of Information.

I think that it's interesting to consider that both CRM and PLM require an extra repository (database) for all that juicy information that we believe we want and need, but so far, and quite tellingly, that information has not been collected.

Both systems collect new descriptive and classification data (called metadata). When CRM is at the early stages of being rolled out, implementation teams can become carried away, or pressured by management, with how much data they want to extract from the people driving the process.

The same is true of PLM. The danger is that engineers and designers, in particular, are given far more administration to do, which can be, or can be seen by them as, a waste of time and actually reduce their productivity.

Moreover, if they don't buy into the benefits of the metadata that the PLM system is designed to trap, they'll put minimal effort or even put pure junk in to the system, rendering it far less useful. I have seen this come to pass many times in CRM rollouts—indeed, dirty data is one of the biggest problems with CRM. Because it can be misleading, it can be worse than no data at all. PLM can easily go the same way.

Challenge 4: Understand PLM the Verb versus PLM the Noun

Early adopters of CRM seemed to believe that just buying a CRM product would be enough to respond to their customer care and innovation challenges, and would make them more competitive as a result. Similarly, companies are buying PLM, expecting that in doing so they will have all the unified, joined up, knowledge driven processes that these solutions promise. However, CRM early adopters discovered that CRM is actually an approach to business more than a technology—that it is a verb rather than a noun. It was then when they ran into the biggest problem of all—changing the business processes and culture. Let me explain. With CRM in place, the customer-facing processes should be slicker and more "joined up". That's the easy bit. What is more difficult is analyzing the data collected in order to interpret what your customers' actions are telling you about product direction or opportunities for improvement.

If you already have CRM, here are a few open-ended questions you can ask yourself, which illustrate this point: Do your engineering and product design folk even have access to the CRM system and its data? Do you really find new business opportunities through mining the data for trends? Are your customer-facing folk more empowered as a result of using the system? And (my personal favourite) do you believe that your customers actually know what it is that they want from you in the future?

It became very apparent to early users of CRM that while the system could be installed relatively quickly, effecting the organizational change, and getting down to doing CRM was going to take far longer, and cost far more than was previously thought. It has to be said, though, that the benefits do exist and are considerable.

The parallels for PLM rollouts are obvious. Before gains can be made from the exploitation of intellectual property and design re-use, the organization has to spend a long time filling the database. The extra time spent doing this will actually slow down processes in the short-term and management needs to be aware of that. Moreover there is a huge organizational change that needs to take place, where designers have to become more open, and even become more customer-facing.

Challenge 5: Don't Ask If You Don't Want to Know

Somewhat linked to the previous point is the fact that processes for approval of designs and engineering change notices (ECN) can become convoluted as PLM enables (sometimes requires) more people to become involved. Decisions that used to be made by relatively few people autonomously could and should be subject to input from many stakeholders, such as customer support, engineering, manufacturing, customers, and suppliers.

However, once we begin to encourage these stakeholders to contribute to design sign-off, we had better be prepared to respond to their feedback! This makes it difficult to ignore them if we disagree, and difficult to by-pass them if we want a fast decision.

Challenge 6: Overlap in the Applications

There are already overlaps between CRM and ERP. When PLM is rolled out, there are even more overlaps, and more functionality choices to be made as a result.

I started this essay by pointing out a few of the key components of PLM. Let's recap.

• Issue and revision control of data
• Management of the design database and the cross-referencing of components
• Collaboration technology such as portals to disseminate information
• Workflow to drive (predominantly) sign-off and engineering change notices
• Input/output and integration tools to be able to communicate with the downstream systems

The first two, issues and revision control, and the management of the design database, are dealt with by PLM's predecessor, product data management (PDM). (Indeed most of the PLM solutions on the market at the moment are derived from former PDM tools, or marketed by their authors). PDM makes sense. It has a clear place in the architecture. Its role and interfacing is clear.

It is the rest of the components in the list that are less easy to compartmentalize, as companies rolling out CRM have found. Taking collaboration as an example, the ERP system will almost certainly have its own portal and e-business tools, which also hopes to help organizations gain grace and lock-in their customers. The CRM system will have collaboration in the region of sales and support. Adding to this, a prospective PLM system will have design-centric collaboration.

In an engineering firm, it is really difficult to separate commercial and engineering issues—that is the point of a PLM strategy. So why have separate collaboration solutions, each with its own user identities (ID), maintenance costs, and user interfaces? Will your customers and suppliers accept all these systems, and will they be useful in the end?

Workflow has very similar issues. Any good ERP system will have a workflow system for processing, amongst others, engineering changes, purchase approval, and manufacturing expediting. CRM tools often have their own workflow system that again cover sales and support processes.

Once more PLM comes along and, as the third part of the enterprise architecture, muddies the water. Faced with different workflow systems, one has to ask which workflow system should be used for engineering change and design sign off? Should designers be forced to work outside their normal toolset and use the ERP workflow? Or should the rest of the user population use the PLM's workflow in order to feedback on design issues?

Either of these two is a compromise. The ERP workflow typically is oriented towards handling the ERP data (and almost certainly is not optimized to deal with design data). However, the PLM workflow would require the deployment of lots of licenses and a foreign system to the majority of the user population.

Are There Any Answers?

Are there any answers? I believe so. First, recognize the limitations of technology! Whereas PDM is necessary to control revisions of CAD models, etc., true PLM only happens when existing systems are integrated to deliver cohesive processes. Applications that promise to "give" you PLM should be viewed with some scepticism.

It should be no surprise that I mention this, but choose a vendor carefully. Any potential vendor should have demonstrable understanding of both CAD and ERP. (If, at any point a vendor uses the words "PLM" and "out-of-the-box" in one breath, you know they haven't got any experience to offer!)

Given potentially huge overlaps in functionality between systems (collaboration and workflow are perfect examples), try to avoid over-investing in capability that you've already got. Rather, think about what your processes demand of you, take an inventory of the capability you already have through ERP and other applications, and then look to fill the gaps.

Integration! Integration! Integration! Press hard on this issue. PLM is all about integration—it can't be stressed enough. Moreover the integration should not be designed around one particular system, rather it should be neutral (so-called "loosely coupled"). Press vendors on how they might achieve integration, and also what happens when the applications are changed, replaced, or improved.

Finally, like all good plans, keep it pragmatic.

About the Author

David Smith GDBS BEng (Hons.) MIEE is a consultant for in2grate, a company that specialises in helping its clients achieve PLM. in2grate draws on experience from 1,000 CAD, 300 ERP, and 60 warehouse management implementations.

Smith can be contacted at (1) (44) 1844-295-245; david.smith@in2grate.com.

See http://www.in2grate.com and also http://www.anisagroup.com.