People

Abstract

The skills needed by a company depend on the product it makes. With a particular product, a company will need people with the corresponding particular skills. Another company, with a different product, may not need people with those particular skills, but will need people with other skills.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

11.1 Introduction

It takes many people to develop and support a product throughout its lifecycle. Like most things in the PLM environment, the people who work in it are referred to by different names (Fig. 11.1).

Fig. 11.1

Some different names for people in the PLM environment

And what they do in the organisation also has many names (Fig. 11.2).

Fig. 11.2

Some different names for what people do in the PLM environment

More specifically, they may have a job title. This may say something about the type of work they do, or their level in the hierarchy, or their part of the organisation. Figure 11.3 shows some of the hundreds of names used to describe their jobs. These names may be used in different ways in different companies. What a person with a particular job title does in a particular company is likely to be different from what people with the same job title do in other companies.

Fig. 11.3

Job titles in the PLM environment

There are various names for the units in which people work (Fig. 11.4). These names may be used in different ways in different companies.

Fig. 11.4

Some different names for work organisations in the PLM environment

11.2 It’s a Jungle

From the above, it can be seen that it may not always be crystal clear, from a business card showing a job title and the name of an organisation, exactly what somebody does in a company.

As well as issues with naming, there are many other people-related issues in the PLM environment (Fig. 11.5).

Fig. 11.5

Common people-related issues

11.2.1 Different Products

The skills needed by a company depend on the product it makes. With a particular product, a company will need people with the corresponding particular skills. Another company, with a different product, may not need people with those particular skills, but will need people with other skills.

11.2.2 Different Companies

In some cases, people doing a particular job will be working within a company. In other cases, that particular job may have been outsourced, so the equivalent person is working in another company. Outside the company, many other organisations may be involved with the product (Fig. 11.6).

Fig. 11.6

Organisations where people can work outside the company

11.2.3 Different Departments

Different companies give their departments different names. In one company, there may be an Engineering Department. In another company, perhaps there won’t be a department called the Engineering Department, but there will be a department called the R&D Department that does exactly the same type of work. And a third company may have both an Engineering Department and an R&D Department.

As well as the name, the scope of a department’s activities may differ from one company to another. A person doing a particular job in one company may be working within a particular department, such as the Engineering Department. But, the person doing the same job in another company may be working in the Manufacturing Department.

11.2.4 Same Job, Different Title

Different companies give different names to the same job. In one company, someone doing a particular job may be called a Product Engineer. In other companies, people doing the same job may be called Product Developers, or Engineers, or Designers.

11.2.5 Same Title, Different Job

People with a particular job title may do very different things in different companies. For example, a company’s expectations of a Product Manager may be very different in different companies (Fig. 11.7).

Fig. 11.7

Different expectations of a Product Manager in different companies

11.2.6 Different Locations

Across the lifecycle, people may be at many different locations. They may be working on the company’s premises. They may be working for a supplier, or a partner, or they may even be the final customer of the company’s product.

11.2.7 Different Background

Some of the people in the lifecycle will have an engineering background, others will have other backgrounds such as accountancy, human resource management, marketing and sales. Some of the users of the product will be customers with completely different backgrounds to those of people in the company.

11.2.8 Different Computer Literacy

Many of the users will have different levels of computer literacy. Some will be writing state-of-the-art software. Others will need their secretary or assistant to interface with the computer.

11.2.9 Different Data Need

Depending on what they’re doing, different people in the lifecycle will have different product data usage and product data management needs. Some will create data, some will modify it, some will delete it. Others will only want to reference data, perhaps for management purposes.

11.2.10 Different HR Policies

Some of the people in the lifecycle will be working for a company with a Human Resource Department that has developed skills matrices, training plans and career paths. Other people in the lifecycle will be working in companies in which the Human Resource Department is only involved with people when they join the company and when they leave the company.

11.2.11 Different Metrics

Some of the people in the lifecycle will be working in organisations that are measuring performance on one set of parameters (such as Time To Market achievement). Other people in the lifecycle will be working in organisations that are measuring performance according to other metrics (such as scrap rate).

11.2.12 Different Bonus Systems

Some of the people in the lifecycle will be working in an organisation in which their bonus is mainly linked to the performance of the company. In another organisation, there may be no bonuses. In a third organisation, the bonuses may be closely linked to the performance of each individual.

11.2.13 Different Languages

Some of the people in the lifecycle will be working in organisations with one working language (such as Spanish or German), others in organisations with another working language (such as English).

11.2.14 Different Culture

Some of the people in the lifecycle will be working in organisations in which everyone is expected to say what they think. Others will be in organisations where everyone is expected to keep quiet and just do what their boss tells them to do.

Some of the people in the lifecycle will be working in organisations in which a meeting is held to give formal agreement to an issue that has already been agreed informally. Others will be in organisations in which a meeting is held to discuss an issue in detail from all possible viewpoints, after which a manager will take the decision alone.

11.2.15 Changing Population

Some of the people in the lifecycle will have been working with the company for decades, have wide experience and be able to carry out many activities at the same time. In another organisation, most people will be new to the company, have little experience, and only be able to carry out one or perhaps two activities at the same time.

11.2.16 Different Roles

Independently of their job title, or their job description, people may play several roles. One person may, for example, have the roles of Process Owner, Product Developer, Document Owner and Document Creator for some documents, and Document Approver for other documents. Another person may have the roles of Process Owner and Change Reviewer.

11.2.17 Different Sins

People in the lifecycle are humans, not machines. They aren’t always 100% rational and cooperative. Sometimes their individual needs and objectives play a larger part in their decisions and behaviour than those of the company. In some companies, if they want promotion, it may be important to do something simple that shows short-term success. In others, it may be important to do something complex that will only show success after many years. People in the lifecycle, like other humans, may suffer from envy, gluttony, greed, lust, pride, sloth, and wrath.

11.3 Response to PLM

Many people in a company will understand why PLM is important. They’ll be able to see where it can help, and what benefits it can bring.

Unfortunately for those wanting to implement or improve PLM, there are many people who won’t understand the need for PLM. Among those who won’t understand will be many whose support is essential to the success of a long-term, cross-functional initiative that will have significant effects on company performance and organisation. From their position in the company, PLM may seem to have a low priority, or even be unnecessary.

PLM is necessary, but many people will initially fail to understand this simple message. They won’t react to it in the right way. They’ll slow down the speed at which the company can obtain the potential benefits. Many of the people whose support is necessary, and who control the resources needed for success, just won’t understand. Their level of understanding will be low and it will take a long, long time to get it to a level where they'll become supportive. Yet it’s not possible to implement PLM without support throughout the company. It’s not possible to go it alone. PLM is holistic and cross-functional. It’s as much an organisational approach as a technological approach, and it needs positive involvement from people at many levels in many functions.

Those who may have difficulty in understanding the need for PLM could include the CEO, top managers, product development managers, product support managers, engineering managers, quality managers, human resource managers and IS professionals. Figure 11.8 shows possible reactions to talk of PLM.

Fig. 11.8

Different reactions to PLM

11.4 PLM at C-Level

11.4.1 The CEO

PLM is so important to the future of a company that the PLM Initiative needs to be led by the Chief Executive Officer (CEO). However, CEOs have other things to think about than process mapping and the number of duplicate parts. Among other things, the CEO has to set company directions, objectives, strategies, organisational structures, plans and budgets, lead the company, act as a figurehead for employees, shareholders and customers, and make sure that sales exceed costs. So, while it’s important to get the CEO to lead the PLM initiative, it shouldn’t be expected that the CEO will get involved in the details. And, as the CEO may have little time available for the PLM initiative, it’s important that whatever time is available should be focused on activities where the CEO adds most value.

With the CEO’s leadership, and the CEO setting coherent targets for PLM, many other managers will also be supportive. Good ways to bring the PLM Initiative to the attention of the CEO include: demonstrating successful use of PLM by a competitor or customer; pointing out articles in the business press; and starting discussions with other high-level managers, such as the CFO.

Another way to get the attention of the CEO is to underline the benefits of PLM for a CEO. With PLM, the CEO has visibility over the products and is in control. As a result, the CEO can develop strategies based on a better understanding of the products. The CEO can make decisions based on reality, rather than guesses. It’s easier to take account of potential risks. Better control over the lifecycle provides better assurance about environmental impacts. Costs can be reduced as activities that don’t add enough value become more visible.

11.4.2 The CFO

With PLM, the Chief Financial Officer (CFO) can see the real financial figures for a product across its lifecycle, so knows precisely how much it’s cost and earned. Better estimates can be made for the real financial figures related to developing and supporting each product in the future. With uncertainties reduced, more reliable financial projections can be made.

11.4.3 The CIO

PLM provides the Chief Information Officer (CIO) the opportunity to carry out a wide range of necessary activities to clean up the company’s product-related processes and data. These will solve many everyday problems that currently occupy the time of IS professionals. This will lead to a reduction in IS costs and a redirection of IS effort to activities that add more value.

11.4.4 The CPO

PLM provides the Chief Product Officer (CPO), who is responsible for all products, with visibility of the products. With PLM, the exact status of every part, and the exact status and structure of every product, is known. The CPO can take control, both during product development and at later stages in the product lifecycle. The risks associated with development, support and retirement of products can be better understood and managed. PLM helps the CPO get an integrated view over all product development projects. PLM enables secure collaboration with design chain and supply chain partners wherever they’re located. The CPO can develop and implement strategies for faster development and introduction of new products, and for better support of products across their lifecycles. Unwanted product-related costs, resulting from rework and scrap, warranty and liability claims, and returns and recalls will be reduced, then eliminated.

11.5 PLM and Managers

11.5.1 Business Planners

Full implementation of PLM will take many years and affect many functions and people. A PLM Initiative will cost a lot of money, and should bring a lot of benefits. With these characteristics, it will have to be included in company budgets and investment plans. Anyone hoping to implement PLM had better get some support from the people who look after the business plans. This may not be easy.

In theory, the people looking after business plans may just be meant to look after the figures, and not take decisions on the content of the company’s various projects. Usually though, they have ways of influencing decisions on proposed activities. They may have little hands-on experience of what happens throughout the product lifecycle, so it’s unlikely that they’ll instinctively support PLM. It may well be that their only job in the company will have been a staff job. They may have little real experience of what happens in the product lifecycle, who the customers are, what the products are, or the processes that a product goes through from its conception to its use by a customer. Instead, they may have a spread-sheet view of the company. Here are the costs, here are the sales, add some market share figures, some market growth, some tax rates, and look! By year 3, we will have increased our profits. If we were now to merge our figures with those of Company Y, rationalise and take out more costs, then we would increase our profits even more. Let’s acquire Company Y.

It may be difficult to get such people to understand the difficulties involved in doing something such as bringing a new product to market, or to understand the effects of something as difficult as defining the benefits of “better control of product data”. They may be head-in-the-clouds planners, rather than feet-on-the-ground doers. However, getting them on board will ensure that the PLM Initiative is presented in a favourable light.

11.5.2 Marketing Managers

Managers running a functional department, such as Marketing, Engineering or Manufacturing, live in the real world, and are expected to produce instant results. As a result, they may not show much interest in benefits of PLM that may appear in two or three years time. By that time, perhaps, they’ll have moved on to another position or company. They’re often so busy working at day-to-day problems, that they can’t get involved in long-term issues. Their primary concern is to meet the short-term targets set for them by the CEO. As a result, it’s important to demonstrate to them the short-term benefits of PLM.

Marketing managers will react positively to the CEO’s interest in PLM. They’ll find subjects of interest for their future. PLM will provide them a new reason to identify more finely segmented niche markets and imagine corresponding products. Marketing can claim to be listening to the voice of the customer and, “like the Japanese”, customising the product line. At the same time, they’ll grumble about the time it takes engineers to develop the new products, and the inability of the sales force to actually sell the products. PLM can help Marketing Managers make sure better and faster responses are made to Requests For Proposal, material from successful proposals is re-used, and proposals are priced realistically and competitively. It can help get better feedback about product use. With all the product data and customer specification information available, it will be much easier for Marketing to evaluate future opportunities.

However, Marketing is already stretched by the CEO’s demands for faster, deeper and wider market penetration. So Marketing managers won’t be able to offer any resources to work on a PLM initiative.

11.5.3 Manufacturing Managers

Manufacturing managers will react positively to the CEO’s interest in PLM. But they’ll claim they’ve been set the objectives of reducing costs, improving productivity and maintaining Six Sigma quality levels, and they can’t see how these targets can be achieved by PLM. After all, they’ll say, PLM should be the responsibility of the design engineers who create the products. In private, of course, the Manufacturing managers will agree that anything that gives some control over design engineers and product data must be a good thing. PLM can help Manufacturing operate more effectively. Manufacturing personnel can be involved increasingly in product development activities, advising against difficult to manufacture designs, reducing scrap and rework.

The Manufacturing organisation is flexible, fast and working flat out to meet the CEO’s demands for increased product diversity yet higher production rates. As a result, Manufacturing managers won’t be able to offer any resources to work on a PLM initiative.

11.5.4 Engineering Managers

Engineering managers know only too well how difficult it is to develop new products in response to constantly changing requirements. They’re used to constant changes from Marketing and Manufacturing, and try to improve their responsiveness. Only too often though, they find that in spite of all their efforts, they finish up with the same results of late delivery and poor quality. They know that sometimes they aren’t in complete control of the projects entrusted to them. But there are so many unforeseeable external influences. However, as they look around, they see the potential for improving the situation. They see time wasted as drawings are manually transported from one activity to another. They see time wasted as information waits to be signed-off. They see their engineers going into far too much detail where it’s not needed, and not enough detail where it’s needed. They see an unnecessarily high number of signatures holding progress back. They see Marketing personnel wasting their time going far too deep into technical details. They see Manufacturing personnel doing nothing as they wait for information. They see support engineers wasting time trying to use technical manuals that are out-of-date. They’re aware of the scrap, the personnel time that’s wasted, the possibilities of reducing the product development and support cycles. They know that late market entry is going to cost the company a lot of money. They understand as well as everyone else that the time to reduce product costs is during the development phase, when most of the product costs are defined. They understand that it’s much cheaper to reuse, or slightly modify, an existing design than to start a new design from scratch. Like everyone else, they know that it’s important that engineering changes are controlled and that exact product configurations are maintained. Unlike everyone else though, they’re responsible for getting these things done, and in practice they know it’s not as easy as it looks. Most Engineering managers will welcome PLM.

However, all Engineering resources are booked on high priority projects to get new products to market quickly. And the Engineering budget has been spent on new applications. As a result, Engineering managers won’t be able to offer any resources to work on a PLM initiative.

11.5.5 Product Support Managers

Product support managers are at the end of the Marketing-Design-Manufacturing-Sales-Support chain in a company. They’re faced with many problems generated earlier in the product lifecycle. For example, people in Field Service often have no way of knowing what’s been configured in a particular product that they’re required to service. Design engineers might send them an “as-designed” configuration, but all sorts of things can have changed since that was produced. Design Engineering may change components but not tell anyone. Some of the sub-assemblies may be purchased, and have different components compared to the initial in-house design. Manufacturing might also make changes. At the Assembly and Test stages, where there’s always a lot of pressure to get the product out the door, additional changes may be made but not get properly documented. Another example is that when the Installation teams of, for example, machinery makers, go out to the installation site, they often find that a lot of the parts are missing or don’t fit. Between the Marketing, Engineering, Manufacturing and Logistics Departments of the numerous organisations in the supply chain, there may be all sorts of misunderstandings, and the end result is that installation isn’t completed on time. Most product support managers will welcome PLM, and will provide valuable input to the PLM Initiative.

However, everybody in the Service organisation is already working overtime to provide essential support to customers. Product Support Managers won’t be able to offer any resources to work on a PLM initiative.

11.5.6 PLM Managers

For most PLM Managers in industry, the current focus is to manage everyday operations successfully. Often this isn’t as easy as it looks. In many cases, there will have been implementation problems in the past, and these are frequently carried forward rather than solved. However, the budget for them has usually been spent in the past. These legacy problems can be particularly difficult to solve without a budget. They complicate both the management of everyday PLM operations and the planning of future PLM operations.

Many PLM Managers have implemented the foundations of their PLM solutions, and would now like to extend the reach of PLM in their companies. Step-wise implementation is often the easiest way for a PLM Manager to extend the coverage of PLM in the company. Often a PLM implementation will start with “Data Management and Document Management”. From this basis the PLM Manager can extend PLM to many areas such as Maintenance, Repair and Overhaul; Portfolio Management; or implementation of a phase/gate development methodology.

Most PLM Managers would like to have more financial and human resources so that they can make faster progress with their PLM implementations. However, they’re often faced with pressures to reduce costs and headcount. Business executives in their companies often assume that, if the current implementation is running, it could run just as well with slightly reduced resources.

Everybody in the PLM organisation is already working overtime to maintain current levels of support. The PLM Manager won’t be able to offer any resources to work on a new PLM initiative.

11.6 PLM and Others

11.6.1 The Workers

Many of the workers in the lifecycle are highly-skilled, well-trained, under-utilised, under-respected and under-paid. For years, they do their job well and see little reward, whereas other people rise rapidly up the company hierarchy. As functional organisations give people little chance to expand their skills horizontally by working in other departments, many workers eventually become isolated, highly focused on their own skills, and somewhat resentful of other departments. If they aren’t in Marketing, they see Marketing as over-indulged and over-paid in view of the poor product specifications it produces. If they aren’t in Engineering, they see engineers as uncommunicative impractical theorists living in an ivory tower. If they aren’t in Manufacturing, they look down on manufacturing workers, often immigrants, who are incapable of making even the simplest product properly. If they aren’t in F&A, they don’t like the bean-counters in the Finance Department, who understand neither products nor processes, but often finish up at the top of the company hierarchy. If they aren’t in IS, they complain that the computer systems are too slow and don’t work properly. They say that their suggestions for new applications are always ignored. Across the product lifecycle, the workers complain about bureaucracy and form-filling. They feel unable to use their talents and experience to the full. They’ll tell you that 10 years ago it was all different. Then they could work better. For example, when product engineers had an idea, they would talk to a colleague in Manufacturing, make a prototype, put it in their briefcase, and go off to see a potential customer. The customer would give some feedback, and soon there would be a new product bringing in sales of a few million dollars each year. But now, it’s different. Now, it’s all paper and plans and gates and meetings and reviews and milestones and spreadsheets and job descriptions. And no-one can just go and see a customer with an idea for a new product.

11.6.2 Product Engineers

The product engineers hear a mixture of messages. Managers keep telling them to be closer to customers, and develop more and better products and services faster. Instinctively, they feel that would take more time and money, but they’re told to reduce costs, improve quality and reduce lead times. At the same time, they’re expected to fill in all the forms, and to meet the product development target dates in the company plan. As the individual requirements of the different requests are often different, or even contradictory, product engineers have to walk a fine tightrope. They focus on what they think is most important, and most likely to be used by management to measure their performance. They look for ways to play down the other issues, or to pass them on to others. Probably there will be one or two key products that must be produced on-time and to specification. Most of the effort will go on these. For other products, Marketing and customers will be blamed for not providing full specifications, and for continually changing the specifications. Manufacturing will be blamed for not being able to produce the products that have been defined. If all else fails, the target of reducing lead times can be achieved by releasing unfinished work to Manufacturing. Of course, this will come back later in the form of rework, but since no-one will have set a target for reduction of engineering changes, hopefully this will go unnoticed by management. Sometimes, Manufacturing will also be under pressure, and won’t have time to fix the problems. Then the customers will complain about the problems. That will mean more work for the support engineers. Of course, they’ll complain loudly, but actually they’ll be happy to be paid overtime for the extra work.

Product Engineers, with all sorts of daily problems to worry about, may not be very interested in whether or not PLM is introduced. They may understand the benefits it can bring, but doubt that it will ever work as proposed, help them in their daily work, or be implemented before they retire. And overloaded with daily problems, they won’t be able to work on a PLM Initiative.

11.6.3 Application Vendors

A Product Development Director told me about a visit he’d received from a new salesperson from an organisation that sells application software for the PLM environment. He’d banned visits from the previous sales executive after being button-holed outside his home one morning. He’d been assured that the new person would respect his private life. He told me how the new salesperson had said that this flexible Web-based PLM app is a platform for creating and managing design content across an outsourced supply chain enabling today’s manufacturers to get innovative new products to market faster. Native applications for product development create the product record which is stored in a centralised or distributed vault. The digital model, including options, in native or STEP-compliant format, can be viewed by team members from purchasing and marketing in a BOM-like structure from an advanced product configurator. Digital manufacturing is enabled by flexible interoperability across multiple platforms and shrink-wrapped integrations to all leading state-of-the-art apps and legacy systems. Shopfloor workers on multiple sites can visualise toolpaths prior to cutting metal. Service workers can navigate lightweight data models over wireless environments. The modular product architecture and data model offers customers all necessary functionality out-of-the-box tailored to the requirements of different industry sectors. SOAP, .NET, Linux, the Cloud and Web 2.0 are supported. Versions are available in Kanji, Korean and Mandarin. There’s all the application functionality any company needs (Fig. 11.9).

Fig. 11.9

Application functionality

The Product Development Director gave me some of his thoughts about PLM application vendors (Fig. 11.10).

Fig. 11.10

Some thoughts about PLM application vendors

11.6.4 Service Providers

The Product Development Director told me about the proposals he’d received from service providers wanting to help him (Fig. 11.11).

Fig. 11.11

Proposals from service providers

11.7 Nobody is an Island

No man, or woman, is an island (Fig. 11.12), isolated from the rest of the company. People are closely related with other PLM components. They are also influenced by other forces within the company, and outside the company.

Fig. 11.12

No man or woman is an island

For example, a new manager may be hired to improve performance in a particular department. To change performance they’re likely to change working methods. They may hire people who they have previously worked with successfully in other companies. They may bring in equipment used in their previous companies. Old-timers in the company may not like all these changes, and may decide to leave. The new methods may call for new applications. The new methods will probably use new documents. The new methods will be reflected in changes to processes. Process documentation will be changed to reflect the changed processes. There’ll be training sessions to make sure everyone understands the new methods. New procedures will be written for the new equipment. New people will be hired to operate it. Job descriptions will be changed to correspond to the new situation. The new manager will implement new performance measures to show that the new methods are leading to better performance. The company may then acquire a company on another continent to help improve business there. The organisational structure will be changed accordingly. In the resulting structure, the new manager is one level further from the top than before. Unhappy about this, and discussing it with a colleague from a previous company, the new manager is offered a more important job in their previous company. And takes the job, leaving the new company to cope with all the changes.

11.8 The Challenges

The specific challenges related to human resources that a particular company faces could come from several sources (Fig. 11.13).

Fig. 11.13

Potential people-related challenges for a company

11.9 The Way Forward

The issues described in this chapter all relate to people, but they can’t be solved in isolation from the other components of PLM. Their solution, within the PLM environment, is addressed in part 3 of this book.