|
|
www.johnstark.com |
|
|
|
People often ask about the best way to introduce EDM/PDM. 'Should we do EDM/PDM top-down or bottom-up?'. 'Should we do a Big Bang implementation, or should we introduce EDM/PDM step-by-step?' 'Should we implement EDM/PDM only in the Engineering Department, or should we implement it company-wide?'. 'Do we have to build a prototype?'. 'Should we do a feasibility study?'. 'Do we need to test it out in our Research Labs?'. The answers to some of these questions are company-specific. They depend on a mixture of factors such as the industry sectors the company competes in, the company's organization and culture, the company's computer systems, its personnel, and the company's experience of implementing EDM/PDM. Answers to other questions are less company-specific. One of the most important factors in choosing the approach is the level of EDM/PDM understanding in the company. If the company understands very little about EDM/PDM, then a feasibility study will be helpful. If it has a basic, but incomplete, understanding, then a prototype will be helpful. If it really understands how EDM/PDM will be used, then it may need neither feasibility study nor prototype. There are two types of feasibility to address - the feasibility of EDM/PDM as a technology, and the ability of a particular company to apply EDM/PDM. It's now fairly easy to demonstrate the feasibility of EDM/PDM as a technology. There is a lot of published information, and EDM/PDM vendors can generally show results from their customers. It's much more difficult to demonstrate the feasibility of using EDM/PDM within a particular company. However, it's also much more useful, because it implies understanding how to use EDM/PDM, where to use EDM/PDM, and how to organize for EDM/PDM. It means understanding where the benefits of EDM/PDM will occur, and how they will relate to the corresponding costs. This type of feasibility study really helps a company improve its understanding of EDM/PDM. A well-planned prototype can be a useful tool for increasing the overall awareness of EDM/PDM, and learning enough about it to show that wider-scale implementation will be successful. All too often, though, prototypes take place in conditions that do not represent normal use, or they are hijacked by a few individuals with the result that the overall gain in experience is negligible. A prototype carried out by the Central Research Laboratory to test the use of EDM/PDM is unlikely to be meaningful, whereas a prototype supporting a small, real-life, market-driven development project should be very useful. It must be remembered, though, that the prototype needs to be well planned. The objective and deliverables must be clearly defined before the prototype starts. The experience gained must be regularly communicated. Unless the prototype takes place on a live project, it is unlikely to yield maximum benefit. If the project is not essential, or is seen to be unrealistic, interest will soon flag, people will move, or be moved, to essential projects, and the eventual result may be disillusion with EDM/PDM. In such a case, it might have been better not to have started the prototype. A prototype is by no means obligatory. Some successful users of EDM/PDM did not prototype. Some companies that did prototype created unnecessary expense and problems. In a Big Bang approach, a company would switch overnight from only using manual data management to only using computer-based EDM/PDM. Unless a company is extremely well-organized, and has all its processes in order, a Big Bang approach should not be tried. Mega-projects like this rarely work. A step-by-step approach is much more likely to lead to success. Although a Big Bang approach may appear quick and simple, it is generally the opposite. The Big Bang only comes after a very long preparation and planning phase, during which people lose interest and are demotivated by the lack of results. A step-by-step approach, starting with an overall multi-step plan, is more likely to succeed. As each step is implemented, people can see and appreciate the progress, and should any problems occur, these can be resolved before they get out of hand. The decision as to whether the initial implementation of EDM/PDM should be in the Engineering Department, or elsewhere, will vary from one sector to another. In some industry sectors there is enough pressure from competitors and customers to overcome any doubts about getting started with EDM/PDM. In these sectors, Engineering is often a strategically important function, and able to act fairly independently. As a result, there is a tendency for EDM/PDM to be implemented bottom-up, starting within the Engineering Department, and spreading out to other areas of the company. The opposite occurs in sectors where Engineering is less important, and the Engineering Department is comparatively weak. In these cases, top management may be the driving force behind EDM/PDM, and may view initial use in the Engineering Department as an uninspiring approach. The choice between implementing EDM/PDM in one department or cross-functionally depends a lot on the current organizational structure. Companies that are used to working with cross-functional teams and projects will find it easier to implement EDM/PDM cross-functionally than those where each department is surrounded by high walls. For the former, a cross-functional project will be a good place to start a prototype of EDM/PDM. In a company where the departments are very separate, cross-functional EDM/PDM will be nearly impossible to implement, so EDM/PDM will probably start within a single department, even though this may make it more difficult to go cross-functional later. The choice between top-down and bottom-up implementation depends a lot on the culture of the company. A bottom-up approach is going to be difficult in a company where management is used to running things top-down. More likely, this type of management will favor a top-down, Big Bang approach. In companies where there is a more consensual, less autocratic, culture, a step-by-step, department-by-department approach will probably be preferred. The computer systems in the company also play a part in the decision. If there are a lot of different systems, each needing to be interfaced to EDM/PDM, then a Big Bang approach, or an immediate company-wide approach, will be difficult. On the other hand, if most of the applications are running on a central mainframe, it should be easy to integrate them with EDM/PDM. The way systems were implemented in the past will also affect the approach. Companies often prefer an approach with which they have succeeded in the past, rather than one which has failed. Another factor that weighs heavily in the decision is the skill level in the company. There is no point in suggesting a company-wide or Big Bang approach if the company doesn't have the people available to support or use it, and can't afford the money to buy in outsiders to do the work. EDM/PDM requires a lot of effort for implementation, training, data load, user support, and process improvement. The requirements at each stage of the product life cycle are different, and different skills are needed at each part of the process. One or two supermen can't do it all alone. Perhaps the most important factor in choosing the approach is the EDM/PDM experience so far. If the general level of EDM/PDM awareness is low, then the approach should be cautious and include a lot of training. If there has been little support from management, it is unlikely that a top-down approach will be appropriate. If different departments can't agree on what they want to do with EDM/PDM, then a company-wide approach will be unsuccessful. If the Engineering Department hasn't shown any interest, it wouldn't be sensible to propose starting with EDM/PDM in Engineering. If no one has taken the work done so far very seriously, it is probably too early to start thinking about implementing EDM/PDM, and the best approach is to try to increase awareness. |