|
|
www.johnstark.com |
|
|
|
As well as understanding the overall flow and use of engineering information, the project team should also address the individual activities that create or use this information. These activities, such as engineering design, process planning and NC programming will probably be partly automated but still have a significant manual content. The project team needs to understand the information needs (input, processing, output and storage) of each application area. These applications, which are part of the overall engineering information process, will need to be integrated into the overall EDM/PDM solution. The different structures of engineering information such as Bills of Materials, assemblies and parts lists should be identified, and other associations such as product/drawing relationships clarified. The project team will begin to understand the way that packets of information are created, modified, and moved between activities. The project team should describe each activity, its objective, and its position in the overall activity flow. If necessary the activity should be broken down into its constituent tasks. The project team should identify who is involved in the activity, how long it takes, and how often it is carried out. The information input, created, used, and output should be described, as should the sources of information and the definitions of information. If possible, the cost of the activity should be identified. Any information systems used in the activity should be identified, their information requirements described, and their interfaces with other systems described. Management procedures and performance measures associated with the activity should be described. Any problems with current operations, or non-conformance with documented procedures should be noted, as should suggestions from people involved in the activity. As the individual activities are examined, the project team will begin to understand not only the information needs of each activity but also some of the parameters concerning the volume of information involved. These will include the number of existing products, parts and tools, the annual number of new products, parts and tools, the number of modifications, the number of new and modified drawings and other documents, the number of drawings released daily, typical design times, the number of engineering changes, the timing of engineering changes, the time taken to process engineering changes, and the number of levels and constituents of Bills of Materials. The amount of data created each year by computer-based systems will be found and analyzed. The volumes and lifetimes of products need to be understood. It is important to know these parameters as the EDM/PDM requirements of a company oriented towards low-volume, short-life, fast-changing products will be very different from those of a company with mass-produced, long-life, products that undergo little modification. The project team will be able to outline a picture of the current organization of the company from the point of view of engineering information. This will show the number of users and their location, both geographically and functionally, and the way they store and communicate information. It will show where data is stored and how it is shared. The sources and users of engineering information should be identified. This exercise will highlight the large number of users who are not within the conventional definition of the Engineering Department. An attempt should be made to understand how users create, access, modify, store and communicate information. The access needs and rights of users and groups of users need to be understood by the project team. Shared and redundant data needs to be identified. Data standards and data ownership must be understood. It is useful to understand the activities of the various groups, or classes, of users. It will be found that different classes of user have very different activity profiles. Some users are mainly involved in creating product or process definition data, others in managing documents, in managing changes, in managing configurations, in managing the overall engineering process, or in managing relationships with other functions. Within each class it will be found that users often spend relatively little time in their main task. For example, individual design engineers may only spend about 40% of their time defining product and process data. Another 40% of the time may be spent on documentation, and 20% on communication of various sorts. Engineering managers often spend over 50% of their time just trying to understand the current status of projects. As well as looking at information use and flow along product paths, the project team should also look at the structure of product paths, and identify the typical milestones, events, and management activities along these paths. There will be different structures for different product lines, and, no doubt, some individual projects will follow specific rules. This information will help to provide the generic product life cycles that are a key component of effective EDM/PDM. The project management techniques in use should be identified. Project status and review needs should be identified. This information will also be needed for workflow management. The management of engineering information, in particular at departmental boundaries, needs to be understood, as do data security and data integrity issues. Existing data management systems need to be examined. The transition rules between the different states of information must be classified. The rules vary along the product life, from the initial product concept, during which the information's owner can modify it at will, to the time when the product is in the customer's hands, and information can only be modified if strict conditions are met. Review, release and change processes need to be understood. The project team should discover how many engineering changes are made, and the way they are made and recorded. The time and effort required to carry through changes should be brought to light. The roles and rights of users and managers at change and release time must be understood. |