|
|
www.johnstark.com |
|
|
|
The four major areas that the project team needs to understand before proposing a solution for EDM/PDM are the current engineering process and information environment, the company's business objectives, the users' requirements and the functionality of the systems available. Study groups may be set up within the project team to address particular issues such as understanding the flow of the current product development and manufacturing process, describing the systems currently in place, and identifying the EDM/PDM activities of competitors. At a later stage, individual study groups could take on tasks such as describing the required systems and estimating the business benefits of EDM/PDM. The description of the current situation addresses seven subjects; the functional use and flow of engineering information, the activities that create and make use of engineering information, the organization of engineering, the users of engineering information, the life cycles of products and projects, the management of engineering information and the engineering process, and the current methods (both manual and automated) of creating, communicating and storing engineering information. Information models will need to be developed to help describe the current situation. However, since many months or even years can be spent in developing information models, this activity should be kept under close project team control. Although modeling is a useful activity, it can become very expensive and time-consuming if pursued to a too-detailed level. Initially the project team may only need high-level information models, with further refinement only taking place once a high-level EDM/PDM strategy has been defined and it is possible to see where modeling would be most effective. The project team must define the objectives of modeling, and the expected end product, before initiating modeling activities. Where appropriate, existing models can be used. In this stage of the EDM/PDM project, the project team will collect a lot of information about the way engineering data is used and created in the company. Before jumping on their horses and riding off to aimlessly interviewing all and sundry, the team should define:
Part of the answer lies in the definition of the boundaries of the project. However, the boundaries don't define how the content is to be collected. A top-down approach or a bottom-up approach could be taken. Alternatively, the approach could follow the product life cycle for a particular product, following it through marketing, conceptual design, engineering, analysis, testing, detailed design, drafting, production planning, process planning, tooling, Numerical Control (NC) programming, machining, assembly, Quality Control, testing, packaging, distribution, and after-sales, identifying for each activity the input, use, creation, storage, and output of information. Alternatively, the approach could follow the way an order from a particular client is processed. The approach could make use of a written questionnaire and/or face-to-face interviews. Defining the deliverables due at the end of the activity may help the team to define the approach. The major deliverables could include:
As it will probably not be possible for all team members to be involved in gathering information to answer each question, it will be best to work in small groups of 2, 3 or 4 people. The person from the function most directly related to a question should be involved in finding the answer, but so should people from other functions. A team member from the upstream source of the information and a team member from a downstream user function are suitable candidates. This reduces the risk of a biased answer, and helps team members gain cross-functional knowledge. The team is jointly responsible for the results it produces. At the end of the process, all team members should understand all the answers, understand what they mean, and agree with them. If this is the case, a solid engineering data knowledge base will have been built, and consensus achieved. This will be the ideal starting point for the next activities - defining an EDM/PDM strategy, and selecting an EDM/PDM system. One extremely important input to the project team, that can only be obtained from top management, is information on the business objectives of the company as they relate to EDM/PDM. In most cases, top management will not be able to give this answer directly. The project team will have to piece it together from information that is more readily available, such as the company strategy, and the individual IS, R&D/Engineering and Manufacturing strategies. The relationships between business objectives and EDM/PDM may also become apparent from the issues raised, and the concerns expressed, by top management when discussing EDM/PDM and related subjects. The project team should try to identify the four or five factors, and business metrics, that seem to be most important for management. These could include, for example, the need to be CALS-compatible for work with the Department of Defense. There could be a need to reduce lead times significantly, or to improve product quality. There could be specific problems that have to be avoided or relationships with powerful customers that need to be improved. There may be the intention to suppress some product lines, or to develop new, or improved, products. There could be plans to change the way clients and markets are addressed, or the way work is carried out with design partners. Management may want to focus use of EDM/PDM on reducing product cost. Management may want to introduce major business programs such as Total Quality Management (TQM), Just In Time (JIT), or Design for Manufacture (DFM). Management may be aiming to reduce the lead time in the engineering department by 50%. The factors of most importance to management should be very closely linked to business strategy. These top-level issues are just as important for the future of EDM/PDM as the technical requirements. If a particular product or process is to be abandoned, then there may be no reason to include it in the analysis. Its exclusion could significantly change EDM/PDM requirements. A company intent on market dominance through lowest unit cost may have very different EDM/PDM requirements from one that will manufacture to specification in a speciality niche market. If possible, the information obtained from management should be quantified. If the information is quantified, it will have more meaning, and can be used later both as a target and as a measure of progress. It is not enough to know that profitability and market share must be increased, some quantification is needed. There are hundreds of ways qualitative objectives like these can be met. Without quantified targets it is not possible to differentiate between them. Once management has set the targets, the team will be able to differentiate between possible solutions. If the project team believes that EDM/PDM can not help achieve a quantified target, it has to be able to tell top management why this goal is unrealistic. In such a case, the project team might be able to propose another solution, perhaps involving the removal of a bottleneck in the process. The business objectives provide a clear business focus for the project team. This will help them greatly and, in particular, it should prevent them from drowning in the sea of information that they will produce. Without the business objectives, the project team can all too easily produce technical findings that are of no benefit to the business. With the business objectives, the project team has clear targets in sight, and can focus its activities and prioritize its recommendations. Knowledge of the business objectives will help the project team to balance the perhaps divergent needs of improved management of engineering drawings, CAD data, alphanumeric engineering documents, alphanumeric/graphic documents and engineering workflow. The Engineering Department will clearly be a major source of information, but there are other sources and many other users, including manufacturing engineers, manufacturing planners, suppliers, customers, and after-sales service staff. The project team can take two complementary approaches to understanding engineering information flow. One of these is a top-down functional decomposition approach. The other is a product path approach that follows product information through successive activities in the product life cycle. A particular product may start in the marketing function and then go through conceptual design, engineering design and analysis, testing, detailed design, manufacturing engineering, process planning, tooling, NC programming, production planning, purchasing, sales order processing, machining, assembly, testing, packaging, distribution and maintenance. Other new products will follow a different path as will small changes to existing products. In some cases, the path will lead out of the company to suppliers and partners. In most cases it will eventually lead back to customers. Detailed workflow diagrams will need to be produced to help understand the workflow, and communicate this understanding. |