Improving Supply Chain Operations performance by

using a collaborative platform based on

a Service Oriented Architecture

Rubén Darío Franco, Ángel Ortiz Bas, Víctor Anaya, Rosa Navarro

Research Centre on Production Management and Engineering (CIGIP)

Polytechnic University of Valencia

Ciudad Politécnica de la Innovación, Edificio 8G, Planta 1

C.P. 46022 – Valencia, Spain

Abstract. Every new technology promises to solve a lot of problems inside

companies and to achieve unforeseen performance improvements. Nowadays,

Service-Oriented Architectures begin to be promoted as new balsam where

companies may realize their visions and put all their new strategies in practice.

Initially focused on intra-organizational integration efforts, they begin to be

used when supporting inter-organizational business processes engineering in

networked organizations. Although these kinds of initiatives in most of cases

are lead by major companies, the INPREX project (Spanish acronym for Inter-

operability in Extended Processes), here presented falls out this category. By

contrast, this is an undergoing initiative leaded by a Small and Medium Enter-

prise (SME) and founded by a local government in Spain. In this work, we in-

troduce the IDIERE Platform which has been designed for supporting three ma-

jor requirements of networked enterprises: openness, flexibility and dynamism

when deploying and executing distributed business processes

1 Motivation

Collaborative Networks (CN) are enabling new ways of conducting business transac-

tions and functional alignment between their members [7]. As organizational form,

they tie together two or more companies that had understood the benefits of conduct-

ing win-win partnerships coming from such collaborative environments (([2], [6]).

When adopting this emerging approach, extended functionality needs to be de-

signed and deployed to reach such levels of interaction. Collaborative, Extended or

Distributed Business Process are terms used to name a set of activities that, in such

context, need to be carried out in order to accomplish some commonly agreed busi-

ness goal.

New technologies, mainly those related to the Internet are enabling the deployment

of global business processes and facilitating, at the same time, the interoperability of

the information systems in which they are supported [8].

The INPREX Project is an undergoing initiative founded by the Ministry of Educa-

tion and Science of the Spanish Government. One of the main objectives is the de-

Darío Franco R., Ortiz Bas Á., Anaya V. and Navarro R. (2005).

Improving Supply Chain Operations performance by using a collaborative platform based on a Service Or iented Architecture.

In Proceedings of the 2nd International Workshop on Computer Supported Activity Coordination, pages 56-65

DOI: 10.5220/0002576300560065

 SciTePress

ployment of a platform (called IDIERE) that, taking advantage of web services and

their orchestration, enables the engineering, deployment, execution and monitoring of

distributed business processes in a network of companies surrounding one SME

stamping firm in the automotive sector, located in Valencia, Spain.

In this work, we are going to present the architecture and main components of the

platform and how it has been used to improve the coordination and information visi-

bility in a distributed business process inside a network of companies surrounding a

stamping firm in the automotive sector.

The paper is structured as follows: Section 2 depicts how the service-oriented ar-

chitectures support Distributed Business Process Management. Then, in Section 3, the

IDIERE Platform is presented, that is, its architecture and the software components

that implement the architecture. In Section 4, how it has been applied for improving a

Production Planning Business Process and, finally, in Section 5, we state some con-

clusions that we are gaining when developing this project.

2 Distributed Business Processes Management and Service-

Oriented Architectures (SOA)

2.1 Introduction

Relaying on emergent Internet technologies, Service-Oriented Architectures (SOA)

[3] are allowing to conceive the Internet not merely as a communication channel but

also as support of more complex activities tied, for instance, to purchasing, personnel

recruiting or customer service support.

Business process management’s requirements and the Internet are moving towards

a third stage of evolution [9] where the applications that support business processes

are conceived as a single user graphic interface (based on web browsers) but whose

functionality is composed of computational capabilities on the client side combined

with a set of invocations to third-party provided services ([1]).

The main changes provided by SOA are:

• The capability of narrowing down the gap existing between the modelling and the

operational phases of the business process engineering, by means of intermediate

languages like Business Process Execution Language (BPEL) to link the business

process modelling world and the web-services world. BPEL is explicitly designed

to work with Web services and provide coordination and integration of business

services into higher-level business processes.

• The emerging web-services technologies (mainly XML, SOAP, WSDL, UDDI and

BPEL4WS) supporting the service-oriented architecture are wide-spread and well-

accepted by service-oriented tools.

• Web Services allow a loose decoupling between process’s functionality and execu-

tors [4] so they provide a higher dynamicity

When these concepts are applied to collaborative networks (CN) they gain additional

advantages related to information sharing policies and visibility. SOA-based applica-

tions orchestrate and compose invocations of computational capabilities by means of

service interfaces. This mechanism allows companies to keep as independent as they

want by only providing the information that could improve the global performance of

the CN.

Based on those principles, has been proposed [4] that web services interfaces are

able of encapsulating activities, or sub-processes, of a business process definition, and

then, support composition and execution of their instances.

2.2 Web Services extended

The term Web Service is used by various groups to describe widely differing con-

cepts. From a technological perspective, they have been defined as [11].

A Web service is a software system identified by a URI [uniform resource identifier], whose

public interfaces and bindings are defined and described using XML. Its definition can be dis-

covered by other software systems. These systems may then interact with the Web service in a

manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

By contrast, in a more business-related context, web services are also considered as

pieces of business functionality that companies provide (offer, rent or sell) to third

parties by using Internet-related technologies.

Despite the technological complexity that may be related to this technology, most

companies can be able of start providing services in a short period of time. This has

caused that service offering rate had increased quickly but without much order.

Although web services are not distributed objects [10], applying object oriented

computing principles may help when engineering software applications based on

SOA. Looking for such order, some attempts in the right way have been carried out

[5] where an extension of web service’s concept has been proposed in order to create

an upper-level entity which provides a unique access point for a set of web services

belonging to the same domain.

2.3 Supporting distributed business processes

Distributed business process can be conceived as a set of activities which are assigned

to different members of a CN in order to be accomplished to achieve a common goal.

When modelling this kind of processes, is not always possible to keep the same ab-

straction level for each activity/role. In fact, depends on how much detail can be gath-

ered. More, initial steps in process modelling always begin with a more or less clear

picture but without so much detail.

In the scope of this work, these two interrelated concepts will be introduced:

“Definition 1: an Execution Unit is a work package that may be com-

posed of a single activity, a sub-process or a whole process and that

could be assigned to some executors which have the proper knowl-

edge and capacity to accomplish the task for the global process”

From the information flows management perspective, the execution unit can be

seen as a computational function (ws) which maps some Data Inputs into Data Outputs

through some internal logic not accessible by others (in a black box way).

This led us to the concept of service and service provider. If each execution unit is

wrapped under some interface that can be located and consumed by third parties, it is

possible to consider it as a service that may be provided by some service provider.

Then, service providers or executors can be defined as follows:

Definition 2: executors are those service providers (organizations

or their resources) that are capable of accomplish some execution

unit for the global process by providing and consuming third-

parties services.

And relaying on SOA principles, it could be convenient to add:

“...by means of web services interfaces and a supporting data

model.”

We consider executors as some extension of the object web service concept. They

represent a conceptual unit that will be used as functional/computational building

block when assigning some execution unit for accomplishment. They have the follow-

ing structure (See Figure 1):

• Data Model layer: this data model is specific for the business domain within

which executor works and it’s devoted to provide the interoperability foundations

from the information flows perspective.

• Internal Logic layer: the data model represents the external interface to be ex-

posed in terms of information. If some additional computation is needed or exist-

ing system must be integrated, the internal logic layer is the mechanism to be

used.

• WS Layer: the internal logic may use several mechanisms to feed up the data

layer, even web services. Despite this, this layer is devoted to provide a set of

web services that will be offered to external applications. This layer is also de-

pendable of the executor’s interaction scenario.

There is no one single definition for executors. Instead of this, like when defining

classes in Object Oriented Programming, it could be better to define as many types as

needed.

Then, it’s possible to consider as executor to all organizational resources that may

provide some services to a global process by means of their WS interfaces. In this

sense, whole organizations, organizational units, systems, machines or devices (which

can be used for human interaction) being able of run web services instances may fall

under this definition.

Fig. 1. Executor’s Architecture

In order to completely define the execution model, we must create the execution units

(eu) which represents the atomic building blocks used to compose inter-organizational

business processes. Each eu represents a complete piece of work that will be assigned

to executors in order to be accomplished.

The proposed Execution Model is based on execution units’ assignment and moni-

toring to different executors. This facilitates a loose coupling of execution units and

the corresponding executor, enabling either early or late binding (at process runtime)

between them (See Fig. 2).

Fig. 2. The Execution Model assigns EU to executors and maps business representations with

process interfaces at runtime

3 The IDIERE Platform

The IDIERE Platform relays on SOA capabilities in order to automate business proc-

ess execution and monitoring. The platform provides a set of components allowing

users to be involved in several business process instances of execution.

The principle is straightforward: it works as any business process system does but,

at the same time, it provides different levels of automation when needed. Such levels

of automation are supported by corresponding web services interfaces.

IDIERE Platform is the information system that supports distributed business proc-

ess management capabilities by providing a set of components that allows creating and

maintaining a centralised set of repositories of processes, executors and exchanged

messages in each process’s instance.

3.1 The IDIERE Architectural View

The IDIERE Platform, is based on a traditional client-server architecture that is de-

ployed over the Internet. Inside the platform it’s possible to identify:

− The IDIERE Server: it supports two major phases: process engineering and execu-

tion. It allows defining collaborative business processes structure, storing them in a

common repository, registering executors, assigning execution method and execu-

tors to individual activities or sub processes, monitoring delegated activities, de-

ploying a set of indicators for performance measurement.

− Client-side: in terms of users, there would be a set of nodes which may be con-

nected to the platform in order to notify each assignment’s status. Each node repre-

sents the instantiation of one executor for each process instance. Correspondingly,

each deployed thin client, will act as Task Manager for the system (in the tradi-

tional workflow sense) but having some extended functionality.

Initially, we have defined three different kinds of users that will access the plat-

form that is, users that will interact with the platform in order to: manage processes,

accept or reject assignments, or status reporting. The types of user identified are:

 Organization: this user initially will act as any company that provides some ser-

vice to a process. By means of its Task Manager, it will provide a service inter-

face that may be located and accessed by the server some eu accomplishment.

When Workers users are present, work items can be delegated.

 Workers are nodes belonging to an Organization. A Worker is a Task Manager

also but with a simplified functionality in terms of capabilities for delegating

tasks or accepting offers, for instance. Organization is able of adding their work-

ers by registering them into the system. Once this process has been completed,

tasks can be delegated to these nodes to be internally processed.

 Individual: finally, it represents individuals not belonging to any organization

but, once registered, may conduct transactions inside the platform.

3.2 The IDIERE Software Architecture

Major components of the platform are shown next (software modules, applications

and databases) and how they are interrelated.

Fig. 3. The IDIERE Architectural View and its Major Components

On the server-side, the architecture is mainly composed of:

• A Business Process Modelling Tool: it’s devoted to model business processes in a graphi-

cal way. Definitions are stored in three repositories:

 A Centralised Business Process Repository (CBPR) which will store business process

definitions. This repository can consider processes appearing in reference mod-

els as SCOR, or in standard documents as the ISO series; business processes de-

fined by a user as a template and finally business processes induced from web-

services by an inducer tool.

 A repository with all the business object documents that will give support to he

definition of information and control flows.

 The Network model configuration module is devoted to configure all those top-

ics related to the network deployment. That is, the organization model, execu-

tors’ permissions or additional parameters.

• The Business Process Engine is responsible of executing and monitoring proc-

ess’ instances. Consequently, it considers the enterprise models released by the

business process modelling tool and it is able to execute and monitor them. By

assigning each execution unit to the corresponding executor.

• Web Services Portfolio within which all active web services definitions that may

be used to compose a business process will be registered. There will be three

kind of services: sub-contracted with third parties (outside of the CN), internally

deployed (owned by the core members) and additionally those services that the

CN will able to provide to third parties to be consumed.

• The inducer engine is capable of inducing business process templates from exist-

ing web-services definitions.

4 Case Study: an SME stamping firm in the automotive sector

4.1 Business scenario

The IDIERE Platform has been deployed inside a network of companies surrounding

an SME (which is a 1

-tier Supplier, and high level sub-assembly supplier, for one

Original Equipment Manufacturer (OEM) in the automotive sector. The company is

responsible for its own logistics and independently chooses its own suppliers (2

tiers), the components of its products, etc.

The network, as it is now, has a relatively low degree of synchronization and col-

laboration. Generally, although the production plans of the company that is directly

connected with the demand are those who launch the supply chain’s production, cer-

tain information that needs to be drawn upstream is held up and sequentially the cycles

of planning and production decrease, and therefore the delivery time of the final item

is significantly affected.

Currently, this information flow is relatively restricted. The SME receives OEM’s

demand planning and makes its production plans and attendant orders to 2nd-tiers

according to it. But when small- scale changes and variation in demand coming from

the OEM arrive, SME’s production plans and order needs change, but the sub-tiers are

not informed on time and thus do not have the time they may need to change their own

planning, if this is possible.

4.2 Proposed solution

We have applied the IDIERE platform principles in order to achieve a successful

reengineering of the Production Planning Process (PPP).

After conducting a BP Analysis, PPP was identified as the most critical and conflic-

tive one. Due the company’s raising trend of outsource part of their production activi-

ties, more information visibility and co-ordination of such activities was needed.

Three kinds of executors were identified and their services modeled:

1. Productive: they transform some inputs (raw material or components) into out-

puts (components) by performing of some activity (stamping, painting, welding

or similar). Finished or semi-finished goods are packaged in specific containers.

2. Transport: this kind of executor moves containers between productive executors.

3. Warehouse: they stores finished or semi-finished goods

Fig. 5. Organizational resources have been modeled as executors

Once executors have been modelled, supporting services were developed for each

kind of executor. Then, there is a set of services belonging to each one of them. For

instance, productive executors are able of notify stocks, capacities, enact their Bill of

Material, receive demand, put orders and so on.

Table 1. Supported services (non exhaustive)

Executor ServiceName Description

NotifyDemand() It allows knowing which the demand for

some reference is.

NotifyStock() It returns stock of some reference

BillOfMaterial() It returns those references which compose

other one

Productive

Capacity() Notify agreed capacity about some refer-

ence based on signed contracts

Input() Register receptions of material

Output() Register material consuptions

Warehouse

Stock() Notify availability

Load() Load some package into the transport

Unload() Unload packages

Transport

Move() Move them between executors

After that, we modeled the production process of each reference (almost ninety) as a

business process within which each activity (stamping, welding, and painting) is asso-

ciated with the corresponding executor and its services.

Subcontract or

Assembler

Raw Material Supplier

Subcontratista

Proveedo r

Fig. 4. Composing business processes by using executors and services

By using this set of services we provided the SME with a complementary module

running in the platform: a collaborative planner who checks SME’s plans feasibility

after analyzing the information gathered from each executor and, complementarily,

traces plan’s execution.

5 Conclusions

In this work we have presented advances in the work carried out within the INPREX

Project. We have introduced the IDIERE Service-Oriented Platform, and have defined

the main components that implement it. The project looks for a low-cost, flexible and

extensible platform that companies can use in order to design and execute inter-

organizational business processes by composing a sequence of services invocations.

We strongly rely on Service Oriented Architectures as a medium for enabling Small

and Medium Enterprises get involved in this kind of initiatives. By adopting standards

related to the Internet (Web Services stack for Communications, current initiatives

like OAGIS for content and BPMN/BPML for modelling) we have composed a

framework that is open, flexible and dynamic.

Regarding the project, it could be convenient to point out that currently there are a

lot of initiatives concerning business process management by using web services com-

position, but real undergoing implementations being carried out by SMEs are not so

usual. Currently, we are at the development stage of major components.

Acknowledgments

The INPREX (Interoperability of Extended Enterprise Processes) is project founded

by Ministry of Education and Science under the FEDER Program.

References

1. Britton, C. (2001). IT Architectures and Middleware: Strategies for Building Large, Inte-

grated Systems. Addison-Wesley.

2. Camarinha-Matos, L. and Afsarmanesh, H. (2001). Dynamic Virtual Organizations, or Not

So Dynamic? BASYS Proceedings pp 111-124.

3. Erl, T. (2004) Service Oriented Architectures: A Field Guide To Integrating XML and Web

Services. Prentice Hall.

4. Franco, R.D., Ortiz, A., Anaya, V. and Lario F.C. “IDR: A proposal for managing inter-

organizational business processes by using service oriented architectures". To be published

in PRO-VE ’04 Proceedings. Kluver Academic Publishers.

5. Kraft, R. (2002). "A Model for Network Services on the Web". The 3rd International Con-

ference on Internet Computing, IC 2002, 3:536:541, June 2002, Las Vegas

6. Mowshowitz, A. (1999). 'The switching principle in virtual organization', Virtual Organiza-

tion Net eJOV, vol. 1, no. 1, pp. 6-17

7. Ortiz, A., Franco R.D. y Alba, M. “V-CHAIN: Migrating from Extended to Virtual Enter-

prise within an Automotive Supply Chain”. PROVE’03 Proceedings. Processes and Foun-

dations for Virtual Organizations.

8. Rust, R.T. and Kannan, P.K. (2002) E-Service: New Directions in Theory and Practice. ME

Sharpe, Armonk, New York

9. Smith, H., and Fingar, P. (2002) Business Process Management: The Third Wave. Tampa:

Meghan-Kiffer Press, 2002.

10 Vogels, W. (2003). Web Services are not distributed objects. IEEE Internet Computing

Magazine. November/December 2003 (Vol. 7, No. 6)

11 World Wide Web Consortium (W3C), available at http://www.w3.org/TR/2002/WD-ws-

gloss-20021114/