Figure 3-4 shows the engineering design change management process that the company adopts at the moment. The process is a kind of a stage-gate development process (Cooper and Edgett, 2006), which means that after a task is carried out, its outcome will be reviewed and decisions on the next stage of the process will be made based on the result of the review.
Engineering design changes come from different sources due to the business nature of their product. Engineering design change requests may come from customers, engineers of the company and manufacturing partners from outside. When a change request is received, the product development review board meet to decide whether the change request is worth carrying out based on the judgement from the board with their considerations of potential change impacts on the business and the product. The review board is mainly composed of management and senior engineers from related functional departments.
If the engineering design change is accepted, the task of carrying out the change will be assigned to engineers responsible for that part of the product where the engineering design change is requested or engineers in related areas and having necessary
-54-
expertise. Normally one engineering change is carried out by one engineer in this company. However, depending on the importance, the complexity or the scale of an engineering change, the task may also be carried out by an engineering team. The engineers use their expertise and experience to analyse the engineering design change problem and propose candidate solutions for it.
When the solutions are proposed, the review board is called up again and review the solutions for the engineering change. In this review meeting, members of the board need to discuss the feasibilities of the solutions, their impacts on other parts of the product or impacts on customers’ requirements, and then prioritise alternative solutions and choosing a most promising one. But the chosen solution is not the end. It also needs to be reviewed by their manufacturing partners to check the impacts in the manufacturing phase. If it is necessary, further work needs to be carried out to improve the solution which will be further reviewed as well. If the solution is approved by both the review board and the manufacturing partner, it will be formally documented and implemented.
However, problems are identified in the change management process and the methods that they use to solve engineering design change requests. These identified problems are discussed next.
-55-
Change request review
Task assignment
Design change review - manufacturing Design change analysis
and solving
Design change review
Engineering design
change process Participants
Engineering design change request Request accepted No Abort Yes Change accepted Yes No Design change suggestion Change accepted Yes Manufacturing issue report No Design change documented and implemented
Customer (needs, local policy, restrictions, etc), engineers,
manufacturing partners
Product development review board (including management,
senior engineers)
Engineers in charge of the design of related parts or in the related
areas
Product development review board (including management,
senior engineers)
Manufacturing partners
Product development team Manufacturing partners
Figure 3-4 Engineering design change management process in Vensys
One of the problems found in their engineering design change management process is that there is a lack of method to analyse the impacts of changes on functional requirements and on physical components.
In terms of the products of the investigated company, changes in the functional requirement domain are normally caused by: (i) change to satisfy customer requirements; (ii) change to satisfy local government policies; (iii) change to meet
-56-
implementation restrictions and; (iv) change to meet manufacturing restrictions. Any change of a functional requirement may have potential impact on other functional requirements depending on the dependency relationships among them. The dependency relationships need to be captured in the functional requirement model so that causal impacts can be analysed and controlled when engineering change resolving is being carried out. This type of impact is termed ‘change impact between functional requirements (functional-functional)’.
It has been noted that any changes to physical components are also required to be analysed against their corresponding functional requirements. Normally, there is a solution for a functional requirement. However, in many cases, a component may get involved in more than one solution. Therefore, any change to that component may potentially have impact on the realisations of other functional requirements. This type of impact is termed ‘change impact between functional and physical requirements (functional-physical)’.
In the current engineering design change management process of the company, impacts of functional-functional changes and the functional-physical changes are evaluated during the board review meeting. There is no systematic method for engineers to use while resolving the engineering design change. Therefore, it is difficult for engineers to consider all the potential impacts when they work on problem solving. A common situation is that an engineer assigned with a change task proposes solutions and submits to the review board for evaluation. Unsurprisingly, in most cases they are rejected, because the unexpected impacts on other functional requirements are not analysed. Therefore, the engineer needs to refine the solution according to the suggestions from the board. The refined solution may get passed or may be rejected again. This kind of iterations is very time consuming and inefficient.
The second problem identified from their design change management process is that there is a lack of method to trace change propagations. Change propagation between physical components is a recognised problem in engineering change management, which is also a main concern in the investigated company. In the current approach, an engineer does consider related components while he/she works on the solution for the
-57-
engineering change. Due to the lack of a systematic method, it is difficult for the engineer to consider all possible direct change propagations, and it is even more difficult for the engineer to consider all the indirect change propagations. Without fully considering possible change propagations, the solution is very likely to be rejected during the board meeting since other engineers in the board may find other change propagations that may have serious impact on other parts of the product. Or it will be even worse if the possible change propagations are not found during the board meeting and brought into the manufacturing phase, which may cost a lot to correct. The change propagation routes within the functional domain and the physical structure domain, and the routes between them are synthesised by the author and depicted in Figure 3-5.
F
1F
2F
iF
nC
1C
2C
iC
mFunctional Domain Physical Domain
Interdependence between Functions Change verification Change between Physical structures Change caused by functions
Figure 3-5 Design changes between functional and physical domains (By Author)
The third problem is that there is a lack of method for conflict resolving in design change management. As discussed above, changes of a component or a function may require other parts of the design to change. Furthermore, changes of these parts would cause changes of more parts of the design. This effect is referred to as ‘change propagation or knock-on effect’. Actually, the reason why a change of a part of the design causes changes of other parts is because the initial change of the design may harm or obstruct operations of other components or satisfaction of other functional targets, which can be seen as functional or structural conflicts. In other words, change propagations are caused by design conflicts. Once there is no design conflict arising from any design changes, the change propagation stops. In the current approach,
-58-
engineers have to use their experience and expertise to solve any design conflicts they find in the engineering change case. However, there are a lot of design cases that may be similar to the current problem and their solutions may be very useful. But there is no such a method in this approach that can support the reuse of previous design knowledge, which is discussed next.