Leveraging
For decades - maybe longer - companies have known that cross-functional development
teams add value to the creation of new products. By convening repre- sentatives
from all parts of the development chain, ideas flourish, costs fall, manufacturability
increases, and go-to-market times shrink. Even in the most vertically-integrated
companies, development is enriched by collaboration among interconnected processes,
people, locations, and job functions.
Over time, those interactions have become more formalized. Key collaboration points were documented. Best practices and process benchmarks were developed. Powerful enabling technologies were introduced. At that point, a formal descriptor also became necessary. What stuck was Product Data Management (PDM) or Product Information Management (PIM).
For the most part, PDM's scope has been limited to the four walls of a (somewhat vertically-integrated) organization. But this no longer typifies most leading organizations. With today's "extended enterprises," the four walls of most successful businesses are osmotic - ideas, processes, people, and technology functions pass through them. As a result, the principal collaboration need is inter-organizational, geared to companies that outsource manufacturing and design responsibilities in order to focus more tightly on core capabilities such as creating brand image or acquiring and servicing new customers. This sort of business model is not the province of traditional PDM, which, being somewhat agoraphobic, is not geared to inter-enterprise collaboration.
Instead, a new approach has evolved: Collaborative Product Commerce (CPC) adds external partners - component suppliers, contract manufacturers, customers, third-party design partners - to the new-product-development mix. In effect, CPC is the enabler of virtual communities focused on new-product development. With CPC, people, processes, ideas, and technologies come together regardless of time or location. As a result, innovative products come together faster and cheaper, and the core capabilities of multiple organizations are leveraged across the extended enterprise. The net effect is that companies that could not respond quickly to new market opportunities in previous eras can do so now.
The balance of this white paper examines briefly the functionality of CPC, explains how it differs from (improves upon) PDM, and profiles some real-world CPC applications.
What's Really Different?
It isn't wrong to think of CPC as an inter-enterprise upgrade of PDM. After all, their objectives are comparable: a fully-integrated product development environment. They're also based on common implementation strategies that start with basic document-management and vaulting (data repository) capabilities, and drive toward comprehensive change management and configuration management. Functional requirements and business process change mechanisms also are similar.
The most fundamental difference is that CPC is "Internet empowered" - built for travel. There also are dissimilarities in architecture, implementation characteristics and the scope of affected processes and organizations. Compared to PDM, CPC technology also requires less product data manipulation and can be implemented in shorter time frames. Most important, however, CPC caters to the realities of today's new-product-development and design environment by using the Internet to build virtual development teams, leverage the core capabilities of multiple organizations and shorten development cycle times.
All in all - and unlike PDM - CPC should be thought of as the key ingredient in a new design environment that permeates the extended enterprise and helps its constituents work together more effectively. You also might say that CPC helps companies become system integrators by allowing them to focus more intensely on their core capabilities and on leveraging external partnerships to ensure the configuration of a complete solution. In either context, CPC helps a company's development strategy become three-dimensional, by making possible the collaborative development of products, processes and supply chain strategies (such as build-to-order). On a stage-by-stage basis, here are some of the key ways that CPC adds value to the extended design/manufacturing environment.
Document Management and Vaulting
To promote early-stage, cross-functional collaboration, most CPC implementations begin with the introduction of basic document management and vaulting capabilities. These capabilities make it possible for product data pertaining to requirements, specifications, bills of materials, CAD drawings, approved vendor lists, process sheets, and so forth to be stored in a single repository or data vault, with users positioned to check information in and out based on their assigned privileges and responsibilities. Information in traditional PDM data vaults might be accumulated in much the same way, but it would not be accessible to external team members.
Obviously, technology plays a key part at this (data organization) level, but significant business process changes also must occur to ensure the development of cross functional teams, and to promote concurrent engineering practices such as Design for Manufacture and Design for Service and Support. This blend of technology and process is what makes it possible for companies to collaborate during the early stages of the product development process. Properly implemented, CPC ensures that cross-functional team members always have access to the latest revisions and can use that information to make expedient decisions. In practice, this could mean that Manufacturing Engineering recognizes the need to delay the purchase of expensive new tooling after seeing that a part has just been put under change control by a design engineer at a partner company.
Engineering Change Management
As a new product moves through the development lifecycle (concept development, build, test, production ramp-up), managing changes to the product and its manufacturing process becomes more complex. In fact, this is the first capability that some companies seek to implement - prior to more basic document management capabilities. Across the extended enterprise, CPC addresses product-change management with features that include:
- Electronic workflow: The ability to automate the routing of changes for approvals.
- Notification: Letting individuals across the extended enterprise know that an action of some sort must be taken.
- Subscriptions: Associating data objects with specific people or departments, thus ensuring that notifications reach the right individuals in a timely and comprehensive way.
- Visualization: The ability of each participating person or group to view an engineering document, regardless of whether they possess the original application.
- Red line markup: The ability of each participating person or group to add comments to an engineering document, regardless of whether they possess the original application.
To accelerate the process of implementing the correct product or engineering change, companies can automate the review and approval process using electronic workflow technology. Based on the type of engineering changes (e.g., mechanical or electronic), approvals are routed automatically to the correct people (e.g., mechanical engineers or electronics engineers). The ability of CPC to extend the scope of approval workflows to team members outside the company obviously is a significant advantage.
For a company to fully realize CPC benefits in automating their change management capabilities, it also must have the right practices and processes in place. For example, if a company does not fully involve functions outside Engineering in the approval of changes, the result will be an inefficient change process with long cycle times. Results will be compromised further if a company does not have a rigorous engineering change execution and approval process that mirrors its development process and promotes cross-functional decision making. The engineering change process must be designed in conjunction with enabling CPC technologies to achieve maximum benefit.
Product Structures and Consolidated Bills of Material
In the early stages of a new design, the cross-functional product design team creates the first Bill of Material (BOM), also known as a Product Structure or Engineering Bill of Material (EBOM). Some companies may not create a BOM until they get close to the end of the development process, when prototypes must be ordered and tested. The problem with doing this is that multiple BOMs are more likely to be developed by different functional organizations. For example, a procurement engineer may create his own BOM to initiate the ordering of materials, even as a manufacturing engineer is creating a BOM to launch the development of prototype tooling. Not surprisingly, this can result in serious accuracy, reconciliation, and version-control problems, as well as a lot of wasted money and effort.
By integrating the product structures created from the various engineering applications used in design (MCAD, ECAD, etc.) CPC make it easier for companies and external partners to develop and work off of a single BOM. This ensures that each cross functional team member has an identical view of the current product and process definition. It also helps promote true concurrent engineering in the early stages of design (e.g., manufacturing engineers working with design engineers to optimize the design and manufacturing process simultaneously). For example, an engineer seeking to make a component substitution in the product structure can easily review the manufacturing process plan (also contained in the product structure) in order to understand potential manufacturability issues. To make this happen, a company must have a concurrent engineering process in place that promotes cross-functional collaboration in the early stages of design and the joint release of product and process definition. It also will be helpful if the program structure is comprised of cross-functional development teams that are in place throughout the product's life cycle. Traditional PDM systems do not facilitate a shared product structure with external partners, which makes it difficult to maintain accurate bills of material in the early stages of design.
Configuration Management
More and more customers are demanding products that are customized to their specific needs. This creates a tremendous challenge for product manufacturers. It also mandates the development of a "portfolio management strategy" that is focused on the joint development of product and process strategies. CPC addresses the challenge of configuring products to specific market needs. Basically, CPC-based configuration management creates associations between components and assemblies. This helps determine the range of permutations that a product potentially can have. Unlike PDM, CPC creates these associations regardless of whether or not external organizations have designed the part or assembly. Configuration management capabilities also help companies contain the number of non-standard product configurations, and help control component proliferation. Configuration management is particularly powerful when it is deployed in conjunction with a portfolio management strategy. Among other things, the portfolio management strategy should define the approval issues associated with new products, promote standard product configurations that leverage existing product platforms, introduce ways to shorten development times and identify ways to reduce the development cost of derivative products.
Building a Case for CPC
Like all initiatives, a CPC strategy must be driven by a company's core business strategy. The pre-eminent question is "how can CPC help me do a better, faster, or more expedient job of achieving my business mission?" In most cases, the response should reside in a formal CPC business case. To help identify the associated benefits, costs, activities and ROI, developers of the business case will need to capture information about:
- Data: What content will be managed?
- The scope of the data to be managed: engineering, supplier, manufacturing, customer, etc.
- Processes: What processes will be involved?
- Business change issues: What organizational changes will be needed to achieve and sustain new approaches to enterprise-wide design and manufacturing?
- External collaboration: What business partners or stakeholders - customers, R&D sites, suppliers, etc. - will be part of the mix?
The business case also should articulate how the company and its partners plan to manage information throughout the product-development life cycle. This will help the company recognize how much collaboration may be needed among external parties and help define the requirements for a CPC architecture.
Lastly, a business case must accurately assess the degree of change that a revolutionary approach to cross-enterprise product information management might entail. For example, if a company relies on complex, ad-hoc product-development processes and practices, it is imperative that new approaches be developed in conjunction with the enabling CPC technology.
Once again, a CPC business case must identify the potential of CPC to help a company meet its business goals. For many companies, CPC may emerge as a serious opportunity - an ideal starting point for companies looking to become more externalized, less vertical, and more successful.
Case Study 1: Applying CPC to Engage New Customers
A semiconductor manufacturer was looking for new ways to provide its customers with personalized, value-added services. After careful investigation, the company concluded that it could assist customers most effectively by:
- Helping them evaluate and select product and process technologies.
- Providing Just-In-Time product status and process-development status during the prototype and production ramp-up stages.
The result was a CPC initiative designed to give customers the tools, information, and services needed to improve their product-design capabilities. First, CPC technologies and processes were developed to support inter-company document management and vaulting capabilities. From there, personalized project portals were created to maintain and present up-to-the-minute status about the design, testing, and manufacturing of customers' products.
In addition to a unique "service franchise" and selling proposition, the result was an environment that incents the semiconductor manufacturer's customers to develop and manufacture their products with its goals and parameters "designed in."
Case Study 2: Helping Contract Manufacturers Manage Change
In the telecommunications industry, more and more OEMs are outsourcing their manufacturing operations. As a result, contract manufacturing is a rapidly growing field and acquisitions are common.
One recent CPC initiative was undertaken by a contract manufacturer seeking to leverage the power of several acquisitions by promoting standard processes across the organization and tightening relationships with OEM customers. Because contract manufacturers work primarily at the end of an OEM's product development cycle - providing testing, prototyping, and production services - there was a clear opportunity to collaborate more effectively around engineering changes. A Collaborative Product Commerce initiative helped the manufacturer take advantage of this opportunity by:
- Automating the engineering change markup and approval process with its customers
- Promoting a standard process with a common workflow technology applied across the organization
The company's new CPC capabilities shortened customers' time-to-market by eight weeks, which correlates to approximately $100 million in revenues. Reductions in scrap and rework costs trimmed another $5 million. In addition, the new CPC capabilities made it easier for customers to conduct business with the manufacturer, thus positioning it more frequently as a leading supplier of choice.
Case Study 3: Leveraging Acquisitions to Increase Market Share
Following a series of successful acquisitions, the revenues of a medical products company skyrocketed from $200 million to $2 billion. To leverage its newly acquired design and manufacturing capacity, the company launched a global, operational efficiency program based on collaborative product commerce. The heart of the program was a "Design Anywhere and Build Anywhere" strategy.
During Phase One, a central repository (data vault) was implemented to manage product-design and manufacturing-process data across all product lines and geographic sites. Accessible to all product-development personnel, this capability moves the company closer to a single global process: from product design through manufacturing. Benefits include increased product and process re-use for new projects, shortened times to market, lower product-development costs, higher product quality, fewer recalls, and tighter compliance with FDA regulations.
During the second phase, the company will improve upon its manual updating systems with CPC initiatives to automatically manage engineering change and integrate the applications that manage product data (e.g., CAD and SAP). These efforts will be followed by an enterprise-wide, intellectual-capital management initiative.
