Traditional Pre-PLM Environment

Abstract

Previous chapters have addressed the resources in the PLM environment and described some of the issues related to their management. The environment in which products are developed, produced, used and supported is complex, stressful and competitive. Not surprisingly, simple everyday things can easily get ignored or lost in this environment. Many problems can occur down in the details of the humdrum tasks that the company’s workers carry out every day. Such problems may not be of interest, or appear to be of concern, to managers who are looking at more strategic topics, and are expected to produce results at a higher level. However, it’s often a combination of these issues at a low level that leads to the problems with products that eventually become visible at a higher level.

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.

16.1 Introduction

Previous chapters have addressed the resources in the PLM environment and described some of the issues related to their management. The environment in which products are developed, produced, used and supported is complex, stressful and competitive. Not surprisingly, simple everyday things can easily get ignored or lost in this environment. Many problems can occur down in the details of the humdrum tasks that the company’s workers carry out every day. Such problems may not be of interest, or appear to be of concern, to managers who are looking at more strategic topics, and are expected to produce results at a higher level. However, it’s often a combination of these issues at a low level that leads to the problems with products that eventually become visible at a higher level.

16.2 Serial Workflow

In the traditional Pre-PLM environment, there are many activities in the lifecycle of a typical product. It might start life in the marketing function, and then go through conceptual design, engineering design and analysis, testing, detailed design, manufacturing engineering, process planning, tooling, NC programming, production planning, purchasing, machining, assembly, testing, packaging, technical publishing, installation and maintenance.

It can take a long time for a new product to go through the Marketing, Engineering, Manufacturing, Sales, Support chain in a departmentally-organised company. First of all, Marketing has an idea. This doesn’t take long because the people in Marketing are very bright, and they want to get the product on the market before the competitors. However, when they talk to Engineering, they are told Engineering is already over-burdened with far too many projects. Engineering can’t start work on yet another new product!

When Engineering does have some free time, it realises it didn’t quite understand Marketing’s idea. Engineering asks for more details, but the Marketing people are at their East Asia Conference and won’t be back for 2 weeks. When they do come back, the Engineering Manager is away. The Engineering project leader who has been assigned to the idea discusses it with the people in Marketing. A week later he goes back to Marketing with some suggested changes. Marketing has also thought of some changes, and the engineers go away to see if they can develop something from the new ideas. When they’ve defined it down to the last detail, they pass it over to Manufacturing. Manufacturing can’t produce the product the way it’s been designed, and asks Engineering to change it. The changes will have such an effect that Engineering decides to check with Marketing. When they do, they find that in the meantime, Marketing has realised that some additional functions are needed. The engineers go away to see if they can develop the new idea. This iterative process continues until the departments eventually accept that the product can be released to the market. A prototype is installed for a customer. The installation engineer claims that installation time is too long, and proposes some changes. The customer tells Marketing the product is too expensive, and anyway, doesn’t behave the way it should.

Although the above approach may appear nonsensical, there are good reasons for organising the company in departments (Fig. 16.1). However, the result of this type of company structure is often that the product gets to market late, is too expensive, and doesn’t meet customer requirements.

Fig. 16.1

Some advantages of a departmental organisation

One reason it takes so long to get the product to market is that the departments work in series. Marketing takes 2 weeks to do its job, then Engineering takes 7 weeks, then back to Marketing for 1 week. Then on to Engineering for 3 weeks, then on to Manufacturing for 2 weeks, then back to Engineering for 2 weeks. Then back to Marketing for 1 week, then on to Engineering for 1 week, then on to Manufacturing for 3 weeks. Then back to Engineering for 1 week, then on to Manufacturing for 2 weeks. 2 + 7 + 1 + 3 + 2 + 2 + 1 + 1 + 3 + 1 + 2 = 25 weeks (Fig. 16.2).

Fig. 16.2

To and fro for 25 weeks

Then Service takes a week, and the customer takes 4 weeks to do a 1-day test. Then, Service takes another week to write its report. Engineering has to make a change which takes another 2 weeks. Marketing takes a week to review the change. The change takes 3 weeks to go through Manufacturing. 1 + 4 + 1 + 2 + 1 + 3 = 12 weeks (Fig. 16.3).

Fig. 16.3

To and fro for another 12 weeks

Five weeks in Marketing, 16 in Engineering, 10 in Manufacturing and 2 in Service, and the whole thing is stretched out over 37 weeks.

One reason the product is too expensive is that too much time is used up in the process. Another reason is that, with so many false starts, the real objective may get lost. If an error gets into the design, it’s often not clear who is responsible for getting it out. Marketing may look at a problem and decide it’s a problem for Engineering to resolve. Engineering may look at the problem and decide it’s a problem for Marketing to resolve. Manufacturing may look at the problem and decide, like Marketing, that it’s a problem for Engineering to resolve. Support may look at the problem, and see the solution, but not tell anyone, on the assumption that someone else has seen it as well. Everyone spends time looking at the problem, but no-one feels directly responsible, so no-one solves it.

Working in series increases costs. During the 11 weeks out of the first 25 weeks that the product is in Marketing and Manufacturing, Engineering isn’t working on it. Assume that the engineers aren’t working on another product. What happens to their wage costs during these 11 weeks? They are added to the product cost. The product cost (and price) is increased to include 11 weeks of non-value adding Engineering time. Time is money. The longer a product stays in the product development phase, the more costs it picks up.

One reason the product doesn’t meet customer requirements is that too many decisions are taken inside the departments without any reference to the customer. Errors creep in as the product description is sent to and fro between departments. Each department uses the vocabulary best suited to its activities. It has difficulty communicating with the other departments which have their own vocabularies. Errors and other confusion creep in through misunderstanding of the other departments’ jargon.

16.3 Departmental Environment

Serial product workflow through the departments is just one of the problems of the departmental organisation. Some other barriers are shown in Fig. 16.4. All these barriers slow down the flow of business.

Fig. 16.4

Some problems of the department organisation

Product development and support is carried out in a conflictual atmosphere with individual departments reacting to problems. Changes, scrap, delays, work-arounds, waste, and rework are seen as normal behaviour. Management focuses on supervising individuals. Fire-fighting is necessary and rewarded. Internal bureaucracy, back-stabbing, turf battles, and cosmetic changes to the organisation chart add problems and unnecessary operations on an ongoing basis. The only thing that seems to keep such organisations together is their fear of the common enemy, the customers.

People in such companies don’t agree about what they are doing. At one extreme, forward-thinking engineers develop products that customers may not want. At the other extreme, salespeople sell products that engineering can’t develop. And Marketing proposes products that it thinks customers want, but they don’t actually buy. Service engineers don’t get the information to enable them to track product revisions. As a result, they can’t control the timing or cost of repairs and upgrades. Management can’t assess the business impact of a change to a product because no-one knows what’s really going on. In some companies, management gets so frustrated that it sets up a parallel organisation outside the company to do the job better. And from there, it’s only one step to acquiring and operating a separate company focused only on product development.

Marketing’s estimate of the cost of a product development project may differ from R&D’s, and from that made in F&A. After talking to F&A, Marketing may have had discussions with R&D and changed its customer segments and estimates. Marketing may propose products that R&D can’t develop. Someone in R&D may have said that it would be good to develop them, but not meant to imply that they could be developed. Design engineers may send manufacturing engineers designs that can’t be produced. The design goes back for rework. Engineering changes costing thousands of dollars result.

The Engineering/Marketing, Engineering/Finance and Engineering/Field frontiers are also sources of problems. Sales people offer customised versions without knowing if it will be possible to produce them profitably. Design engineers are unable to get cost information from the Finance function. Design engineers don’t receive field reports about product performance in the field, and design existing problems into new products. Maintenance requirements aren’t taken into account during conceptual design. This isn’t surprising since “Support” may not even appear on the organisation chart. The traditional product lifecycle doesn’t encourage users in different functions to communicate freely and prevent these problems.

16.4 Confused Modelling Environment

The environment in which planning and modelling for the future PLM environment takes place is likely to be conflictual. People from functional departments may only be interested in selecting an application that reduces the workload in their function. They would like to see this new application available immediately and without any effort on their part. Often they won’t be interested in the overall information and process architectures. They won’t be interested in the procedure that’s taken to develop a better overall approach to managing products across the lifecycle.

On the other hand, some of the other people involved in modelling the environment will have a different, if not opposite, approach. They’ll be specialists in developing the logical design of the overall system and of the database. They may well have no interest at all in the information itself or in its use. They may have little understanding of the real issues involved in developing and supporting products, and, following a particular methodology, will generate vast volumes of superfluous data that obscure the most important needs.

Parallel to the different behaviour of these two groups of people may well be a disagreement over the best way to develop and implement a new application. People looking for a quick solution to their specific functional problems will appreciate a prototyping approach. This is an iterative approach that accepts that user requirements can’t be clearly defined initially and, in any case, will change as the users get to know the new application. A “prototype” is built to meet the user’s apparent requirements. Experience of its use provides input for the development of a more advanced prototype. Unfortunately the result of this approach is often that once a reasonably good prototype has been developed it’s declared to be the solution, and development is stopped. Users are left with a half-baked prototype instead of a fully-fledged solution.

However, another group of people, the IS specialists, may reject the prototyping approach. They may prefer the waterfall approach of feasibility study, requirements analysis, system design, detailed design, programming, testing, and use. Unfortunately, this approach is often very time-consuming, yet doesn’t produce the results required by the users. When it’s “complete”, an additional maintenance phase is started. In this phase, which becomes a major activity, the application is modified to meet user requirements.

A third group of people will prefer the use of a more business-oriented approach to modelling. They want to be sure that the result meets the major business requirements. They want to give priority to these important requirements, rather than to less important issues. Typical approaches of this type look at critical success factors, the value chain, and competitive advantage. In the first of these, effort is focused on identifying the factors that are essential to meeting business goals. The underlying methodology is based on the experience that, if management focuses on a limited number of critical issues that are essential to business success, their chances of success are higher than if they address less focussed goals. On this basis, if it’s decided to focus only on lead time reduction and product cost reduction, there will be more chance of attaining these goals than if a larger and less clearly defined set of goals is chosen. Value chain theory recognises that a company’s activities are made up of a set of activities, such as sales, logistics, production, and service, each of which adds value to the company’s product. By understanding where the company is most effective at adding value and focusing resources on such areas, the company can improve its market position.

16.5 Product Data Issues

In the typical company with large numbers of people involved in the product lifecycle, there are usually many issues with product data. People often waste a lot of time looking for product data. Sometimes they are unable to find the data they need. If they can find it, it may not correspond to the actual state of the product. For example, a facility drawing may not correspond to the physical facility layout. Developers may be unable to rapidly access a particular design among the mass of existing designs. To find specific information, they may have to search through many paper and electronic files. They lose valuable time. Studies show that design engineers spend up to 80% of their time on administrative and information retrieval activities. They develop new designs which may be almost identical to existing designs. As a result, unnecessary additional costs are generated as the new designs are taken through the various activities necessary for manufacture, and then supported during use.

As more and more data is generated on computer systems, it becomes more and more difficult to track the location of data, to prevent unauthorised access and to maintain up-to-date product configurations. In the second decade of the twenty-first century, companies may not yet have yottabytes (10²⁴ bytes) of data. However, they may have terabytes, petabytes, exabytes or even zettabytes (10²¹ bytes) of data.

Companies have thousands, or even millions, of drawings. The 3D CAD part models may take up several gigabytes. One company calculated that it needed 250,000 pages of paper to describe a new product, and that, on average, each of these was reproduced 30 times. Printed on paper, the technical documentation for a helicopter weighs more than the helicopter. That for a submarine exceeds 100,000 drawings, of ten different sizes, weighing more than 5 tons.

In 2001, a major outsourcing contract for technical document services was agreed by Rolls-Royce Plc, a global company providing power for land, sea and air. Annually, Rolls-Royce plc produced 96 million copies, 20 million printed drawings, microfilms and geometric designs, and archived over 30 million drawings. In 2004, UGS PLM Solutions announced its PLM solution at MTU Aero Engines would cover the management of more than 10 million documents, elements and objects accessed by more than 5,000 users. In 2010, Imaginestics, LLC announced that it had been awarded a contract by the US Defense Logistics Agency (DLA), which is tasked with providing logistical support for US military forces. Associated with the nearly five million items the DLA manages are approximately 107 million sheet images of engineering data, the majority of which are in two-dimensional raster format.

Data entry is often poorly controlled. it’s easy to type the wrong character or copy the wrong file. Data is easily lost and may be impossible to retrieve. Then it’s re-created and more errors are introduced. The wrong product goes to a customer. Product configuration data isn’t up-to-date. When a defective part is found in the field, many more products than necessary have to be recalled. Design history isn’t maintained, so it’s impossible to draw on previous experience.

Data is often spread across several applications. Due to gaps between incompatible applications, data is transferred manually between the applications, and errors occur. They have to be corrected, and their correction has to be managed. This costs time and money. An error slips through and isn’t discovered for several weeks or even years. Correcting it leads to months of delay. Part descriptions and Bills of Materials developed with a CAD application may be manually transferred to an ERP application in a computer that’s not linked to the CAD computer. The Manufacturing Bill of Materials may be different from the Engineering Bill of Materials. The CAD and ERP applications may be the responsibility of different departments or organisations or companies. The change processes in the two organisations may be different and out-of-step. At a particular time, a given change may have been made in one application, but not in the other. As a result, not all users will have immediate access to the most up-to-date information. Thousands of dollars are wasted when Manufacturing works on the wrong version of a design for several weeks.

Several copies of the information describing the same part may be maintained. Often nobody knows which is the master copy. When a change is needed, it may be that some copies aren’t changed, some users aren’t informed, and some downstream functions aren’t alerted. Old, unwanted revisions of parts are produced, while the new, required versions are ignored. When there isn’t an agreed master version of a particular item of information, and no agreed owner, all users of the information will behave as if they are the owners. Each user will define the item to suit their particular requirements. All the definitions may be different. Such wasted effort leads to confusion when information is transferred between users.

Increasingly, companies expect suppliers to design and produce complete assemblies containing many parts. Attempts to work closely with a supplier in the design phase will be hindered if it takes several days (a month in the case of one aircraft manufacturer) to transfer a drawing from one company to another. And unless the company’s after-sales engineers have access to information on individual parts of the supplier’s assembly, problems can arise in the field.

Project and resource management tools may not be linked to the design information. Unintended overlap in data and workflow results, wasting time and money. Any attempt to save time, by running the various phases of a project in parallel, leads to chaos. As a result, the phases are run in serial, lengthening project cycles. Rules and procedures are difficult to enforce. Design rules may be ignored because there’s no way to enforce them. Project planning exercises can’t draw on real data from the past, but are based on over-optimistic estimates. Project managers find it difficult to keep up-to-date with the exact progress of work. As a result, they are unable to address slippage and other problems as soon as these occur.

Component costs may be difficult to estimate. Often there’s no relevant data available to provide a basis for calculation. When some data is found, it’s seen to be inaccurate or outdated. When data from different sources is brought together, it may conflict. Or it may not make sense.

Engineering changes are poorly co-ordinated, with the result that unnecessary changes may be introduced. Design cycles are longer than necessary, and unreleased versions of data are acquired by manufacturing, sales and support, causing confusion and waste. The time taken for raising, approving and implementing changes becomes much longer than necessary. The change process may take days, weeks or even months, whereas the actual processing time may be only minutes or hours. In large companies, it costs thousands of dollars to process an engineering change.

Engineering change control systems are often bureaucratic, paper-intensive, complex and slow. A central engineering services group may have the responsibility, but not the tools, to push the changes through as quickly as possible. Many departments may be involved (one manufacturer found that, depending on the change, up to 16 departments were involved). As a result, it may take several months, and fifty or more different documents, to get a proposed change approved and incorporated into the product design. Even when a change has been agreed and announced, many months may go by before the corresponding documentation gets to the field.

As the management and change process appears as an inefficient and time-consuming overhead, some people will try to avoid it. For some information, there may not be a formal change control process. Some companies even have a formal ISO 9000-compliant change process, but management doesn’t expect anyone to use it. Minor modifications to products and drawings are made without informing anyone. Components will be substituted in end products without corresponding changes being made to test routines. People will fail to maintain the trace of the exact ingredients in ever-smaller batches of products. Nobody will notice until something goes wrong or another change has to be made. Then, unnecessary effort will be needed to find out where the problem comes from. Additional support staff will be employed to try to prevent further problems.

Informal communications are developed between departments to cope with the lack of suitable formal communications. Few records will be kept of this type of transfer and, in the absence of a particular individual, it may be impossible to find any trace of important information.

People wait hours, even weeks, for a given piece of information. The person who should sign off a design is called away for a few hours. Work is held up because nobody knows who else has the authority to sign off. When people do receive information, they aren’t sure if they've received the correct version. Sometimes they just want to make a simple request for information from an application, in the same company, that “belongs” to another department. And have to wait several days to get it.

Configuration control breaks down. Configuration documentation no longer corresponds to the actual product. Unexplained differences appear between as-designed, as-planned and as-built Bills of Materials. Increased scrap, rework and stock result. Incomplete products are assembled and delivered. Field problems are difficult to resolve. Inefficiencies occur in spare parts management. New versions of applications are introduced without sufficient care being taken to ensure that, for example, data created with earlier versions is still usable. Software is insufficiently documented. Modifications are made to software without appropriate change control.

Users manuals may be difficult to understand, apparently written by people who haven’t used or seen the product. Translated into other languages by people with little knowledge of the product, or its associated vocabulary, they’re even more difficult to understand.

Technical manuals become outdated, yet aren’t updated. Logistics support data gets out of control. Inadequately documented configurations become difficult to maintain. Spares replenishment becomes inaccurate. Customers have to immobilise products while efforts are made to identify correct replacement parts. When the right part arrives, the right handling equipment and maintenance tools aren’t in place. Information about problems with product use isn’t fed back to developers, with the result that they design the same problems into the next generation of products.

Product development and support in a whole range of manufacturing industries is delayed for a myriad of apparently random and minor, but cumulatively significant reasons. Product and service quality is erratic despite vast investments in technology and Quality programs, and significant expenditure of management time.

16.6 Uncertain Environment

Customer expectations are rising. With so many manufacturers proposing products, why should a customer settle for a second-rate product? Customer demands imply better products and services, a wider product range, customisation and market niches. But there’s also increasing consumer resistance to price increases. At the same time, there are technology issues to be faced, including the effect of the increasing amount of electronics and software in products, the possibilities offered by widespread communication networks, and the rapidly decreasing cost of computer power. Multi-technologies in the product and the manufacturing process make things more complex. In fast-evolving technological environments, products become obsolete sooner. The reduced time between product launch and product retirement erodes sales revenues. Since this phenomenon depends on factors beyond a company’s control, the only way it can lengthen a product’s life is to get it to the market earlier.

Business is becoming more complex. There’s more and more uncertainty in developing new products. The price of failure is high. Why take the risk? Why risk billions of dollars developing a new commercial aeroplane when the potential customers may decide, at some unknown date in the future, not to take up their options, or may not, by that time, even exist?

Uncertainty may come from a global marketplace, a wider range of customers, shorter product life cycles and more competition. This means greater uncertainty about the life of products and investment decisions associated with them. There’s growing competitive and legislative pressure. Legislation such as that concerned with product liability, deregulation, privatisation, health, safety and the environment places additional strains on business. it’s difficult to know what the effects will be. That can make it difficult to develop long-term plans.

16.7 Piecemeal Improvements

Departmental organisations are built on the premise of being excellent at a limited number of activities. If they’re excellent, how can they improve? Are there things they’re doing wrong? But they’re doing things the way they’ve always done them. If things were good enough for their predecessors who got the company going, it’s difficult to justify changing them.

If performance improvements are really needed in a departmental organisation they are, naturally, implemented on a departmental basis. Each department works on its own improvement projects. Each department is responsible for its own performance, so it does what it can to improve itself. There would be no point in trying to improve performance in another department. First, they wouldn’t want your advice, and second, you wouldn’t be rewarded for it.

So each department does its “piecemeal implementation”. The three main characteristics of this appear to be that it mustn’t affect the other departments, it must involve IS applications because everyone knows they improve everything, and it must be a Mega-project, a huge project that by its magnitude alone will attract management attention and demonstrate the quality of the department.

In the Marketing Department, bigger databases and more powerful computers are brought in to understand customer needs better, and to provide better segmentation of customer profiles. More Customer Focus Groups are created in faraway locations. Sales Associates are equipped with the latest communication devices to enable them to stay up-to-the-minute with customers’ unique needs, trends, recaps of previous sales meetings, latest prices and discounts. The Support Department builds its own database of product information and provides it to engineers on a single DVD. In the Engineering Department, old generation CAD applications are replaced by the latest technology. EDM applications are upgraded to PDM applications. The Manufacturing Department upgrades the controllers on its existing NC machines, and buys powerful new machine tools. More modules and interfaces are bought for the ERP application. it’s moved off hardware with an old architecture to one with a new architecture.

The result of these projects is generally invisible. The company continues to produce products that are late to market, cost too much and are of poor quality. Even if Engineering buys the most modern CAD technology, it’s not going to make much difference. Designing products that customers don’t want with a modern CAD application isn’t any better than designing products that customers don’t want with an old CAD application. More unwanted designs will be produced, creating even more pressure on Manufacturing, and distorting the production plans. And when the products do get into use, there are problems, and they have to be recalled. After all the investment in improvement initiatives, companies still suffer from many problems (Fig. 16.5).

Fig. 16.5

Many product-related problems

16.8 Traditional and Modern

Traditional companies expect a certain type of behaviour from a PLM Manager. Modern companies expect another. The differences can be seen in several areas.

16.8.1 Manager or Leader?

In a traditional company, the typical PLM Manager will define the work schedule and activities for the project team members, then sit back and wait until team members have finished their activities. Modern companies expect a PLM Manager to lead the overall activity of defining a PLM concept, detailing the requirements, implementing the processes and applications and making sure everything works well. They expect the PLM Manager to define the direction, lead from the front, and coach the team.

16.8.2 Cash or Customer?

Traditional companies expect PLM Managers to focus on the PLM budget. They reason that if the money is under control, then the project is under control. PLM Managers in this type of company aim for a budget as big as possible, knowing that, once they have it, they’ll be safe for a year or two. Modern companies expect their PLM Managers to focus on making things work for product development managers and other people in the PLM environment. They reason that a project will succeed if the people in the lifecycle get what they need.

16.8.3 Rules or Mission?

Traditional companies expect their managers to follow the rules. In turn, this means that the PLM Manager will want all the project team members to follow the rules. But PLM is new territory. So the rules don’t exist. As a result, the PLM Manager will try to implement old rules from old projects. And then the team members will ask, “Do you want me to follow this detailed rule if it’s going to cost a lot of money?” Modern companies reason that the most important thing to do is to get people to understand their overall mission. They reason it’s better to have a broad outline of mission, principles, guidelines, roles and responsibilities. And then let the project team members work out, with management help if necessary, the details of what needs to be done and how to do it.

16.8.4 Control or Empowerment?

Managers in traditional companies want to have everything under control. They detail all the activities of the people reporting to them. This under-uses skills, but leaves the manager in control. Modern companies reason it’s better to give people the freedom to do things within an outline framework, and not make them follow detailed rules. Their managers don’t try to control every activity and task. Instead, they empower people to get on, get results and meet the objectives.

16.8.5 Fire-Fighting or Vision?

Managers in traditional companies love fire-fighting. It gives them a warm feeling that they are making a great contribution. Managers in modern companies don’t want to waste time fire-fighting. PLM Managers in modern companies reason that if they take the time to develop a vision for a project, then they won’t need to waste time fire-fighting. Instead they’ll be able to add more value to the project.

16.8.6 Mega-Project or Continuous Improvement?

Traditional companies love Mega-projects. These high-budget, multi-year projects can be endlessly discussed in meetings, giving everyone the impression they’re playing an important role in the company. PLM Managers in traditional companies love Mega-projects. They reason that there’ll be no pressure to produce deliverables, and the budget will keep them alive for the foreseeable future. In modern companies, managers know that the Mega-project or Big Bang approach is very difficult, that departmental managers may not accept it, and that people who aren’t used to change aren’t going to handle Mega-change. Modern companies know that change has to come in small regular doses. They know that once people get used to continuous change, they can improve fast.

16.8.7 Fear or Desire?

Traditional companies believe people work best when they are afraid. They instil a fear of failure in their managers. Their PLM Managers have a fear of failure which they pass on to the project team members. They’re so afraid of failure that they prefer to avoid anything even slightly risky. Modern companies teach their managers to have a desire to succeed. This desire is shared by PLM project team members who focus on supporting people across the lifecycle, not on avoiding failure.

16.8.8 Width or Focus?

Traditional companies want as much of the cake as possible. Their PLM Managers propose PLM projects that will do everything, even activities normally considered to be outside the scope of PLM. Modern companies aim to succeed in well-defined niches. Their PLM Managers propose PLM projects that are focused on clearly-defined functionality that’s required by the company.

16.8.9 Hire or Promote?

Traditional companies have a low opinion of their workforce. They go outside the company to hire new managers, such as the PLM Manager. Modern companies believe their workforce is the best. They look inside for new managers. And they understand that to succeed with PLM requires a lot of knowledge and experience of the low-level details of the company including details of data, processes and documents. And they know managers hired from outside don’t have it.

16.8.10 Pressure or Help?

Traditional companies put their managers under extreme pressure to succeed. They set targets which can only be reached if their managers then put everyone else under extreme pressure. The desired end result is forgotten as everyone rushes round frantically and works long hours. Managers in modern companies know that if they define the required end result clearly, and help people to achieve it, then there’s no need to put everyone under extreme pressure.

16.9 Moving Towards PLM

Companies will not achieve expected significant improvements (Fig. 16.6) from PLM if they continue to behave in the traditional way.

Fig. 16.6

Potential PLM project target

Approaching, and carrying out, a PLM project with traditional behaviour will lead to the type of traditional results shown in Fig. 16.7.

Fig. 16.7

Results of application of traditional methods to a PLM project