SUPPORTING NETWORKED PRODUCT DEVELOPMENT

WITH BUSINESS-TO-BUSINESS INTEGRATION

Recognizing a New Phase in the Integration Implementation

Hannu Laesvuori, Paavo Kotinurmi, Katrine Jokinen

Software Business and Engineering Institute, Helsinki University of Technology, Espoo, Finland

Keywords: Business-to-business integration, Product data management, Product development, RosettaNet.

Abstract: Networked product development is becoming an important topic for many industrial companies due to the

need to improve the performance of product development processes. In product development, product data

management (PDM) systems are typically used to store and manage the information related to the developed

products and thus business-to-business (B2B) e-commerce in this context requires integration of

heterogeneous PDM systems located in different companies. In this paper, we describe the characteristics of

B2B integrations (B2Bi) that enable e-commerce in the context of networked product development. The

basis for this paper is a set of semi-structured interviews conducted among the representatives of PDM and

B2Bi personnel in three companies, and the experiences gained on constructing a laboratory prototype of

PDM systems integration using the RosettaNet standard. We argue that there is a unique phase in the B2Bi

implementation process in the context of networked product development that we call project-level

integration. This phase arises from the project-oriented nature of product development, and recognizing it

seems important for the successful implementation of B2Bi in the context of networked product

development.

1 INTRODUCTION

E-commerce in business-to-business (B2B)

environment means automation of business

processes by using electronic networks (Turban et

al., 1999). The automation of a single business

process such as order fulfilment may require

interoperation of several heterogeneous information

systems (IS), such as Enterprise Resource Planning

(ERP) and Supply Chain Management (SCM)

systems from different vendors. These systems need

to be integrated with each other to enable the

exchange of information without human

involvement (Nurmilaakso and Kotinurmi, 2004).

The current experience with business process

automation between enterprises is mostly limited to

certain type of business processes. If we divide

business processes into continuous and project-

oriented business processes, we find that B2B e-

commerce has mostly been limited to continuous

business processes such as order fulfilment

(Laesvuori and Kotinurmi, 2004). With project-

oriented business processes we mean business

processes such as new product development (NPD)

that are temporary and non-routine in nature, and are

typically organized in projects (Eloranta et al., 2001;

Turner, 1999). There are indications that several

project-oriented business processes, such as the

NPD, would benefit considerably from business

process automation (Eloranta et al., 2001; Borgman

and Sulonen, 2003; Laesvuori and Kotinurmi, 2004).

This is also indicated in a study by Brunnermeier

and Martin (2002) who discovered that

interoperability costs due to poor communication of

product data during NPD are one billion US dollars

a year in the US automotive supply chain. In this

respect it seems important to consider what the

project-oriented nature of NPD would mean to the

integration of the information systems.

In this paper, we describe characteristics of B2B

integrations (B2Bi) in the context of networked

NPD. To pursue this objective, we chose to use the

case study methodology. Case studies provide a rich

methodology for studying the organizational context

in which the technology resides and case studies are

good for answering questions like how and why

(Benbasat et al., 1987). We conducted semi-

Laesvuori H., Kotinurmi P. and Jokinen K. (2006).

SUPPORTING NETWORKED PRODUCT DEVELOPMENT WITH BUSINESS-TO-BUSINESS INTEGRATION - Recognizing a New Phase in the

Integration Implementation.

In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Society, e-Business and

e-Government / e-Learning, pages 74-81

DOI: 10.5220/0001248300740081

 SciTePress

structured interviews in three companies, which all

had experience with networked NPD projects and

B2B integrations. The size of the companies varied

from one thousand employees to tens of thousands

employees. We interviewed 18 people altogether

responsible for B2Bi in general or Product Data

Management (PDM) systems integrations. All the

interviews were taped and transcribed. The results

were validated by presenting them to the

representatives of the case companies in a workshop.

We have also experiences gained by constructing a

laboratory prototype of PDM systems integration

using the RosettaNet standard (Kotinurmi et al.,

2004). Based on the interviews and the prototype

experiences, we illustrate how the project-oriented

nature of NPD would affect their B2B integrations.

The rest of this paper is organized as follows. In

section 2, we present previous research and our

findings from the semi-structured interviews

concerning B2Bi conceptualization. In section 3, we

briefly discuss business process automation and

B2Bi in the context of networked product

development and engineering change (EC)

management. In section 4, we illustrate based on the

experiences gained in building and evaluating a B2B

e-commerce prototype system (Kotinurmi et al.,

2004), what the project-oriented nature of product

development projects could mean to B2Bi in the

context of networked product development. In

section 5, we discuss project-level integration and in

section 6 we position our work in regards to related

work on B2Bi. Finally in section 7, we present our

conclusions and need for future research.

2 B2B INTEGRATION MODELS

2.1 Models in the Literature

There are few reports or case studies concerning

implementation activities of actual B2B integration

(Gunasekaran and Ngai, 2004; Chan and Swatman,

2003). In addition, the few existing articles have

different perspectives on the implementation process

activities.

Chan and Swatman (2003) analyzed 10

Australian companies and their e-commerce

initiatives and found that an organization’s change

process to e-commerce consists of four stages:

initiation, systems development, utilization and

routinisation, and diffusion and expansion. In this

model the change process initiation stage follows the

decision to adopt the e-commerce technology and it

would typically include experimentations and

feasibility study. Systems development stage would

include systems design and testing, and utilization

and routinisation would mean deploying the

technology to real use through user training etc.

Diffusion and expansion would mean introducing

the technology to new trading partners and new

business units within the organization.

Nurmilaakso and Kotinurmi (2004) see B2B

integrations as a one-time activity that consists of

business document, messaging and business process

issues.

Ousterhout (2003) presented that B2Bi

implementations consist of three stages: business

process modelling, back-end integration, and trading

partner integration. Business process modelling

would mean agreeing on business documents and

their exchange sequence, an activity largely

standardized by standards such as RosettaNet. Back-

end integration would mean getting the existing

enterprise information systems such as PDM and

ERP systems to exchange information according to a

set of business rules, typically defined in an EAI

system. Partner integration would mean getting the

agreed on business processes to operate with new

trading partners.

2.2 Models in the Case Companies

In the interviews we performed in the B2Bi teams of

three companies, we asked what kind of

classification to different B2Bi cases the

interviewees used. The interviewees in the two

companies that had hundreds of B2B integrations

had very homogenous view on the B2Bi cases: they

were either mass deployment or pilot cases. Pilot

cases were the times when a new business process

was being automated for the first time with a new

business document. Pilot cases were usually rather

complicated and they required considerable amount

of time and effort. The reasons for this included

need for building back-end system integrations, need

for modifications in the company’s internal way of

working, and the lack of experience with that

particular business document. Mass deployment

cases were straightforward B2B integrations on

business processes on which a pilot case had already

been finished. Mass deployment cases mainly

required exchange of B2B connectivity details such

as IP addresses of B2B gateways and digital

certificates, and the configuration of these details

into the B2B gateways.

In addition to the mass deployment/pilot cases

explicitly mentioned by the interviewees, two other

SUPPORTING NETWORKED PRODUCT DEVELOPMENT WITH BUSINESS-TO-BUSINESS INTEGRATION -

Recognizing a New Phase in the Integration Implementation

differentiating cases became evident: B2Bi towards

companies that were in customer role were

uniformly thought much more difficult than B2Bi

towards companies that were in supplier role. The

reason for this was that despite using standards such

as RosettaNet for the B2Bi, companies typically

used the standards slightly differently. This caused

need to somehow align the differences in the use of

the standards by, e.g., designing rules that use

conversion tables and Extensible Stylesheet

Language Transformations (XSLT) to translate the

differences. Typically the companies in customer

role could demand that their suppliers do this work.

Another type of B2Bi that arose in the interviews

was the need to somehow change existing B2B

integrations. The need for change could arise from

many different reasons, including the simple

technical reason that digital certificates used in the

secure messaging expire periodically. A perhaps

more important observation was that when customer

company changed the internal business unit with

which supplier company was operating, it typically

meant changes to the business message used

between the two companies and thus typically the

creation of new transformation rules. The reason for

the change in the business message was believed to

originate due to the new business unit having a

slightly different business process and/or back-end

information system.

2.3 NPD Project Differences in the

Case Companies

The PDM experts were asked to describe the

differences between the ongoing NPD projects in

their companies. One major difference was that

typically each NPD project had their own way of

working, i.e. they had different processes e.g. for EC

management. The back-end information systems

supporting the processes could also vary. Another

difference was that NPD project could be working

either on a totally new product or the new product

could be based on an existing product. NPD projects

based on existing products were typically smaller

and shorter in duration than NPD projects

developing new products from scratch, which were

overall considered much more complex and

dynamic. The amount, nature and partners with

which the NPD project collaborated varied, as

varying parts of the NPD were outsourced to varying

business partners.

Differences between NPD projects were often

tied to the physical location, or site, where they were

executed. It was typical for each NPD site to have

their own way of doing NPD. A major difference

related to NPD project sites was also that NPD

projects could be either done within a single site, or

the NPD project could be collaborative work

between several different sites.

3 B2B INTEGRATIONS IN NEW

PRODUCT DEVELOPMENT

In order to describe the context for this paper, we

present an example scenario of B2Bi, and discuss its

implementation. Consider the case of NPD for

consumer electronics, which is nowadays

increasingly being done collaboratively in a network

of independent companies (Borgman and Sulonen,

2003). The development of new products is driven

by the exchange of design documents such as CAD

models, which are typically stored inside the

company’s PDM system (Kotinurmi et al., 2004).

When a company participating in a networked NPD

wants to suggest a new feature to the product, it

means initiating engineering change request (ECR)

business process. This means that the company

initiating the ECR sends specifications of the

suggested engineering change (EC) to the other

companies involved in the networked NPD, which

can then respond to the ECR by stating how the

change would affect them in terms of e.g. expenses.

In order to automate the above ECR process with

B2Bi, all companies participating in the ECR

process must act uniformly on three separate levels

(Nurmilaakso and Kotinurmi, 2004):

• The companies must have shared

understanding of the business process. This

involves agreeing on the different roles that the

companies have in the ECR process such as which

company can initiate the ECR process, and the

sequence of the interactions such as that engineering

change request is always followed by a related

response to the request.

• The companies must agree on business

documents that contain the information needed to

execute the business process, such as identification

codes that specify to which product this ECR is

related to. This involves using uniform format,

structure and semantics in the business documents.

• The ECR specifications need to be somehow

communicated to the other companies. Typically this

is accomplished by packaging the business

document and necessary routing into a single

message, which can then be sent to the other

companies securely over the Internet.

WEBIST 2006 - SOCIETY, E-BUSINESS AND E-GOVERNMENT

Uniform agreement on the business process,

business document, and messaging may be difficult

even inside a single company. Companies have

different ways of working internally, and it is

unrealistic to assume a uniform way of working in a

dynamic company network with changing members.

However, a collaborative business process involving

multiple companies can be divided into private and

public sub processes. The private processes are

executed within a single company, and the public

processes are interfaces between companies. The

companies have the freedom to execute the private

processes in any way they wish and only the public

processes need to be standardized. Standards, such

as RosettaNet, already exist for this purpose

(Nurmilaakso and Kotinurmi, 2004).

A high-level architecture to support the above

ECR scenario with B2Bi is illustrated in figure 1,

which is a simplified version of the architecture

presented by Medjahed et al (2003).

This architecture consists of several isolated

back-end applications that are internal to the trading

partners, such as PDM and ERP systems. The back-

end applications are connected to Enterprise

Application Integration (EAI) layer that controls

internal business processes and provides services

such as workflow management and data

transformation facilities. The EAI layer is also

connected to the B2B Gateway that handles the

public process, typically according to some B2Bi

standard such as RosettaNet or EDI.

After successful B2B integration, the flow of

events in the ECR business process would be similar

to the following using our prototype system

described by Kotinurmi et al. (2004), and adjusting

it to the figure 1.The ECR process is initiated when a

designer, e.g. a mechanical engineer working in

Trading partner A fills an ECR template in the PDM

system, and links it with a drawing illustrating the

suggested engineering change to the product. This

creates a new document of type ECR to the PDM

system. When the lifecycle state of this ECR

document is changed to ‘approved’ in the PDM

system, a new inter-company ECR process is

initiated. The PDM system notifies the EAI system

about the state change, which starts a predefined

workflow in the EAI system. The workflow has

rules for deciding what events originating from the

PDM system require further processing. In this case,

there is a predefined rule in the workflow defining

that when a document of type ECR is changed to

‘approved’ state in the PDM system, a new inter-

company ECR business process using RosettaNet is

initiated. Thus, the workflow retrieves the drawing

and metadata describing it from the ECR document,

and creates based on them a RosettaNet business

document. The workflow then passes this business

document to the B2B gateway, which sends the

business document to the trading partner B securely

over the Internet, as specified by RosettaNet. After

this, trading partner A starts to wait for a response

message to the ECR.

Trading partner B receives the business

document at its B2B business gateway and unpacks

the received message into two parts: the drawing and

information about the related EC request. These are

sent to the EAI system, which creates ECR on

trading partner B’s PDM system. After this, a

Figure 1: B2B Integration architecture.

SUPPORTING NETWORKED PRODUCT DEVELOPMENT WITH BUSINESS-TO-BUSINESS INTEGRATION -

Recognizing a New Phase in the Integration Implementation

designer at trading partner B can review the

suggested EC using the drawing and a textual

description, and respond to the ECR with the

estimated impact of the EC using their own PDM

system. This initiates sending of a response business

document back to the trading partner A similarly

through EAI systems and B2B gateways.

Trading partner A then receives the ECR

response message through their B2B gateway, which

associates it with the related ECR request message,

and extracts the business document from it. B2B

gateway passes the business document to the ECR

workflow instance in the EAI system. The ECR

workflow then extracts the ECR reply from the

business document and notifies PDM system to

create a new document to the PDM system of the

type ‘ECR response’, and changes the lifecycle of

the original ECR document to ‘ready to process’

state. This completes the B2B integration of the

ECR process, and it is now up to the organization to

decide how to act on the received ECR response.

4 PROJECT-LEVEL IN B2B

INTEGRATIONS

When a new NDP project starts between companies

that have previously collaborated in NPD, there is a

certain amount of information system

implementation work caused by the initiation of the

new project. The companies have agreed on the

business processes to use, and have successfully

done the back-end system integrations necessary for

the automation of the business processes during

earlier collaboration. The new project, however,

requires work on top of the existing business process

automation between the two companies.

We call this additional information system

implementation work the project-level integration

work, as the source for it is the need to

accommodate the requirements of new projects. We

argue that the vast heterogeneity of NPD projects

even within a single organization causes variability

in the requirements for the business process

automation, and that it is unlikely that any single

configuration in the business process automation

between two trading partners could sufficiently

satisfy the requirements of all different projects.

The project-level integration work due to the

start of a new NPD project consists of several tasks

that are very different from each other. Moreover,

the project-level integration work can affect several

parts of the B2Bi between two trading partners. To

get a better understanding, we can divide the

modification work caused by the initiation of a new

NPD project in three groups based on the software

architecture presented in figure 1: project-level

integration work in the PDM system, EAI system,

and the B2Bi system.

4.1 Project-Level in the B2B

Integration System

The B2Bi system is responsible for implementing

the messaging, business document, and business

process specifications as specified by RosettaNet.

The B2Bi system must be configured with details on

how to use the standard, such as what IP addresses

to use in the messaging etc. Based on the interviews,

these details are mostly relatively stable and that the

B2Bi work used for one NPD project could be used

in the following NPD projects, as there is no need to

change for instance the IP address of the B2Bi

system just because a NPD project was started.

However, there appears to be a few exceptions.

Different NPD projects can require different

response times from the B2Bi. At early phases of

NPD projects ECs are often frequent and there is

possibility to use light-weight ECR process with

short response time. As the NPD project approaches

production stage, ECs become less frequent but they

can have severe impact on the NPD, which typically

leads to more thorough internal evaluations and thus

to longer response times. In addition, depending on

the nature of the collaboration and on the product

being developed, the project may or may not want to

use additional security such as non-repudiation

mechanism on the messaging to avoid possible later

disagreements. As RosettaNet specifications can be

ambiguous and leave room for interpretation

regarding these settings, we expect that different

NPD projects would choose these settings

differently. This would create need to change them

upon the initiation of a new NPD project.

4.2 Project-Level in the PDM

System

The EC and design documents, such as CAD

models, bills of material, etc., are usually stored in a

PDM system. The system handles the documents as

a file with the actual contents of the document (e.g.,

a CAD file) and its metadata. The metadata includes

information, such as the creator, version, and

lifecycle status of a document. In addition, it

describes the relation to other PDM objects, such as

users, projects, and other documents. A subset of

this metadata has to be sent to the other companies

with the actual document file, because the receiving

system has to be able to store the document so that it

WEBIST 2006 - SOCIETY, E-BUSINESS AND E-GOVERNMENT

can also be found from the system. This subset

might vary depending on the NPD project and their

internal way of working, and the modifications due

to this variability are assumed to be handled by the

EAI system as described later in this section.

The PDM system controls the access rights to

documents within the company. At the beginning of

each project it has to be decided who is allowed to

view the documents received from trading partners.

These access rights have to be added to the

documents when they are received and stored in the

PDM system, and they can vary from project to

project. For example, some projects can assign

access rights on a team level, meaning that each

team member working on a specific component is

allowed to see all documents related to that

component, whereas in other projects access rights

are assigned on a person level, i.e., it is separately

defined what documents each person is allowed to

access.

4.3 Project-Level in the EAI System

As noted in the interviews, different NPD projects

even within a single company typically have

different processes and back-end information

systems which lead to differences in the used

business message. Thus, even if two companies have

automated the inter-company ECR process with

transformation rules aligning the company-specific

differences in the ECR process business message, a

new transformation rule is needed to align the

differences in the business message between the

NPD projects. An example of such difference is the

distribution of access rights either on team level, or

on person level, as mentioned earlier in this chapter.

This kind of alignment work is common in B2B

integrations, but in our experience it is typically

rather stable and the need to do it repeatedly on the

start of every new NPD project would be unique to

NPD. This transformation logic could be rather

complex as there are many potential differences in

the business message. For example, the

transformation rule might need to include logic to

retrieve and insert data in the PDM system: some

fields in the RosettaNet business message are

optional, so some NPD projects may require their

use, whereas others allow the fields to be left empty.

An example of such a field could be the identifier

the trading partner uses for a product: in some

projects these might be required, in others they

might not even be known by the trading partners.

Moreover, companies often use internally different

identifiers for products, projects, etc. These

company-specific identifiers have to be mapped to

commonly agreed identifiers used in the message

exchange between the trading partners. Similarly,

RosettaNet uses unique identifiers, called DUNS

numbering, to identify companies and their different

locations. However, PDM systems can represent this

information differently, so conversion tables and

transformations to take care of the differences would

likely be required.

Another functionality of the EAI systems is the

creation and management of workflows that describe

activities and decision points in business processes.

The decision points describe what events result in

sending documents to trading partners, and what

should be done when documents are received from

trading partners. These workflows have to be

defined or at least checked at the beginning of each

project, to make sure that confidential documents are

not sent to wrong recipients, and that all relevant

documents are sent to those who need them. For

example, if a document version is approved, this

could mean that it has to be sent to those trading

partners who work with the same component. An

example for a receiving workflow is that the person

responsible for the corresponding component is

always notified by e-mail when a document related

to that component arrives.

The workflows can also take care of the business

message delivery timing which can be configured

per each NPD project (Jokinen et al., 2004). For

instance, some NPD project might want to have two

weeks time to implement previous ECs before

accepting new ECRs. The EAI system has to keep

track of the documents that should be sent to this

trading partner and then send the documents to them

at the right time.

4.4 Other Project-Level Issues

In addition to the changes to the PDM, EAI and

B2Bi systems, there is other B2Bi work that may

need to be done upon the initiation of a new

networked NPD project. The B2B integration must

be tested to see that the whole chain from the

initiating back-end system to the receiving back-end

system works as intended.

5 DISCUSSION ON

PROJECT- LEVEL IN B2BI

In this paper we argue that the vast heterogeneity of

NPD projects even within a single organization

causes variability in the requirements for the

business process automation, and that it is unlikely

that any single configuration in the process

automation between two trading partners could

SUPPORTING NETWORKED PRODUCT DEVELOPMENT WITH BUSINESS-TO-BUSINESS INTEGRATION -

Recognizing a New Phase in the Integration Implementation

sufficiently satisfy the requirements of all different

projects. Therefore, we believe that in a dynamic

company network with changing business

relationships there must be project-specific

differences that need to be aligned with project-level

B2Bi work upon the initiation of every new NPD

project. However, neither the existing literature on

B2Bi, nor our interviewees in the B2Bi teams

explicitly recognized this ‘project-level’ integration.

The reason for this, we believe, is that existing B2Bi

concern continuous business processes such as order

fulfilment. This is true also for the three companies

on which we performed interviews, as these

companies are only now starting to plan extending

their B2B integrations to concern also NPD.

A weak point in our argument for unique phase

in the B2Bi work in the context of networked NPD

is the somewhat loose connection to a concrete

business process. We described ECR business

process in general terms, but real B2B integrations

use more detailed business process specifications

such as Partner Interface Process (PIP)

specifications in RosettaNet. Using a specific ECR

PIP as the basis for our analysis would have given it

more credibility, but RosettaNet PIPs for ECR are

not yet in mature state (Laesvuori and Kotinurmi,

2004). Thus, rather than using work-in-progress for

our analysis we chose to use a higher-level

abstraction of the process that we believe is

generally acceptable.

The usefulness of our identification of project-

level B2Bi work in the context of networked NPD is

limited because we do not propose any solution to

problems we identified. Nevertheless, we believe

that recognizing these differences is an important

starting point for the solution proposition, which

remains future work.

Same functionality that in our example was

handled in, e.g., PDM and EAI could be

implemented also in other systems. For example,

workflow management tools for defining and

implementing business rules can exists in all PDM,

EAI and B2Bi systems. Moreover, it would be

possible to implement the business rules in a

separate software component. Thus, the grouping we

presented was somewhat arbitrary and affected by

what was considered the typical location of

functionality in the software architecture of our case

companies. It is meant to serve for illustrating the

typical case and for showing that typically several

components in the software architecture are affected

by the project-level related integration work.

6 RELATED WORK

Chan and Swatman (2003) analyzed 10 Australian

companies and their e-commerce initiatives and

found that an organization’s change process to B2Bi

consists of four stages: initiation, systems

development, utilization and routinisation, and

diffusion and expansion. Project-level integrations

would be done in their “diffusion and expansion”

stage. They did not identify project specific

differences in their work.

Ousterhout (2003) separated business process

automation between different business processes,

and different trading partners. In this division

project-level integration would reside on top of

existing business process automation in a certain

business process between two trading partners.

Nurmilaakso and Kotinurmi (2004) discussed

business process automation in more general terms,

and the project-dimension could be seen as a special

case of the one-time business process automation

that reuses existing integration work consisting of

agreements on business document, messaging and

process issues.

Altogether, in regards to the existing work on the

information implementation system activities,

project-level integration could be considered a

special case that was not previously explicitly

recognized. Moreover, the few existing articles

about the implementation activities of B2B e-

commerce implementations have different

perspectives on the process. Although the project-

level integration was not explicitly recognized in the

literature that concerns the implementation activities

of B2B integration, it has been recognized

elsewhere. Attempts to support networked NPD

projects through portals that can be reached over the

Internet exist, and in their context the project-level

has been recognized (Hameri and Puittinen, 2003).

In regards to this paper, Hameri and Puittinen (2003)

have different approach as instead of B2B

integrations they focus on the use of WWW as a

communication medium.

The need for flexible B2B integrations has also

been recognized in the context of virtual enterprise

(VE) research. VEs are enterprises that exist only for

a brief time and that are created by several

independent organizations to cooperate on a specific

business opportunity, and then dissolve when the

operational phase for the business opportunity has

been completed (Camarinha-Matos and

Afsarmanesh, 2003). VEs have many similarities in

their requirements for business process automation

with project-based business processes, as both

require flexible and dynamic B2B integration that

must be setup repeatedly and quickly. As VE

WEBIST 2006 - SOCIETY, E-BUSINESS AND E-GOVERNMENT

research is not focused on the support for the special

characteristics of networked NPD, we did not

discuss VE research in this paper.

7 CONCLUSIONS AND FUTURE

WORK

There is increasing demand to extend business

process automation also to project-based business

processes like new product development (NPD).

This drives the integration of product data

management (PDM) systems located in different

companies. On the basis of a set of semi-structured

interviews and the experiences gained on

constructing a prototype of PDM system integration,

we argued that there is a unique phase in the B2B

integration implementation process in the context of

NPD. We motivated this by describing the

engineering change request business process, which

is typical to NPD, and showing how this business

process would be automated in a typical B2B

integration architecture. Then, we showed what parts

of the B2B integration supporting the business

process automation would require further work upon

the initiation of new NPD projects.

We suggest that taking this project-level B2B

integration work into account when planning B2B

integrations for NPD context would be useful, as

otherwise there is risk that the B2B integration

would not fully support the project-oriented nature

of NPD. The lack of support for the project-level

B2B integration work could lead to unnecessarily

small breadth and scope for the B2B integrations,

with would cause unnecessary manual work.

It would be useful to target more research on

integration of project-based processes to propose

solutions to handle these differences. The different

project-specific aspects should be identified better so

that the B2B integrations would be agile to the

changes needed in different projects. As this project

specificity is not necessarily only NPD related

concept, it would be good to gain more experiences

in other business process automations that are

organised in projects.

REFERENCES

Benbasat, I., Goldstein, D. K., and Mead, M., 1987. The

Case Research Strategy in Studies of Information

Systems. In MIS Quarterly, Vol. 11, No. 3, pp. 369-

388.

Borgman, J., Sulonen, R., 2003. A Case Study of the

Impacts of Preliminary Design Data Exchange on

Networked Product Development Project

Controllability. In Proc. of the International

Conference on Engineering Design.

Brunnermeier, S. and Martin, S., 2002. Interoperability

costs in the US automotive supply chain. In Supply

Chain Management: An International Journal, Vol. 7,

No. 2, pp. 71–82.

Camarinha-Matos, L., Afsarmanesh, H., 2003. Elements

of a base VE infrastructure. In Computers in Industry,

Vol. 51, pp. 139-163.

Chan, C., Swatman, P., 2003. International Examples of

Large-Scale Systems - Theory and Practice IV: B2B

E-Commerce Implementation in the Australian

Context. In Communications of the AIS, Volume 11

Article 23, March.

Eloranta, E., Hameri, A-P., Lahti, M., 2001. Improved

project management through improved document

management. In Computers in Industry, Vol. 45, No. 3,

pp. 231-243.

Gunasekaran, A., Ngai, E., 2004. Information systems in

supply chain integration and management. In

European Journal of Operational Research, Vol. 159,

No. 2, pp. 269-295.

Hameri, A-P., Puittinen, R., 2003. WWW-enabled

knowledge management for distributed engineering

projects. In Computers in Industry, Vol. 50, pp. 165-

177.

Jokinen, K., Borgman, J. Sulonen, R., 2004. Support for

Managing Design Document Exchange in Business-to-

Business Networks. In Proc. of 10th International

Conference on Concurrent Enterprising.

Kotinurmi, P., Laesvuori, H., Jokinen, K., Soininen, T.,

2004. Integrating Design Document Management

Systems using the RosettaNet E-business Framework.

In Proc. of the International Conference on Enterprise

Information Systems.

Laesvuori, H., Kotinurmi, P., 2004. Towards Integrated

Document Management in Networked Product

Development. In Proc. of International Conference on

Electronic Business.

Medjahed, B., Bouguettaya, A., Ngu, A., Elmagarmid, A.,

2003. Business-to-Business Interactions: Issues and

Enabling Technologies. In The VLDB Journal ,

Volume 12, Number 1.

Nurmilaakso, J.M, Kotinurmi, P., 2004. A review of

XML-based supply-chain integration. In Production

Planning & Control, Volume 15, Number 6.

Ousterhout, J., 2000. Managing Trading Partners. In EAI

Journal, pp. 89-92, October 2000

Turban, E., King, D., Lee, J., Viehland, D., 1999.

Electronic Commerce, a Managerial Perspective.

Pearson Education, Inc., New Jersey

Turner, R. 1999. The Handbook of project-based

management: improving the process for achieving

strategic objectives. McGraw-Hill, London, 2

edition.

SUPPORTING NETWORKED PRODUCT DEVELOPMENT WITH BUSINESS-TO-BUSINESS INTEGRATION -

Recognizing a New Phase in the Integration Implementation