Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Common Data Model for Design Document Exchange in Business-to-Business Networks Katrine Jokinen, Jukka Borgman, Reijo Sulonen Software Business and Engineering Institute Helsinki University of Technology P.O. Box 9210, FIN-02015 HUT, Finland
[email protected]
Abstract Design documents can be exchanged in business-tobusiness networks through Product Data Management (PDM) system integration. This rarely used approach provides new possibilities for faster and more controlled document exchange according to networked product development (PD) needs. PDM system integration requires, however, a common understanding of the exchanged document metadata (e.g. name, type, and version of the document). We analyzed internal data models for design documents in six companies to find their common concepts. On the bases of this analysis and requirements from the PD network perspective, we developed a common data model for design document exchange. This model was then used in a prototype system for PDM system integration. We suggest that e-business standards, such as RosettaNet, could benefit from including this kind of a common data model as a part of their message descriptions. With such an extension these standards could be used for PDM system integration in PD context.
1. Introduction Product development (PD) projects are more and more often conducted in a concurrent manner in networks of co-operating companies. This is a trend among our case companies and it is also documented in earlier research [10]. Accordingly, design documents need to be exchanged between the companies several times a day. These documents can be CAD models, drawings, bills of material, etc. that are stored in Product Data Management (PDM) systems. At the moment design documents are exchanged by e-mail or www-interfaces to PDM systems [8]. These practices can make design document exchange slow and error prone due to plenty of related manual work
and can thus be a major obstacle to PD outsourcing. As lead-times of PD projects need to be constantly shortened document exchange in PD networks needs to be quicker and more reliable accordingly. Networked PD sets new kinds of challenges for document management compared to traditional in-house document management [2]. Due to the heterogeneity of the network, documents must be exchanged between companies with different procedures and different PDM systems with different data models. For example, document and version identifiers differ from company to company causing unnecessary manual work and confusion. Furthermore, PD processes are dynamic: new versions of design documents, such as CAD models, are created daily. This rapid versioning requires efficient version control throughout the PD network [3]. Because PD activities are done in parallel in several companies the new document versions should be synchronized quickly and in a controlled manner within the company network. Because of these challenges we have chosen systemto-system integration of PDM systems for managing design documents in a PD network. With this approach document exchange can be done in few minutes with a reliable and controllable exchange process. This is due to reduced need for human intervention in the process and acknowledgement mechanisms between the systems. As a result the PD processes in company networks are expected to be in better control compared to current e-mail or www-based approaches. This is very important when companies are outsourcing PD to their supplier networks. The difficult problem in PDM system integration is the large number of different kinds of internal data models for design documents in different companies. These data models have to be mapped with each other to transfer documents from one system to another. For example, in one company, project, customer, and document identifiers are all coded into document name, and in another company they are four separate attributes. Mapping different
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
1
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
data models takes time, and if it has to be done separately with each company in a network it makes the system integration very slow. With a common data model each company only has to map their internal data model with this common model. This makes the integration quick and independent of any changes in the internal data models in other companies. There exist different integration standards for enterprise integration. An earlier comparison [8] found RosettaNet e-business standard [13] to be best suitable for integrating PDM systems. In RosettaNet, Partner Interface Processes (PIPs) are the integrating elements. These processes offer the control needed in document exchange and related engineering change management. Nevertheless, the current support for design document exchange in RosettaNet is inadequate for PDM system integration. This is why we decided to define a common data model for design documents to be used within RosettaNet messages. The use of RosettaNet supplemented with this data model standardizes the message format and contents, which has been found important in Business-to-Business (B2B) application integration [7]. Our research problem was: What kind of a common data model for design documents is needed for PDM integration in B2B networks? Our objectives were (1) to analyze internal data models used in the PDM systems of our case-companies, (2) to construct a common data model for design documents capable of transferring enough information for the integration of PDM systems with RosettaNet messages, and (3) to validate the result by building a proof-of-concept prototype for this kind of integration. We studied data models in our six case companies concentrating on design documents only. Preliminary experiences with the prototype suggest that our data model works at least in the scope of our case companies. The rest of this paper is structured as follows: in section 2 we present related previous work. We describe our research data and methodology in section 3, and the results from the case studies in section 4. Section 5 illustrates the common data model for design documents. The results are evaluated in section 6 and discussed in section 7. Section 8 is about conclusions and future work.
2. Previous work There has been plenty of research on project management and PD, but little attention has been paid to document management in that context. To our knowledge, document metadata has not been studied in PD context, but there have been efforts to standardize document metadata in other contexts.
2.1. Product development network research We have previously studied design document exchange in PD networks [2]. One reason for unnecessary
rework in PD projects was using old document versions. Rapid versioning makes it essential for the network to exchange new versions of design documents quickly and in a controllable way. By control we mean that the sender can be sure that the sent document was also received. In addition, when sending engineering change requests or orders, it is important to control, e.g., the response times and related design document versions over the network.
2.2. Document metadata research Tyrväinen and Päivärinta have identified and evaluated 11 organizational document genres of an industrial organization [14]. Their results show that universal definitions for a document are not sufficient in an organizational context when designing document management systems. They find that an analysis of document genres would enable the development of a particular genre and the related technology and processes. Karjalainen et al. [7] have identified and analyzed metadata that is related to genres of organizational communication. They did not attempt to analyze metadata at the document level, though. The metadata they identified on genres was related to describing the users, producers, and the use frequency of genres; describing the current technological implementations of a genre; and about processing needs of a genre. Therefore, their work cannot be used as such in this context. Päivärinta et al. [12] have studied different document metadata standards. These standards were developed for library and information collection contexts, however, and they do not include attributes important in the PD context. On the basis of an analysis of these metadata standards, Päivärinta et al., with the experts of their target organization, developed an enterprise-wide metadata specification for documents. The context of their study is to integrate document management systems after a merger, and the specification is intended to be used with all documents, not only PD documents. Therefore, their definition with 48 metadata elements is too effusive for the use in collaborative design networks. Peltonen has defined PDM concepts and a document data model for PDM systems [11]. The model has been implemented in a document management system, which is in use in a large Finnish corporation. Peltonen has not defined the attributes needed for PD documents, however, and his data model does not consider document exchange between companies.
2.3. Integration and data exchange standards PDM system integration can be done by constructing point-to-point integration, i.e. direct connections between systems, or by using integration standards. RosettaNet [13] is an e-business standard that enables integration using standard processes, which include standard XML messages. The design documents and their
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
2
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
metadata need to be transported within these messages. If the metadata is in standard format, design documents can be exchanged between the companies quickly and controllably. RosettaNet is not designed for PDM system integration, however, and thus needs additional definitions for document metadata. The standard is constantly developed, and there is a plan for a new Partner Interface Process segment called ‘2D Collaborative Design & Engineering’. The processes in this segment should include a standard way to describe design document metadata. PDX standard IPC-2571 [6] focuses on communication of product content information between original equipment manufacturers, electronics manufacturing services providers, and component suppliers. It is based on XML, and it provides a way to describe product content (bill of material), approved manufacturer lists, engineering change requests and orders, and deviations. It is anticipated that these descriptions will be added to the RosettaNet standard for exchanging manufacturing information [6]. Nevertheless, the standard does not include all the attributes needed for describing design document metadata. This is discussed further in section 6.
3. Research data and methodology The study was conducted as descriptive case study [15] including data from six companies. The six enterprises are all from Finnish high tech industry; two of them are design and manufacturing service providers, two sell consumer products, and two provide investment goods. All the products of these six companies are technically advanced and at the top of their market segments. Three of the companies have conducted PD projects collaboratively, and all of them have PD or manufacturing functions outside Finland. Five of the six information systems used for PD document management in the case companies were PDM systems. One was an engineering document management system with document management functionality equivalent to that of PDM systems. This system was developed by Peltonen [11]. In data collection we concentrated on document data models in those systems, although due to relations to other objects, such as projects and items, those objects were also investigated. Two researchers collected the data between June 2002 and August 2003. We interviewed the people responsible for PDM in some companies to get a better understanding of the internal data models and their usage. During those semi-structured interviews the company representatives also demonstrated their PDM system to us. The data were saved into an Excel sheet that acted as our research database. The common data model was constructed on the basis of an analysis of these data. A common data model could be constructed emphasizing several perspectives. Our priorities for the common
data model were PDM integration, simplicity of implementation, and reuse possibilities of the common data model in other RosettaNet processes that need to transfer design documents, e.g., engineering change requests and orders. PDM integration means here that the common data model provides enough objects and attributes for the receiving PDM system to save the document in the system and attach it to the right project and product. Simplicity refers to end user usability and implementation simplicity. Our case companies encouraged us to keep the common data model as simple as possible for usability reasons. In addition, we wanted to make the integration implementation as simple as possible. That is, as few objects and attributes as possible. The starting level of concepts and attributes in the common data model was the minimum set of attributes required by the PDM systems to save a document. To this attribute set we added the common attributes in the internal data models of our case companies. We also added concepts and attributes required because of the PD network context, e.g., sender and receiver information. This first draft of the model was further developed in discussions with case company representatives and PDM experts. It was also presented in a public seminar. Finally, we built a prototype of design document management system integration [9]. The common data model developed was used in the prototype to test that it could be implemented. The prototype included two instances of a document management system that had different internal data models for design documents. These instances were integrated to a messaging server that sent and received standard messages using the common data model. We tested the prototype by sending a design document (a CAD model) and its metadata from one system to another. We also compared our common data model to existing metadata standards to find out differences in them.
4. Results of the case studies The internal data models had a varying amount of objects, attributes, and relationships. The simplest included only 21 attributes for design documents, whereas the richest described these documents with 111 attributes. The smallest set was only a plan. We found more than 250 different attributes in the company data models. Table 1 presents the attributes found in three or more of these data models. Attributes present only in one or two of the data models were not considered important for a general data model, because their values would typically not be found in the PDM systems of the receiving companies. If such attributes were important for some collaboration partners, their exchange would have to be conducted with other attributes. This is further discussed in section 5. The documents in the different PDM systems varied on their structures, which were not explicitly described in all
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
3
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
the material we had. It was also not always clear to which concept an attribute belonged. However, all documents had version(s) and there were file(s) attached to them. A document is a main concept with attributes common to all its versions. The versions can have different functions. There can be parallel versions, e.g., in different languages, which are interchangeable. Other versions can describe the temporal evolution of the document; later versions replace older ones. The actual contents of a document are usually stored in a file, such as a CAD file or an Excel sheet. In addition, some systems include a possibility to construct a document of several subdocuments.
x x x x x x x x x x x x x x
x x x x x x x x x x x x x x x x x
Company F
x x x x
x x x x x x x
Company E
x x x
Company C
x x
x
x
x
x x x x x
x
x x x x x
x x x x
x x x x x x x x x x x x x x x x x
5. The common data model
Company D
Document identifier Name Document type Drawing type Creator Creation time Version Parent version Version information File name File format File location Modified by Modification date Current state Responsible person Responsible team Description Comments Language Approved by Approval date Related documents Item code Project
Company B
Attribute
Company A
Table 1. Common attributes in the internal data models of the case companies
x x
x x x x x x x x x
x x x x x x x x x x x x x
tor). Furthermore, there can be attributes, such as document identifier, that are not shown to the user. They can still be relevant in the exchange of documents, because the PDM system uses them as a relationship reference. Our case companies did not have a need to transfer product structures. The customer maintained product structures and attached design documents, including CAD models of items, to them. Bills of material documents were actually Excel sheets. If product structures had been more complex, an Excel file would not have been the best tool for storing and modifying the bill of material. Instead, the bill of material would have been stored in PDM as a real product structure with ‘where-used’ relations to other components. Our common data model is not capable of transferring such bills of material.
x
x x x x x x x x x
Documents have a unique document identifier. In some systems document name is used as its identifier and is thus unique; in other systems these are two different attributes. Some attributes were not explicitly listed in the material we received, but it is likely that the PDM system adds these attributes automatically (e.g. document crea-
The common data model includes the attributes shared by the internal data models in our case companies. In addition, there are attributes that were otherwise found necessary to include in the model – either because they were needed for RosettaNet messaging or as a result from interviews in the case companies or with PDM experts. The minimum level of attributes includes the attributes found in all six companies, either in their internal data model or the system they use. These are: document type, creator, creation time, version, file format, approved by, and project. The attributes responsible team, item code and document description were also found in all six companies, but they were not compulsory attributes. Therefore, they might not have a value for each document, and are thus also not compulsory in the common data model. The maximum set of attributes includes the common attributes from at least three of the internal data models of the companies. The set also includes other attributes, which are important to RosettaNet messaging (e.g. receiver information), or otherwise found necessary to include in the common data model (e.g. document identifiers used by the receiving companies). The common data model is presented as a UML (Unified Modeling Language) [1] class diagram in Figure 1. The objects of the data model are classes in the diagram, and the attributes of the objects are listed as attributes of the classes. The relationships of the objects are modeled as associations in the diagram. There is also one generalization relationship: Receiver and Owner are specializations of Company. The UML class diagram also includes example enumerations for document type, version status, version language, and file format. The document structure can be seen in the UML class diagram. Documents include Versions that have Files attached to them. This structure was not always clear in the research data. Some PDM systems do not include a separate master document concept, but instead only han-
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
4
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
sembly drawing”, it is obvious that the supertype is “Drawing”. Document types used within an organization have to be mapped to these common document types agreed on within the network. The number of different document types used varied in our case companies. One of the companies used 127 different types of documents, and adding such a list to a common model is not possible. Documents can be associated with other documents. For example, a CAD model for a tool used to manufacture a component would be related to the CAD model of the component. If there is a change in the CAD model of the component, the tool might need to be changed accordingly. The relationship from documents to other documents is many-to-many, which means that one document can be related to many (or zero) documents. For example, one tool can be used to manufacture two different components, and its CAD model would then be related with the CAD models of these two components. The relationship is noted by the attribute RelatedDocuments, whose value is a list of document identifiers. A document has an optional attribute, DocumentDescription that can be used to exchange company or network specific information not included in the common data model. For example, a company could add document keywords to its description. Such special use of this attribute should be defined in an agreement between the trading partners.
dle document versions. The objects and their attributes are listed in Table 2, which shows the description, type, and cardinality of the attributes. The optionality of an attribute is specified with its cardinality, which is (1) or (1..*) for a compulsory attribute and (0..1) or (0..*) for an optional one. The value lists for attribute values are modeled as enumerations. The common data model is intended to be used in RosettaNet messages, which should contain the metadata of a PD document in the common data model format. An example XML representation of a design document is shown in Figure 2 at the end of section 5.
5.1. Document A Document has two identifiers: ProprietaryDocumentIdentifier, which the owner of the document (e.g., a manufacturer) uses, and PartnerDocumentIdentifier used by the partner(s) in question (e.g., suppliers). The reason for having two or more identifiers is that companies do not use common identifiers for products: each company has its own naming convention for the products or components in question. In addition to the identifiers, a document has a descriptive name. The DocumentName is also used as its identifier in some PDM systems. In such cases, the attributes DocumentName and ProprietaryDocumentIdentifier are identical. DocumentType is chosen from an enumeration list. Drawing types can be added to this list; if the type is “As-RelatedDocuments
«enumeration» DocumentType +Assembly drawing +Quality data +CAD information +Project document +...
0..*
0..*
Version
Document -ProprietaryDocumentIdentifier : String -PartnerDocumentIdentifier : String -DocumentName : String -DocumentType : DocumentType -DocumentDescription : String -ResponsiblePerson : String -ResponsibleTeam : String -RelatedItemCode : String
0..*
1..*
1..* 1
Company
0..*
-VersionIdentifier : String -CreationTime : Date -VersionCreator : String -CurrentState : VersionState -StateTransitionTime : Date -StateTransitionUser : String -EffectiveDate : Date -ObsoleteDate : Date -VersionLanguage : Language -VersionDescription : String -Comments : String
1
-CompanyName : String -Location : String -ContactName : String -E-mail : String
Project -ProjectName : String
0..*
0..*
«enumeration» VersionState -ParentVersion +Draft +Ready +Checked 0..1 +Approved +Rejected +Obsolete +... 0..*
-ChildVersion
«enumeration» Language +eng +deu +fin +swe +...
File 1
0..*
Owner
Receiver
-LastModifier : String -ModificationDate : Date -FileName : String -FileFormat : Format -FileLocation : String
1
-ProjectMember
«enumeration» Format +text/plain +application/pdf +application/msword +image/jpg +...
0..*
Figure 1. The common data model
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
5
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
Table 2. Common data model attributes Object Attribute Type Document ProprietaryDocumentIdentifier String PartnerDocumentIdentifier String DocumentName DocumentType RelatedDocuments
String Enumeration String
DocumentDescription ResponsiblePerson ResponsibleTeam
String String String
RelatedItemCode
String
VersionIdentifier ParentVersion VersionCreator CreationTime CurrentState StateTransitionTime StateTransitionUser VersionLanguage EffectiveDate ObsoleteDate Comments VersionDescription
String String String DateTime Enumeration DateTime String Enumeration Date Date String String
LastModifier ModificationDate FileName FileFormat FileLocation
String DateTime String Enumeration String
CompanyName Location ContactName E-mail ProjectName
String String String String String
Version
File
Company
Project
5.2. Version The versions of a document form a set of trees. In other words, each version of a document can have at most one earlier version as ParentVersion, and each version can have any number of child versions. In the example of Figure 2, version 1.0 has version 0.8 as its ParentVersion. This could mean that versions 0.9 and 1.0 are parallel, and they are both based on version 0.8. A common version identification policy should be de-
Cardinality Description [1] [1] The identifier the document owner uses [0…*] The identifier(s) the partner(s) who receive the document use [1] Name of the document [1] Type of the document [0…*] Other documents this document is associated with (list of document identifiers) [0…1] Description of the document [0…1] Person responsible for the document [0…1] Team or department responsible for the document [0…*] Item codes of products the document is associated with [1…*] Document version(s) [1] Identifier of the document version [0…1] Parent version’s version identifier [1] The creator of the document version [1] The time the document version was created [1] State of the version [0…1] The time the state was changed [0…1] The user who changed the state [0…1] Language of the document version [0…1] The date the version becomes effective [0…1] The date the version becomes obsolete [0…1] Comments on the document version [0…1] Description of the version [0…*] The file(s) of a document version [1] Last person who has modified the file [1] The time the file was modified last [1] Name of the file [1] Format of the file [0…1] URL where the file is located (2) Owner (sender) and receiver of the document [1] Name of the company [1] Location or department of the company [1…*] A contact person within the company [1] E-mail address of a contact person [1] Name of the project fined in an agreement between the trading partners. After that, the proprietary version identifiers have to be mapped to these common VersionIdentifiers. There can be different kinds of semantics associated with document version identifiers as well. For example, in one company, versions 1.0, 2.0, etc. indicated that the document could be sent to suppliers. Versions in between, 1.1-1.9, were for internal use only. With the common data model this should be described with the VersionState attribute. VersionState describes the lifecycle status of the
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
6
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
document version. These states are related to the document management processes within the company. For example, in one company, the state of a version cannot be changed from “approved” to “draft”. Instead, a new version needs to be created. The possible state values should be agreed on with the trading partners. StateTransitionUser corresponds with the Approved by attribute found in the company data models. StateTransitionUser covers all state changes; if the state is “approved” the StateTransitionUser is the approver. The state of the document version is shared within the network, i.e., a document version should not be in different states in different PDM systems. A document version can have two dates describing its validity: EffectiveDate and ObsoleteDate. Effectivity is one of the key concepts in engineering change management [4]. It enables companies to optimize their processes on the network level. For example, an engineering change order can be sent to partners in advance with a date that tells when the change is effective. The date can be set beforehand to the date when, e.g., an old version of a changed component is used up from stock and thus eliminate costs from unnecessary scrap.
5.3. File A File contains the actual contents of a document, e.g., a CAD model. It is always associated with one version of a document, but there can be many files for one document version. For example, there can be PDF representations for documents such as CAD drawings that would otherwise require expensive programs to view. FileName and FileFormat are separate fields, because RosettaNet messages need the MIME type of the attachment as a separate field. Examples of the MIME types are given in the Format enumeration in the UML class diagram in Figure 1. If files are sent as attachments with RosettaNet, they have to be BASE-64 encoded, which increases the file size [9]. For large files (>10 MB), it might be more efficient to only include a URL where they can be downloaded. The URL is stored in the attribute FileLocation. This attribute does not have the same meaning as the file location attribute in the company data models. Within a company, this attribute usually refers to a vault or archive where the document is stored. These are typically not accessible by the partner companies.
5.4. Companies and projects A Company can be either the Owner or a Receiver of a document. The Owner is responsible for the document, and takes care of its delivery to other companies. There can only be one owner for a document, but the owner can change during the document life cycle. For example, the design supplier owns the document in the design phase, and the brand owner in the production phase.
Cover345 5766-345-22 Cover345 CAD information 345Specs Plastic cover for 345 Sonya Smith Design 345 1.0 0.8 Chris Brown 20031122T105047.047Z Approved 20040502T105231.031Z Eric Ericsson 20040615 20041231 eng This version is interchangable with version 0.9 Top left corner should now be ok! Sonya Smith 20021122T105446.046Z cover345.vtx application/octet-stream Designex London Mike Taylor
[email protected] Big Corp Dallas LeAnn Fraley
[email protected] Maggie
Figure 2. XML example of the data model
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
7
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
A company has contact information required for RosettaNet messaging: CompanyName, ContactName and E-mail. Company Location has to be defined as well, because there can be many divisions of an organization participating in the same PD project. These values have to be mapped to the unique identifiers used in RosettaNet. Documents can belong to one or many Projects, and projects can have many documents. ProjectName is also the identifier of a project and it has to be commonly understood in all integrated systems.
6.
Evaluation
The common data model is evaluated on the basis of a comparison with PDX standards and previous work, and experiences from tests with a prototype system. The research data and methodology are also evaluated.
6.1. Comparison with PDX standard We mapped the objects and attributes of our common data model to PDX standard IPC-2571 [6]. It was possible to describe our data model with this standard using only few user-defined (non-standard) attributes. The resulting document description in PDX format had, however, over 30 unnecessary attributes. Some of these attributes were compulsory in the PDX standard, but did not have a rational substitute in our model. This was mainly because PDX standard did not have objects, such as documents, that would correspond to our common data model, or objects in PDX standard and in the PDM systems were different from each other. This may cause unnecessary work and possible wrong mappings between the attributes of an internal data model and the common data model during implementation.
6.2. Evaluation of the data model The document structure of our common data model is simpler than that defined by Peltonen [11]. In his model a document is made of subdocuments that have different subdocument versions, to which the document files belong. We favored simplicity to ease the implementation of PDM system integration. In addition, the subdocument concept we left out was only found in the company using the system developed by Peltonen. This will, however, result in losing some of the information when transferring document metadata to the common data model from a system with a data model of higher expressive power. Tyrväinen and Päivärinta [14] found that document genres should be analyzed separately. This seems consistent with our comparison of the common data model with the core element set Päivärinta et al. [12] found in document metadata standards. PD context related attributes were not found from these standards. For example, important information on document version and its life cycle status were not included in the core set of these standards.
Our results back up their finding that these metadata standards are not adequate in the organizational context. We expected the internal data models in different companies to vary on the number of attributes, as well as on the attributes themselves. Nevertheless, it was surprisingly easy to find the common set of attributes from the internal data models. Almost all attributes that were not included in the common data model were actually only present in one of the internal data models. The vast amount of attributes excluded from the common data model and present in only one internal data model show that the common data model is only useful in the integration of PDM systems. It is not adequate to be used as such as an internal data model, because the internal data model of an organization has to reflect the company specific processes and document management practices. The common data model should, however, be considered when designing the internal data model. The common data model has been tested with a prototype system for design document exchange in PD networks, on which further details can be found in [9]. Tests with the prototype have proved that PDM system integration is possible with the common data model developed, and using RosettaNet. The tests were conducted in a prototype environment, but the systems used are also used in industrial environments. Therefore, it is presumable that the concept would also work in an industrial environment.
6.3. Research data and methodology evaluation The internal data models used as research data might not represent the best possible data models for the case companies. Internal data models might not be carefully designed, but instead be accumulated through acquisitions and other additions. Attributes are usually not removed from an internal data model. These are the internal data models actually used in the case companies, however, and therefore represent the metadata that needs to be transferred with a design document. The development of the model through experiences with the implementation of the prototype has been most beneficial to the usefulness of the model. It has also been encouraging to get positive feedback from the company representatives during the development process, and their comments have been taken into consideration in the development of the model.
7. Discussion 7.1. Discussion on the data model The benefit of the common data model is that companies do not have to analyze their data models separately with every new partner joining a network. This should make PDM system integration easier and faster. It is also possible to include project or company specific informa-
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
8
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
tion in the description attributes of the common data model if found necessary in some collaboration networks. There are also drawbacks in using a common data model in design document exchange. Important attributes might not be included in the exchange, because a general model cannot cover all special situations. If these attributes are not transferred using other attributes, this might result in unnecessary delays. For example, a designer might have to call the partner company’s designers each time there are updates to documents. The common data model is only a small subset of company data models, and two companies might have a much larger common subset of attributes if their internal data models were mapped directly with each other’s data models. If there are only a few stable partnerships, these drawbacks can outweigh the possible benefit of reducing integration time. However, in the PD context the reduction in integration time should outweigh the drawbacks, because the partnerships are dynamic, and there are many different partners for each company. Our interviews in the case companies revealed that the suppliers for one company can change as often as weekly, and there can be hundreds of them. One of our case companies states having about 300 suppliers. Adding a point-to-point connection to a supplier can take them up to three months. A PD project can take the same time, which makes this kind of set up time unacceptable. In addition, with point-to-point integration typically nothing can be reused. It also makes it difficult to change systems if there are many integrations to other systems. This backs up using an integration standard because of its quicker implementation and the possibility to reuse existing integrations.
7.2. Discussion on allowed attribute values The common data model does not include instructions on the allowed values for the attributes. We find that issues like lengths of strings etc. should be dealt with in the implementation. For example, VersionCreator could be ‘Chris Brown’ or ‘Brown, Chris’. This could cause problems, e.g., if the value of the attribute is needed to form a relation to a user. We expect, however, that usually humans, who can interpret information in different formats, would read this information. In the above example, the user would not even be found from the receiving company’s PDM system. The data model includes two identifiers for a document: ProprietaryDocumentIdentifier and PartnerDocumentIdentifier. It would be simpler to have all partners use the same identifiers for documents and versions. Changing the identifying conventions is not considered an option, though, as there can be many partners who all have different semantics for their document identifiers. For example, a document named “front_cover4” in one company can be “12-4445-5394” in another company. In addition, the identifier can be automatically given to the
document by the PDM system, in which case it would be impossible to use the same identifiers in all PDM systems of the network. It might be a good idea, however, to have a common data dictionary with unique names for documents, products and projects for each PD project. The issue of different identifiers also has to do with document versions. Version identifiers vary across organizations, both in their format (numbers, letters) and semantics (version status can sometimes be inferred from version number). Common version identifiers would solve the problem, but there are the same problems as with document identifiers discussed above. In addition, versions can have a different meaning. Some versions might be parallel, e.g., in different languages, whereas others might replace an older one. This information has to be added to the VersionDescription attribute. An example of this can be seen in Figure 2. Common document lifecycle models and document management practices would allow us to define a common state graph for document versions in PD networks. This would require the definition of common processes, and mapping the internal document management processes to these common processes. Such definitions are out of the scope of this study. For PDM systems with a richer data model, such as the one developed by Peltonen [11], that includes subdocuments and subdocument versions, the structure of a document has to be described in another way. For example, the document and its subdocuments could all be represented as different documents. The RelatedDocuments attribute of the original document would then list all the subdocuments, and the subdocuments would have the original document as their RelatedDocuments. The ModificationDate of a file refers to the last time it was modified by its owner, not to the time it was copied into the receiving PDM system. Most PDM systems do not allow the user to modify this attribute, though. When a partner sends a file, which is copied to a PDM system, the receiving system usually sets the current time as the last modification time of the received file. Therefore, it might be necessary to save the original creation time received in the document metadata to another attribute; for example, to add the text “original creation time” and the value of the attribute to the value of the description attribute in the receiving PDM system. Usually only the owner of a document should be allowed to make changes to it, e.g., to create new versions. This helps to avoid problems like having two companies create two new versions of a document and sending them to a third company.
8. Conclusions and future work Current document exchange practices in product development (PD) networks, such as e-mail and www-
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
9
Proceedings of the 38th Hawaii International Conference on System Sciences - 2005
clients to product data management (PDM) systems, can be slow and error prone. This study has provided a solution to facilitate document exchange by PDM system integration. We analyzed internal data models in six companies and found a common subset in them. This subset was the basis for a common data model, which provides a general way to describe design documents. We used the common data model in a prototype for PDM system integration. Preliminary experiences with the prototype suggest that our data model should work at least in the scope of our case companies. The prototype implementation shows that the data model includes enough information to transfer documents from one system to another. As more PD projects are conducted in business-tobusiness networks where the number of partners is large and the partnerships are dynamic, there is a need for fast PDM system integration. This integration process is facilitated by the common data model, as internal data models of the companies have to be mapped only once to this model and not separately with each partner. This would enable faster and more controllable PD processes in company networks, which is a prerequisite for current networking and PD outsourcing trends. The common data model can also be used as a starting point when developing company internal data models for design documents. We suggest that after further validation, RosettaNet e-business standard would benefit from including the model it in its forthcoming standards for collaborative design and engineering. Three of our case companies have started planning on testing our common data model in their collaborative PD processes. The development of the data model is a basis for further work in developing support for faster and more affordable PDM system integration in business-to-business networks. In the future, the common data model should be industrially validated with companies actually mapping their internal data models to it when integrating PDM systems. Future research should also include other product data besides documents: the exchange of item, product structure, and configuration information should be taken into consideration. The common data model could also be developed to include common enumerations for design document types and version states. In addition, a common version identifying policy could be added to the model. Such additions would require common document management processes across the PD network.
Acknowledgments
References [1] Booch, G., Rumbaugh, J. & Jacobson, I. The Unified Modeling Language User Guide. Addison-Wesley, Boston. 1998 [2] Borgman, J. & Sulonen, R. A Case Study of the Impacts of Preliminary Design Data Exchange on Networked Product Development Project Controllability. In Proc. of the Int. Conf. on Engineering Design, Stockholm, 2003. [3] Eppinger, S., D., Whitney, D., E., Smith, R., P. A ModelBased method for Organizing Tasks in Product Development. Research in Engineering Design, Vol 6, 1994. pp. 1-13. [4] Guess, V. C. CMII for Business Processes Infrastructure. Holly Publishing, USA. 2002. [5] Hasselbring, W. Information System Integration. Communications of the ACM. Vol. 43, No. 6. 2000. pp 32-38 [6] IPC-2571. Generic Requirements for Electronics Manufacturing Supply Chain Communication – Product Data eXchange (PDX). IPC, Northbrook, Illinois, USA. 2001. [7] Karjalainen, A., Päivärinta, T., Tyrväinen, P. & Rajala, J. Genre-Based Metadata for Enterprise Document Management. In Proc. of the 33rd Hawaii Int. Conf. on System Sciences. 2000. [8] Kotinurmi, P., Borgman, J. & Soininen, T. Design Document Management in Networked Product Development Using Standard Frameworks. In Proc. of the Int. Conf. on Engineering Design, Stockholm, 2003. [9] Kotinurmi, P., Laesvuori, H., Jokinen, K. & Soininen, T. Integrating Design Document Management Systems using the RosettaNet E-business Framework. In Proc. of 6th Int. Conf. on Enterprise Information Systems, Porto, 2004. [10] Paasivaara, M., Lassenius C. Communication in New Product Development Networks - A Case Study. In Proc. of 8th Int. Product Development Management Conf., Enschede, 2001. [11] Peltonen, H. Concepts and an Implementation for Product Data Management. Acta Polytechnica Scandinavica, Mathematics and Computing Series No. 105. The Finnish Academies of Technology, Espoo, 2000. [12] Päivärinta T., Tyrväinen, P. & Ylimäki, T. Defining Organizational Document Metadata: A case beyond standards. In Proc. of the Xth European Conf. on Information Systems, Gdansk, 2002. [13] RosettaNet. http://www.rosettanet.org. Referenced on 5/31/2004
This work is part of NetData research project, which is funded by the National Technology Agency of Finland and the case companies. We wish to thank Kati Sarinko, Hannu Peltonen, and the rest of the NetData staff for their constructive comments and suggestions.
[14] Tyrväinen, P. & Päivärinta, T. On Rethinking Organizational Document Genres for Electronic Document Management. In Proc. of the 32nd Hawaii Int. Conf. on System Sciences, 1999. [15] Yin, R. K. Case Study Research Design and Methods. 2nd ed. SAGE Publications, USA. 1994.
0-7695-2268-8/05/$20.00 (C) 2005 IEEE
10
