|
|
www.johnstark.com |
|
|
|
Information repositories need to be identified. These will contain engineering drawings, CAD/CAM and other electronic data, and alphanumeric engineering documents. The current methods of creating, numbering, classifying, communicating and storing engineering information need to be understand and quantified. The cost structure for preparation and distribution of documents should be understood. The volumes of drawings and other documents in storage and under modification are important parameters. The quantity of information communicated will be an important parameter for network design. There may well be comparatively little known users and repositories of engineering information that would be ignored without a wide-ranging analysis. Particular attention should be paid to engineering data in areas outside the traditional engineering area. There will probably be engineering information in production planning systems (such as ERP), NC part programming systems, process planning systems, analysis programs, test systems, quality control systems, office automation systems, F&A systems and spreadsheets. Suppliers, partners and customers may also store and use the company's engineering information. An inventory of existing IS systems related to engineering information should be drawn up. As well as systems such as CAD, CAM and CASE, the list should 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 listed and analyzed. Their use of engineering 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 data should be noted. A list of current engineering and IS projects that may affect engineering workflow and engineering information should be drawn up. The priority of some of these may have to be modified as a result of the findings of the project team. The project team should quantify the Information Systems ability and resources of the company. The aim of this activity is to avoid proposing a solution that requires IS support that the company's IS function is incapable of supplying or managing. The company's IS function may be centralized, or there may be a 'central' IS group reporting to the F&A Department with local IS support teams in each individual function. In many cases it will be found that the IS group sees F and A as its primary client, and all other departments as secondary clients, yet is unable even to provide F&A with the right service. Similarly, IS support teams in individual functions are often unable to address strategic issues as they are overwhelmed with mundane tasks. In such an environment it may be difficult to see where the resources for major EDM/PDM development and implementation work will come from. It will be for top management to decide whether new resources should be hired, or existing staff assigned new roles. If neither of these are possible, the Project team may be led to solutions that, once implemented, will require very little IS experience and support for on-going use. As the project team learns about the current situation it may well identify activities that are illogical and/or wasteful. Perhaps some administrative procedures will be found to be unnecessary or duplicated. Some documents or drawings may not actually be used. The project team should signal such findings in their report to management. It may be possible to initiate short-term actions to correct them. Once the project team feels it has obtained all of the information required, it should start to analyze, cross check and structure it. When this is done it will be apparent that the current process is full of redundancy and inefficiency. Activities should be ordered in logical sequence. Flow diagrams should be produced to visually represent the flow of activities and data. CASE tools may be used to represent information usage. However, in many cases use of CASE will be unnecessary, since simple flowcharts and project planning techniques will produce suitable results. The information that the team collects should, after analysis and structuring, be shown to the people interviewed to make sure that it really does represent the current situation. If it does not, corrections must be made and missing details added. Before the findings are presented to management, the team members should agree among themselves on the information being presented. |