PDM vs. PLM: Implementation Gaps

One of the topics that people often ask is what is the difference between PDM and PLM. The question is almost rhetoric, since the number of explanation is +1 from the number of people involved into the discussion. I stumble on the following article in the FISHER/UNITEC blog – PDM or PLM: Top Down or Bottom Up.  There are two important point that caught my attention. First point was about the gap between the product design (CAD) and the layer of managing financials, material requirements and manufacturing planning (ERP). Here is my favorite passage, which clearly position the problem:

Most will agree that the gap between CAD and ERP is too great to ignore the value proposition of the two “middle layers”. However, which should be selected and in what order: PDM or PLM? Additionally, can a typical manufacturer select just one or the other?

CAD Data Management
Wide adoption of CAD system created a crappy problem – what to do with all CAD files and other information CAD systems produce? People are not good in the organization of their data, in general. Engineers are interesting in how to create product design, but not much interesting in how to organize and manage the results. So, CAD Data Management was born. It called TDM, EDM and lately PDM (Product Data Management). As mentioned in Fisher/Unitech blog, many years of CAD data management implementation made it almost perfect:

The PDM solutions marketed today offer near-perfect CAD integrations, because they are typically developed by the CAD vendors themselves and come with a guarantee that new releases of CAD will be supported by them. Additionally, the many complex features of a 3D parametric CAD system are supported by the PDM system available from the same developer. As an example, SolidWorks Enterprise PDM offers simply the very best CAD integration to SolidWorks available on the market.

However, as soon as functional requirements are going beyond simple CAD file management or going beyond support of a single CAD system / environment, the implementation becomes crappy. PDM is a crappy solution for a crappy problem created by CAD.

Product Development and PLM Implementation Gap
Despite well defined, development of systems that support product development from various standpoints wasn’t so straightforward. For many years, ERP was the only system that was visible on the organizational level to manage processes, materials and production. Engineering was considered as a “black box” that needs to be self managed. Engineering supposed to through the results of their work over the wall to manufacturing and execution. The efficiency of this organization was sufficient probably 15 years ago. However, nowadays it is not so anymore. Global development, competition, cost management and many other factors raised need to create more transparency in product development management.

So, the value proposition of PLM became obvious. Now, PLM implementation became the issue. The PLM implementations are complicated, requires lots of service work and corporate involvement. In the real world, only very big companies can handle it. In order to take PLM implementation to mainstream, software vendors created so called “best practices” or “out of the box solutions”. It was good for marketing. The reality check didn’t show as a success, in my view. Most of the “out of the box” PLM implementations are not going beyond CAD file management.

Another problem of PLM implementation is CAD file management. In most of the organization, PLM implementation has to deal with multiple CAD (and sometime PDM) systems. Quoting the same blog:

Conversely, PLM systems today provide application support for managing product data and it’s metadata. Applications like engineering BOM management, configuration management, portfolio management, quality management, project management and supply chain management are available and native functions of a PLM solution today. However, because of the many 3D parametric CAD brands on the market, the PLM software developers and resulting systems do not normally have robust CAD data management capabilities that are always in step with current releases and design features, as noted above.

What is my conclusion? I can clearly see the gap between an organizational need to have a robust and scalable system to support product development (let’s call it PLM to be consistent with industry terminology) and maturing of PLM and PDM implementation. For me, bottom up approach makes more sense. People are trying to stay away from complexity these days. The next generation of PDM/PLM will need to take it as an axiom for a future success. Just my thoughts…

Courtesy - Oleg

PLM - Highlevel Overview

PLM Scope To make fair and accurate comparisons, it is important to clearly define the scope of PLM. At the same time it is important to understand that not all companies define the scope of PLM the same way. Some PLM vendors, mainly those who have their origin in CAD, CAM and/or CAE (CAx) and still have these tools in their portfolio, include them in the scope of PLM to be able to report larger revenues. Some industry analysts also include these tools to make the PLM market look bigger. ThePLM Technology Guide defines the scope of PLM more narrowly - as illustrated below - and only includes aspects related to the management of information and processes created and used throughout the life of a product (see also “What is PLM?“). . Four different capability levels: Foundational Capabilities, which correspond to the traditional PDM capabilities, extended capabilities, integration capabilities and strategic capabilities. The importance and value of PLM varies throughout the lifecycle of a product. It is most important from ideation to product launch, i.e. during the development and design of a product, and has lower importance between product launch and the end of production, i.e. during manufacturing and distribution, when ERP takes over the dominant role. Finally PLM gains a little more importance again in product support and maintenance.

Most manufacturing companies distinguish two main process chains: The operational process chain and the technical process chain. ERP systems largely address the operational process chain, whereas below PLM Systems automate and enable predominantly the technical process chain.

PLM Systems

Product	Client Focus	Vendor
Accolade	Small-Medium	Sopheon
Agile Advantage	Small-Medium	Oracle/Agile
Agile e6	Medium-Large	Oracle/Agile
Agile 9	Medium-Large	Oracle/Agile
Aras Innovator	Small-Medium	Aras Corp
Arena	Small-Medium	Arena Solutions
Enovia MatrixOne	Medium-Large	Dassault Systemes
Enovia SmarTeam	Small-Medium	Dassault Systemes
BPMplus	Small-Medium	Ingenuus
ProductCenter	Small-Medium	SofTech
SAP PLM	Medium-Large	SAP
Teamcenter Engineering	Medium-Large	Siemens PLM Software
Teamcenter Enterprise	Medium-Large	Siemens PLM Software
Teamcenter Express	Small-Medium	Siemens PLM Software
Teamcenter Unified	Medium-Large	Siemens PLM Software
Windchill	Medium-Large	PTC
Windchill On-Demand	Small-Medium	PTC

Processes that are usually automated with PLM systems include:
Management

• New Product Development and Introduction (NPDI)
• Program Management
• Project Management
• Requirements Management
• Change Management(ECR/ECO)

Sales and Marketing

• Portfolio Management
• Proposal Response

Engineering

• Concept Development
• System Design
• Detailed Design
• Configuration Management
• Variant Design and Generation
• Verification and Validation
• Design Outsourcing

Sourcing

• Early Sourcing
• Component and Supplier Management

Quality Assurance and Regulatory Affairs

• Quality and Reliability Management
• Regulatory Compliance

Manufacturing

• Manufacturing Process Management
• Tooling Design and Manufacture
• Manufacturing Outsourcing

Customer Service and Support

• Product Support Analysis and Planning
• Technical Information Creation and Delivery
• Performance Analysis and Feedback

Change Process The change process is the process of requesting, evaluating, planning and implementing of changes to a product or process. Usually the change process consists of three phases: Identification of an Issue Engineering Change Request (ECR) Engineering Change Order (ECO) The process flow diagram below depicts a best-practice, closed-loop change process with activities and deliverables (courtesy of Metafore).

Business Problems PLM Can Solve

Typical business problems PLM can solve include:
Innovation/New Product Development:

• Bringing new products to market takes too long
• The product development pipeline is too small or nonexistent
• Undesirable mix between new and established products (Stars and Cash Cows)
• Not enough revenue generated from new products
• New product development projects are often over budget and over schedule
• Little or no visibility over status of new product development projects

Change Management:

• It takes a long time to process change orders through the organization
• Many people have to sign off on change orders
• Difficulty determining the impact of changes on products, documents, manufacturing procedures and production equipment
• Affected parties (internal, customers, suppliers, etc) are not notified of changes

Information and Intellectual Property Management:

• Difficulty to search, access and retrieve existing information
• Little or no re-use of existing information and parts
• Significant effort to re-create documents and drawings that cannot be found
• Little information security
• No or little protection of intellectual capital

Compliance:

• High cost and large effort to meet and adhere to all regulatory and environmental rules and requirements (SOX, FDA, EPA, ISO, ITAR, RoHS, REACH, WEEE, ELV, etc.)
• Difficulty to keep track of and meet all the different international regulations (US, EU, Japan, etc)
• Large effort to prepare for audits
• Risk of non-compliance
• Product redesign and changes to meet regulatory requirements
• Large effort to determine all materials used in a product

Business Inefficiency:

• Redundant or duplicate parts and resulting excess inventory
• Spend significant time and effort to re-enter data in various systems
• Spend significant time and effort to distribute information internally and externally
• Need significant space to storage paper files and documents
• Large paper consumption for printing and copying

Quantitative and Qualitative Benefits of PLM

Business Level Benefits
The following benefits can be expected as a result of implementing a PLM system. These results were determined in user surveys and show actual improvements attained (Source: VDI 2219 Guideline).

Benefit Area	Improvement
Time-to-Market	~ 30% Reduction
Cost of Quality	~ 20% Reduction
Product Development Costs	~ 24% Reduction
Product Costs	Up to 20% Reduction
Change Management Costs	Up to 40% Reduction

Task Level Benefits
The following benefits have been determined empirically. Generally not all listed benefits will be achieved cumulatively, and some may be redundant.

Task	Avg Time w/o PLM	Avg Time with PLM	Typical Improvement
Searching and retrieving information (data, documents, drawings, emails, etc)	2 hours/day	Minutes……	~ 90%
Gathering the complete history of a product or document (such as the DHF)	4 hours	15 Minutes	> 90%
Where used analysis	Up to 8 hours	Minutes	> 90%
New part setup (get new part number, find and enter associated data)	1 hour	10 Minutes	~ 80%
BOM creation	Up to 4 hours	Up to 1 hour	Up to 90%, depending on complexity of BOM
Change order creation and processing	8 Hours	1 hour	~ 90%
Data re-entry into various forms and business systems	1 hour/day	0	100%
Handling of paper documents (copying, printing, distributing, vaulting, etc)	1/2 hour/day	0	100%
Recreation of lost information (data, documents, drawings, etc)	1/2 hour/day	0	100%

After determining the specific benefits an organization can achieve they have to be converted in monetary savings to create a business case and to calculate the ROI/NPV that can be achieved through the use of PLM.

The Cost of PLM

The overall cost of a PLM solution is comprised of several elements and dependent on a number of factors.

Cost Element	Cost Type	%1)	Cost Dependent On n
Software	One-time capital investment	30%	Number of users Type of users: Authors and viewers Required functionality or functional modules Deployment option: On-premise or on-demand Licensing method: Floating licenses or named user licenses List price and discount
Software maintenance	Annual recurring expense	6%	Number of users Type of users: Authors and viewers Required functionality or functional modules Deployment option: On-premise or on-demand Licensing method: Floating licenses or named user licenses List price and discount
Hardware	One-time capital investment	8%	Number of users Number of sites Required configuration Desired performance Quantity of data and required disk space Required system availability and uptime Deployment option: On-premise, hosted or on-demand List price and discount
Education and software selection	One-time expense	8%	Number of system included Understanding of PLM Market knowledge Duration Thoroughness of evaluation Involvement of an external PLM consultant
Process optimization	One-time expense	8%	Number of processes Size of organization Documentation of existing practices and processes Methodology Understanding of PLM Involvement of an external PLM consultant
Implementation services	One-time expense	25%	Required configuration and/or customization Contract terms: Fixed price or time & material Hourly rate and discount
Training	One-time expense	5%	Training delivery: Vendor or Train-the-Trainer Training material: Standard or custom Training location: Vendor, on-site and/or web-based
Data migration	One-time expense	5%	Approach: Manual or automated Number of source systems Type of data: Metadata (item master, etc), structured data (BOM, assemblies, etc), files (CAD models, drawings, documents, etc) Quality of data Quantity of data
Post-go-live support	Annual recurring expense	5%	Duration Type and level of support Required response time Required system availability Hourly rate and discount

¹⁾ Approximate share of total initial cost (one-time capital investments, first-year software maintenance, one-time expenses and initial post-go-live support)
xxx
xxx
Based on the different elements and dependencies it is obvious that the cost of a PLM solution can vary widely. We know of companies that have implemented PLM for a few users and with limited functionality for less than $10,000, but there are also companies that have implemented extensive PLM functionality for tens of thousands of users and have spent millions of dollars.
As a rule of thumb we have found in numerous projects that the initial cost for a complete PLM solution will generally be in the range of $4,000 to $6,000 per user (for capital investments and one-time expenses). Where in this range the overall cost falls depends largely on the number of users and the implemented functionality. The more users, the lower the cost per user, and the more extensive the functionality, the higher the cost per user.

Courtesy - PLM Websites

Benefits of Product Lifecycle Management (PLM)

PLM software can help people improve their understanding of how products are designed, built and serviced. Most users appreciate centralized access to all product-related information; they feel more productive and efficient. But the benefits are quite concrete and easy to demonstrate.

These benefits can be categorized as

Increase revenue 

It's fairly intuitive that shorter design times and faster change cycles yield earlier product introductions and optimized products, resulting in earlier revenue and longer product life.

Reduce design time

PLM avoids wasted design effort through

• immediate, managed access to all design data
• concurrent reviews by affected data consumers without distracting designers
• elimination of lost or damaged files
• consistent, data-rich bills of materials with real-time cost roll-ups
• reapplication of existing items in new designs

Accelerate release and change cycles

Some PLM systems allow tasks to be attached directly to an document or part, keeping both designers and project managers in the loop.

Perhaps the most remarkable impact of PLM is the substantial efficiency gained when processing product releases and changes. A non-automated process usually requires extensive document collection and copying efforts, repetitive and error-prone change order creation, and relying on time-consuming interoffice mail or on an engineer or change analyst walking the package from office to office. Involving supply chain partners may require express parcels, insecure or lost mail, irrelevant or incorrect file attachments, and a host of other time-wasters.

By design, a PLM system contains all product information in a secure central location; allows multiple users simultaneous access to the data; provides templates for change types, including pre-defined review workflows, approving departments and interested observers; identifies all dispositioning tasks and rolls up cost impacts automatically; and utilizes email so there is no lag between one person's approval and the next person's notification. Changes can typically be pulled back, reworked, and resubmitted without leaving your desk to chase down a physical package.

Reduce product cost

Conduct more comprehensive, less intrusive collaboration

Real-time visibility into evolving designs encourages early and frequent design checks; these permit sourcing, production, quality and service specialists, as well as supply chain partners, to provide timely feedback. Include all aspects of the product plans, drawings and procedures for production, inspection, service, repair and disposal. This information is available in a single location, without having to distract designers with on-going requests for in-process data. 

Purchase fewer parts in larger volumes

Part re-use is difficult in larger organizations with significant numbers of parts. Relying on designers' memory or searching through the ERP system is a hit-or-miss affair, resulting in almost-identical parts being sourced. PLM encourages item exploration, which avoids sourcing new parts that are functionally similar to items already in inventory.

Increase production experience

Earlier product introductions ensure longer production runs; increased production experience results in more rapid, on-going cost reductions.

Reduce production rework and scrap

Changes are reviewed by all affected parties; on-line review and approval is faster and more comprehensive than paper-based change process; bills of materials are consistent and can include documentation on production and inspection processes.

Reduce overhead

Simplify regulatory and contractual compliance

If your development or production process is subject to audit by a third party, a PLM product can simplify review and acceptance. It's far easier to document your process when it's based on commercial-grade documentation and system configuration reports, particularly if the PLM vendor is sensitive to regulatory issues, and has experience designing compliant products.

Mitigate and, if required, report on a product's environmental impact

Government regulations both restrict the types of materials contained in products and specify more stringent environmental-impact reporting.

Europe's Waste Electrical and Electronic Equipment ("WEEE") and Restriction of Hazardous Substances in Electrical and Electronic Equipment ("RoHS") directives address product environmental impact and require material tracking and, in some cases, data reporting. The US Environmental Agency also prohibits or restricts the use of certain hazardous materials, and your company may be required to track and report on certain compositions.

New efforts are underway, particularly in the electronics and automotive industries, to increase the use of environmentally-friendly materials, and supply chain partners often require detailed materials reporting via a Materials Declaration.

Manual calculations, particularly for hazardous substances that are measured in parts per million (ppm) or parts per billion (ppb), can be time-consuming, imprecise and error-prone. PLM systems that can automatically calculate and report product material composition across a bill of materials radically simplify the task.

Reduce process administrative and clerical costs

Depending on your industry, for every 8 to 12 engineers and designers a manual document control and change management process may require a change analyst, administrator, document checker, or clerk. Implementing a PLM system may allow you to cut that ratio to 20:1 or better.

Courtesy - www.product-lifcycle-managment.com

Investigating and adopting a PLM solution

Deciding on a PLM solution is no different from looking at other business productivity applications, and can be as simple or as detailed as you want to make it.

Whether you spend a few hours or several months, you'll probably want to consider the following topics:

1. Define your Project Objectives:

Understand your project's strategic objectives. That is, answer the basic question: Why do you need a PLM solution?

Your goal is to...	PLM can help by...	Measure PLM impact by...
Increase product quality	Ensuring affected users consistently review product changes; automatically notifying users about new & revised documentation; tracking that obsolete data is promptly removed from production areas; checking that as-built products match approved design and process documentation	Monitoring change-related defects; periodically auditing production floor documentation; performing periodic audits of as-built product
Manage increased product complexity	Encouraging on-going collaboration and review of product design and process files; providing consistent structure to your bill of material management; enforcing product change review using defined workflow	Categorizing reasons for changes (principally those related to failure to meet design requirements)
Reduce product unit costs	Encouraging part re-use by easier searches, and thereby increasing purchase volume	Tracking reductions in new part numbers that are issued for each new product
Reduce time-to-market	Reducing number of items designed through re-use; reducing design iterations via concurrent review; speeding the design release process though automated workflow and notifications	Measuring average project development time; monitoring defect frequency immediately after new product launch
Reduce change-related administrative overhead	Eliminating manual change processing, and carrying physical change packages from one approver to the next; automating materials declarations for environmental compliance	Demonstrating change in staff throughput, such as number of changes processed per unit time; eliminating manual processes such as copying, faxing, shipping, "walking changes through system"
Reduce production rework and inventory scrap	Speeding changes through the review and approval cycle; automatically calculating cost impact of changes based on item-by-item disposition expense	Monitoring rework and scrap expenses; tracking total cost impact of changes
Improve customer satisfaction and enhance loyalty	Executing quickly, consistently and predictably	Asking customers and sales staff for feedback
Plug gaps in current business processes	Encouraging business process designers and users to seek more efficient methods, and capture these methods in well-defined PLM attributes and workflow	Assessing employee satisfaction; eliminating tedious activities
Enhance cooperation with your supply chain partners	Encouraging early review of requirements; exchanging design, procurement, production, and service information	Tracking rework charges and non-recurring tooling and setup costs

2. Assess your organization's existing processes for design, data management & change:

Examine your organization's existing design, data management & change processes. Your alternatives are to:

• Do nothing: You may decide that your processes are sufficient for current business needs; you don't anticipate any worthwhile efficiencies by modifying or automating your existing manual processes.
• Adopt PLM without changing your process: This is a reasonable path when you're under significant resource (time, money, staff) constraints, but believe that immediate automation of key areas can provide immediate benefits or can control an on-going problem (such as chronic bill of materials errors or slow change processing). You'll usually be able to tweak a few of your most challenging process pressure points under the flag of "system configuration".
• Re-engineer processes without PLM: Another possibility when you don't have the time or budget to do everything, but believe that your processes are too flawed to automate efficiently. This should make a subsequent PLM project much easier to implement.
• Re-engineer processes as part of a PLM project: The most challenging approach. You'll need to spend considerable time negotiating cultural changes, specifying PLM business rules and workflows, and trying to reconcile the demands of users who like things just as they are with those users demanding radical change. This approach requires a particularly strong champion with enough political clout to get everyone lined up behind the effort. But it can offer a radical transformation in your organization's efficiency, and the risks may well be worth the rewards.

3. Set realistic Goals:

After reviewing the strategic objectives and assessing your organization's needs, set realistic goals for your PLM project

• Plan for an incremental & benefits-driven implementation; avoid the "big bang" approach if possible, and capture the quick payback before tackling tougher problems with harder-to-justify ROI
• Establish simple, easy-to-track success metrics and make sure that they're directly related to your original objectives

4. Identify potential expenses and forecast actual costs related to purchase, installation and operation:

According to AMR Research, in 2004 software license fees represented about 38% of total PLM industry revenue.

Typically, most of the implementation, consulting and training costs are incurred at the beginning of a PLM project, so you may find that these expenses consume more than half of your initial project budget.

In practice, the most cost-effective methods for minimizing project expenses:

• Emphasize easy to use software   Ensure that your installation, configuration and training costs are as low as possible by choosing the simplest, most user-friendly software that meets your needs. Most reputable vendors will let you try before you buy.
• PLM will be a big win, so don't over-buy  Minimize configuration consulting and custom development work, principally through avoiding enterprise integration projects that yield only minor productivity improvements.

Actual Costs:

There are many PLM solutions available. Some vendors will require an extensive hardware, software and services investment; others are more sensitive to a limited budget, and will try to work with existing hardware, low-cost (or free) databases, and minimize the use of consultants.

This list suggests some possible expenses to explore:

• Staff time to research & evaluate alternatives
• Software solution costs
  • per-user or concurrent-use client licenses
  • per-CPU (or other) application license
  • database license
  • special administrator licenses
  • annual maintenance, support, upgrades
• Hardware costs
  • workstations
  • application and/or database servers
  • backup devices
• Special file viewers
• Downstream ERP file import or integration
• Network & bandwidth costs
• Deployment costs
  • Consulting services for process reengineering and application configuration
  • Legacy data import and migration
  • Pilot (proof of concept)
  • Production deployment

5. Review how software licensing can impact your budget and operations:

Before contacting vendors, consider the operational and financial aspects of software licensing models carefully. Some vendors offer more than one licensing approach. Decide what will work best for you and make your list accordingly.

Traditional perpetual license, with annual maintenance

If you have the budget, this path is usually the simplest to manage as well as cheapest over the long run because you have a definite control over your costs. The alternative license methods all represent an on-going cost, and may bundle financing costs into their monthly charges.

Perpetual licenses, as well as subscription licenses, let you tailor the configuration to your exact needs and even customize the product and/or its interfaces. You have complete control over performance, storage costs, maintenance and service interruptions, and - most important - your critical product data. Furthermore, if you're perfectly satisfied with the system that you have, the maintenance can usually be stopped.

Subscription or lease

This is typically like a magazine subscription where you can buy for any number of users, and can stop at the end of the subscription period. It's an inexpensive way to get into PLM, since there are no large upfront software costs, except (if needed) a database server license. You still get the operational benefits of a perpetual license: high performance, typically a superior user interface, in-house control of your critical product data, ability to tightly integrate your other systems. Subscription licenses are sometimes preferred because they can be dropped if, for instance, you only required a large number of licenses for a temporary project, or you're concerned about unaccounted-for licenses installed on obsolete PCs. Some subscription models allow you to convert to perpetual licenses after a certain period ("lease to own").

Internet ASP-based services

A PLM application service provider (ASP) hosts the entire PLM system off-site, using a data center shared among all of its customers. A PLM ASP perhaps offers the most financially attractive short-term PLM solution but comes with significant longer-term risks. The per-user cost is initially reasonable if you aren't particularly concerned with the total cost over 5 or 10 years.

The principal benefit of a PLM ASP is that the vendor handles the hardware and software management tasks: acquisition, installation, maintenance, and upgrades. Furthermore, the ASP defines a rather specific set of features that simplifies your configuration choices. Finally, if you don't want to bring your legacy data into the system, and can quickly make your configuration choices, you can have access to your PLM system in a matter of hours.

As you'll see, we have reservations about a PLM ASP solution; a hosted application may be perfect for incidental business processes (think "travel reservations" or "HR benefits"), but it's a much tougher decision when applied to mission-critical functions and irreplaceable proprietary data.

If limited budget or internal IT resources suggest a PLM ASP, you'll want to weigh these issues:

• Your company's mission-critical data is not on site. This has two effects:
  • How much do you know about the security, backup process, operations skill, disaster recovery procedures, and financial stability of your PLM ASP, and
  • What happens to your productivity if your Internet connection or PLM ASP goes down for a day?
• A PLM ASP solution typically implements a "one size fits most" approach, and is much more limited in its configurability; make sure your business processes won't be constrained.
• Usability will be limited by the browser-based user interface, and web technology simply isn't as flexible and as powerful as native applications. Can you imagine CAD or even a spreadsheet hosted on the web?
• Performance is determined by your Internet connection's available bit rate and utilization, your vendor's available bit rate and utilization, the load on datacenter computers, and the systems selected for the datacenter. If you aren't happy with the system performance, upgrading will require more analysis and negotiating. There's no guarantee that you'll get the performance you need if your requirements exceed your vendor's abilities.
• There may be additional charges for exceeding contract limits for data storage, processing time, or connection bandwidth.
• Upgrades and service downtimes are scheduled for the vendor's convenience, not yours. Except during project "crunch time", this should not be a significant issue if your office runs inside the typical workweek, especially if you select a PLM ASP in your time zone.
• In most cases, all of the PLM ASP's clients share a common code base, so you can't delay or skip an upgrade. Whether you're in the middle of a time-critical project or simply satisfied with your software, you'll still be getting your new upgrade (and possibly re-training, data conversion, and new bugs) with everyone else.
• If you're not happy with your PLM ASP, check your service contract and practice your diplomatic skills before asking for any help in moving your data to a competing PLM system. 

A PLM application service provider may be the only reasonable alternative for your company, but you'll want to anticipate all of the ways the arrangement could fail, and make appropriate contingency plans.

6. Establish a budget and define expected results:

Establish a budget and figure the return on investment (ROI)

• Control costs at each stage of the project; savings accrue at each step as you simplify your requirements
• If you are having trouble with justifying ROI
  • Scale back project scope
  • Look for simpler, more affordable solutions
  • Lease rather than buy

If you choose to concentrate on the "low-hanging fruit", ensure that this short-term focus supports a flexible, well-rounded PLM Solution and is not a dead end.

7. Determine the selection criteria that you'll use :

There's good news: Almost any broad-based PLM solution that can support your small or medium business (SMB) will be better than the manual process you have now. To simplify your selection process, consider these as necessary (and perhaps sufficient) points to start your examination.

Focus on your needs, not the supplier's capabilities

Make sure that you align your PLM supplier's capabilities to your goals. With all of the choices available, it's easy to get distracted. But there's not much return on investment (ROI) in buying a CAD file management system if you're mostly looking to accelerate your change process or reduce your bill of materials errors.

Protect yourself from fatal commitments  

Your organization will be living with your decision for awhile. A low upfront cost may be essential to get the project funded, but it's the on-going cost of day-to-day operation, user productivity, training, administration, and support and maintenance that will determine success in the long run. 

However, don't worry that your PLM decision is forever. Once your data is in any modern PLM database, shifting to another PLM system ought to be easy provided that:

• your PLM license vendor uses a well-known database server (SQL Server, Oracle, DB2, etc.); or 
• your PLM ASP provides a written guarantee that all data they manage for you can be extracted easily, and will demonstrate this capability whenever you request it. 

Generic user interfaces are, well, generic

Many PLM systems offer both browser-based Java clients and OS-specific (typically Microsoft Windows) clients. Where you have a choice, align the client software with the types of users you'll be supporting. 

For example, compared to a dedicated Windows client, web browsers still have relatively slow and weak user interfaces. Enabling complex PLM UIs in a web browser requires heavy-duty Java and custom plug-ins, which burden the web client while compromising the run-anywhere thin-client advantage. 

Most users will prefer the higher performance, information-rich OS-optimized interface if they have the choice. 

However, web clients are appropriate for casual or guest users (such as supply chain partners) who just need to browse data, for less-popular operating systems (e.g., Mac OS X), and for mobile users who must look up data or approve a change while out of the office.

PLM is great, but don't get in over your head

Surprisingly, for smaller companies, CAD and ERP integrations are often "nice to have", not essential. Why? Because there's a lot of ROI available in just data and file management, bill of materials construction, automated change control, and workflow/email notification. In smaller companies, integrating PLM with CAD/ERP may only represent 10% of total PLM financial benefits, yet cost 40% or more of the total project budget. Projects that require custom integrations can be time-consuming and can delay project payback by months (or worse). Quick PLM implementations rely on simple data exports for loading the ERP BOM tables; your CAD and ERP processes will be no worse than they are now, and you'll see the PLM benefits much sooner. Only after you've extracted all other PLM benefits should you then examine system integrations.

Courtesy - www.Product-Lifecycle-Managment.com

The importance of a long term roadmap for PLM

One of the big project level benefits of a PLM implementation is that most PLM solutions can be rolled out to the users in stages. New PLM processes and workflows and modules can be incrementally added after the foundation is laid – this is GREAT and it is TERRIBLE.

It is great that PLM can have core functionality within weeks or months of starting a deployment – systems like Arena Solutions or Teamcenter Express that target the small businesses can be rolled out literally in 1-2 weeks if your business can accept out of the box workflows for change management. For the mid-sized businesses systems such as Agile and Windchill can typically be deployed within 3 to 4 months with core functionality in place. What adds time to these types of deployments is typically dealing with preparing the training program and process documentation associated with implementing these solutions. With the larger enterprises implementing Windchill, Teamcenter or Enovia the enterprise complexities come into play earlier and take longer to deploy at 6-9 months, but even the large enterprises tend to only see a small piece of the PLM vision and only obtain limited benefit due to stopping at change management.

What is terrible is how many PLM systems get implemented without an enterprise roadmap that takes the implementation beyond the foundational deployment. Change management is put in place without enabling the part classification (to enable reductions of duplicated parts). BOMs are built without enabling Multisite or BOM variants (tracking the site specific build data or the engineering vs. manufacturing BOM). Manufacturer and Supplier data is managed with the product information, yet the external partners are still sent CD’s or paper and kept outside the loop on major changes that impact their contribution to the finished product.

Why is this? It is the curse of the initial success of a PLM deployment. When an ERP system is rolled out for the first time (after 2-3 years preparation) it gets turned on with 90% of the functionality in place and then is very cautiously modified mostly for tuning purposed. PLM on the other hand can be rolled out successfully with only 40-50% of the business functionality implemented and considered successful at which point the senior management often thinks the project is done – losing the vision for the other 50-60% of business benefits that have yet to be obtained.

It is this tendency that makes the initial long term roadmap so critical. Without defining what the long term business objectives are that the PLM deployment is to address the execution typically halts after the “engineering” system is in place yet the enterprise enabling capabilities have not even been tapped into. The selection of the system is often targeted at a short term objective, then the longer term benefits may be hindered or require a second PLM system to obtain the next tier of benefit. (See Gartner’s Predicts 2008: Manufacturing IT Becomes More Than Business IT, December 2007)

No company would deploy ERP without a 5 year plan. Yet PLM, which impacts 30-40% more end users than ERP, typically is deployed without a similar long term plan. Then the users and the management end up stymied about why the benefits expected from PLM have yet to be achieved. (See Aberdeen’s July 2007 report – Profiting from PLM: Strategy and Delivery of the PLM Program)

What is your PLM roadmap?
Have you tied the PLM implementation to true business benefit or are you just implementing a data vault?
Do you have a phased plan that identifies the business value obtained from each and every phase?

What many companies will find is that for true understanding of what is possible and what to do to build that roadmap – it takes experts in PLM and in your industry issues to help you build that vision. To expect the IT or Engineering department to vision cast is often not possible – as internal resources often do not have the subject matter or process expertise to cast the PLM initiative into a plan that ties the implementation to direct business strategy.

Courtesy - Liala

Successful Implementations – Invest in Phase 1 – Establish the Business Case for PLM

Perspectives on successful PLM deployments – what are the common themes across successful implementations.

A reader recently asked me to share perspectives on successful PLM deployments – what are the common themes across successful implementations.

The thought that comes to mind first and foremost is the upfront planning.  By planning I don’t mean the development of a project schedule or of the system requirements - it’s the investment in taking the time to really make sure the business justification is well understood.

There is a process I have used repeatedly that involves managing expectations very carefully before engaging the software vendor.  Too often it seems that the PLM decision is reactive – as sold by the software vendor, not based upon a clear set of business drivers.

To be successful with the process steps executive level endorsement is critical as it has a lot in common with a business process assessment in that it probes the entire organization, however, the assessment is focused upon the product record, not operations or production.  The challenge for many however having someone who knows  PLM well enough to be able to see the opportunities is often not a skill set contained within your company.  The cost of having consulting done for this stage is often well worth the initial investment when taking into account the overall investment you may end up making in the implementation.

The single most significant thing to be done is to look at the PLM project with the same kind of rigor as a product development project.  Too often IT projects (coming from a non revenue perspective) fail to use simple PMO types of processes.  It all starts with the business case phase.

But on the successful implementations – the business case stage would include the following activities:

1. Take your organization chart and mark every department that handles product related information, identify key external partners that are also interacting with your product records (note – do not count your financial transactions here – just focus on the product information).
2. Evaluate each department around it’s  handling of product information or the product record look for manual transactions, duplicated entries, printouts, markups, shadow databases, network storage of product information.  Include examining what IT infrastructure components are involved.
3. Dollarize the impact of the “non-value” added activities associated with these product record related transactions – the caution is that executives will readily let you turn this into a blame game rather than a financial business case – so be careful how this is framed (Read the Dollarization Discipline for more on this).
4. As in product development project management practices – develop a high level specification (similar to a Market Requirements Document) that ties business objectives to the functionality requirements – this is NOT where to say it must run on xyz database, or have n tier architecture.  This is a market level specification for executive consumption.
5. Obtain executive buy-in for the next stage – do not go too deep into specification definition until this phase is approved.

Courtesy - Laila Hirr

PLM – Clearer Definition or Problem Solving?

I’m adding another post to my collection of PLM definitions. Gavlin Quinlan came with the blog post on concurrent-engineering blog earlier this week. Here is the name – A Clearer Definition of PLM. I spent 10 minutes reading the blog and material. It points out to the CIMData Whitepaper 10 Questions to ask PLM Solution supplier from the last year sponsored by PTC. The following passage is presented by the author as a clearer definition of PLM:

PLM is software designed to enhance process efficiencies related to a product’s bill-of-materials (BOM) – the core information that tells manufacturing companies how to design, manufacture, and support products. Specifically, PLM software enables manufacturers to optimise the management and evolution of a BOM throughout a product’s entire lifecycle – from concept to retirement. Any and all activities that affect, change, influence, or finalise a BOM are factors that will drive a manufacturer’s overall operational effectiveness and as such are considered to reside underneath the PLM umbrella.

Also, Gavlin note the following: For clarity’s sake, it’s important to note that it is our perspective that PLM does not include the technologies used to author the information that populate a product’s BOM – such as MCAD/ECAD files and engineering/design calculations.

When talking about PLM ROI, author is coming to the definition of functional areas, but most importantly provides the definition of characteristics for PLM system. Here it is - A single scalable system architecture characterised by high performance, effective data replication, and robust security to support the modern geographically disparate company. The system should be integral, Internet based, and interoperable with other company systems.
Seven functional areas are Document, Visualization, Collaboration, Workflow, MCAD Data Management, BOM Management and Configuration Management.

PLM: Network vs. Single System

I found the definition provided by concurrent engineering interesting and here is why? It represents a very popular for the last 10 years approach on a single large PLM suite (or product) that can solve all product development company problems. Just go for that and all your problems will go away. There is nothing wrong in this approach, in my view. In one of my previous I discussed the “singularity topic in PLM” - PLM Network Effect and Single Point of Truth. My take is the “network” is a more powerful system organization compared to the a single system. The web is the best example, in my view.

What is my conclusion? The run for a completeness in PLM definition, requirements and implementation was, in my view, trendy and popular for the last 10 years of PLM. I think, the vendor’s “me too” and comparison of functional capabilities will go away in coming years. What will come as a replacement? My take is following- the capability of solving a specific business problem with a minimum of effort and in a shortest time period. Does it sounds obvious? Yes, I think so. PLM vendors, service providers, please take a note. This is important, in my view.

Courtesy - Oleg