On this page
Abstract
Collaboration in hardware product development needs to start at the inception of the project and extend through its entire lifecycle, integrating every member of the product team: engineers, project managers, suppliers, outsourced partners, and more. Most collaborative tools fall short of accomplishing this due to fundamental handicaps relating to how information is structured and how users can access and work with it.
A collaborative system needs to address the following key issues:
Arena has many inherent advantages over spreadsheets and client-server collaborative applications that enable it to address the issues named above.
In addition, Arena provides key features that enable organizations to work much more effectively not only with suppliers, but with outsourced design and manufacturing partners as well.
The BOM-centric, web-native approach of Arena creates a collaborative environment that extends throughout the product lifecycle and integrates all members of the product team, regardless of location. Because Arena addresses the fundamental challenges of collaboration, project teams are freed to concentrate on their core responsibilities: to produce more competitive products.
During the development of a hardware product, individuals with specialized skill sets are working on various aspects of a product. In a perfect world, each person’s work would mesh perfectly with everyone else’s, and the product would just slot together. The reality, of course, is that this never happens. In product development, mistakes cost money so the stakes are high, and therefore a lot of effort goes into setting up communication within the group.
The current practice for collaborating within product development groups is unstructured communication. Information is broadcast one-to-one: engineers talk to each other, the project manager talks to the purchasing agent, and so on. Each member of the team is responsible not only for his or her primary function, but also for being an active member of the communication network—collecting, filtering, and passing along information. Human oversight and error can cause failure in the system, which is why a lot of energy is focused on capturing information.
Another consequence of this ad-hoc solution is that there is no central repository for information about the object of collaboration—that is, information about the product itself. At any point in time, each member of the team is working with his or her own copy of a subset of the product data, often capturing data in an idiosyncratic—and possibly incomplete—form that works for the individual without necessarily benefiting the entire team. Decisions are often captured incompletely or not captured at all. These copies represent inconsistent versions of the same information: there is not “one version of the truth” about what the product is at any given moment. When these fragmented data sources are finally aggregated into a cohesive whole—as must happen at the end of the design process—conflicting pieces of information are often arbitrarily reconciled, causing delays, mistakes, and even data loss. This is a fundamental problem in any group collaboration project: in the absence of a definitive set of data shared within the group, team members risk working with bad information, and good information—decisions and authoritative data—can be lost during the reconciliation of individual data sources.
In product development, communication around the product information is often done around a bill of materials (BOM) entered in a spreadsheet. The logic behind this is straightforward: there must be a fast way to capture data in flux, and simple spreadsheets are capable of doing this. Unfortunately, spreadsheets cannot do more than simply snapshot data. There is no sense of the connectivity of data; each consequence of a change must be assessed and implemented manually. Multiple appearances of a single part in a BOM result in multiple entries of part data. And using spreadsheets in development introduces the burden of continually evaluating and implementing change by hand—yet another communication task that takes resources away from the primary job of designing.
The need for more sophisticated collaboration tools is compelling enough that many solutions have sprung up to try to fill it. But many of these solutions attempt to adapt existing product data management platforms to a collaborative environment, an undertaking that involves enormous re-engineering to create access to an inherently closed system. Naturally, these costs are passed on to clients. The result is that to set up a collaborative development tool of this sort, clients face huge implementation, IT support, training, maintenance, and upgrade costs for a solution that is fundamentally ill-suited to the purpose. While client-server development systems have worked hard to remain competitive in an increasingly demanding arena, the reality is that retrofitting aging technology creates security vulnerabilities, upkeep burdens, and prohibitive costs—for a solution that is handicapped by fundamental shortcomings when it comes to collaboration.
A final thought about collaboration, and perhaps the most relevant consideration in the current market, relates to outsourcing. There are enormous strategic and financial benefits to an organization to outsource key design and manufacturing tasks. Outsourcing adds new capabilities to an organization’s product development resources: certain things become possible that simply weren’t possible for a single group to accomplish. However, involving an external partner during any phase of product development requires good collaboration practices, well-structured information and clear, logically consistent communication about tasks. As discussed above, these goals are difficult enough for an organization to achieve internally, let alone with partners located around the world.
Collaboration is the key to increased competitiveness and innovation because it enables organizations to take advantage of core competencies as well as combine skills in financially advantageous arrangements to accomplish better product design. According to Business Week, Yankee Group Research Inc. estimates that over the next five years, collaborating over the Internet can save companies $223 billion by cutting transaction, production, and inventory costs.
The benefits of collaboration are obvious—but the best way to achieve collaboration is not.
A tool for product development must have certain key attributes to be effective for collaboration.
Regardless of the nature of the work it is doing, a collaborative group needs a unified framework for data aggregation: a structure to capture and organize the information developed by the group. Within this structure, there must be a common vocabulary and behavior; terms must be developed to describe objects and functions that are comprehensible to the group, and the data in the structure must follow a logical model with predictable behavior and consequences. These conventions enable users to rely on the system to provide a better solution than ad-hoc communication.
Aside from the way that information is treated in the data aggregation framework, the framework itself must be designed with the group in mind. Each individual in the process must be able to perform their key functions within the framework, and all the relevant data generated by these diverse functions must be accommodated. The products of the collaboration must be captured and reused: key decisions must be recorded, preserved, and broadcast throughout the group.
Finally, in addition to accommodating diverse information and users, a successful collaborative environment should also filter the information it contains. One way to consider this is in the context of “signal-to-noise ratio.” In other words, of all the information you receive on a daily basis, only a portion is relevant to you. An effective collaborative tool should increase the ratio of relevant information—“signal”—to irrelevant information—“noise”—by establishing filters that help people focus on the information that is relevant to them. A sophisticated collaborative environment includes controls for how information is propagated through the system, and what information is surfaced to each user.
On a more technical level, the information within a collaborative system cannot contain internal contradictions. In the product development environment, which incorporates information from many different sources, this is a critical issue. For example, if different people are working on a part, they must all refer to the same part number; if they use a different part number by accident, they introduce an internal contradiction into the system. This simple internal inconsistency can cause enormous confusion, and more subtle contradictions—which can’t be as easily caught as a simple part number error—can create tremendous problems the longer they persist within the system. A collaborative system must enforce rules for what data is entered and how it is entered, and enable the data to be checked against itself.
Data access is largely an interface issue, but also involves more fundamental principles. In a collaborative environment, data must be freely accessible to everyone in the group. Particular pieces of data must be easy to locate. And, ideally, the data must be available from anywhere so that users can make use of the tool at their convenience.
A second information access issue (related to the aggregation point mentioned earlier) is that different kinds of users should be able to see data according to their functional interests. Effective data filtration and clear data presentation will encourage people to use the tool. Users will not make use of a tool that does not help them do their work; on the other hand, the better the tool serves them, the more they will incorporate it into their working habits. Product information will thus be captured more completely and consistently, and the organization will benefit from a more efficient development process. A collaborative tool must be used to be useful; good interface design is required to encourage people to integrate the tool into their work.
The idea that data access must be controlled does not contradict the previous point (that data access must be clear). An organization wants to enable clear but not universal access to data; it is not appropriate for every member of the group to create or modify every and all types of information. This raises two issues: what information does an organization make visible to users, and which users are allowed to change that information.
Dissemination—the act of making information visible to members of the group—must be selective. Each member’s role within the group implies ownership of certain information—as well as possible exclusion from other kinds of information. In product development, most organizations strive for maximum visibility of information to as many users as possible, because the tools to fine-tune user access don’t exist and the assumption is that the more information is available, the better. But for complex collaborative groups that incorporate supply chain members, total data visibility is not desirable.
The privilege to change information must be controlled as well. A collaborative system must distinguish between users who can see information and users who can both see and change that information. Mistakes in product development can be expensive—mistakes due to unauthorized access to data are not only expensive but a sign that the collaborative system is not doing its job.
When data in the system changes, the updated information must be quickly visible to everyone who needs to see it. Most companies communicate change in an ad-hoc fashion: big changes are communicated quickly, while small changes often languish within one small group before making their way to the group as a whole. Users need to be able to rely on the system to communicate all changes in a standardized reliable way. In addition, the system needs to have the process integrity to implement changes consistently, so that a change takes effect without risk of being lost. Finally, the system must have referential integrity: each piece of data affected by a change must be updated, so that the consequences of a change are reflected along with the change itself.
Product development is idiosyncratic. Different organizations use different tools and applications depending on their industry, expertise, market, and budget. It’s not cost-effective for companies to install copies of every application for every user; the IT overhead for installation and support is prohibitive. The solution has been to print data for review on paper, or to import and export data between tools. But this introduces the tasks of translation between tools and mediums, which adds non-productive time. A collaborative tool needs to be flexible enough to work around a variety of tools, facilitating the communication between them, while remaining a cost-effective solution.
Product development by definition involves working with external suppliers. Mistakes with the supply chain are expensive in time and money. For example, specification changes made during the time that a supplier is trying to fill an order must be communicated to the supplier immediately; there is significant financial exposure for an organization that fails to get information to its suppliers in a timely manner. Ideally, suppliers should be treated as members of the product development team, with access to up-to-date information about what they’re supposed to quote and deliver. Ideally, this access should be easy—but not unrestricted: every organization needs to protect its intellectual property.
Once the communication with a supplier is transparent, there is an opportunity for the supplier to contribute information to the process as opposed to simply receiving information. This is not a requirement for a collaborative tool, but an enormous benefit if the collaboration works well. Enabling suppliers to contribute to the design process can ultimately improve an organization’s products.
Arena is designed to be a collaborative environment, so it has many inherent advantages over alternatives such as spreadsheets or client-server collaborative applications.
The bill of materials (BOM) is the framework to capture and organize product data. Arena uses the BOM format as its content aggregation framework. The BOM is the ideal content aggregation tool for product development data because it accommodates large amounts of data of any complexity, and it can be filled in as development progresses. Arena users don’t have to learn a new proprietary data format, but can work within a format they already know. In addition, the BOM is final deliverable to manufacturing. In Arena, product data is developed within the structure of the BOM itself, so there is no extra step needed to gather, re-format, or organize product data to create the final manufacturing BOM. And finally, because the BOM is universally understood across industries and around the world, people can instantly navigate product data in a BOM format, which eases collaboration in general.
Database architecture establishes data consistency. Arena is built on a relational database, meaning that each item in the system exists once. Multiple instances of an item in one BOM—or many BOMs—still point to a single entry in the database, so a change to an item is instantaneously reflected everywhere that item is used. If an item is re-used in a new product, that same single instance of that item is referenced in the new assembly. There are no dead links: up-to- date information is always reflected, and connections between items are always valid. In addition, all items are consistently entered and displayed, adding internal consistency. All of these qualities require no extra work on the part of the user—they are the automatic consequences of the database that underlies the system and the data model that Arena Solutions has developed.
The web-native design provides clear access to data. From both an architecture and an interface perspective, Arena gives clear access to information. Arena runs over the Internet, so users can log into their workspaces from any web-connected computer. There are no “remote users” who need special passwords or a virtual private network (VPN) to use the system; there are no client applications that need to be installed at each user’s computer. The system provides consistent access to everyone regardless of location.
The interface is designed for maximum usability as well. Rather than focusing on tasks—and presenting an interface tuned to the functions that a particular user performs—Arena focuses on the types of information in the system, presenting an interface organized around “worlds” for items, suppliers, and so on. The interface for each user is the same; there are no specialized terminals for particular tasks. While some users may be allowed to perform certain functions, the links and buttons to perform these tasks are always in the same location.
Within this unified interface, Arena focuses on streamlining critical tasks. Users can search for any kind of item from any location in the system. Items can be stored on a “dashboard” for quick access. The system remembers which item a user was last viewing, so if a user is sidetracked by a particular task, it’s easy to return to the “last visited item” to pick up where he or she left off.
User roles provide structured access.Account administrators can assign access roles on a user-by-user basis and fine-tune each user’s level of access as required. In addition to this basic level of control, Arena includes more sophisticated access controls as well.
Privilege management tools have intelligence built in to share primary information with the right users. Specific privileges control who can make changes, create versions and move items between stages.
Version control allows communication about the status of individual pieces of data. Because data can be locked down into an effective version, the group can be certain about which iteration of each item in a product is current. User privileges control whether a user can release versions; separate access roles assign release privileges according to the different stages of development. All users can be certain that the status indications are authoritative.
Changes are pushed out to the people who need to know about them. The change approval process is designed to give users pre-release access to and approval of planned changes, not just to provide notification of past events. Notifications ensure that people are actively alerted about version releases of components and assemblies that concern them. Each notification is recorded with the version; the positive record of notification establishes accountability.
Information travels through the system instantaneously. Because each part exists in a single instance in the database, updates are instantly visible throughout the system. Multiple instances of a part in the BOM point to the same reference in the database, so each change is instantly reflected everywhere an individual part appears; there is no danger of an update not being propagated, or of an inconsistency being introduced into the system. The notification system enables users to subscribe themselves and their suppliers to the parts and assemblies that concern them so that they are automatically alerted when versions are released of those items.
Arena is designed to work with other applications. Arena enables users to associate any number of attachments to an item: documents, web pages, links to files on internal servers. Integration adapters go even further by establishing data links between program files and the data in Arena. Data can be quickly exported in a standard comma-delimited text file at any time, so hand-off to ERP systems is streamlined, and data can be quickly imported and integrated into the workspace.
Sharing features provide access privileges for suppliers. Arena users can invite suppliers to view item data within Arena, which ensures that the supplier is looking at the same data as every other Arena user. Sharing is electronic—the supplier is emailed a link to the appropriate item within Arena—so the process is instant and requires no printing, faxing, or emailing of data. The result is that suppliers are essentially part of the design process, and the integration is automated so that it doesn’t require management overhead.
Additional benefits
Arena does more than just satisfy the requirements for a good collaborative tool. It delivers a number of added benefits.
Retention of institutional knowledge. Over time, Arena becomes the repository for institutional knowledge: records of how certain design challenges were solved, how iterations of innovative technology were developed, and how the product development process was handled. Arena captures and securely stores product data, , for reuse and analysis.
Better product design. Arena enables an organization to focus its resources on solving design problems instead of managing communication. Furthermore, by facilitating the outsourcing process, Arena enables organizations to work with more advanced technologies and materials than would otherwise be possible.
Increased capacity for growth. Organizations can evaluate themselves—how decisions are made during the design process, the frequency and impact of design changes, how costs are incurred and reduced, and so on—in order to refine their processes for designing and producing products. Organizations can become more efficient as employees focus on their core capabilities and deliver more value, and can more easily scale, as information is centralized and universally available instead of concentrated with a few key employees. And finally, it’s much easier to re-use past work, enabling organizations to build on past design decisions and accelerate improvements.
Enabling individuals to focus on core competencies. Arena manages the collaboration process so that individuals are freed to concentrate on their primary responsibilities. Engineers no longer need to take extra steps to share their work—they simply work with data directly in the application, and others can instantly see what’s going on. Project managers no longer need to call frequent meetings for updates on the progress of the project; centralized data and numerous analytical views provide direct insight into a product’s status.
Outsourcing enables organizations to work with each other to capitalize on their unique competencies and advantages. Successful outsourcing of design or manufacturing projects can cut costs, improve product quality and open new markets. Outsourcing can be undertaken during both the design and production phases of development, but each undertaking has different objectives and requirements.
Outsourced manufacturing is undertaken to reduce costs for such things as labor and parts. An additional benefit is that it isolates product costs during manufacturing: the cost of goods sold (COGS) is known with precision because it is paid by invoice to the manufacturer.
However, outsourcing requires that design documentation be rigorous and accurate; excellent product documentation results in better product quality and lowered maintenance costs. The process of handing off documentation to an outside party introduces a kind of formality to the process that raises the bar for the quality of the engineering deliverable. But this greatly increases the pressure on the engineering group to positively document every aspect of the product.
The biggest obstacle to effective use of outsourced manufacturing is that organizations can’t deliver sufficiently complete and robust documentation. This factor is also the key issue for outsourced manufacturers themselves: the biggest impediment to success in their relationships with their customers is that they do not receive adequate documentation and the quality of the produced product is compromised.
The goal of outsourcing a design project to a consultancy group is to improve the design of the overall product. A design consultancy can provide specialized skills that an organization may not be able to support in-house. Customer expectations are constantly increasing, but many companies can’t afford full-time staff dedicated to developing new technologies, so a design consultancy selected for its expertise can provide access to innovation.
The complex logistical issues here can be considered as two distinct but interrelated obstacles: cost and integration. A good portion of a design consultancy’s fee goes toward the administrative overhead for collaboration: project management, meetings, and so on. The second obstacle, integration, concerns the personal interactions between the consultancy and the client, as well as the physical integration of the delivered design into the larger product. Bad integration on the personal level degrades the quality of the collaboration by introducing frustration into the relationship. And bad integration on the physical product level produces designs that must be modified to work or, at worst, discarded.
In an outsourced design relationship, the consultancy carries a documentation burden, as if it is outsourcing the manufacturing of its product. And the client must work to integrate the consultancy into the design team and into the design process to ensure the productivity of the relationship. If communication between the consultancy and client is not transparent, the consultancy can become a “black box”, working in isolation from the client organization and potentially delivering a mismatched or even unusable design.
Arena can accommodate very complex outsourcing arrangements. If all parties are Arena account holders, collaboration becomes very easy. But even if only one member of a complex outsourcing relationship uses Arena for its product development, there are still significant benefits to involving other partners on even a limited basis.
The Arena collaborative benefits listed earlier translate into specific advantages for managing outsourced relationships between client organizations, suppliers, design consultancies and contract manufacturers.
Internet-based technology provides instant access to remote users. All users have Internet-based access to Arena regardless of their physical location. The process for getting new collaboration partners started is very fast: access is instant-on so new users can get to the product data quickly.
Privilege management ensures that all parties have appropriate access to data. Each user can be assigned an access role that provides the appropriate visibility and change privileges without giving unrestricted access to intellectual property. Sensitive information such as cost quotes can be hidden from particular groups of users if desired. Component manufacturers can be restricted to particular components or assemblies that they supply. Change privileges for consultants can be set so that they can freely work with product data, but the client organization can retain approval over locked-down versions. On the other hand, users can also be given significant autonomy, while the client can be automatically notified of changes. The Arena notification system handles this automatically so neither client nor outsourced partner needs to manage the relationship.
Content aggregation framework centralizes data. All users are working with the same set of product data, so that when one piece of data is changed, every reference to that data is updated. There can be no confusion over out-of-date information.
All data is captured in structured form from beginning of design process. Because product data is natively stored in BOM format, there is no additional step to prepare a special documentation package for hand-off to manufacturing. The data is high quality and comprehensible both internally and externally.
No expensive install, IT support or training is required for suppliers or outsourced partners. The cost of using Arena for collaboration is negligible relative to its advantages (and to the costs of alternatives such as client-server applications). The instant-on sharing capability makes it easy and cost-effective for organizations to integrate suppliers into the development process; suppliers do not need to invest time, effort or money to install or train to use Arena.
Product data is visible during design. Design consultancies can provide a high degree of visibility to their product data to their clients during design, which eliminates the black box phenomenon and facilitates the relationship and integration with the client. Contract manufacturers can be shown product data before hand-off, so they can review the BOM and identify problems before ramp. And for all participants, communication about the product is easier because everyone is working with the same information.
The product development process is complex, and the benefits above come into play in numerous ways during the day-to-day interactions between collaborative teams. One way to understand the positive impact of Arena for collaboration is to consider some specific scenarios.
Design consultancies are often asked to use their client’s purchasing system to generate purchase orders for prototype parts. This helps the client monitor costs during the design process, but also requires the consultancy to communicate very intensively with the client’s purchasing department. With Arena, sourcing information is centralized and linked to each part, so the consultancy can easily specify approved and potential source options. The purchasing BOM view clearly indicates what needs to be purchased, who it will be purchased from, and the active quote for each item—and it reflects changes to information as soon as they are made.
Original equipment manufacturers (OEMs) often need to collect competitive quotes from multiple contract manufacturers during the sourcing process. Traditionally, this procedure involves producing duplicate copies of full product documentation, followed by a bidding phase where detailed quote information is gathered. In the meantime, if any part specifications change, the updated information must be packaged and re-sent to each manufacturer. With Arena, there is a single instance of the product data available online and always up-to-date. Access is granted electronically so there is no printing, shipping or faxing. The contract manufacturers invited into the workspace can’t see one another’s quote information, so the OEM retains privacy and control. And the OEM has confidence that the competitive bids are truly competitive—that is, based on the same product specification information. Soliciting bids is greatly simplified to a process of setting up access privileges and emailing a link to potential suppliers.
During the bidding process with a contract manufacturer, an OEM’s design can change, and the OEM needs to be certain that the contract manufacturer is aware of the changes when they occur. Traditionally, this means a lot of phone calls, faxes, and emails, followed by double-checking the contract manufacturer’s bid to make sure it’s accurate. With Arena, the OEM can subscribe the contract manufacturer to the part or assembly in question. Whenever a change is released, the contract manufacturer is notified and a record of that notification is preserved. If multiple contract manufacturers are involved, each one is automatically working with the updated data. The OEM does not need to worry whether the contract manufacturer has the adequate IT structure to incorporate the change into its data set—the data remains centralized in Arena and instantly available. In addition, contract manufacturers can use Arena to share as-built BOMs with their clients, using the notification system to alert the client to changes.
During product development it’s possible for an OEM to make a change to a component during the lead time required for procurement. Imagine a hypothetical situation where the component is shipped without incorporating the change. Traditionally, this creates a very messy situation. With Arena, there is an unambiguous, positive audit trail of notifications of change, both establishing accountability and protecting each member of the system.
Many OEMs choose to work with design consultancies for circuit board designs, while the OEM’s own engineers work on the mechanical design. These parts must fit together. If an engineer makes a mechanical change that affects the electrical design—for example, moving a connector—the consultancy needs to know about the change. Traditionally, someone at each end must continually monitor the design of critical interface elements and know to alert the other team about changes. With Arena, each user can subscribe to the parts he or she is concerned about, and be notified automatically of changes. The system does not rely on a human to make the connections between separated teams, and a positive record of notifications is created to ensure accountability.
As an OEM completes the design process and prepares to hand it off to a contract manufacturer, the product data is typically scattered and unstructured. A project manager must collect and prepare the data for delivery and confirm that the documentation package is complete. In the relationship between an OEM and a contract manufacturer, the product documentation is the critical requirement for success, and mistakes due to incomplete or inaccurate documentation have a direct impact in both cost and time: slower ramp means slower time to market and potential lost revenue. This adds a lot of pressure during the hand-off process to check and re-check the documentation for completeness, and many organizations build extra time into the schedule to allow for this. With Arena, product data is already aggregated and formatted, so the hand-off process consists of emailing a link to the contract manufacturer. The OEM can invite the contract manufacturer to review the product data as hand-off approaches to avert potential problems and facilitate the ramp process.
Collaboration in product development is not a new idea; designers, managers and manufacturers have always needed to work together to bring a product from concept to manufactured reality. But increasing market pressures are driving organizations to work with each other in ways that challenge traditional collaborative systems.
©2012 Arena Solutions, Inc. Arena and Arena Solutions are trademarks of Arena Solutions, Inc., Reg. U.S. Pat. & Tm. Off. All rights reserved. Other product and company names are the property of their respective holders. Contact Arena at questions@arenasolutions.com for permission to repost or syndicate this content.
Ready to start? Try Arena free for 10 days. Sign up
