|
|
www.johnstark.com |
|
|
|
People often ask if a company needs both EDM/PDM and Concurrent Engineering, and if so, should it introduce EDM/PDM before or after Concurrent Engineering, or should it do the two together. The answers to these questions depend a lot on the current situation in a company, the company's culture, and the way it is organized. It is always difficult to know what someone really means when they talk about Concurrent Engineering. Concurrent Engineering is theoretically defined as a systematic approach to the concurrent design of products and their related processes, including manufacture and support. This is a good definition, but it raises a lot of questions. What does it really mean?, how would you do Concurrent Engineering?, how would you measure progress towards Concurrent Engineering?, how would you know if you had achieved it?, has Concurrent Engineering got anything to do with information? In practice, many companies claim to be doing Concurrent Engineering if they manage to carry out some parts of the engineering process in parallel rather than in series. Others think they are doing Concurrent Engineering if they have set up teams, or have bought a Design For Manufacture program, or trained people in Quality Function Deployment. The common characteristic among these activities seems to be something to do with working on several processes at once. EDM/PDM systems are slightly easier to define. They are computer-based systems that manage the engineering data defining a company's products, and defining the processes used to define, manufacture and support products. The key words are 'computer', 'product', 'data', and 'process'. The definitions of Concurrent Engineering and EDM/PDM overlap with the word 'process'. There is a lot of overlap between EDM/PDM and Concurrent Engineering, and it would be virtually impossible to do one well without addressing the other. In general, therefore, the answer to the first question, irrespective of industry sector, type of product, and level of engineering skills, is that both EDM/PDM and Concurrent Engineering need to be introduced. Most engineering processes exist to create information or to communicate it to someone else. A lot of information is created to describe processes. Deciding if the process needs to be addressed before the information is like trying to decide if the chicken comes before the egg. Most people have an underlying understanding of the concepts 'chicken' and 'egg', and the relationship between them, yet still find the chicken and egg question difficult to answer. The corresponding underlying understanding is generally missing in the Concurrent Engineering/EDM/PDM debate, hence the general difficulty in answering the question. Concurrent Engineering is not a computer system, and it is not based on a computer system. Concurrent Engineering is a philosophical approach to the way engineering should be carried out. Some people think of Concurrent Engineering as a paradigm. It's easy to see if a system is implemented, but extremely difficult to measure to what extent a philosophy is being followed. Philosophies and paradigms are 'soft' issues. They are difficult to sell, implement and measure. In general, computer systems are 'hard', and they are easier to sell, implement and measure. The relationship between EDM/PDM and Concurrent Engineering is one of synergy. Concurrent Engineering provides the right 'soft' environment, and EDM/PDM provides the 'hard' backing to make sure it works. The system makes sure that engineering is carried out the way the Concurrent Engineering philosophy says it should be. In the absence of EDM/PDM, there may be nothing to prevent people going back to serial engineering. The answer to the question about the timing of Concurrent Engineering is linked to the understanding that the company has of engineering processes, the use of engineering data during the product life cycle, the flow of work and data in the life cycle, and the objectives and functionality of particular implementations of EDM/PDM and Concurrent Engineering. If a company has a good, well-balanced understanding of all these issues, it probably won't even try to prioritize Concurrent Engineering and EDM/PDM. Implementation will come naturally. A little EDM/PDM and a little Concurrent Engineering. Then a pause to see what progress has been made. Then some more EDM/PDM and some more Concurrent Engineering. The two will be implemented side-by-side in the effort to achieve a particular goal. The questions about the relative timing of the introduction of EDM/PDM and Concurrent Engineering are more likely to be raised when companies don't really understand the issues, or have an unbalanced view. These companies may be suffering from too much emphasis on the chicken, and not enough on the egg. An unbalanced view leaning too far towards Concurrent Engineering will produce a surfeit of activities involving teams, quality circles, ISO 9001, process modeling, QFD, and the DFX acronyms (Design for Manufacture, Assembly, Decommissioning, etc.). Of course all these are important but, until information use, structure, flow and processing are addressed, only a fraction of the expected results will be obtained. Similarly, many companies have an unbalanced view leaning too far towards EDM/PDM. This will lead to a lot of discussion about distributed databases, entity relationships, Level 2 data modeling, schemas, and STEP. Of course, all of these are important, but until the process issues are addressed, only a fraction of the expected results will be obtained. It's often difficult to find where the correct balance lies, and just how receptive a company's culture and organization will be. Positive signs include use of systems that manage the flow of work through engineering processes, or that apply rules to the way engineering is carried out. The extent to which different departments work closely together is another key indicator. If they can work closely together it often implies that they have understood how their processes use data, and how engineering data has to be structured and organized for shared use. Another key measure is the extent to which people are trained to think beyond the boundaries of their own department. Companies that don't understand the issues, or can't understand that both Concurrent Engineering and EDM/PDM are important, need to find out more about them before starting implementation - otherwise the implementation will be costly, time-wasting and, eventually, a failure. Companies that focus only on Concurrent Engineering will probably succeed in the short-term, but then find they can't build on this success, and may even find that it slips away from them. Companies that focus on small-scale EDM/PDM, and, for example, only apply it for CAD/CAM data, will achieve very limited results. Companies that focus only on EDM/PDM, and try to apply it company-wide, will fail because they will run into endless problems caused by inefficient and uncontrollable engineering processes. Unbalanced champions of one side or the other need to understand that Concurrent Engineering and EDM/PDM are both partial answers to the problems of uncompetitive organizations. They both aim to improve product quality. They both aim to reduce lead times. They both aim to reduce costs. The aim of an organization is to provide customer satisfaction. Companies need to have an overall picture of what they are going to do to achieve this objective. They should recognize that they need to improve the management of both data and processes, and that the resulting action plans should address concurrent improvement of data management and process management. |