If a computer support system for the information management process is to be implemented, well developed information exchange models needs to be done in ...
The Complementary Roles of IDEF0 and DSM for the Modelling of Information Management Processes J. Malmström, P. Pikosz and J. Malmqvist Machine and Vehicle Design, Chalmers University of Technology, Göteborg, Sweden
Abstract The paper compares the IDEF0 [1], (sometimes referred to as SADT) and DSM (Design Structure Matrix) [2, 3] modelling techniques. They both serve the purpose of modelling information flows. The aim of the paper is to identify positive and negative aspects of the different modelling techniques, thereby suggesting what kind of problems the different techniques are best suited for and how the techniques complement each other. As an example, both techniques are used to model the configuration management process at FFV Aerotech. It can be argued that IDEF0 focuses on the formal communication of specified information. DSM, on the other hand, focuses on informal communication. The techniques support each other. Depending on the objectives with the modelling work, both techniques can be used. Useful insights can be reached with little additional work by using both techniques.
1
Introduction
The trend in today's business life is increasingly harder competition. New markets are available to companies, with possibilities to grow and prosper in an earlier unprecedented way. However, as a result companies also face fierce competition on formerly secure home-markets. In order to deal with these opportunities and threats, firms must succeed in parameters such as cost, quality and time to market. Efficient automated production systems, such as lean production, and increasingly shorter product life cycle puts greater emphasis on the product development process [4]. As a consequence the information management process has become more important for companies attempting to reduce their product development time, requiring the right information at the right place at the right time throughout the entire organization. Additionally, methods like concurrent engineering with its simultaneous
work increases the amount of information that needs to be distributed within the company. In order to understand and improve the information management processes, companies need techniques to help them model their processes. If a computer support system for the information management process is to be implemented, well developed information exchange models needs to be done in advance to decide the system design. The paper compares the use of IDEF0 and DSM, two different techniques for process modelling, and applies them on the configuration management process at FFV Aerotech, i.e., one example of a information management process. The advantages and disadvantages of the different techniques are discussed, and a method for using them in conjunction is proposed. The structure of this paper is as follows: Section 2 outlines the research approach used in this study; Section 3 presents the IDEF0 modelling technique; Section 4 presents the DSM modelling technique; section 5 describes the case study starting with a company presentation followed by the IDEF0 and DSM modelling results; Section 6 compares the two techniques; Section 7 describes the proposed modelling technique, section 8 discusses related work and the conclusions are listed in section 9.
2
Research approach
In order to evaluate the two modelling techniques both where applied to the configuration management process of a Swedish company. The techniques were then evaluated with respect to: (1) time needed for developing the model; (2) information needed; (3) level of detail of model; and (3) the applicability for analysing various problems associated with information management processes, e.g. long lead times. The result of the analysis is a method where the two techniques are used together in order to utilize their different strengths.
3
IDEF0
To study information management processes the standardized IDEF0 [1, 4, 5, 6] modelling technique is a useful tool. IDEF0 was specifically developed for the modelling of information flow in complex and interrelated systems. IDEF0 was derived from SADT (Structural Analysis and Design Technique [1]). The modelling is performed in four aspects: input, output, control and mechanism. See Figure 1.
Control Input Output Mechanism Figure 1 Conceptual IDEF0 model.
The arrows attached to the left side of the boxes indicate inputs. The input is what will be “changed” within the box. The arrows that come out on the right side of the boxes are the outputs. The output is the “result” of the activity in the box. On top of the boxes controls are attached. The controls represent controls or constraints relevant to the performance of the activity within the box. The arrows at the bottom of the boxes represent the mechanisms by which the activities in the box are accomplished. The IDEF0 model can be hierarchically decomposed, a common trait for most functional modelling techniques. Each of the higher level processes can be broken down into lower level subprocesses. See Figure 2. The subprocesses can then be decomposed into lower level subprocesses. It is possible to continue the decomposition to micro level processes, e.g. minute to minute work tasks for each individual. However, this is very time consuming and does usually not result in a better model. Therefore, the decomposition should be stopped when the modelling objectives are reached.
MORE GENERAL
This diagram is the “parent” of this diagram
MORE DETAILED
Figure 2 IDEF0 decomposition.
VCC_ECP
Complementary documents
Reports
Instructions
Product documentation
Information
Processmodell Komponentuppdragsplan Systemuppdragsplan
Produktstruktur
Projektplan
Kvalitetsfelrapport
System
Marknadsönskemål
VCC A0 ÄO-Process
Produktstruktur
Produktdokumentation
ÄO-utgåva Produktstruktur VCC A1 Beslut om ändring
Produktdokumentation Ändringsbeslut
HD
HD-utgåva HD
VCC A2 Registrering av ÄO, artikel, dokument
Dokumentid (KDP) uses
Produktstruktur
Produktdokumentation (PUBL)
ÄO
VCC A3 Registrering i dokumentkatalog
Dokumentid (dokumentkatalog)
MEMO VCC A4 Konstruktion
KDP
Dokumentkatalog
Produktdokumentation (PRIV)
used communicates communicates by with in with o has
VCC A5 Preliminär frisläppning för beredning
communicates with o has
has
Produktdokumentation (PREL)
System user
VCC A6 Godkännande
ÄO-utgåva
partpart of of
partpart of of Y-axis X-axis in in
Produktdokumentation (OK)
partpart of of Y-axis X-axis in inCATIA
contains
Y-axis X-axis ÄO-hantering in
HD-hantering
in
FrameMaker
CADAM
contains contains
contains
role of
role of SU-ledare
KU-ledare
Projektledare
Egenskapsansvarig
TDS
MEMO
Konstruktionsgranskare GOA
Linjechef
Konstruktör
role of
Final report
Service report
ECO
DIDAS report
role of
ECO report ATS
Request for guidence change
Problem report
Failure report
ECP
TOS
Project instructions
Standards
ÄO-beredare
KOPRA
Systems development handbook
TOMF
Specification
Drawings
User
Product structure (KF)
VCC A7 Publicering och distribution
role of
role of
role of
role of
role of
role of
KDP
contains
contains contains
Roller
has
Information
has
has
has
has
Uses system
stored in
stored in
Produktstruktur
ÄndringsOrder (ÄO)
Projektplan
Kvalitetsfelrapport
Ändringsinformation has has part ofhas has X-axis in
ÄO-beredare part of
Project leader
contains contains contains
role of Dokumentkatalogen
role of
role of
Konstruktör
Y-axis in
Projektledare
SU-ledare
has has has has has
part of X-axis in
part of X-axis in
information information element element type of information type of information information information information information element element element element element element type of type of type oftype oftype oftype of
Konstruktionsgranskare
stored in
stored stored in in
HD
part of Y-axis in
part of Y-axis in
part of Y-axis in
Ritning
part of Y-axis in
Designer
of
Utfrädare
of
information element of
Projekt
information element of
of
Benämning
information element of
of
information element of
Godkänd teknik
of
information element of
Kontrollerad
of
information element of
Godkänd projekt
of
information element of
Angelägenhetsgradof
information element of
Införande i produktion
part of X-axis in
stored in
Artikel (HD)
stored in
Teknisk Bestämmelse (TB)
Systemuppdragsplan (SU-plan)
stored
has
stored in
hasin
Konstruktionsförutsättning Övrig (KF) dokumentation
information element of
information element of
Artikelutförande
stored in
Modell
Komponentuppdragsplan (KU-plan)
information element of
HD-utgåva
ÄO-utgåva
Supervisor Customer
Linjechef
has
has
has
Production
part of Y-axis in
KU-ledare
part of Y-axis in
TDS
has
has
GOA
part of Y-axis in
Egenskapsansvarig part of Y-axis in
part of Y-axis in
Team leader Matriser
Manager Drawing archive TO-editor
Y-axis Y-axis Y-axis X-axis X-axis consist X-axis consist consist consist ofof of of consist consist X-axis of of consist of
Information i system
use used by
Y-axisX-axis Y-axis Y-axis X-axis Y-axis X-axis Y-axis Y-axis Y-axis Y-axis consist consist consist consist consist consist consist consist consist consist Y-axis consist of of of of of ofof of X-axis of of of consist part of Y-axis consist of X-axis consist of in of
System-användare
use used by
Central archive System coordinator ATS-coordinator
Figure 3 Relationship matrix example. Adapted from[9] The IDEF0 technique supports the need of modelling the process in a formalized manner to be able to compare and refine the modelled process. It is especially important when the modelling is done to support the implementation of e.g. a computer support system which have strong demands on the structure and semantic of the information. When processes that will be performed by humans are modelled the demands are not as stringent, since humans can understand small differences in structure and semantics better than computers, thereby making the process more robust. One limitation with the IDEF0 technique is that mainly document producing actions are captured, whereas important goals for an activity such as minimize cost or improve quality may be left out. The IDEF0 methodology gives weak support for the modelling of parallel subprocesses and for the informal communication within a subprocess. Iterations between levels are difficult to analyze with help of the IDEF0 technique. The IDEF0 models tend to grow fast in complexity with a large amount of relationships. However, the process model can be expanded with a information model, system model, and model of roles [8]. The relations between the different entities can be created and analyzed in relationship matrices between the different entities. In Figure 3 one example of a relationship matrix is presented. The example describes what kind of information items the different user roles need during the engineering change process [9]. In Figure 4, a concrete example of a model
Figure 4 Complete model example. Adapted from [9]. implemented in Metis [10] is presented. It describes the engineering change process at Volvo Car Corporation. The model contains one container with the IDEF0 process model of the change process, one container includes the different computer support systems available to the personnel, one container lists the different roles in the process, and one container holds the different information items handled in the process. The relationships between the entities in the different containers are added. To be able to analyze these relationships matrices are used The advantages of an extend use of IDEF0 modelling with process, system, role, and information containers are [9]: • good overview of the objects within an aspect • the complete model gives a formalized picture of the entire process and therefore forms a good base for discussions and a future reference model • the relations between objects can be represented in relationship matrices, which enables an easy interpretable representation of relations between objects • existing computer tools can be used for the modelling as well as for the visualization (Metis and www).
4
DSM
Another method for analyzing how a PD process can be improved is the use of design structure matrices (DSM) [2, 3]. This technique provides a better overview than IDEF0, since the complexity of DSMs does not grow as fast as that of IDEF0 diagrams. The DSM technique uses a form of matrix notation of the relevant variables. All variables are listed on the x axis and then in the same order on the y axis. See Figure 5. The relations between the different variables are then listed in the matrix. Many different kinds of relations can be listed, depending on what variables are modelled, e.g. need_information_from, spatial_relationship, etc. The relationships can be given a numerical value indicating, for example, their importance. Numerical values facilitates a more thorough analysis with the help of linear algebra. A
B
C X
Parameter
A
•
X
Task/activity
B
X
•
Component
C
X
X
•
D
X
X
X
E F
D
E
F x x x
• X
• X
•
Figure 5 Simple DSM example. Adapted from [3]. DSM is a very robust technique that can be used on many different problems. It is easy to use the DSM on different problem sizes. One of its strengths is its applicability on large problems, while maintaining a relatively good overview of the model. It is possible to reach a viable result reasonably fast by using DSM on large chunks of the modelled problem. The three most common choices of variables in a DSM are: • Parameters [2]. • Tasks [11]. • Components [12]. In this paper the focus have been on the task DSM. The task DSM is used for analyzing the overall process and its tasks. The DSM provides insights about how the overall process is working, and what changes that can be made in order to make it more efficient. It especially highlights issues like iterations, task sequencing, and information needs for different tasks. Different tasks can be organized in three different ways depending on what information is needed to perform it. See Figure 6. A task that needs information from another task to be possible to perform is dependent on the previous
task and needs to be performed after it. The tasks can also be independent, and can thereby be performed in parallel. However, if both tasks need information from each other, they are interdependent, and need to be performed concurrently.
A
A
A
B
B
B
Dependent tasks Independent tasks Interdependent tasks (Series) (Parallel) (Coupled)
Figure 6 Task sequencing. Adapted from [3]. A DSM helps identify problem areas within a process and can support restructuring of it in order to make it more efficient. Figure 7 presents one example of process restructuring, taken from Eppinger [13]. The DSMs compares the design processes of two different companies. Both companies manufacture dashboards. However, for the faster firm (bottom) it takes 3-5 weeks to reach the first prototype, compared with 6 months for the slower. With the help of DSM the reason behind the discrepancy can be identified. Comparison of the two DSMs shows that the two companies have designed their design processes differently. The slower firm has three activities that are interrelated and need to be performed in parallel with close collaboration with each other. This type of relations mean that the product goes through a number of redesigns within a part of the process which makes it time consuming. In the faster process, the interrelated chunk is broken up, and has only two activities that need to be performed interrelated. The company with the faster process also manufactures a soft prototype for testing by their customer and makes the needed changes before the hard tooling. Their process is thereby much faster.
Casing Design
•
X
X
Wiring Layout
X
•
Lightning Details
X
X
•
Tooling
X
X
X
documents are stored in different computer systems or in archives. FFV Aerotech’s products are classified as critical for flight safety. The test equipment is developed and manufactured in parallel with the aircraft, which can take up to 15 years, and documents are frequently exchanged with the aircraft manufacturer. The external configuration information that FFV Aerotech receives from the aircraft manufacturer changes over time. The internally produced material must be connected to the correct version of the external product design information. This makes configuration management a key issue. In addition, the customer demands extreme cautiousness with the CM process. Since FFV Aerotech manages both customer and supplier documentation, the demands on CM is very high; all actions must be documented due to air worthiness certification demands. FFV Aerotech maintains data of the configuration of each individual product produced, configuration of all the customer’s aircraft and the allowed combination between maintenance equipment and aircraft for each individual aircraft.
x x
Hard Prototype
x • X
•
Testing
X
•
Slower Design Firm 5-10 iterations 6 months (to first prototype) Casing Design
•
X
Lightning Details
X
•
Wiring Layout
X
X
•
Soft Prototype
X
X
X
Testing
• X
Revision Hard Tooling
X
X
X
• X
•
X
X
•
5.2 Faster Design Firm 2 iterations 3 - 5 weeks (to first prototype)
Figure 7 DSM example. Adapted from [13].
5
Case Study
In this chapter the company and the different results of the modelling techniques will be presented.
5.1
FFV Aerotech
Both methods have been used for the modelling of the Configuration Management (CM) process at FFV Aerotech, a Swedish company in the aerospace industry. FFV Aerotech manufactures test equipment for aircraft. The main objective of the CM process in engineering is to provide the customer with a product with the right configuration of parts and correct documentation at the right time. The product must contain parts that have been tested together, proving that they meet the promised performance, before the product is delivered. The documentation for the product must be compatible with the delivered configuration. The main activity of CM is to manage the controlled change of the information content in documents, thereby providing support for development, production and maintenance of the products. The
IDEF0 Results
The IDEF0 modelling of the CM process at FFV Aerotech was done in METIS [10], a computer software which can be applied for IDEF0 modelling. Metis is primarily intended for enterprise modelling. Therefore the software also allows the use of different entities than the classical IDEF0 boxes. However, in this model only the traditional IDEF0 technique was used. In Figure 8 the top level model is displayed. It contains three top level processes with inputs, outputs, controls and mechanisms. FFV Aerotech divides its CM process into: maintenance planning; resource development; and operation. The top level processes are decomposed into subprocesses. The maintenance planning process is two levels deep. The resource development is the deepest with four levels, and the operation process is three levels deep. The entire IDEF0 model represented in Metis contains 44 processes. It is up to 5 levels deep. It contains 5 controls, 18 different mechanisms, and 463 relationships. The IDEF0 modelling of the CM process gave a very detailed information model, with input, output, controls, and mechanisms. All the lower level subprocesses are well documented, with the same level of detail. The stringent formal definition of all relationships makes the resulting model suitable for computer support system implementation. IDEF0 models tend to describe a traditional “waterfall” model of the PD process since it is difficult to handle parallel tasks with its interdependencies in the model. Additionally, informal communication within groups, which is often argued to be one of the foundations for
KOPRA
SUPPLIER Product documentation
Product usage data
Problem report
System development handbook
Standards
FFV CM0 FFV Configuration management
Product documentation
SUPPLIER Product structure
Product structure (KF)
Customer order Standards
Product documentation
Product structure (KF)
System development handbook
Problem report
KOPRA
Individual product documentation
Product usage data
Product structure (KF) Product documentation
Produktstruktur (KF)
FFV CM1 Maintenance planning
Produktdokumentation
Kravspecifikation
Product
Target specification Handling officer
Project leader
Designer
UO SUPPLIER
System coordinator
Prototype test shop
Customer
Group manager
Department manager
Standards
Product structure (KF)
Product documentation
Target specification
SUPPLIER Product structure
SUPPLIER Product documentation
System development handbook
Problem report
KOPRA
Test protocol
Product usage data
Product documentation
FFV CM2 Resource development
Product documentation
Product structure (KF)
Decision protocol
Final report
Test protocol
Final report
Product structure (KF) Designer
Technical manager
Project leader
Test programer
ATS-coordinator
Drawing archive
PPU
TO-editor
CAD
System coordinator
Customer
Prototype test shop
FrameMaker
BORIS
Central archive
Group manager
Department manager
Problem report
Product usage data
Decision protocol Produktdokumentation
Produktstruktur (KF)
Produkt
FFV CM3 Operation
Customer
Test programmer
ATS coordinator
Drawing archive
PPU
TO editor
Handling officer
Individdokument
Prototype test shop
CAD
System coordinator
Customer
Prototype test shop
Fra
Figure 8 Top level IDEF0 model. concurrent engineering, is also hard to handle in the IDEF0 model. The IDEF0 modelling at FFV Aerotech supported the implementation process of a new computer support system for configuration management. The modelling work provided FFV Aerotech with a greater understanding of their present process, e.g. a document was produced early in the process without any need for it further downstream. Additionally, the modelling helped with finding a shared view of the details in the CM process, e.g. the IDEF0 model made it easier to reach an agreement on what approvals that was needed before production could start. Previously had the different functions divergent opinions about how the process actually worked. One negative aspect of the IDEF0 modelling technique is the complexity and difficulty to interpret the complete process. When viewing the top level diagram, it is hard to tell if a process contains a number of subprocesses in several levels, or no subprocesses. Iterations and feedback loops are difficult to follow in IDEF0, because of its strong feed forward focus. Additionally, modeled iterations and feedback loops are hard to follow due to the multitude of relations and use of hierarchic models. The modelling
work demands very detailed information, even for the lowest level subprocess. All information needs to be collected and analyzed thereby making the modelling work time consuming. The collected information needs to be documented in the model. Large models are difficult to do on paper, since it is hard to keep the hierarchical layout in mind while modelling. Furthermore, it is very time consuming to change the model. Luckily, there are suitable computer tools available for the modelling. Otherwise, the models would very soon be to large to comfortably handle manually. While modelling, it is sometimes difficult to find the correct level of detail to address a certain problem. i.e. the interesting information can drown in all other information. The IDEF0 model focuses on formal communication based on documents and does not address informal communication. Thereby some organizational aspects of the process can be hard to address in the model.
5.3
DSM Results
The result of the DSM modelling of the CM process at FFV Aerotech is shown in Figure 9. Here the lowest level subprocesses from the earlier described IDEF0 model are
?= Need to check if information had changed
X= Needs information from
♦= Potential feedback/alter loop
Figure 9 DSM decomposition. listed in on the left side of the matrix. The variables are noted in the same order on the top. The DSM of the CM process is composed of a 35 by 35 matrix with 165 relationships in the matrix. The modelling was done in an Excel spreadsheet. The notation for the interdependencies in the matrix are: X needs information from. ? need to check if information has changed. ♦ potential feedback/alter loop. The DSM shows that the process is fairly straightforward without too many dependencies (Xs) on the top of the diagonal. Ideally, a DSM of a process should have all interdependencies below the diagonal. Thereby the process could be finished without any rework. Regrettably, reality is seldom ideal. The largest interdependent block is within the design phase, where much information needs to be exchanged between the test and design departments (hardware, software, and test manual). The greatest experienced advantage of the DSM modelling is the good overview of the process that the model provides. This makes the process easy to explain to
other people thereby focusing on the problem areas instead of the modelling technique. DSMs are easy to use on large problems since the size of the subprocesses does not affect the technique, i.e. large subprocesses can be used in the matrix. The level of detail is also easy to change. The interaction between different parts of the matrix can be modelled with a simple mark, saying that there are interactions. The interactions can be modelled in detail by expanding the boxes in the matrix. Thereby the kind of information, the direction etc. can be modelled. However, this tends to make the matrix very complex, and more difficult to analyze. The DSM technique is fast and easy to use compared to the IDEF0 model previously discussed. Unlike the IDEF0 technique, the DSM is possible to perform with help of remotely distributed questionnaires done with, for example, e-mail. The DSM does not require expert knowledge of the process. It is often sufficient to know that you have a relationship between two processes, not exactly what information that are exchanged. The matrix notation in the DSM makes it possible to analyze the process with help of linear algebra, for example to
optimize the task sequence. One of the advantages of the DSM is that it makes iterations in the process visible. Thereby focus is put on activities which may require substantial rework in other processes. However, the aggregate notation of the subprocesses in the DSM matrix makes it hard to model the low level processes with sufficient detail. The information exchange process is often modelled only as an interaction. Detailed information of what kind of information that is exchanged is difficult to model. Mechanisms and controls that govern the information exchange process are not included in a DSM model. Moreover, hierarchical differences of the subprocesses are difficult to model. The subprocess is given one row in the matrix, independent of if it is a large or small process. FFV Aerotech found the DSM model easier to handle than the IDEF0 model, especially since it could be done in a spreadsheet and did not need special computer tools. The DSM was also easier to communicate within the company. The DSM gave FFV Aerotech a better understanding of the overall process and helped them to decide on suitable locations for tollgates where the status of documents are changed.
initial DSM modelling, supported by a IDEF0 if needed. Information management issues are best solved by IDEF0 modelling supported by DSM. For example, when introducing computer support for a process such as the CM process, the process may firstly be modelled with the IDEF0 technique to estimate whether the process is suitable for computer implementation or if a larger business process reengineering (BPR) is necessary. If the process is considered good for computer implementation a DSM can be made to determine potential risks with iterations and organizational changes that are easily omitted in the IDEF0 model to make the process more efficient. Based on this, the IDEF0 model can be updated and the improved process can be implemented in the computer system. Neither the IDEF0 or the DSM modelling technique support the modelling of time based relationships. Since time-to-market is becoming an increasingly important competitive advantage, the inability to model time based relationships must be viewed as a limitation of the techniques.
6
As earlier noted IDEF0 and DSM have different strengths and weaknesses. It can thereby be beneficiary to use them in conjunction if the extra information and insight is needed. Especially since the use of two methods does not mean that the entire modelling work needs to be redone. The equation is not 1+1=2. It is more like 1+1=1.2. Much of the previous work can be re-used, which speeds up the creation of the second model. The case study verified that less time was needed for the second model. However, it is possible that the extra work involved with using two methods is greater than the benefit for some problems. The used method must support the objectives of the modelling effort. For example, if changing the process is out of the scope for modelling work and the process is fairly simple, it is probably not necessary to perform a DSM. On the other hand, if the modelling work is just interested of task sequencing in the process, an IDEF0 model will probably not be necessary and it will be enough with a DSM. The method proposed by the authors will fit most processes and objectives. The proposed method is listed below: 1. Determine focus and objectives. Most modeling work is done to reach an objective and the technique used should support this objective. The objective should be kept in focus throughout the entire modelling work. Some examples of objectives are: • Organizational changes. • Implementation of computer support.
Comparison
The two different techniques are complementary and can provide good results if used together. It can be argued that the DSM is primarily focused on organizational issues about how the PD process is designed and highlights problem areas within the organization, e.g. task sequencing and information needs. IDEF0, on the other hand, focuses on supporting computer implementation and therefore enforces more information and formalism. The sizes of the models are relatively similar. The IDEF0 model contains 44 processes, 5 controls, 18 mechanisms, 463 relationships, and is up to 5 levels deep. The DSM is a 35 by 35 matrix with 165 relationships. The lower number of processes in the DSM is due to the hierarchical nature of IDEF0. Only the lowest level processes of the IDEF0 model was incorporated in the DSM. The difference in the number of relationships is due to the reduced level of detail in the DSM. A relationship that is defined as “needs information from” in the DSM may need several more formal relationships in the IDEF0 model. Furthermore, the control and mechanism relationships in IDEF0 are not included in the DSM. Depending on the stated focus of the modelling work, it can be said that the CM process at FFV Aerotech is to detailed for DSM and to “large” for IDEF0 modelling — one technique is not enough. However, together the two techniques provides a good method of modelling the CM process. Organizational design issues are best suited for
7
Proposed Method
• Reorganization of document flows. 2. Determine available time and resources. Before the modelling work is started the available resources in form of manpower, computer tools, access to key personnel, budget, etc. Moreover, the time allotted to create the model needs to be determined. If the results are required in a short period of time, a fast technique with low level of detail will be preferred, i.e. a rough DSM. If an accurate model is needed, and a lot of resources are available, both a detailed IDEF0 and a detailed DSM can be performed. 3. Determine size of process. The size of the process that should be modelled needs to be identified. This sets the boundaries of the modelling work. A small process that needs to be understood in detail is best suited for an IDEF0 model. A very large process with iteration problems is best suited for a DSM on large subprocesses. 4. Determine level of detail. Before modelling, the required level of detail needs to be determined. What kind of details about the subprocesses are needed to reach the objectives with the study? Is it enough that you know if there are an relationship between two activities, or do you need to know exactly what kind of information is exchanged and when? Do you need to know what mechanisms and controls that govern the process? The answer of these questions helps the decision of which process to focus on. 5. Choose technique. The exact combination of used techniques will depend on the previous discussed issues. It may be sufficient with one single technique to reach the desired objectives. Nevertheless, the authors believes that the following categorization of problem areas can be done: Organizational changes: To solve organizational problems an initial DSM should be used to identify problem areas. Task sequencing to solve sequencing and iteration problems can then be used. An IDEF0 model can be done if needed to investigate formal communication between processes and identify formal shortcomings. The results of the modelling work can then be used to reorganize the process. Computer support: If the main problem is identifying the exact information exchange process and implement it in a computerized document handling system (e.g. PDM, Product Data Management) an initial IDEF0 is preferred. Thereby, it is possible to determine if the process can be supported with computer tools. Better understanding of the process is also obtained. After the IDEF0 modelling a DSM can be done in order to identify iterations and make organizational changes. After the organizational issues are solved, the changes needs to be implemented in the IDEF0 model in accordance with the DSM results. The final step will be to implement the IDEF0 model in the computer support system.
6. Perform modelling. When the objectives with the modelling work, available time and resources, the size and needed detail level of the process is known, and a proper set of techniques is decided, the modelling work starts. The models need to be well documented for further analysis. 7. Analyze the models. When the processes are modelled, any needed analysis can be performed on the models. 8. Confirm and implement results. As a last step the results of the modelling and analyses needs to be controlled against the stated objectives. If they are reached the results of the modelling work should be implemented. If there are discrepancies, some rework may be needed or, if that is not sufficient, another method may have to be used.
8
Related Work
Gebala and Eppinger [14] investigated different methods for analyzing design procedures. They reviewed directed graph, PERT (Program Evaluation and Review Technique), SADT (IDEF0), and DSM. They found the notation form in the directed graph technique to be to cluttered and disordered for modelling of large networks, rendering it unsuitable for modelling most design procedures. The PERT technique did not handle feedback and iterations in any other way than by collapsing them to one single composite activity. Since one of the challenges in design management is uncertainties about iterations, a modelling technique for design procedures should be able to handle them. The SADT technique was likewise described as weak in this area making it less efficient for some kind of design procedure problems. However, the SADT technique was described as more orderly and structured than the previous two. Both PERT and SADT was perceived as having a practical size limitations of the documentation. Gebala and Eppinger [14] preferred the DSM for modelling, since it overcomes the size and complexity problems of the techniques discussed above. The DSM handles iterations well, and is relatively easy to understand. The results of this paper supports the findings of Gebala and Eppinger [14]. The problem with visualizing iterations in the IDEF0 model was also noted. However, the authors of this paper believes that in some cases this problem is offset by the strong sides of IDEF0, i.e. the structure and formalism suitable for implementing, for example, computer support systems. The applicability of the DSM was found to be good in both papers. However, this paper found the DSM technique to be weak when a strong formalism was needed. Furthermore, this paper
compares IDEF0 and DSM, and finds them to be complementary rather than competing techniques. Christian and Seering [15] address the design procedure modelling by including the intricacies of communication between interdependent design team into the model. Their model specifies work and communication for each task in the design project, the nature of the dependencies between the tasks, and the roles of the individuals assigned to the tasks. This makes it possible to simulate the process with computer agents representing individuals to obtain better understanding of the process. However, the discrepancies between real life individuals and the computer agents makes it difficult to use this approach when modelling company processes.
9
Conclusions
It can be argued that IDEF0 focuses on the formal communication of specified information. DSM, on the other hand, focuses on informal communication. The techniques support each other. Depending on the objectives with the modelling work, both techniques can be used. Useful insights can be reached with little additional work by using both methods. IDEF0 support activities like computer support implementation better than DSM since it provides more information and formalism in the models. DSM supports organizational issues like task sequencing and iteration problems better than IDEF0 since it easily takes informal communication into consideration.
Acknowledgments This work was financially supported by the Swedish National Board for Industrial and Technical Development. This support is gratefully acknowledged. The authors would also like to thank Sören Janeheden at FFV Aerotech for his invaluable support during the modelling work.
References [1] Ross, D.T. “Structured Analysis (SA): A Language for Communicating Ideas,” IEEE Transactions on Software Engineering, vol. SE-3, No. 1, pp. 16-34, 1977. [2] Steward, D.V. “The Design Structure System: A Method for Managing the Design of Complex Systems,” IEEE Transactions on Engineering Management, Vol. EM-28, No. 3, pp. 71-74, 1981. [3] Eppinger, S.D., Whitney, D.E., Smith, R.P. & Gebala D.A. “A Model-Based Method for Organizing tasks in Product Development,” Journal of Engineering Design, Vol. 6, No. 1, pp. 1-13, 1994.
[4] Clark, K. & Fujimoto, T. Product Development Performance: Strategy, Organization, and Management in the World Auto Industry, Harvard Business School Press, Boston, 1991. [5] Bravoco, R.R. & Yadav, S.B. “A Methodology to Model the Functional Structure of an Organization,” Computers in Industry, No. 6, pp. 345-361, 1985. [6] Colquhoun, G.J., Baines, R.W. & Crossley, R. “A State of the Art Review of IDEF0,” International Journal of Computer Integrated Manufacturing, Vol. 6, No. 4, pp. 252264, 1993. [7] Sarkis J. & Lin, L. “An IDEF0 Functional Planning Model for the Strategic Implementation of CIM Systems,” International Journal of Computer Integrated Manufacturing, Vol. 7, No. 2, pp. 100-115, 1994. [8] Vroom, R.W. “Information Generated and/or Used During Product and Process Development,” Proceedings 2nd WDK Workshop on Product Structuring, pp. 131-140, Delf, The Netherlands, 1996. [9] Pikosz, P. Product Data Management in the Product Development Process, Licentiate Thesis, Machine and Vehicle Design, Chalmers University of Technology, Report No. 1997-11-07, 1997. [10] Metis, Metis Users Guide 1.9.1, NCR Metis A/S, Horten, Norway, 1997. [11] Smith, R.P. & Eppinger, S.D. “Identifying Controlling Features of Engineering Design Iteration,” Management Science, Vol. 43, No. 3, pp. 276-293, March 1997. [12] Pimmler, T.U. & Eppinger, S.D. “Integration Analysis of Product Decompositions,” Design Theory and Mehtodology, ASME, DE-Vol. 68, pp. 343-351, 1994. [13] Eppinger, S.D., Seminar notes, Royal Institute of Technology, Stockholm, Sweden, August 25, 1997. [14] Gebala, D.A. & Eppinger, S.D. “Methods for Analyzing Design Procedures,” Design Theory and Mehtodology, ASME, DE-Vol. 31, pp. 227-233, 1991. [15] Christian, A.D. & Seering, W.P. “A Model of Information Exchange in the Design Process,” Design Engineering Technical Conferences, ASME, DE-Vol. 83, pp. 323-328, 1995.
