See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/258555496

An e-Collaboration Software Framework for the Ship Repair Supply Chain

Conference Paper · January 2005

CITATION READS

1 884

5 authors, including:

S. Makris Dimitris Mourtzis

University of Patras University of Patras Lab. For Manufacturing Systems and Automation (LMS)
190 PUBLICATIONS   4,286 CITATIONS    289 PUBLICATIONS   7,063 CITATIONS   

SEE PROFILE SEE PROFILE

Nikolaos Papakostas George Chryssolouris

University College Dublin University of Patras
100 PUBLICATIONS   2,617 CITATIONS    386 PUBLICATIONS   13,598 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MINOAS View project

CAPP-4-SMEs View project

All content following this page was uploaded by Dimitris Mourtzis on 14 July 2019.

The user has requested enhancement of the downloaded file.

An e-Collaboration Software Framework for the Ship
Repair Supply Chain
Dr. Sotiris Makris, Dr. Dimitris Mourtzis, Dr. Nikos Papakostas, Professor George
Chryssolouris
Lab. for Manufacturing Systems, Univ. of Patras, Dept for Mechanical Engineering &
Aeronautics, Greece

Dr. Ioanis Gaviotis

Neorion Shipyards, Siros & Dept. of Product & System Design, Univ. of Aegean, Greece

Abstract
This work deals with the issues of information flow and efficient coordination of the
activities performed by cooperating companies for the repair of a ship. In small-to-medium
ship repair yards, the business chains that need to be established are short-lived with rather
low transaction volumes and varying terms, reflecting loose or even one-time business
relationships. Moreover, work scheduling is in a constant state of flux and last-minute
change.
Having studied the business practices of the ship repair sector, we present a comprehensive
model addressing workflow and information flow within the ship repair environment. We
then present a software framework that implements our model with a high degree of
behavior customization. This framework makes minimal assumptions concerning the
information technology infrastructure of the business partners, such as the ship repair yard,
suppliers of materials, subcontractors and ship owners.
The software system is an Internet-enabled application operating through a web browser
interface. Email and SMS messages serve as additional communication channels. A
collaboration framework integrates the existing software applications of each partner using
XML to seamlessly swap data. A standards-based security mechanism safeguards the
sensitive nature of exchanged information.
The system handles critical operations of the ship repair business, such as enquiries,
tendering, cost estimation and order promising. When the contract is confirmed, the system
continues with job scheduling and monitoring and it concludes with invoicing. Moreover,
the system can handle ship repairs taking place in many production sites.
We present our findings from the pilot-use of the system in five European yards, where it
operates as a non-obtrusive tool for the management of supply chains. It required minimal
investment / organizational changes from participating partners and returns immediate
results: monitoring of historical transactions, capture of interim negotiation phases, and
immediate notification through alternative communication channels. Finally, we pinpoint

Contact person: makris@lms.mech.upatras.gr

© ICCAS 2005
1
some modeling preconceptions from the system developers and legacy business rules
abstaining from currently viable best practices.

Introduction
Supply chain management (SCM) crystallizes concepts about integrated business
planning, having been suggested by the academic community since 1950s (Shapiro
[3]). Strategic planning involves resource acquisition decisions to be taken over
long-term planning horizons, tactical planning involves resource allocation
decisions over medium-term planning horizons, and operational planning involves
decisions affecting the short-term execution of the company’s business. At the
strategic level, few decisions are made, but each decision takes a long time, and its
impact is felt throughout the organization, while at the tactical planning and
operational level many decisions are made, each requiring shorter time. The great
number of decisions in the tactical and operational level is taken together in short
time and can have significant impact in the overall performance (Chryssolouris
[1]).
There is a trend for the implementation of computer-based environments, to
facilitate automated communication among the partners in a supply chain network.
Value-chain integration uses Internet technology to improve communication and
collaboration among all parties within a supply chain (Papazoglou, et al. [5]). The
Internet fosters the integration of business processes across the supply by
facilitating the information flows that are necessary to coordinate business
activities. (Lancioni et al. [6]). Although traditional electronic commerce such as
EDI transactions have been conducted over proprietary value-added networks, new
Internet-based electronic markets could include much larger numbers of buyers and
sellers. Utilizing the Internet to support procurement-related processes enhances
customer service, lowers costs, and improves supplier relationships (Roberts,
Mackay, [7]).
More recently, integrated frameworks for supporting supply chain management of
process industries have been proposed. Retailers, warehouses, plants and raw
material suppliers are modelled as a network of cooperative agents, each
performing one or more supply chain functions. Interactions between agents are
made through a common agent communication language and data is modelled
using standard exchange of product model data (STEP) (Garcia-Flores et al. [8]).
Even further, supply processes described with business documents and UML
diagrams may be automatically transformed to specifications for software agents
(Huhns [9]).

Business Model
The analysis of the business processes was realised with a combination of
traditional modelling approaches such as flow diagrams and UML (Quatrani [4]).
UML is a graphical notation based on the combination of three different object
oriented analysis and design approaches and defines a set of diagrams for software
engineering and for modelling business processes using the object oriented
paradigm. The use of UML was adopted for two purposes, the analysis of the

© ICCAS 2005
2
current business processes and the design of the architecture of the software that
was developed.

Maintain work
Shipowner
specification list Shipowner,
Sign contract
Shipyard

Submit Enquiry Shipowner

Repair worklist to
Shipyard
purchasing department
Examine Enquiry
Request work Shipyard
specification list Shipyard,
Plan the work
subcontractors
Submit work specification Shipowner
list Shipyard,
Ship inspection
shipowner
Shipyard
Prepare estimate Shipyard,
Update repair worklist shipowner,
Receive work subcontractors
specification list

Estimate Shipyard Materials requisition, Shipyard

manhours Plan the work (Production), RFQs (Production)
Estimate Subcontractors
materials, RFQs Combine Material Shipyard
Keep manhours
Estimate Shipyard Requirements (Purchasing)
record
subcontracts, RFQs
Estimate Shipyard
time Follow up Orders to suppliers
Shipyard (Purchasing)
subcontractors work

Produce tender
Materials delivery Suppliers

Shipyard
Submit tender
Produce shiprepair invoice Shipyard

Negotiations

Submit invoice Shipyard

Accepted No
?

Payment of the invoice Shipowner

Yes

Figure 1: Overall business process of the ship repair

The overall business process of the ship repair was represented by a flow diagram
that is very similar to the UML activity diagram and in a simple way models the
interactions among the cooperating partners as it is in figure 1. According to this
diagram, four types of companies are involved that are the ship owner, the material
suppliers, the subcontractors and the main partner that is the shipyard and links all
the other partners together.
A supplementary view that helps to realise the role of each partner in the ship
repair supply chain is provided by the UML use case diagram. Use case diagrams
give a graphical representation of the involved partners that in the UML jargon are
called “Actors” and the behaviour of the actors that is represented by the so called
“Use Cases”. The overall use case diagram of Figure 2 helps to model the
activities of the interrelated partners (Chryssolouris et al. [1]).

© ICCAS 2005
3
 <<uses>>

Shipowner
Submit enquiry Receive enquiry

Estimate produc tion

<<uses>>

Receive tender Plan produ ction

Submit tender

Submit shiprepair contract

<<uses>> Shipyard
Submit request for quotation

Start shiprepair work <<uses>>

Receive quotation
<<uses>>

Receive request for

quotation
Submit quot ation
Track shiprepair work

Update production plan Update plan

Subcontractor

Plan production Estimate production

Figure 2: Overall shiprepair use case model

Web-Based Implementation
The approach that is discussed in the previous sections has been implemented in
the form of an Internet-based software application. This software application
consists of two individual though integrated modules, the Collaboration and the
Monitoring and Planning module. The electronic collaboration among the ship
repair supply chain partners is realised through the Collaboration module, which
will be discussed in the current work. Based on the design of the system, there is
one instance of the Collaboration module, installed at the main shipyard that is
running the ship repair supply chain. All the supply chain partners have controlled
access to the Collaboration module workspaces, this means that the ship owner has
his own workspace that allows him to access the data that are related to his
business process. Similarly, the suppliers have access to their independent
workspace and access data related to the orders where they are involved. Finally,
the shipyard, as the operator of the supply chain has access to the information

© ICCAS 2005
4
provided by all the ship owners about the requested ship repairs, and also has
access to the information submitted to all the suppliers and all subcontractors.

Main Shipyard
= XML Interface
Shipowner

Legacy Collaboration Legacy

S/O Planning
Applications Application

R e qu

ry
Application Applications

i
c e es

qu
Re

iv t D

es En
e

q u it
E n e ta

Re bm

t
qu ils

Su
Legacy DB Collaboration DB

iry
S/O Legacy DB
Collaboration DB

ve
ei
c
Re
Planning
Application Internet

t
Re

es
ce

qu
i
Su ve R
Re
Planning DB bm FQ
e it
Supplier
n
Qu e i v
Qu
io ot
at
c

at
Re

ot

io
Subcontracted Shipyard ns
it
mb

SU Planning Legacy
Su

Legacy Planning Application Applications

Applications Application

SU Collaboration Legacy DB
Legacy DB Planning DB DB

Figure 3: The web enabled architecture

Both modules of the software framework have been implemented using the Java 2
Enterprise Edition namely the J2EE. The client interactions are implemented
through a common web browser and offer a rich functionality utilising available
technologies such as the Dynamic HTML, JavaScript, and Cascading Stylesheets.
Content is generated on the server side, which has been implemented using J2EE
web applications tools, particularly the Java Server Pages and Java Servlets
through the Jakarta Struts framework. The data are stored in a relational database
management server that; in this particular case it is the Oracle database.
Connectivity between the web server and the database server is implemented
through Java Database Connectivity (JDBC). Data exchange between the two
modules of the software is implemented using XML. A set of Data Type
Definitions is developed to model the exchanged data and to support the exchange
of data between the two modules and also with third party applications and with
legacy systems (Couch, Steinberg [Error! Bookmark not defined.]).
The ship repair business process was modelled and implemented in the system as a
set of business rules, thus controlling the interaction among the partners as well as
the validation of the exchanged information. An example of this implementation is
the enquiry business process implementation. The flow diagram and the way that
every partner interacts with the other partners as well as the way that the software
controls their interaction is demonstrated in Figure 3.

© ICCAS 2005
5
 Shipowner Representative Outgoing Enquiry
(Ow ner, Agent)

SUBMIT

ENQUIRY SUBMITTED
notification email

Shipyard Representative Incoming Enquiry

(Com.Man)

CREATE TENDER DECLINE CREATE RFQ

REQUEST DETAILS Reason for Decline

ENQUIRY ACCEPTED
notification email ENQUIRY DETAILS
SUBMITTED
ENQUIRY INITIALLY ACCEPTED notification email
notification email SUBMIT

ENQUIRY DECLINED
notification email

Shipowner Representative Outgoing Enquiry SUBMIT

(Ow ner, Agent)

Figure 4: The enquiry business process control implementation

The bold style characters, represent the status of the business process, therefore
when an enquiry is submitted by the ship owner, its status is “ENQUIRY
SUBMITTED”. As soon as the shipyard receives it and requests details from the
ship owner, the status of the enquiry becomes “ENQUIRY INITIALLY
ACCEPTED”. If the enquiry is declined for any reason, the status becomes
“ENQUIRY DECLINED”. When the details of an enquiry are submitted by the
ship owner to the shipyard the status becomes “ENQUIRY DETAILS
SUBMITTED”. Finally, when a tender is created for an enquiry, the status
becomes “ENQUIRY ACCEPTED”. As soon as a state change takes place, the
system sends a notification to the system users that are involved, the
representatives of the shipyard and the ship owner.
The above diagram demonstrates the business process implementation for the
simplest of the cases that is the enquiry submission. The actual software
implements the total of the ship repair business process including supply chain
tendering, contract planning and monitoring, subcontracting and purchasing.

© ICCAS 2005
6
Electronic collaboration scenario
A typical ship repair scenario can be analysed in the following set of steps or
functions as they are called in the jargon of the developed software:
• The ship owner submits an enquiry to the shipyard, giving abstract
information about the repair, for example that it is a planned maintenance
case. Additionally, a few details, such as the size and weight of the ship are
given.
• The shipyard then decides if they can do the work, if they have the
appropriate equipment and if they have had previous experience with the
ship owner.
• If the shipyard wishes to proceed with the repair, then they ask for detailed
information.
• The initial work list is sent from the ship owner to the shipyard. Next, the
shipyard performs an estimation of the work to be performed, based on the
initial work list. In order to build the estimate, the shipyard makes an
internal requisition for available personnel as well as for external supplies
required for the ship repair. A set of quotes becomes available to the
shipyard from the corresponding suppliers.
• The shipyard produces a tender. The tender is actually a list of quotes on
the work specification list that was initially provided by the ship owner.
• The tender is forwarded to the ship owner to be processed which can be
either accepted or sent back with comments.
• Negotiations are reflected on the work list and on the prices.
• Should the ship owner accept the tender, the initial contract is signed
between the ship owner and the yard, according to an updated work list and
tender.
• The ship arrives at the yard and the repair work is initiated. During the
repair, the work list is continuously modified so as to reflect the actual work
done. New items are attached to the initial contract and some items are
cancelled.
• When the ship repair work has finished, the invoice is issued by the
shipyard and is sent to the ship owner.
The major part of this scenario evolves around the use and modification of the
work list, which changes constantly.
These functions have been implemented in the software package and the business
process was supported adequately. The electronic form of an incoming tender is as
in Figure 5. Similar forms implement the rest of the business functions. Each
form is separated in two sections, one that details the tender specifics such as dates
and total cost and another one the details in itemised form the work to be done. For
each item more information is available such as item name, item description, item

© ICCAS 2005
7
cost, item status etc. Buttons on the upper part of the form enable to control the
workflow for example pressing the Accept button makes the tender acceptable and
therefore there is an agreement on the specification of the ship repair so that further
processing can be made.

Figure 5: Electronic processing of an incoming tender

Another important view of the system is the graphical representation of the work
plan and status of completion. It is implemented in the form of a Gantt chart that
can be viewed using the web browser and provides information on the plan and the
status of the work of each one partner of the supply chain, Figure 6.

© ICCAS 2005
8
Figure 6: Supply chain plan and status of work

In the specific case “NEORION” shipyard will perform the most of the items while
some of them are perform by the “HULL WORKS” subcontractors and by the
“External Shipyard”. The percentage of the completion of the work that each
company performs is also available through this view.

Conclusions
Most approaches to Supply Chain Management target large companies conducting
volume transactions with a fixed set of business partners. Implementing electronic
supply chains for small-to-medium enterprises (SMEs) poses quite different
requirements and calls for treatment of a number of practical issues.
In the case of SMEs in ship repair, business relations are far from static. The
developed system implements a dynamic supply web (Kumar [10]), where business
rules vary for each transaction, since typically there is not an up-front agreement
between partners. The setup and abandonment of the supply chain between two
partners is the norm, therefore it must entail minimal organizational effort and cost.
For this reason and due to the specialized nature of the market, employment of
intermediaries (Fielt [11]) is not recommended.
SMEs computing infrastructure that includes equipment and IT personnel is often
minimal. The developed system requires only a workstation with an Internet
connection. Since the connection may be non-permanent, messages can be
delivered via email or notice will be sent using SMS messages on mobile phones.
Also the fact that most companies will not be willing to alter their business
processes is considered, since the software system is non-obtrusive: it can operate
stand-alone to record and transmit transactions between partners. Negotiations
between people of different cultures, possibly over the phone, may result in
misconceptions; the proposed system acts as a flexible logging mechanism for
successive steps of negotiation.
If an ERP is in place, interfaces can be easily setup in a standard XML based way,
to move information in/out of it; neither retyping, nor re-customization should
occur.

© ICCAS 2005
9
Pilot tests have proved that all ends of the supply chain gain. For example, the ship
owner can have more timely and precisely-structured tenders that can be
automatically fed into its system for comparison. The shipyard can produce high
quality tenders, taking into account past tenders having been produced for the same
ship owner. Although, business relations typically are loose, such a system may
encourage long-term contracts for maintenance of a ship owner's fleet.
Concluding, both from a technical and a financial perspective, implementing such a
system brings positive results and entails minimal commitments and upfront
investments.

Acknowledgments
This work was partially funded by the European Union under project INTERMAR.
We would like to thank the rest of our partners in the project: Lisnave Estaleiros
Navais, Elefsis Shipbuilding and Industrial Enterprises, Dunston Shiprepairs,
AVEVA, Shipbuilders & Shiprepairers Association, Instituto Superior Tecnico,
Univ. of Newcastle upon Tyne, Izar Construcciones Navales and CASP.

References
1. Chryssolouris, G., Manufacturing Systems Theory and Practice, Springer-
Verlag, New York, 1992.
2. Chryssolouris, G., Makris, S., Papakostas, N., Xanthakis, V., A Cooperative
Software Environment for Planning and Controlling Ship-repair Contracts, 4th
Int. Conf. on e-Engineering & Digital Enterprise Technology, pp. 321-330,
Sept. 2004.
3. Shapiro, J. F., Modeling the Supply Chain, Duxbury, Thomson Learning, 2001
4. Quatrani, T., Visual Modelling with Rational Rose and UML, Addison-Wesley,
1998.
5. Papazoglou, M., Ribbers, P., Tsalgatidou, A., Integrated Value Chains and their
Implications from a Business and Technology Standpoint, Decision Support
Systems, vol. 29, pp. 323–342, 2000.
6. Lancioni, R., Schau, H. J., Smith, M., Internet Impacts on Supply Chain
Management, Industrial Marketing Management, 5336, 2002.
7. Roberts, B., Mackay, M., IT supporting supplier relationships: The Role of
Electronic Commerce, European Journal of Purchasing & Supply
Management, vol. 4, pp. 175-184, 1998.
8. Garcia-Flores, R., Wang, X. Z., Goltz, G. E., Agent-based Information Flow for
Process Industries' Supply Chain Modeling, Computers & Chemical
Engineering, vol. 24, pp. 1135-1141, 2000.
9. Huhns, M., Stephens, L., Ivezic, N., Automating Supply-Chain Management,
Proc. of 1st Int. Conf. on Autonomous Agents & Multiagent Systems, pp. 1017-
1023, 2002.

© ICCAS 2005
10
 10. Kumar, K., Christiaanse, From Static Supply Chains to Dynamic Supply Webs:
Principles for Radical Redesign in the Age of Information, Proc. of 20th Int.
Conf. on Inf. Sys., pp. 300-306, 1999.
11. Fielt R., et all, Confronting the Design and Acceptance of Electronic
Intermediaries: A Case Study in the Maritime Sector, Proc. of 6th Int. Conf. on
Electronic Commerce, pp. 392-400, 2004.
12. Welty B., Becerra-Fernandez, Managing Trust and Commitment in
Collaborative Supply Chain Relationships, Comm. of the ACM, pp. 67-73, vol.
46, no 12, Dec. 2003.

© ICCAS 2005
11

View publication stats