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-
74
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
Copyright
c
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
75
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
76
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
77
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
78
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
79
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
80
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
nd
edition.
SUPPORTING NETWORKED PRODUCT DEVELOPMENT WITH BUSINESS-TO-BUSINESS INTEGRATION -
Recognizing a New Phase in the Integration Implementation
81