Case Study: Ford Motor Co.

Case Study: Ford Motor Co.

by Kevin Shea

Ford Motor Co. is learning how effective collaboration can be in driving efficiency in its product development process.

Collaboration in product development is defined as "group creation, access, exchange and sharing of product development knowledge inventories, leading to increases in overall [product development] process efficiency." In the case of product development, these groups would include product engineers, program managers, system integrators, purchasing agents and others from both the development firm and its suppliers.

Alternately, collaboration in product development could also be viewed as the integration of PD interactions into a fluid environment of information access and exchange, in which single one-to-one interactions are replaced with shared many-to-many interactions. Collaboration opens product development process information equally to all participants and removes barriers and problems that may exist from excessive one-to-one interactions.

Specifically, collaboration in product development, or CPD, makes all process activities open so that team members can fully discuss, share documents, add comments, vote and otherwise conduct a free exchange. In addition to this direct support for process, CPD can also be used to share knowledge; it can provide a well-defined recent running history (or be archived as a historical record); and it can support lessons learned.

Binary Engineering, an engineering consulting firm, has been assisting Ford Motor Co. in establishing collaboration within its product development activities. Binary first assisted Ford by assessing its product development, or PD, process, then defined needs and sought opportunities for improvement. Needs were determined to be:

o Improved communications (internally, internally among remote peers, and with remote and geographically dispersed suppliers);

o Increased sharing and exchange of critical documents in a secure environment;

o Ability to rapidly respond to changes in such documents, and to create a version history;

o Assurances that only "the single, correct" documents are shared and exchanged;

o Ability to integrate documents in process flows or in packages that are controllable, and thus shareable with suppliers;

o A common approach that could support the defined PD process as well as apply broadly throughout the extended supply chain;

o A method to capture lessons learned; and

o A system that would allow self-service to information from anyplace to anyone.

The idea of "self-service" originated from the desire to reduce engineering activities that are associated with requests for helping someone find something. Low-value activities like finding documentation consume a significant amount of an engineer’s time. When engineering activities are interrupted by such requests, revenue-generating man-hours are reallocated to more mundane administrative tasks. When PD engineers support multiple product lines with numerous suppliers, the number of requests is large. To this end, Binary generated a requirement that prompted Ford to create a means by which individuals can readily retrieve an item themselves.

In addition, other needs existed which defined the need for "more discipline" throughout the process. Those needs included increased consistency, more common methods, and additional structure—all with an eye toward flawless process execution.

Using these criteria, Binary and Ford opted to implement a solution using eRoom, a general-purpose collaboration application from eRoom Technology. ERoom provided the basic capabilities that would satisfy the general needs and yet would be customizable to suit the unique needs of Ford. In selecting an IT solution, it was also critical that the solution satisfy ease-of-use requirements. The selection of eRoom followed an evaluation of multiple applications against all these criteria.

In assessing Ford’s existing PD process, a number of inefficiencies were also uncovered. These inefficiencies were the result of factors ranging from differing implementation practices among engineers to the influence of other IT solutions to the crowded pool of "competing" IT solutions, which were mostly task solutions attempting to address process problems.

After the collaborative solution was presented to the early-adopter PD teams, the teams quickly understood the potential benefits of using the technology in collaborative product development. It became apparent that the eRoom digital workplace began to serve as a process enabler. As teams sought to implement a solution to address their needs, they became more aware of inefficiencies and, using features of eRoom, were able to create proper solutions that align process needs with IT, rather than being force-fit into an IT tool.

PD within automotive firms is a vast endeavor incorporating dozens of engineering groups and sections, thousands of documents and countless suppliers. This size placed challenges on both the design of the digital workplace as well the scalability of the application. From the start, the design and deployment of the workplace needed to be an enterprise solution, not just a project solution. The design also needed to be consistent, so that when it was deployed, it could be used similarly across the enterprise.

Ford’s design approach was to create common structures and common approaches, with a consistent "look and feel," and then integrate these across the PD infrastructure. Different needs of program management engineers, subsystem engineers and component/parts engineers had to be accommodated, and then integrated. A cleverly crafted set of "libraries" was needed. In one case, the design structure implemented for component needs resembled a paper-based, parts catalog complete with photograph, important details, schematics and links to all the supporting specifications, requirements, test results, timing charts and commercial documents, etc. The subsystem workplace shared design concepts of the component workplace, but integrated additional layouts to provide a collection mechanism that resulted in total subsystem release packages.

These, and other structure subsets, effectively created visible "inventories of PD knowledge" that support specific process needs. However, not only did the digital workplaces need to be internally consistent, they had to be capable of supporting the large enterprise requirements of the company. It was necessary that these inventories be linked and shared and that "information cascades" be established. These cascades needed to mimic traditional working relationships and process information flows.

By following the PD process and creating common process structures, the company now has the foundation for creating knowledge inventories. With the structures in place, the engineering staff then needed to populate the digital workplaces, often by moving documents from desktop folders to the proper location. Continued population, commenting and active sharing will follow, as collaboration becomes a more natural part of the PD process.

So, how does a CPD environment work at this company? A vehicle systems manager, for example, wishes to conduct a technical design review of the wiper subsystems. The manager enters the subsystems workplace and selects wiper subsystems. The structure found therein contains all related specifications, including all versions and changes occurring from initial release through to the present, all schematics—which can be reviewed online (again with versions/changes noted), design analysis, computer-aided engineering, all test plans and test results to date, and any other subsystem related data. The manager could also review, as necessary, all comments that team members contributed during initial design or in-design changes.

Should the manager be interested in how the requirements cascaded to the parts for his vehicle, he can select the subsystem Bill of Material and, selecting the part, link directly to the component workplace that contains all part-related specifications, drawings and test results, etc. By establishing the process connections and interactions within the workplace structure, a complete cascade of relationships from vehicle to system to subsystem to component is achieved. Should the vehicle systems manager be working on Saturday, he can accomplish this without the need of any other program engineer since self-service has been built into the collaborative environment. An added benefit is that this "review" can be conducted not only at any time but can be done at remote locations such as home, a quiet location to limit interruptions, on a business trip or at a supplier’s location prior to an onsite review. No longer will material need to be "carried" to a review. It is always ready and available to be reviewed.

Another scenario could have a supplier being notified that all contractual responsibilities are contained in a layout called a "release package." Each appropriate item (or correct version of the item at the time of contract) has been assembled within the release package. The supplier and company engineer now collaboratively conducts all communication within the release package layout, assuring that all relevant communication and comments are captured and maintained either for demonstrating contractual compliance or creating a history.

In this case, collaboration has established a tight linkage to the corporate process, captured all relevant materials and made them available to persons, who by either direct collaboration or self-servicing can quickly understand the total picture and history of the design activities.

ERoom by itself is effective, but when it is operated in conjunction with tools such as NetMeeting, or other such collaborative communication tools, remote and geographically dispersed situations become even more effective.

CPD may demand some alternative behavior on the part of engineering staff. In cases where individual contributors dominate, the move to collaboration may be slow. Conversely, where team-based design and development is prevalent, collaboration may be more accepted and embraced. Collaboration requires openness and sharing of ideas. It requires less fearful contributions and commenting. It provides an avenue for discussion, for sharing and for team growth outside of traditional meetings. Product development engineers tightly locked on personal control of information may be difficult to move into collaboration without incentive. On the other hand, for product development engineers disillusioned with too many meetings, it provides a means to stay connected without the need for boring meetings.

In terms of the financial bottom line, Ford has found that the use of a digital workplace has resulted in reduced travel costs and less need for co-location, resulting in reduced relocation costs. Additional value is found in reduced audio and videoconferencing costs, reduced information transmission costs such as fax, reduced printing requirements, and reduced time waiting for information hand-off.

CPD is at the early stages of design. It is being tested and probed. It is driving new thinking into product teams seeking to improve. It is challenging behavior of classical "cubicle think." And it is providing a means to break down barriers in supplier/customer relationships.

For a company seeking to maintain advancement of its continuous process improvement efforts, CPD may prove to be a key factor.