|
|
www.johnstark.com |
|
|
|
The 'as-is' situation prior to an PDM project can be addressed under the following nine headings:
Because there's so much information available it's important to define upfront:
The scope needs to be clearly defined. It can be enterprise-wide, departmental, or focused on a particular product, site, or part of the process. Defining the deliverables upfront will help define the approach. The major deliverables could include:
It's important to identify each activity in the product development process, its objective, and its position in the overall flow. If necessary the activity should be broken down into its constituent tasks. Identify who is involved in the activity, how long it takes, and how often it is carried out. For each activity, 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. The different structures of engineering/product information used in the activity, such as Bills of Materials, assemblies and parts lists should be identified, and other associations such as product/drawing relationships clarified. Any information systems used in the activity should be identified, their information requirements described, and their interfaces with other systems described. Management style, procedures and performance measures associated with the activity should be described. The power structure and the culture of the people in the activity should be described. Problems with current operations, or non-conformance with documented procedures, should be noted, as should improvement suggestions from people involved in the activity. As the individual activities are examined, the information requirements of each activity will become clear. The main parameters about the volume of information will become clear. These will include the number of existing products and parts, the annual number of new products and parts, the number of modifications, and the number of new and modified drawings and other documents. It will also include 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 needs to be calculated. The sources and users of engineering/product information will be identified. The way in which users create, access, modify, store and communicate information should be described. The access needs and rights of users and groups of users need to be understood. Shared and redundant data needs to be identified. Data standards and data ownership have to be understood. As the current situation is examined, it will be possible to build a picture of the current organization of the company from the point of view of engineering/product 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, who owns it, and how it is shared. As well as looking at information use and flow along the product lifecycle, it's also necessary to look at the structure of product lifecycles, and identify the typical milestones, events, and management activities associated with them. There will be different structures for different product lines, and, no doubt, some individual projects will follow specific rules. The project management techniques in use should be identified. Project status and review needs should be identified. The management of engineering/product 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. Transition rules between different states of information must be classified. The rules vary along the product life, from the product concept, when 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 roles and rights of users and managers at change and release time must be understood. Information repositories need to be identified. They will contain engineering drawings, CAD files, text documents and other forms of engineering/product information. The current methods of creating, numbering, classifying, communicating and storing information need to be understand and quantified. The cost structure for preparation and distribution of information should be understood. An inventory of existing IS systems related to engineering/product information should be drawn up. As well as systems such as CAD, CAM and CASE, the list will probably include systems used in analysis, project management, technical publications, documentation management, configuration management, and release control. The corresponding computers should be identified. The programs in use should be described. Their use of engineering/product information needs to be understood. Any data base management systems in use should be closely examined. Interfaces and information transfer between systems should be described, as should transfer of information to and from supplier and customer systems. Any use of Electronic Data Interchange (EDI) for engineering/product data should be noted. Once the information has been obtained, it should be analyzed, crosschecked and structured. Activities should be ordered in logical sequence. Flow diagrams should be produced to visually represent the flow of activities and data. The information collected should, after analysis and structuring, be shown to the people who provided it to confirm it really represents the current situation. When this has been done it will be clear that the current process is full of redundancy and inefficiency. It will be apparent that some current activities are illogical and/or wasteful. Some administrative procedures will be found to be unnecessary or duplicated. Some information may never be used. Usually there are good historical or cultural reasons for these oddballs. Understanding them, and understanding why the oddballs continue to exist will make it easier to understand how to bring about change. Findings about waste in the process should be included in the 'problems' and 'proposed improvements' sections of the deliverables. It should be possible to initiate short-term actions to correct them, and make related savings quickly. This will be appreciated as it will help to demonstrate the real benefits of PDM. |