Falling in Love with PLM. The People Side

08/03/2015 07:50

(This blog is a transcript of the presentation "Falling in Love with PLM. The People Side", which has been held at the PI Congress in Düsseldorf on February 24, 2015.)

Last year in joining the PI Congress I was surprised about the mismatch between PLM success stories presented to the audience and stories about PLM deployments in organizations shared during the breaks. What I heard during the breaks corresponded with my own experience. And as you know, deploying PLM in an organization is not an easy task and requires a lot of effort.

We spent a lot of effort to convince our management, that deploying a PLM system will allow rapid development of high-quality, innovative, and profitable products and we spent a lot of effort to convince the users, that the PLM system allows management of increased product complexity. (Are we really sure?)

We try to convince our management to spend the money needed for further deployment, promising return of investment in the near future. But instead of getting the money, quite often we get more requirements regarding solving specific issues.

In talking to the users we communicate the benefits of the tool, to solve their day-to-day problems, but instead of them using the tool with joy, you see resistance, slowing down the deployment process.

Main arguments not to use the system are: too complex, not user friendly, too expensive.

For the management of product definition data we moved from a set of legacy data systems (mainly Excel) to an end to end PLM system. The procedures changed as well, but even up to now there are a lot of questions regarding how to use the PLM system for specific tasks. Users don’t like that. They want to know what to do.

You may ask "Falling in love with PLM" is this a joke? It's not. I would like to show in this presentation how to fall in love again. Let's start our journey.

The Vehicle Metaphor

In changing the realms of meaning using metaphors we often communicate complex concepts. For example in talking about "Money" we may use the concept of "Water" and talk about "cash flows" or "income streams".

To understand what it means to change from legacy data systems to an end to end PLM system we use a metaphor of changing the vehicle used to go to the office. Let's change from a car to a bicycle.

You might ask why a bicycle? After all, PLM vendors offer tools that might better resemble a helicopter metaphor, in that you can get solutions for everything. But it is in fact like a bicycle and you will see shortly why.

The realm of meaning, metaphors in this instance, are schemes describing how going from home to the office and back, works.

Let’s act now in the vehicle scheme performing a tool change in doing basically the same you did in evaluating the PLM system.

The scenario is as follows:

  • You have a target: You want to have more time with your family.
  • Your analysis: You need a lot of time to get from home to the office and vice versa.
  • The reason are daily traffic jams with increasing tendency because of ever-increasing traffic volumes.
  • Your strategy is: To change to a vehicle that is not impacted by said traffic jams, say a helicopter or a bicycle.
  • And you have a measurable target to be sure your change was successful: Reduce the transit time needed by a factor of 2 without exceeding current cost.

A helicopter is not in-line with our cost target, thus your options are narrowed down to the bicycle. In choosing the bicycle scheme you need to assess the impacts of the change; it is not just a new bike but adapted clothing, weather considerations, rain protection, short cuts, fitness etc.

Now let's go through scenarios, to explore the impact of changing the tool and how it could get wrong.

First we map the vehicle realm to the PDM realm.

Let’s assume you decided to go by bike, but you do not want to care about rain, like you did in going by car. You try to adapt the new tool – the bicycle – to the old process, because for example you do not want to buy clothes for rain protection. You request from the bicycle vendor to configure the bike in a way to have a box around you. If it rains, you do not get wet. It is not an expensive change of the tool and you can afford it, but in using the bike with the box around you, you will have difficulties to go up the hill. Now imagine you are forced to go by bike to the office with this bike, up the hill. What would be your reaction? Exactly, you would heavily resist change.

We learn: Changing the tool requires change of the procedures. If you remain using the current procedures, you will fail.

Now we go the other way around mapping the PDM realm to the vehicle realm. As I said, after changing to the PLM system we have still a lot of questions how to use the PLM system for specific tasks. In our mapping we assume that we you do not really know the bicycle scheme.

Consequently you may be unaware of the impacts travelling by bike. You buy the bike based on personal specifications such as gear number and weight, and then use it as you did your car. Very quickly you would begin to encounter a number of issues and would be less likely to realize the benefits. For example, if it rains you will arrive at the office wet. Even more, if you understand, that it might rain, meaning you are aware of the scheme, but you do not use your rain clothes, you get wet as well.

We learn: Using the new tool properly requires identification of the new schemes. The design of new procedures must follow the new schemes.

Supporting Procedures

With this learning we go back to our business and ask ourselves how to find the new schemes and how to design the new procedures based on the new schemes. The answer to these questions should solve our issues.

Before we go to the new practice using new schemes we take a look to the supporting procedures in our current practice using Legacy data systems. Supporting procedures are all the time embedded in a business process.

The business process tells what the organization has to do to get products shipped: business requirements. I take the business process of an automotive supplier, here on top of the slide, I am very familiar with. It is an engineer to order process. (You can replace this business process with the business process of your organization or of your client.)

Here we have a lot of authoring tools, our means, to execute the tasks needed to fulfill the requirements of the business process. These tasks are our supporting procedures telling what to do to fulfill the requirements of the business process. In the current practice, very often the departments are the owners of the supporting procedures using legacy data systems they need.

In talking about the current practice I talk about a status where you - for the management of product definition data - use legacy data systems or you may use a PLM system for specific tasks in your organization, e.g. for managing CAD models, only.

If I talk about the new practice, I talk about using an End2End PLM system to manage all product definition data in an integrated product data structure from concept to end of life.

The End2End PLM system may be realized in several software systems, e.g. Teamcenter, Aras and/or SAP: but forming a consistent set of business solutions to manage the integrated product data structure from concept to end of life.

In the new practice the business process (compared to the current practice) remains and does not change. In introducing an End2End PLM system, our additional means, we have a layer on top of the authoring tools. Using the authoring tools we add product definition data into the integrated product data structure. The supporting procedures now describe the tasks required to fulfill the requirements of the business process including how to create the integrated product data structure from a methodology point of view and how to add information to it generated using authoring tools.

For example we have a new costing procedure, which is used during business acquisition, but after requested product changes during product development and the other phases as well. The procedure describes

  • who is involved and
  • which are the subsequent tasks of each participant

to get the costs of the product implemented into the PLM system.

Each task is described in terms of available input - positions in the integrated product data structure - and intended location of the deliverable, which may be the input for the next task.

Input for example are engineering and manufacturing assumptions for Part items and the Part items itself, for which costing has to be performed.

Output are the cost sheets related to each of the given Part items. Meaning a cost engineer gets a task and finds everything related to the task attached to the task itself. No searching, no guesses, just execution of the task.

A possible new scheme (you might have already implemented it) would be: participants get tasks in the PLM system containing everything they need to execute the task.

Specific Schemes for specific Business Processes

Now we know the concept of "Supporting Procedure". Let's come to the new schemes, which should guide us to design the new procedures and come to the new practice.

How to find new schemes, meaning - in switching back to the metaphor - how to find "looking for short cuts", "use good rain clothes", "understand weather report information", "increase your fitness in fitness centers", etc.? In looking to the metaphor you see, there is not one solution. You may want to go to the office by bike in a country, where it does not rain so often like in Germany. Then rain protection is not required.

I could present solutions we implemented at Autoneum or solution I have in mind based on my findings. The issue is, your business process is different and there is not this one set of new schemes.

Coming back to our original intent, we want to find new schemes to get rid of the risk to run the new tool with current procedures and consequently do not get the full potential of the PLM system rolled out.

For opening up the horizon to lower that risk I very shortly would like to mention the following 2 ideas you – I am sure – know already:

The first is related to high jumping. Jumping backwards was a new scheme for high jumping. The body's center of mass remains a lot below the bar and consequently - at least in theory - someone could jump higher using the same exertion. This is the basic idea. The procedure, how to do it in detail, is a different story. After inventing the new scheme of high jumping there is a remarkable change of the world record. It took some time, but then we see a jump in the results.

Consequently after finding appropriate new schemes to run your business process with a PLM system, there will be a clear improvement of how users get the day-to-day work done properly.

Then - and you will know this as well - if you get the task to connect these nine points with 4 connected strokes, then you will not get the task accomplished, unless you go beyond the area, which is defined by the nine points. I learned: search the solution far beyond the current practice to get rid of the historical grown beliefs, organization's habits, and automated behaviors, which are blocking the change, and prevent to come to a change of the organization's culture.

To be clear: appropriate new schemes of a new practice may require changes of responsibilities and organizational changes.

PLM System as New Team Member

May be even a change of thinking about what a PLM system can do for us, is required. The expectations, what computers can accomplish, are very high and sometimes unrealistic taking limited resources into account (see helicopter versus bicycle).

Introducing a PLM system is basically introducing a new member into the organization, who will get only tasks, which it can perform to our satisfaction. We do the rest.

Computers are not very flexible, but they are very powerful to manage huge amount of data, they are fast in analyzing structures and checking conditions.

Consequently in designing the new procedures they get only tasks, which are appropriate and the rest we do by ourselves.

We define an integrated product data structure for the complete product portfolio of our organization from concept to end of life.

Then we can define for sets of tasks reduced views of the product data structure to get for our users complexity down. User should execute the task in using the reduced views. (You may probably have partially implemented it already in using an eBoM or mBoM.) The PLM system gets the task to analyze the structures upon completeness following defined business rules.

Or the system gets the task to report the potential impact of a change in following the maintained relations between the views. Then a product owner, very familiar with the product (which may probably be a new position in your organization), can decide, up to which extend changes have to be taken into account.

Important is, that we get a very clear vision about the new schemes, to come to optimized procedures supporting, what the strategy demands and aiming to get more immediate ROI. And support real people solving real day-to-day problems.

Implementation of New Schemes

Now in having the new schemes invented for your organization, (it's probably you together with a small team of committed PLM specialists, internal or external,) you have to figure out, how the organization can implement the new schemes in detailed new procedures and how the organization can absorb the resulting proposed change. You may think, you have a committed team and you can define the new procedures by yourself. Relax, it's not you, the organization changes and should be involved as early as possible. (And as an engineer you know, everything you do wrong in the beginning of a product definition without fixing it will result in high additional costs to fix it in later product development phases.)

To design the details of the new procedures appropriate for your organization you have to set up a cross-functional team. The team has to understand the PLM methodology & system, and envision how a prototype user will work.

Cross-functional Team

The core functional PLM team is a multi-disciplinary team and consists of nominated representatives from all departments that are impacted by the design of the end-to-end product lifecycle management process. Each functional member must have enough authority and the right level of management sponsorship to represent his department and to be able to align all stakeholders of his department. Senior management selects the team members, provides support, and acts as their escalation partner. They must set objectives and consistently monitor progress of the expected deliverables.

Because team members must have enough time to carry out their responsibilities, the organization will inevitably resist. They will resist, because involved departments are losing very qualified members, hence putting added pressure on daily performance for a significant amount of time.

The team members must have the skills to communicate with the different parties and promote collaboration amongst them, including C-level managers and users of their own and other departments who will be using the system every day in the future.

Each member of the team is the voice of his department.

And again: Targets are understood to be optimized procedures supporting what the strategy demands and ensuring a more immediate ROI. This requires an intimate understanding of how people, processes and tools are integrated. To bring the new practice to life each member of the team needs to be passionate about user experience.

Understanding PLM Methodology and System

As soon as the cross-functional team members have been nominated they begin by benchmarking their organization against similar businesses to understand and document how they transitioned to PLM, how they currently use the PLM system and how they perform based on pre- and post-PLM metrics. They also evaluate the ‘state-of-the-art’ from sources including blogs, conference proceedings, books and ask PLM experts in the field to understand analysis, opinions, and recommendations.

The team envisions how they as an organization could work with a PLM system, analyzing findings to get high-level insights, converting these insights to design principles and then brainstorming concepts within the widest solution space permitted by these design principles all the while gaining inspiration from metaphors and visualizing concepts.

They play with different design patterns to understand to what extent departments will be impacted and what may be the consequences of supporting procedures and job descriptions.

Understanding the End User

The goal of the team is to understand the end users and their interactions with everything during their day-to-day work. They try to understand how people work in the current practice by documenting people, their activities, and interactions with objects and environment to extract the most valuable insights. They discuss findings with users, and gather feedback and validation.

In designing the new practice they envision prototype users and imagine the problems the PLM system will help them solve without the constraint of current job descriptions and departmental habits. They will explicitly not attempt to make department heads happy nor act on all the wishes the users have. If they did either, they would end up with a design that made none of them happy.

Deployment Preparation

Now, having a solution in mind the cross-functional team have to develop a road map to get the solution implemented.

Questions are:

  • How the organization can absorb the change?
  • How to get enough resources to get the new procedures implemented?
  • How to communicate the change during the complete deployment phase?

Reduction of Complexity

There is a risk of over-designing. For example, the organization intents to globalize its production of a product. Currently this is not the case. The team may design the product data structure taking this business strategy into account but does not realize it in the first implementation wave. Instead, the team will try to reduce complexity wherever possible and designs a road map with a stepwise approach without losing sight of the intended goal.

At the end of this process the project is set up by allocating resources, constructing budgets and schedules, hiring teams, and creating plans for pilots and launches. Now is the time to determine software platforms and partners key to the project’s success.

Communication Plan

Part of the project setup, and this is very important, is a detailed communication concept; people do not resist changes because they are not willing or lazy, but because they wish to maintain stability in a system of highly complex interactions. The communication must therefore ensure that members of the organization understand the change, see the benefits to the whole organization and to them directly and feel safe moving to the new practice.

The communication concept describes how these targets will be accomplished and summarizes the content of the required communication in introducing or redesigning end-to-end product lifecycle management:

  • It describes the added value of the change to the organization in clear and precise terms
  • It contains chapters about benefits, liabilities, and drawbacks of the change for each stakeholder. If there is a drawback for a stakeholder, then it explains the benefit for the organization justifying the drawback.
  • It lists the communication events planned in terms of target groups, content, goals, channels, and the required preparation effort.

Again, communication is key to get the buy in of all stakeholders.

Solution Deployment

And now after having the project setup the cross-functional team guides the organization through the transformation from current to new practices, to a country flowing with milk and honey. Each member of the cross-functional team guides his department in collaboration with the other team members ensuring a best fit for business strategy and end user needs.

This is not a journey most of the people will like. Very often people resist change. As you know, each of your users goes through a change process, in which their perception of competence first goes down. It depends on people's character and the extent of guidance and support accelerating the change.

Now we are at the end of our journey. In focusing to the design of supporting procedures instead of requesting more functionality of PLM systems we found a way, how to come to an improved user experience and optimized procedures, supporting, what the strategy demands and aiming to get more immediate ROI.

In implementing new procedures based on new schemes, managers and users will fall in love with PLM, again. I am sure.