1986-1996, GM Systems Engineering – Working to Achieve a Common Cross-Functional Vehicle Development Process
In 1986, the chief engineers of the North American Car and Truck Divisions set up the GM Systems Engineering Center (SEC) to advance common systems engineering practices across their divisions. This effort was coordinated by the Center personnel and actively supported by a team of systems engineers from the Divisions and Hughes Aircraft Corporation. Over the ten year GMSE led effort, several areas were central to the activity in bringing the groups and evolving common cross-functional processes together.
The Systems Engineering Process
General Motors, beginning in the mid-eighties and working with Hughes, converged on a systems engineering based vehicle engineering process as shown below. The process is driven by the customers’ wants and needs as show at the top left hand corner of this trapezoid. The left side represents what is called requirements engineering. It includes developing and allocating the requirements for the vehicle, and for the manufacturing and assembly processes to build the vehicle. These requirements “flow” directly from and, thus, are traceable to the customers’ wants and needs. The flow is from the customer to the vehicle, then to the subsystems, and then to the components.
On the bottom of the trapezoid we show the detailed design of the individual parts and components, which are assembled and developed to form the vehicle as shown on the right side of the trapezoid. In the middle of the trapezoid the validation process is depicted which includes both validation of the requirements and of the design to meet those requirements. Validation is done at the vehicle, subsystem, and component levels.
This process is often referred to as “top down” since it starts with a customer wants and, via a sequence of steps, leads to the creation of a product to meet that need. This differs markedly from the traditional process of developing an automotive vehicle by assembling a set of existing components to form subsystems, and then the vehicle.
The systems engineering process has provided the basis for GM’s Four Phase VDP, and for the Corporation’s movement to a math-based (virtual) paradigm.
Four Phase Vehicle Development Process (4ΦVDP) – Documenting & Improving Standard Work
This work product expanded the previously developed high level four phase process of gates and timing to the more expanded detailed activities required of each cross-function group supporting the development process. 4ΦVDP brought together all of the activities, defined sequences, deliverables value added and deliverables to be handed forward to the next group. This documentation then provided the baseline upon which future continuous improvement in the process steps could be built.
Requirements Engineering – Building Vehicle and Component Technical Requirements
Defining and documenting design-independent vehicle level technical requirements before the design activity starts is at the heart of systems engineering, brought from Hughes Aircraft. High level requirements allocations and flowing them to the component level creates the basis for good OEM/supplier performance.
Human Factors – Improving the Man/Machine Interface
A critical part of the evolving requirements engineering activity was defining outstanding requirements for the man-machine interface. The Human Factor Criteria Inventory (HFCI) developed a means to evaluate the performance of the softer side of man-machine interface design.
Creating a Vision for a Technical Computing & Information Management Infrastructure
As part of GM’s Systems Engineering capability development, the Systems Engineering Organization together with representatives from Hughes, and supported by EDS, examined the information required to create a vehicle following a systems engineering based vehicle development process (VDP). They also created a vision of how this information could be used concurrently and interactively by a cross-functional team, and went so far as to develop prototype systems demonstrating portions of the concept.
To put this activity in a bit better perspective, the late eighties and early nineties was a period before the WEB was pervasive. Traditional management information systems were typically mainframe computer based, not friendly, and not integrated with each other.
Vision Created by the Systems Engineering Team
The figure above illustrates the vision that we created at that time to show the use of integrated math-based information and tools to support the VDP. This vision comprehended the requirements engineering process, a key component of systems engineering that leads to a set of functional requirements for the vehicle, its subsystems and components. At that time GM was “experimenting” with Quality Function Deployment (QFD) as a tool for achieving this. In parallel, the physical product design proceeded driven by the requirements, as shown.
Supporting these activities and shown near the top of the diagram, is a technical computing capability which allows various concepts to be generated and evaluated, both in the functional and physical domains.
On the bottom of the diagram we show the integrated information management infrastructure to support a vehicle program. This consists of vehicle program information (including business information) linked together to a geometric design data base. The program notebook provides an audit path for vehicle program decisions and rationale. This integrated information is "drives" various corporate databases.
Part of our vision was a "corporate memory" or "knowledge base" (top of diagram). This consisted of the "tribal" knowledge of the Corporation, and is comprised of components such as technical memory and competitive information, rule based models, and analytical models and tools. The very concept of corporate memory is predicated on the theme of continuous improvement or learning, which is illustrated by the lessons learned feedback loop shown on the right. In this manner, the information gleaned by the vehicle program team is captured and put in a format so that it can be reused. The GM Systems Engineering Organization prototyped both technical memory and program notebook systems in the early nineties.
Another system that was an integral part of the vision and was prototyped was a Common Vehicle Program Information Management System (CPIM). The major objectives of CPIM were to provide vehicle programs the information required to run their businesses, and to facilitate vehicle program team and stakeholder (including suppliers) information exchange and communication. At that time a “sneakernet” was being used to provide that information as shown in the cartoon below.
Again, it is important to realize that this was before we had the WEB or even used email extensively. Using the best tools available at that time, a user friendly, graphical, client server system was built that provided the program team needed information augmenting and tapping into existing MIS systems, as illustrated below.
C4 – Coordinating and Creating the Tools of Math Based Design & Engineering
This activity focused on advancing the use of math-based tools for better and more consistent engineered results. The application of C4 technology was coordinated to reach a consistent set of tools supporting a more effective engineering process that could be effectively learned and continuously improved.
PDS – Migrating to a Common Release System
The effort to improve the Product Description System (PDS) the engineering release system focused upon getting to one system for all GM users
Tag Cloud
 |
English |