Patrick Sitek, Sergio Gusmeroli Marco Conte, Kim Jansson, Iris Karvonen (Editors)

The COIN Book Enterprise Collaboration and Interoperability

Bibliografische Information der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in derDeutschen Nationalbibliografie; detaillierte bibliografische Da-ten sind im Internet über http://dnb.ddb.de abrufbar.

Vertrieb:

1. Auflage 2011© Verlagsgruppe Mainz GmbH AachenSüsterfeldstr. 83, 52072 AachenTel. 0241/87 34 34Fax 0241/875577www.Verlag-Mainz.de

Herstellung:

Druck und Verlagshaus Mainz GmbH AachenSüsterfeldstraße 8352072 AachenTel. 0241/873434Fax 0241/875577www.DruckereiMainz.dewww.Druckservice-Aachen.de

Satz: nach Druckvorlage des AutorsUmschlaggestaltung: Druckerei Mainz

printed in Germany

Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung ist ohne dieZustimmung des Herausgebers außerhalb der engen Grenzen des Urhebergesetzes unzulässig undstrafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und dieEinspeicherung und Verarbeitung in elektronischen Systemen.

Patrick Sitek, Sergio Gusmeroli, Marco Conte, Kim Jansson, Iris Karvonen (Editors)The COIN BookEnterprose Collaboration and Interoperability

1. Auflage 2011ISBN 3-86130-713-8

I

List of Authors Achilleas Achilleos (University of Cyprus), Juncal Alonso (TECNALIA), Leyla Arsan (LODER), Gorka Benguria (ESI), Dušan Bušen (GIZ-ACS), Gulcin Buyukozkan (LODER), Vittorio Cannas (CANNAS), Davide Cerri (STI-Innsbruck), Otakar Čerba (WirelessInfo), Karel Charvát (WirelessInfo), Karel Charvát jr (WirelessInfo), Elia Conchione (Soluta.Net), Marco Conte (ESoCE-Net), Enrico Del Grosso (TxT e-Solutions), Brian Elvesæter (SINTEF), Jens Eschenbächer (BIBA), Andrew Faughy (VEN), Pierfranco Ferronato (Soluta.Net), Daniel Field (ATOS), Klaus Fischer (DFKI-GmbH), Pavel Gnip (WirelessInfo), Sergio Gusmeroli (TxT e-Solutions), Konstantin Hristov (FAVIT), Mikko Höynälänmaa (POYRY), Kim Jansson (VTT), Francisco Javier Nieto (ATOS), Aslihan Kagnici (LODER), Iris Karvonen (VTT), Mindaugas Kiauleikis (Kaunas University of Technology), Valentinas Kiauleikis (Kaunas University of Technology), Srdjan Komazec (STI-Innsbruck), Szabolcs Kátai (IND/IVSZ), Gerardo Lancia (FILAS), Man-Sze Li (IC Focus), Aurelian Mihai (University Polytechnic Bucharest), Alexandru Mihnea (University Polytechnic Bucharest), Nerijus Morkevičius (Kaunas University of Technology), Zoltán Mózes (IND/IVSZ), Alberto Olmo (ISOIN), Simon Oman (Polycom d.o.o.), Leire Orue-Echevarria (TECNALIA), George Papadopoulos (University of Cyprus), Antonio Panazzolo (Soluta.Net), George Sielis (University of Cyprus), Michele Sesana (TxT e-Solutions), Patrick Sitek (BIBA), Florian Skopik (Distributed System Group – Vienna University of Technology – tuwien), Fabrizio Smith (TxT e-Solutions), Ioan Stefan Sacala (University Polytechnic Bucharest), Hannes Suttner (Siemens), Timo Syrjänen (POYRY), Jesús Sánchez (ISOIN), Francesco Taglino (CNR-IASI), Mehmet Tanyas (LODER), Drago Trebežnik (Jožef Stefan Institute), Hong-Linh Truong (Distributed System Group – Vienna University of Technology – tuwien), Mikel Vergara (TECNALIA), Ingo Zinnikus (DFKI-GmbH)

Thanks to all the Authors for their valuable contributions.

II

Preface of the Series High performing co-operations between independent companies with the aim to develop and to realise customised products are an important success factor for the competitiveness of the European industry. Due to immense political changes and global markets, new ways of co-operations, so called enterprise networks, can be seen in addition to the traditional supply chains. These enterprise networks are often formed to realise a single customers’ order and play an important role during the conceptual phase (product design) as well as during the realisation phase (production). The “Bremer Schriften zur integrierten Produkt- und Prozessentwicklung” (Bremen scientific series for integrated product and process development) bases on the works performed by the research field “ICT application for production (IKAP)” from BIBA – Bremer Institut für Produktion und Logistics GmbH (www.biba.uni-bremen.de) and on the works performed by BIK – Bremer Institut für integrierte Produktentwicklung (www.bik.uni-bremen.de). The research unit IKAP prepares, develops and realises methods and tools to support co-operative, inter-organizational enterprise networks. The research concentrates on efficient and effective collaborative design and production processes by applying innovative information and communication technologies (ICT). As focus can be seen the collaborative acting of enterprises during distributed design and production processes as well as during the late processes of the product life cycle such as the usage phase or the recycling phase. Additionally, the BIK research expertise is concentrated on the integrated development of products focusing on methods, tools and systems (like FMEA, QFD, CAD, CAE, and PDM). The main focus lies on products constructed by renewable resources, glass fibre or carbon fibre materials. The research results are integrated in the academic education of the next generation engineers (Production Enginnering, Systems Engineering, Engineering and Management) at the University of Bremen. Another application field of the research results are industrial projects where innovative approaches are transferred to practical problems. The institute is publishing the results of its work in a series. The objective of this series is to disseminate dissertations, project reports and proceedings of institute-hosted conferences to a larger circle of interested people.

The Series Editors

Prof. Dr.-Ing. K.-D. Thoben Prof. Dr.-Ing. D. H. Müller

III

The COIN Integrated Project: a flagship project of the Future Internet Enterprise Systems domain The Future Internet Enterprise Systems (FInES) Cluster1 was launched in 2009 by the Networked Enterprise and RFID unit of the Information Society and Media Directorate-General as a follow-up to the work already accomplished in the domain of networked businesses. This innovative domain was considered necessary given the upcoming challenges for our European enterprises in the Future Internet era, in a context of increased globalization and competition. The Cluster inherited the very rich advancements of three research domains previously supported by the unit: Enterprise Interoperability, Enterprise Collaboration and Digital Ecosystems, but the domain has never lost its scope on the usage and integration of ICT by enterprises. Encouraging disruptive innovation, its mission remains to orient research priorities towards new business approaches and business values supported by Information and Communication Technology, where the Internet is the business ecosystem. After the first FP7 call for proposals, COIN became the flagship project of the FInES Cluster and one of its most ambitious, complex and wide-ranging projects. As the full name of the project Collaboration and Interoperability for Network Enterprise may suggest, its primary objective was to aggregate two separated areas – Enterprise Collaboration and Enterprise Interoperability - developed by the precursors of the FInES Cluster. COIN rightfully observed that the two must be put together in order to have a coherent and efficient approach on the technology needed by our businesses. In this endeavour, the COIN partners gathered valuable research results from several EU funded projects that focused, however, solely on one of the two domains (see, for instance, the European ATHENA, INTEROP, ABILITIES, SATINE and TRUSTCOM projects on Enterprise Interoperability and the ECOLEAD, DBE, E4 or ECOSPACE projects on Enterprise Collaboration). One of COIN's most ambitious objectives is the provision of a universal service infrastructure capability based on the concept of the Interoperability Service Utility (ISU),2 a concept of high importance for the FInES community. The ISU, already announced by the Enterprise Interoperability Research Roadmap version 4.0,3 is destined to be a 'utility-like' interoperable technology capability that can be "invoked on-the-fly by enterprises in support of their business activities". The implementation of the ISU should play a key role in granting easy access for small businesses to the business ecosystem it supports, in line with the priorities for SMEs outlined in the Digital Agenda for Europe4 and in the Innovation Union5 Europe 2020 Flagship Initiatives. In this sense, COIN's potential achievements are of tremendous value, tracing the lines for further developments that the European Commission fully encourages. However, the numerous and ambitious objectives of COIN could not have been credible if they were an easy task to accomplish. It is our experience that projects aiming at building service platforms are bound to be confronted to serious obstacles. Furthermore, a project of the length (four years), size (twenty-nine partners) and complexity (seven sub-projects) of COIN meets even more unsteady grounds in conducting its research, having to deal with a continuous

1 http://cordis.europa.eu/fp7/ict/enet/ei_en.html and http://www.fines-cluster.eu 2 The first Grand Challenge of the Enterprise Interoperability Research Roadmap [European Commission, 2006 and 2008 3 ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/ebusiness/ei-roadmap-final_en.pdf 4 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0245:REV1:EN:HTML 5http://ec.europa.eu/research/innovation-union/pdf/innovation-union-communication_en.pdf#view=fit&pagemode=none

IV

redefinition of the questions and needs it was trying to answer to. Moreover, the achievements of the COIN project, as well as the results of the FInES domain, are and will always be "work in progress". A work that can be a source of inspiration for all of us, interested in the evolution of applied technology. A work made of blood, sweat and tears reaching out to other communities. And for all these reasons, a work that needed to be written down and published. I would like to acknowledge the considerable efforts and the valuable substance that is offered by the COIN consortium through this book. I congratulate them for its realisation and hope that the reader will find it an interesting, helpful and rewarding introduction to the subject area of next generation service platforms.

Cristina Martinez, Head of Future Internet Enterprise Systems cluster

V

Preface of the Volume This book presents the key results of the COIN Enterprise Collaboration and Interoperability project. COIN is an integrated project in the European Commission Seventh Framework Programme - EU FP7 Project 216256, which has been running for four years from January 2008 to December 2011. COIN’s dimension and impact is represented by its size of 32 industry, scientific and technological partners from Western and Eastern parts of Europe. The COIN book addresses the current state of the art and current practice, future scenarios and challenges for research and innovation of networking enterprises in the context of Future Internet Enterprise Systems. The COIN book is made of diverse parts following the projects’ main sub-projects trying to cover the broad research results and recapitulate them to a manageable overview for an interesting reading. The COIN book describes the main parts of the developed COIN IT Systems as well as consolidated baseline and innovative Enterprise Collaboration and Interoperability IT-services. It describes the COIN demonstrators in the field of stable industrial Supply Chains, more dynamic Collaborative Networks and most dynamic Business-Innovation Ecosystems. One chapter is dedicated to discuss the approach to bring COIN to the market in order to force our philosophy about the importance of the correlation between the achieved research results and the business world. Looking at the COIN main outcomes, the value of the project is not only constituted by the numerous public research reports which are available through our website www.coin-ip.eu and about 330 international and national events that we have organized. To our conviction COIN results may also impact the EU and the Commission in terms of future work and research priorities in the field of Future Internet Enterprise Systems (FInES). The COIN consortium wishes to acknowledge all those who have contributed to our results. The work has been co-funded by the European Commission under the ICT priority within the 7th Framework programme. We are grateful to the EU project officer Cristina Martinez, Head of Future Internet Enterprise Systems cluster, who has full supported the project throughout four years of research work. Our thanks go also to the COIN review committee Alberto Bonetti, Wolfgang Reisig, Carles Sierra and Joseph Tah for professional and productive discussions and exchanges at anytime.

Sergio Gusmeroli, COIN Project Coordinator TXT e-solutions SpA

Corporate Research Manager

VI

Table of Contents 1 The COIN Motivation, Object and Vision ............................................................................... 1 2 COIN IT System ....................................................................................................................... 7

2.1 The COIN Generic Service Platform for Enterprise Interoperability and Collaboration Service Provision ......................................................................................................................... 10

2.1.1 Introduction ................................................................................................................. 10 2.1.2 The COIN Generic Service Platform ......................................................................... 10 2.1.3 Semantic Execution Environment .............................................................................. 12 2.1.4 Agent-Based Negotiation ........................................................................................... 12 2.1.5 Trust and Security ....................................................................................................... 14 2.1.6 Peer-to-Peer Registry and Repository ........................................................................ 15 2.1.7 Conclusion .................................................................................................................. 16

2.2 The COIN Front End for Generic Service Platform Federation Consuming ............... 18 2.2.1 Introduction ................................................................................................................. 18 2.2.2 GSP nodes and Services provisioning to the GSP Federation .................................. 19 2.2.3 Consume the GSP Federation by a Human Oriented Interface ................................ 25 2.2.4 Guiding User Semantic Search by Free Text Wishes Expression - JSI .................... 28 2.2.5 Conclusion .................................................................................................................. 29

2.3 The COIN Collaboration Platforms Federation for Enterprise Networks and Business Ecosystems .................................................................................................................................. 31

2.3.1 Introduction ................................................................................................................. 31 2.3.2 Modelling, executing and outsourcing cross-enterprise collaborative business processes .................................................................................................................................. 31 2.3.3 Extended Products and Distributed Collaborative Innovation in Virtual Factories . 40 2.3.4 Conclusion and Future Work ..................................................................................... 43

3 COIN Enterprise Collaboration (EC) and Interoperability (EI) Services ............................. 45 3.1 COIN research results for enterprise innovation - Enterprise Collaboration Baseline Services ........................................................................................................................................ 46

3.1.1 Introduction ................................................................................................................. 46 3.1.2 Related Work .............................................................................................................. 47 3.1.3 EC Baseline Reference Model ................................................................................... 48 3.1.4 Conceptual architecture .............................................................................................. 50 3.1.5 Conclusion and key benefits ...................................................................................... 52

3.2 COIN Innovative Enterprise Collaboration Services ................................................... 54 3.2.1 Introduction ................................................................................................................. 54 3.2.2 Methodology and Workplan ...................................................................................... 54 3.2.3 Background and Previous Research ........................................................................... 55 3.2.4 Results - Overview of Developed Services ............................................................... 56 3.2.5 Innovations .................................................................................................................. 58 3.2.6 Conclusions and Key Benefits ................................................................................... 65

VII

3.3 COIN Enterprise Interoperability Baseline Services ..................................................... 66 3.3.1 Towards Enterprise Interoperability services ............................................................ 66 3.3.2 COIN EI framework ................................................................................................... 67 3.3.3 Enterprise interoperability baselines .......................................................................... 69

3.4 COIN Innovative EI Services ......................................................................................... 72 3.4.1 Introduction ................................................................................................................. 72 3.4.2 Information Interoperability services ......................................................................... 73 3.4.3 Process Interoperability services ................................................................................ 73 3.4.4 Knowledge Interoperability services ......................................................................... 74 3.4.5 Main innovation issues ............................................................................................... 75 3.4.6 Conclusions ................................................................................................................. 76

4 COIN Demonstrators .............................................................................................................. 78 4.1 The COIN EI/EC Services in industrial Supply Chains ................................................ 78

4.1.1 An EI/EC Pilot in an Automotive Supply Chain ....................................................... 79 4.1.2 Production Planning and Knowledge Interoperability Services in the Lazio Aerospace Cluster ................................................................................................................... 85 4.1.3 An EI/EC Pilot in a Railways Supply Chain (KTU) ................................................. 90 4.1.4 An EI/EC Pilot in a Construction Supply Chain (UPB) ............................................ 95

4.2 The COIN EI/EC Services in Collaborative Networks ................................................. 99 4.2.1 An EI/EC Pilot in Andalusia Aeronautics Cluster (ISOIN) .................................... 100 4.2.2 An EI/EC Pilot in The Hungarian ICT Cluster (IND) ............................................. 109 4.2.3 An EI/EC Pilot in a Marine Shipping Network (UCY) .......................................... 114 4.2.4 An EI/EC Pilot in a Logistics Network (LODER) .................................................. 121

4.3 The COIN EI/EC Services in Business-Innovation Ecosystems ................................ 126 4.3.1 An EI/EC Pilot in a Healthcare Ecosystem (VEN) ................................................. 127 4.3.2 An EI/EC Pilot in Pöyry business eco-system ......................................................... 135 4.3.3 An EI/EC Pilot in an Agro-Food Living Lab (WirelessInfo) ................................. 139 4.3.4 An EI/EC Pilot in a Digital Media Living Lab (FAVIT) ........................................ 145

5 COIN in the Business ............................................................................................................ 149 5.1 Supporting EC&EI service usability and take-up ........................................................ 150

5.1.1 Introduction ............................................................................................................... 150 5.1.2 Barriers and Challenges for IT take up .................................................................... 150 5.1.3 Development approach: Cross-teams ...................................................................... 152 5.1.4 Contributing to usability in EC &EI context ........................................................... 152 5.1.5 Development of COIN take-up guidelines .............................................................. 153 5.1.6 Conclusion ................................................................................................................ 157

5.2 Saas-U Value Proposition and Business Models ......................................................... 159 5.2.1 Introduction ............................................................................................................... 159 5.2.2 Assumptions and Hypotheses .................................................................................. 161 5.2.3 ISU Value Proposition and Business Model ........................................................... 161

VIII

5.2.4 Conclusions ............................................................................................................... 167 5.3 Bringing COIN to the Market ...................................................................................... 170

5.3.1 Challenges ................................................................................................................. 170 5.3.2 Logic adapted ............................................................................................................ 170 5.3.3 Development of business scenarios ......................................................................... 173 5.3.4 Type of Activity ........................................................................................................ 174 5.3.5 Scenarios in COIN .................................................................................................... 175 5.3.6 Conclusion ................................................................................................................ 178

5.4 Enterprise Collaboration Maturity Model .................................................................... 180 5.4.1 The problem description ........................................................................................... 180 5.4.2 Objectives and Use of the ECMM ........................................................................... 181 5.4.3 ECMM Design Process and Background ................................................................ 181 5.4.4 COIN ECMM Structure and Description ................................................................ 183 5.4.5 ECMM Application into End Users ......................................................................... 185 5.4.6 Conclusions ............................................................................................................... 188

Conclusions - The heritage of the COIN Integrated Project: how to move forward in the Future Internet Enterprise Systems domain ............................................................................................. 190

IX

Table of Figures Figure 1 – The COIN Butterfly model .............................................................................................. 8 Figure 2 – COIN GSP Architecture ................................................................................................ 11 Figure 3 – Composed services in the COIN context ...................................................................... 13 Figure 4 - Main components and relationships in the TSD Platform ............................................ 14 Figure 5 - P2P Repository/Registry Architectural viewpoint ........................................................ 16 Figure 6 - GSP evolution “cube” .................................................................................................... 20 Figure 7 - COIN GSP model ontology stack .................................................................................. 22 Figure 8 - COIN Assets Download ................................................................................................. 23 Figure 9 - GSP Model Configuration .............................................................................................. 23 Figure 10 - nodes waiting for approval ........................................................................................... 24 Figure 11 - The Web form for defining service pre-/post-conditions ............................................ 24 Figure 12 – Generic User Functionalities ....................................................................................... 25 Figure 13 - COIN Front-End deployment schema and COIN System upper Cloud interaction .. 26 Figure 14 - Browse & Search interface ........................................................................................... 27 Figure 15 - detail of the semantic search results ............................................................................. 27 Figure 16 - from the left: try-me button form, trust values and COIN SMW for information on the service ........................................................................................................................................ 28 Figure 17 - FTWE pipeline ............................................................................................................. 28 Figure 18 - Enrichment services ..................................................................................................... 29 Figure 19 - Industrial User - CP Integration Step 1 ........................................................................ 35 Figure 20 - Industrial User - CP Integration Step 2 ........................................................................ 35 Figure 21 - Injection in the business process of a discovered service ........................................... 36 Figure 22 - Industrial User - CP Integration Step 3 ........................................................................ 36 Figure 23 - GAP Identification - Flow diagram ............................................................................. 37 Figure 24 - COIN Step 2 – Overview ............................................................................................. 37 Figure 25 - Transformation Found .................................................................................................. 38 Figure 26 - Available Transformations ........................................................................................... 38 Figure 27 - Process Overview ......................................................................................................... 39 Figure 28 - automatic execution ...................................................................................................... 39 Figure 29 - Moving to an Extended Product .................................................................................. 41 Figure 30 - Evolution towards distributed, collaborative innovation ............................................ 42 Figure 31 - Extended products and collaborative distributed innovation in Virtual factories ...... 43 Figure 32 - EC Baseline Reference Model ..................................................................................... 49 Figure 33 - Conceptual architecture of the COIN Baseline EC software services and tools ........ 50 Figure 34 - Example of decoupling of an existing software .......................................................... 51 Figure 35 - Baseline IT Services Portal .......................................................................................... 52 Figure 36 - COIN overall development strategy ............................................................................ 55 Figure 37 - Overview of developed services .................................................................................. 56

X

Figure 38 - Healthcare sector ontology draft .................................................................................. 58 Figure 39 - Collaborative Production Planning .............................................................................. 60 Figure 40 - Example of meeting process and steps ........................................................................ 62 Figure 41 - Interoperability reference model .................................................................................. 67 Figure 42 - Baseline categories according to AIF .......................................................................... 68 Figure 43 – Commercial Process .................................................................................................... 81 Figure 44 - Technical process ......................................................................................................... 81 Figure 45 - Integration process for the legacy system users .......................................................... 83 Figure 46 - Integration process for the non-legacy system users ................................................... 83 Figure 47 - Knowledge Interoperability Pilot ................................................................................. 87 Figure 48 - Collaborative Production Planning Pilot ..................................................................... 88 Figure 49 - Manufacturing process of “VAE Legetecha” (fragment) ........................................... 91 Figure 50 - University “Politehnica” of Bucharest COIN implementation strategy ..................... 96 Figure 51 - The process of ordering materials from suppliers ....................................................... 97 Figure 52 - The process of collaborative project planning and change management ................... 97 Figure 53 - The Andalusian Aeronautic Cluster main competences and entities. ....................... 101 Figure 54 – Workflow example .................................................................................................... 102 Figure 55 - Some COIN Innovative services tested. Collaborative 3D designer service (left) and Interoperability Spaces (right) have been tested, for product design and contract negotiation, respectively .................................................................................................................................... 104 Figure 56 – Challenges and COIN Expectations .......................................................................... 110 Figure 57 - Use Case 1: Formulating the Recap Pre-Fixture Document ..................................... 115 Figure 58 - Use Case 2 – Creation and Settlement of the Proforma Disbursement Account (PDA) ........................................................................................................................................................ 115 Figure 59 - Use Case 1 – Formulation of the Recap Voyage Document using ProcessMaker .. 118 Figure 60 - Initialisation of the recap document business use-case ............................................. 119 Figure 61 - Dincer Lojistik business network for collaborative transportation ........................... 122 Figure 62 - The general business processes of Dincer Lojistik for use cases .............................. 123 Figure 63 – General development process for order transformation ........................................... 124 Figure 64 - Business Eco-System with actors in facility engineering projects ........................... 135 Figure 65 - Accelerate transition to global operation and networked engineering ...................... 136 Figure 66 - Interrelation of different knowledge levels ............................................................... 140 Figure 67 – Three Layers Architecture ......................................................................................... 141 Figure 68 – System overview ........................................................................................................ 142 Figure 69 - Architecture of Machine searching ............................................................................ 143 Figure 70 - COIN take-up process ................................................................................................ 157 Figure 71 – ISU Summary ............................................................................................................ 160 Figure 72 – ISU Stakeholder Categories ...................................................................................... 164 Figure 73 - Applying Competitive Models to the Supply of Utility Services ............................. 167 Figure 74 - Core and peripheral assets .......................................................................................... 172 Figure 75 - Value Chain for the core COIN technology .............................................................. 172

XI

Figure 76 - The complete value chain for COIN .......................................................................... 173 Figure 77 - Legend for value chain activities ............................................................................... 175 Figure 78 - Facebook Scenario 1 .................................................................................................. 175 Figure 79 – Facebook Scenario 2 .................................................................................................. 176 Figure 80 - Open Source Scenario ................................................................................................ 176 Figure 81 - Markeplace Scenario 1 ............................................................................................... 177 Figure 82 – Franchise Scenario ..................................................................................................... 178 Figure 83 - ECMM Maturity Levels ............................................................................................. 182 Figure 84 - ECMM Results: Comparison between the three companies ..................................... 185

1

1 The COIN Motivation, Object and Vision

COIN Background Enterprise Collaboration (EC) and Enterprise Interoperability (EI) have represented for European Commission’s FP6 research programme two of the major research domains in the field of “ICT for Networked Enterprises” (DG INFSO D4 “Networked Enterprise & Radio Frequency Identification”) and aggregated tens of projects and hundreds of researchers in their projects initiatives. Research in Enterprise Collaboration comes from a business perspective and identifies the process of enterprises - mainly SMEs - to set-up and manage cross-enterprise win-win business relations in response to business opportunities. The aim is to find new paradigms for European enterprise aggregation, process synchronization and people co-operation in response to the more and more demanding and complex business opportunities coming from the global market. In order to fully exploit its tremendous potential, EC research not only aims at achieving important and relevant results from the scientific, organizational, business standpoint, but it also magnifies the investments on resources in the Information Technology (IT) implementation of the key collaboration processes and cross-enterprise applications needed to make collaboration easier and profitable. However, most of the completed EU funded EC research initiatives have achieved significant results in the field of IT support to collaboration management and performance management, but they couldn’t address properly the problem of Enterprise Applications Integration (EAI). Research in Enterprise Interoperability originated by the IT world and identifies the capability of enterprise software and applications to be integrated at the level of data, applications, processes and models. Enterprise Interoperability started from an IT perspective of Enterprise Application and Software interoperability and focused on enterprise modelling, architecture and platforms, ontologies and semantics as the basic pillars for EI. This research stream proceeded very well in an analytical way to deeply investigate the various interoperability problems which affect European enterprises and has come out with a set of solutions for Enterprise Models Interoperability, Cross-organizational Business Processes, Semantic Business Document Reconciliation, IT Service selection and composition and Model-driven Architectures. However, EI solutions so far have been proved as efficient and effective in the IT and research community but have some way privileged in their field adoption the big enterprises while there is a tremendous need for EI efficient and effective solutions in the SMEs environment and in some less IT-developed sectors. Moreover, it seems that EI solutions so far lack flexibility and adaptation to different business scenarios and collaboration forms like Supply Chains, Collaborative Networks and Business Ecosystems. Hence, it is evident that research in EC lacks the adoption of innovative and advanced IT architectures and tools, while research in EI lacks best practices, clear business justification mostly for SMEs and real-life collaborative business applications. In synthesis, it is true that EC and EI are different concepts which cannot be merged, confused and mixed up, but that they are so interdependent, interconnected and simultaneously present in every networked enterprise, that they can be really considered as the two sides of the same coin! COIN Motivation Since more than a decade, the adoption of advanced Information Technology methods and tools has been considered one of the strongest competitive advantages for collaborative enterprises. However, so far EI/EC solutions in networked enterprises have mostly been implemented in hierarchical static supply chains, by forcing the installation and adoption of the same IT solutions

2

in all networked enterprises. But what happens in the presence of less hierarchical collaboration forms like in innovation ecosystems or when SMEs simultaneously belong to different supply chains and cannot simply adopt one single IT solutions. Networked Enterprises simply need more flexible and adaptable EC and EI solutions. On the other hand, the advent of Internet and the so-called Service Web has introduced unprecedented opportunities for e-commerce and e-business processes: the Internet has become a Universal Business System and service oriented architectures have completely revolutionised the traditional software engineering methods and tools. How to implement this huge potential for innovation in the field of EI/EC among networked enterprises? Networked Enterprises need more simple and easy to use access to Internet web services. So, there is a more general question which says “How to bridge the gap between Business and IT, making the Internet of Services easily accessible and integrated in business processes?” and a more specific question which focuses the topic to EI/EC: “How could networked enterprises have access and easily use the most advanced web services available in the Internet to solve their Interoperability and Collaboration problems?” The EI Cluster [13] in its research roadmap v 4.0 identified in the implementation of the ISU (Interoperability Service Utility) Grand Challenge a way to provide all enterprises, including SMEs, with a basic set of Interoperability Services to implement their collaborative business. Such an ISU was conceived both as a utility infrastructure (i.e. a service delivery platform for basic fundamental services) and as a set of innovative business models accompanying it. The fundamental motivation of the COIN project was the urgent need by collaborative business processes to easily access-compose-orchestrate-execute EI/EC services available to all in the Internet at a very low cost and under guaranteed service levels; in one sentence to implement the ISU and its most relevant business models applied to EI/EC services for any form of more or less hierarchical networked enterprise. COIN Project 2020 Vision Statement

“By 2020 enterprise collaboration and interoperability services will become an invisible, pervasive and self-adaptive knowledge and business utility at disposal of the European networked enterprises from any industrial sector and domain in order to rapidly set-up,

efficiently manage and effectively operate different forms of business collaborations, from the most traditional supply chains to the most advanced and dynamic business ecosystems”

The COIN Vision (COIN DoW) implies that in 10 years’ time, Enterprise Interoperability and Enterprise Collaboration services will be commoditized and factorized in the Internet of the Future as a set of Utility Services, available to all enterprises at a very low or zero cost and under non-discrimination and non-exclusivity policies: Interoperability and Collaboration as Public Services. From an IT architectural viewpoint, the COIN Vision implies that commercial Enterprise Systems of the future [13] should focus on the most added value services they could provide (e.g. supporting supply chains, customer relationships, product life cycle, financial and HR issues, in one word supporting Business Innovation) and leave the most commoditized IT services to the Future Internet open platforms developers. The COIN Vision is in agreement with the most recent EC policies and in particular with the Digital Agenda for Europe [12] which identifies 7 key themes to be solved in order to build the European Digital society. One of these pillars is: Interoperability and Standards: a digital society can only take off if its different parts and applications are interoperable and based on open platforms and standards.

3

From a business viewpoint, the distinction between Value Added (pay-as-you-go) and Utility (free) services is stimulating the development of innovative business models bundling Value Added services and Utility Services in a very similar way the media industry is bundling free and premium services. The latest outcomes of COIN business research show however that the full adoption of so called SaaS-U business models (merging SaaS and Utility models) will be effective for EI/EC services just starting from 2020, when Value Added services could be on-the-fly and dynamically selected in the private clouds by Enterprises and therefore the need of standardized EI/EC services available in the open clouds will become essential. Moreover, the present perception in COIN is that in the current business and market landscape for providing enterprises with just EI/EC Utility Services is not guaranteeing the IT providers with the necessary economical returns from the needed huge investments in ICT, according to the current costs of Cloud Computing and similar infrastructures. By 2020, thanks to the implementation of the Digital Agenda for Europe, it is supposed that current obstacles hindering the implementation of the COIN 2020 Vision (e.g. EI/EC services hard-wired, high costs to set-up a cloud service infrastructure, low bandwidth and network performance, predominance of on-premises monolithic solutions, huge availability of EI/EC services/information in the open Internet, legislative and regulatory issues which will combat monopoly positions and support open specifications and open standards) could disappear and make the provision for the ISU profitable also from a mere economic point of view. The COIN Metaphor The COIN “coin” metaphor is also useful to describe the 5 major research topics of the project: • The SIDE A of the COIN: Enterprise Collaboration.

The COIN Project develops innovative services for enterprise aggregation, synchronization and co-operation, adaptable to any collaboration form and suitable for SMEs needs. COIN will develop innovative services for Enterprise Collaborative in Product Development (c-PD), Collaborative Production Planning (c-PP), Collaborative Project Management (c-PM), as well as in Human Centric Collaboration (c-HI). The first three group of services directly support the corresponding collaborative operational functions; product development, production planning and project management, while the forth group of services are more general and not specifically dedicated to a business function. The c-HI services encompass services for human collaboration and data sharing and can be utilized as supporting services, for example in c-PD, c-PP and c-PM. The EC services are explained in more detail in chapter 3 of this book [4][5][6][7]

• The SIDE B of the COIN: Enterprise Interoperability.

Enterprise Collaboration is a term that describes a field of activity with the aim to improve the manner in which enterprises, by means of information and communications technology (ICT), interoperate with other enterprises or organisations to conduct their business. In the COIN context, EI services provide functionality for applying IT solutions that overcome interoperability gaps between two or more enterprises and thus enabling them to set-up and run collaborations. The COIN Project provides innovative integrated-unified-federated solutions for bridging interoperability gaps at the level of data, service, process and knowledge. The main goal of the EI services is to reduce the costs of data reconciliation, systems integration and business processes synchronization and harmonization. The COIN project adopted the ATHENA EI reference framework [1] which addresses interoperability at different levels, by using two main approaches (i.e., model-driven and semantics-based) The EI services are explained in more detail in chapter 3 of this book [8, 9 and 10]

4

Interoperability at the information/data level is related to the exchanging and sharing business documents among organizations, by filling interoperability gaps related to the format and content and to the messages and/or structures to be exchanged. Interoperability at the service level is concerned with discovering, ranking, selecting, composing, orchestrating and executing various applications implemented as a service. Interoperability at the process level is the capability to make proper external views of enterprise internal processes synchronised by a collaborative inter-enterprise business process. Interoperability at the knowledge level should be seen as the organisational and operational ability of an enterprise to co-operate with other, external organisations in spite of e.g., different working practices, legislations, cultures and commercial approaches. For both sides of the coin, COIN’s main objective here is i) to be the catalyst of previously developed EI/EC services, by harmonising their semantic descriptions and by supporting their registration into the same web site and discovering mechanism and ii) to develop innovative EI/EC services, extending the available ones with new methods, techniques and functions, as for instance the implementation of a federated interoperability platform or the integration of social networks in collaboration.

• The Metal of the COIN: Generic Service Platform.

The COIN Project develops a pervasive, adaptive service delivery platform to host COIN services for Enterprise Collaboration and Enterprise Interoperability. A generic Semantically Enabled Service Architecture has been customised for the EI/EC domain and empowered with peer-to-peer, trust & security and intelligent reasoning / negotiation capabilities. Here the objective of COIN is to develop an open-trusted federation of service delivery platforms, namely the ISU (Interoperability Service Utility) aimed at making accessible, browsable, composable and executable from a single one-stop-shop the myriad of EI/EC services developed not only in COIN but in any other research project or standardisation/commercial initiative. In the Future Internet (FI) perspective, the objective is to integrate such a federation with the FI Core Platform and its “Generic Enablers”, with the final aim to develop a set of “Enterprise-oriented utilities” and to realise the vision of FI as the Universal Business System. [3] The Generic Service Platform that has to provide COIN with a platform with a reliable layer for models and services. Regarding the interaction and interoperability with other COIN components, the Evolutionary and Pervasive Service Platform is simply seen as a Web Service, that holds information that is critical to the functioning of the COIN services and models. The pervasiveness of the platform is accomplished through the usage of a decentralization technique; the information is distributed and replicated in a set of connected nodes. The peer to peer protocols are a valuable technology for the organization of the information and for the communication infrastructure. In a peer to peer network the information is shared across the members of the community (represented by nodes) and it is not under the control of a single institution or organization. This approach is a promise for true equality; there is not a single point of failure inside the network and hence the services are more reliable.

• The Value of the COIN: Software as a Service Utility

5

The COIN project supports the establishment of business models for interoperability service utilities that will match current market condition and completion. The Information Technology vision of Software as a Service (SaaS) finds its implementation in the field of interoperability among collaborative enterprises, supporting the various collaborative business forms, from supply chains to business ecosystems, and becoming for them like a utility. In order to describe, reason and where possible assess change on different levels, the COIN research into EI Value Proposition needs to “integrate” the relevant key developments [11]. There are of course different schematics for integrating and characterising those developments. Given that the overall context for COIN is enterprise networking, the research will be concerned with developments that are ICT based and/or ICT enabled. In conformity with the vision and mission of COIN, the research is particularly concerned with market developments and trends with reference to the themes of Software as a Service (SaaS) and Interoperability Service [as] Utility (ISU). SaaS is a market reality while ISU is a research challenge premised upon a re-structuring of the current Internet. The notions of interoperability and collaboration are changing in perspective and scope as a result of both market reality and new research orientation towards a Future Internet. On the basis that the Future Internet represents the future of ICT, this could be elaborated as the Future Internet will provide a critical infrastructure for all enterprises, which is itself an articulation of the FInES Cluster vision of the Internet being a universal business system. The basic assumptions are that the Future Internet represents the future of ICT, this could be elaborated as the Future Internet will provide a critical infrastructure for all enterprises, which is itself an articulation of the FInES Cluster vision of the Internet being a universal business system. Enterprise processes will be subject to increasing commoditisation and IT capabilities will be subject to increasing contextualisation in order to better serve business needs.

• The Market of the COIN: Manufacturing Enterprises, mainly SMEs.

The COIN original project encompasses six industrial test cases in different domains (Automotive, Space, Aeronautics, Healthcare, ICT, Plants Engineering). The test cases have been extended to twelve, by adding new six domains coming from the so-called Enlarged Europe (Marine Shipping, Railways Components, Agro-food, Civil Construction, Logistics & Transport, Media). All the developed constituents of the COIN metaphor need to be deployed and adopted in realistic business scenarios and carefully evaluated in their business benefits and exploitation potential. To achieve this objective, specific attention is being spent in COIN to cover the different industrial sectors, European Countries, application domains, EI/EC heterogeneous requirements and legacy systems and applications.

References [1] Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications

(ATHENA) - IST-507849 FP6 - Integrated Project [2] Grant agreement for Collaborative Project, FP7 IP 216256 - COIN Large-scale integrating project, Annex I

- Description of Work [3] COIN deliverable D3.2.1b - Evolutionary and Pervasive Service Platform, 2009

6

[4] COIN Deliverables D4.2.1b - cProduct Development Services, 2009 [5] COIN Deliverables D4.3.1b - cProduction Planning Services, 2009 [6] COIN Deliverables D4.4.1b - cProject Management Services, 2009 [7] COIN Deliverables D4.5.1b - cHuman Interaction Services, 2009 [8] COIN Deliverables D5.2.1b - Information Interoperability Services, 2009 [9] COIN Deliverables D5.3.1b - Knowledge Interoperability Services, 2009 [10] COIN Deliverables D5.4.1b - Business Interoperability Services, 2009 [11] COIN deliverable D6.2.1b - Integrated EI Value Proposition, 2009 [12] DAE: A Digital Agenda for Europe, EUROPEAN COMMISSION Communication from The Commission

to The European Parliament, The Council, The European Economic and Social Committee and The Committee Of The Regions Brussels, 26.8.2010. COM(2010) 245 final/2

[13] FInES 2010: Future Internet Enterprise Systems (FInES) Research Roadmap FINAL REPORT, June 2010.

7

2 COIN IT System

The COIN system is a complex cross-enterprise environment encompassing several different components, platforms and services, which could be represented as a double cloud (COIN butterfly) visible in Figure 1. By mission, COIN aims at attracting as many EI/EC service providers and as many EI/EC service consumers as possible, becoming this way the reference service platform for EI/EC services. This means that the architecture of COIN system should be open, evolutionary, scalable, incremental, so that to become a catalyst for those who want to publish their services (according to their standards and business models) and those who want to access EI/EC services from the open Internet. During and after the COIN project life time, additional nodes have been and will be added to the initial COIN configuration, by integrating contributions coming from external sources (e.g. research projects like SOA4ALL6 and DEN4DEK7 or business-oriented initiatives like ITA - Information Technology for the German Automotive Industry - or GENESI DEC - Digital Earth Community -), this way experimenting and assessing the openness, scalability and interoperability of our technical choices. The COIN Integrated System is a federation of Platforms, Services and Web Interfaces which allow EI/EC Services to be searched, discovered, ranked, orchestrated and executed by cross-organizational business processes. There are three basic components of the COIN system, which could be interfaced in several different ways: • A COIN Generic Service Platform (GSP) which is an open source instantiation of a generic

SESA (Semantically Enabled Service Architecture), specialized in the EI/EC domain, and empowered with advanced capabilities for trust & security, distribution & scalability, reasoning & negotiation.

• A constellation of COIN EI/EC Services which are able to implement state-of-the-art and innovative technologies to support information, knowledge and business interoperability as well as Human Collaboration in a collaborative business context of Product Development, Production Planning and Project Management.

• A COIN Collaboration Platform (CP) which is a generic open source web portal encompassing Social Networking interaction, Knowledge Assets accession and Business Process management in a unique integrated multi-enterprise collaboration environment customized for more or less hierarchical organizational networks.

The COIN Integrated System Butterfly Model represents the complete vision of the COIN system integrating the previous identified basic components with the work provided in the final part of the project. The focus of the work, apart the empowering of basic components, is the integration and consumption of them through a more general vision of the system including several users and methodologies. The model is made of two distinct clouds, one for service provision (upper cloud) and the other for service consumption (lower cloud), being also supported the pro-sumers’ case; in the middle is the integration software allowing the communication among the two clouds and the service consumption by other kind of actors.

6 Service Oriented Architectures for All, http://www.soa4all.eu/ 7 Digital Ecosystems Network of regions for (4) DissEmination and Knowledge Deployment, http://www.den4dek.org/

8

Figure 1 – The COIN Butterfly model

A first upper cloud of open COIN and non-COIN service delivery platforms (providing utilities for service development, registration, publication, search & discovery, orchestration & execution) federated by EI/EC interoperable ontologies forms the COIN Upper Federation, which could be seen as a subset of the Future Internet of Services core platform (or Interoperability Service Utility) devoted to provide Smart Applications with common EI/EC commodities like human interaction, data mapping, service reconciliation and process synchronization functions. A second lower cloud of domain- and sector-specific COIN and non-COIN Collaboration Platforms provides Supply Chains, Collaborative Networks and Business Innovation Ecosystems with advanced EI/EC services supporting the whole product/service life cycle and collaboration phases, integrating legacy systems and data, constituting this way the COIN Collaboration Federation, a part of next generation FI-based Enterprise Systems (FInES). A third component is the integration software which is called COIN Front End and it is a plug-in either for the service delivery or for the collaboration platform, depending on the case. The scope of this component is to provide the communication among the two clouds and a set of services for the consumption of the capabilities of the upper cloud for users not facing the system from the lower cloud. Four main typologies of users could access the COIN System:

i. Individual users (humans – COIN Front End) who are browsing the content of the GSP and of the CPs (e.g. configuration, nodes federation, services, business models, various info);

9

ii. IT users (humans – COIN Front End) who are able to build and develop their own solutions (with or without the help of COIN platforms) and to link them to the COIN IT System;

iii. Industrial users (humans and/or automatic business processes – COIN Front End and lower cloud) who are able to model and run their business processes in collaborative enterprise environments (supply chains, collaborative networks, business ecosystems) with the help of the COIN System.

iv. Federation Authority (humans – COIN Front End) managing administrative issues of the upper and lower cloud federations.

As depicted in the previous picture, the service delivery and collaboration platforms federations are made of COIN platforms and non-COIN platforms. The COIN Platforms are platforms which are based on the COIN open source developments, developed inside the COIN project by our partners or by external third parties, for example in the community of COIN Multipliers. The non-COIN Platforms are based on other service delivery and collaboration platforms and could be provided by COIN Multipliers as well. Utility and value-added COIN EI/EC services (Value Added Services) are available to both clouds: they are registered in the COIN service delivery platforms nodes to be discovered-composed-executed inside the upper cloud federation, they can be downloaded and integrated with COIN collaboration platforms in order to be directly targeted by Industrial Users.

10

2.1 The COIN Generic Service Platform for Enterprise Interoperability and Collaboration Service Provision

Srdjan Komazec1, Davide Cerri1, Klaus Fischer2, Ingo Zinnikus2, Francisco Javier Nieto3, Pierfranco Ferronato4, Elia Conchione4, Antonio Panazzolo4

1STI Innsbruck, Universität Innsbruck, Technikerstraße 21a, 6020 Innsbruck, Austria {srdjan.komazec, davide.cerri}@sti2.at

2DFKI GmbH, Campus D3_2, 66123 Saarbrücken, Germany {klaus.fischer, ingo.zinnikus}@dfki.de

3ATOS Research and Innovation, Atos Origin, Capuchinos de Basurto 6, 48013 Bilbao, Spain francisco.nieto@atosresearch.eu

4Soluta.Net, via Edificio 2, 31030 Altivole, Italy {pferronato, econchione, apanazzolo}@soluta.net

Abstract The COIN Generic Service Platform (GSP) represents the core pillar of the COIN system. The platform is founded on top of Semantic Web Service technologies and further extended in order to meet additional enterprise-level functional requirements in terms of trust and security, negotiation and composition capabilities and scalability. The platform provides the necessary capabilities for Enterprise Interoperability and Enterprise Collaboration service provisioning, and at the same time offers a fertile environment to implement novel service provisioning business models. This chapter sheds some light on the main COIN GSP components and their functionality.

2.1.1 Introduction The central role of the COIN system is to fulfill a variety of lower-level (i.e., technical) and higher-level (i.e., business) enterprise-level requirements for Enterprise Interoperability and Enterprise Collaboration service provisioning, on top of which original business models, such as Software as a Service (SaaS), can be implemented. In order to reduce difficulties in completing such a challenging vision, the COIN system identifies the main aspects that need to be covered. In particular, proper means to enable precise and automated goal-based discovery, selection and invocation of service offerings is the core of the infrastructure. Additionally, sufficient support to establish trust and security between the service provisioning stakeholders is needed. Furthermore, facilities to enable (semi-)automated negotiation of the service provisioning terms and policies, as well as composition of services are playing a significant role in this environment. The platform should also exhibit proper means to scale in a peer-to-peer fashion over service usage tasks exercised over resources contributing to the service descriptions (e.g., service discovery, ranking and selection and invocation). All those aspects are blended together in a platform called COIN Generic Service Platform (GSP), explained in the following sections.

2.1.2 The COIN Generic Service Platform The Web service technology stack allows exchanging messages between Web services (SOAP), describing the technical interface for consuming a Web service (WSDL), and advertising Web services in registries (UDDI). However, in traditional Web service implementations, the lack of information to express the meaning of the data and of the vocabulary referenced by the interface, as well as the lack of formalisation of the Web service behaviour, implies the requirement of human intervention in tasks such as Web service discovery, composition, ranking and selection, thus severely hindering the automation of the envisioned tasks.

11

Semantic Web Services (SWS) [6] aim at providing more sophisticated Web service technologies through the introduction of semantic Web technologies. SWS utilise ontologies as the underlying data model in order to support semantic interoperability between Web services and clients, and apply semantically enabled automated mechanisms that span the whole SWS usage lifecycle, comprising discovery, selection, composition, mediation, negotiation, and execution of Web services. More generally, the introduction of semantics as an extension of Service-Oriented Architectures, and thus the creation of Semantically Enabled Service Oriented Architectures (SESAs), provides for next generation of service-oriented computing based on machine-processable semantics. The advantages of SWS stem from the fact that explicit, formal semantics is associated with the Web service description, and that the execution environment for SWS is able to interpret and use this semantics appropriately. This supports direct understanding of the Web service functionality at design time as well as at run time. The SWS platform represents the heart of the COIN Generic Service Platform (GSP), as shown in Figure 2. Alongside the core aforementioned tasks, the platform functionality is extended towards providing support for the platform execution monitoring (Monitoring component) and deferred goal resolution (Notification Broker component). In addition, the platform is complemented with the three pillars, addressing following aspects: distributed peer-to-peer service registries and evolutionary model repositories (P2P Federation Registry) that improve scalability and availability of the platform and reduce single-point-of-failure risks; trust-security mechanisms (Trust Negotiator, Trust Manager, TSD Portal and Security ESB components) that provide support to establish and maintain trust in a transparent way between parties involved in conversation with the platform (service requesters/providers), as well as secured access to the resources and dependability policies; and intelligent agent-based service negotiation and composition (Agent platform with Negotiation and Composition components) which provides support for flexible service composition and usage policies negotiation.

Figure 2 – COIN GSP Architecture

A single instance of a GSP can fulfil the requirements of scenarios characterised by limited scale and “closeness”. There are however scenarios in which the above assumptions do not hold, and which raise the need to support a distributed deployment because of scalability or dependability reasons. The deployment is achieved thorough federation of GSP instances (Federation Adapter component) and provided functionalities so that users of each one can benefit also from services provided by other ones.

12

2.1.3 Semantic Execution Environment As explained in the previous section, the core of the COIN GSP is a Semantic Execution Environment (SEE), able to perform Web service discovery, ranking, invocation and monitoring by leveraging semantic Web service descriptions. The COIN GSP SEE is based on WSMX, which is the reference implementation of the Web Service Modeling Ontology (WSMO) [3], and provides functionalities to discover and invoke semantic Web services. The COIN GSP SEE extends WSMX along several directions, detailed in the following paragraphs. First of all, the COIN GSP SEE includes a complex event processing engine coupled with WSMX monitoring facilities. A Semantic Execution Environment constitutes a rich source of events: at the level of the overall platform (e.g., the start of a Web service invocation process), at the level of single functionalities (e.g., tracking of the functionality provided by the discovery engine) and regarding external services (e.g., a fault during a Web service invocation). In order to monitor such events, all internal components have been appropriately instrumented, thus enabling detection and extraction of low-level events and generation of semantically-enhanced event descriptions. These descriptions are defined in the context of the COIN ontology stack and of the SEE ontology, which specifies structure and relationships inside the SEE. Since events have an ontological representation, the complete event history is preserved in an RDF repository for convenience purposes (support for massive storage, inference and querying). Before reaching this repository, events must be adequately processed in order to detect and react in a timely manner to potentially complex situations of interest (e.g., three failed attempts to invoke a particular Web service may trigger another round of Web service discovery, in order to find a different solution). For this processing step, the COIN GSP SEE integrates an RDF-based Complex Event Processing engine (RDF-CEP). The primary objective of RDF-CEP is to detect occurrences of RDF triples which satisfy expressive RDF patterns. When a complex event is detected, the engine executes the appropriate actions associated with the detected event (e.g., updating the aggregated statistical measures, notifying the administrator about successive failed attempts to access GSP facilities, etc.). In order to enable asynchronous notification of discovery results, the COIN GSP SEE includes a Notification Broker component. This component is responsible for registering and storing user subscriptions and for sending notifications when new results are available. The COIN GSP SEE supports subscriptions to goal-based discovery, so that a user can register a goal and then be notified when a service which matches that goal has been registered. The notification can be delivered via email or by invoking an external Web service. The notification mechanism is not limited to goal-based discovery, and can be easily extended to other processes. WSMX can only support single-instance deployments while, as previously discussed, in COIN there is a need to support a federation of multiple GSPs. The Federation Adapter component is responsible for forwarding discovery requests (goals) and responses between different GSPs. Target GSPs for a request can be chosen basing on the category of registered services, on GSP non-functional properties (e.g., offering free services), and on the platform services provided by the GSP (e.g., a certain GSP may offer service discovery but not invocation, whereas the client may want only services that can be automatically invoked). Multiple federations and clusters can be supported, as each GSP that receives a forwarded request may in turn forward it to another GSP which is unknown to the previous GSP in the path. Last but not least, the COIN GSP SEE includes a ranking engine to rank discovered services according to user preferences. The ranking engine is capable of invoking external services to be used as additional sources of information, e.g. regarding reputation of services.

2.1.4 Agent-Based Negotiation In the first place services, as they are registered in the COIN GSP, can be seen as atomic services provided by individual service providers and made available for execution through the COIN platform where the details of how the service is actually provided is hidden from the user who

13

requests the service. However, it is not realistic to assume that a user of the platform always specifies requests which can be directly matched with the available services. Therefore, the platform should also be capable of handle requests that require combinations of available services. Such combinations of services are commonly investigated under the topic of service composition (for an overview see e.g. [5,9]). Service composition is a complex field and comprises several aspects. For the purpose of this discussion, the distinction between design time and runtime and the difference between predefined and automatic compositions is emphasized. These distinctions might be regarded as related, however they are rather orthogonal, as e.g. automatic composition could be used at runtime, but also at design time when a process designer requests support for potential service compositions to be integrated into a workflow at design time. So while the process designer is quite likely interested in the details of how a service is provided, a platform end-user most probably wants to use the service in a black box manner and therefore is not interested in these distinctions.

Figure 3 – Composed services in the COIN context

Accordingly, three roles can be distinguished within the COIN setting: the service provider who owns a service and provides a service description (in WSML) when registering the service, a process designer who uses and combines available services to define workflows (including automatic compositions if necessary) providing them through or on top of the platform and a platform end-user who consumes these services and processes according to his or her business goals. Note that design time is in general different for service provider and process designer. Predefined compositions can be further distinguished into static and hybrid compositions. A static process is usually defined with a business process development tool. An agent-based modelling and service invocation environment is used, because it allows flexibility in service composition in the sense that the services can be composed in a goal-oriented manner. Hybrid processes could contain parts where the concrete service to be used at runtime would be determined according to runtime information (late binding). Predefined compositions constitute an essential part of business processes in service-oriented architectures. The nature of many services requires adjusting the business process in terms of process adaptation and data conversion. For defining and executing agent-based service compositions, a modelling environment which allows specifying complex interaction and workflow patterns for service composition and agent-based negotiations is developed (see e.g. [4]).

14

For automatic service composition, the approach for semantic services in OWL-S to the COIN scenario is adopted. For OWL-S, the conversion of services to the planning domain definition language PDDL has been proposed (see [7]). In an analogous way, the conversion can be done for WSML services. A WSML service with preconditions and post-conditions defined in a capability is transformed into a PDDL planning operator with corresponding pre- and post-conditions. To solve the corresponding planning problem, a PDDL planner can be used. The result of an automatic composition is in general a sequence of services (see [2]).

2.1.5 Trust and Security One of the challenges to be solved in COIN is to improve the security in enterprise interoperability and collaboration scenarios, where it is important to guarantee the secure interaction between parties. For doing so, traditional security mechanisms have been combined with so called soft security mechanisms, more oriented to social-based solutions and other non-functional aspects of the communication, such as trust on services, negotiation of trust-related aspects for interactions and policy management. All these elements have been combined in such a way that the information about trust is used as input for the trust aspects in negotiation and policy management, while the result of the negotiation, moreover, is an agreement which becomes a policy in the system, to be enforced with traditional mechanisms already deployed in an Enterprise Service Bus (ESB). All the components together, interacting automatically, conform the Trust, Security and Dependability Platform (TSD Platform) in COIN, as seen in Figure 4. The basic features are provided by the ESB, where typical components for basic security features are deployed: policy enforcement, authentication and encryption/decryption, etc.

ESB(PEP, PDP, STS)

PolicyAdministrator

TrustNegotiator

TrustManager

SOAP SOAP

Policies

TLA based Policies

Trust Value Trust Value

Figure 4 - Main components and relationships in the TSD Platform

The Trust Manager is a component which calculates the trust associated to services and service providers based on a wide model divided in four main parts: General (location, releases, age, etc.), Capability (announced functionalities and non-functional properties), Measure (monitored values for response time, data volumes, scalability, agreements fulfilment, etc.) and Reference (evaluation from users and other platforms, information in news, etc.). Using the monitoring capabilities of the GSP Semantic Execution Environment and other information sources (service description, information in DBs, etc.), it is able to perform different calculations based on a fuzzy set and combined with a special weighted average which exploits an ontology containing information about used aspects in the model and their relationships, performing a specific control of the consistency between the aspects in the model.

15

One of the components which use the Trust Manager results as input is the Trust Negotiator, which follows a two stages negotiation. In the first one, credentials are interchanged between participants, in order to determine which information to disclose and how to advance the negotiation. Once both parties trust on who they are, a set of concrete security terms are negotiated (bits number for keys, minimum trust values of services and providers, etc). Finally, a Trust Level Agreement (TLA) is obtained, and a policy is generated, for the TLA fulfilment. The Policy Administrator is the component which receives the policies, performing a “hot deployment” of those policies in the ESB components, retrieving context information required in the policies (such as trust values). In the case several policies must be activated at the same time, this component is in charge of merging the actions. Finally, there is a portal which serves as a front-end for facilitating management tasks. It accesses to the Trust Manager, the Trust Negotiator and the Policy Administrator for showing information about trust values, negotiations performed and policies stored to administrative users.

2.1.6 Peer-to-Peer Registry and Repository This section describes the key motivations that were at the base of the definition of the architecture for the Registry and Repository which are the main components of the COIN Evolutionary and Pervasive Service Platform. The strategy is to have a system that does not move data across the architecture when it is not needed. The goal is also to support different architectures, namely: information, model, and application. The service is created and maintained by the service provider, while models are persisted in a separate repository. Models are horizontal with respect to the information and are also shared across services. This separation of concerns, as implemented in this project, helps to avoid data replication and it aims at providing a better alignment between IT and the business. Inside the COIN Evolutionary and Pervasive Service Platform, registered services are associated to models that are stored in the Repository. A registry entry contains only attributes that are used for: • consuming the service, • retrieving the business model instance, • retrieving information about the service vendor, • retrieving the WSDL associated with the service, • retrieving models that are associated with the service.

The service is thus described by models that are associated with it. A user who wants to find a certain type of services must first of all search the models that contain the desired contents, and then search for all the services associated with these models. The Registry works like a DNS server: it does not contain any meta-data that describes services but rather contains only information for associating a service to a model or an ID. Like a DNS server, it must have a fully decentralized architecture for ensuring availability and reliability, and also an automatic synchronization mechanism. The Registry also manages the deletion of a registered service entry, to support the lease concept, implemented by a 3rd party COIN component, which is external to the Model Repository and Service Registry. A dedicated operation, in the Registry interface, is used to delete a specific service entry.

16

The concept of template is introduced (as defined and used by Jini8) to improve models search. To describe models are used tags as a folksonomy9, this is a way for creating a model description that is driven by the community growing around models development. The use of standards is considered very important in a project and in this way WSDL are used for web services, the JAXR10 API for storing and retrieving models. Is also suggested the use of a service crawler and a data warehouse for performing data mining on the data which is collected by inspecting business model instances. The data warehouse can also contain model meta-data for performing powerful queries on clients’ requests. The information contained in business model instances is collected by the service crawler that retrieves them by querying the service provider, inspecting the business model instances and reporting information to the data warehouse.

Figure 5 - P2P Repository/Registry Architectural viewpoint

2.1.7 Conclusion This chapter clarified the notion of COIN GSP and its constituent parts. In the context of the COIN system the platform serves as the broker, blending together needs of different service provisioning stakeholders. In a nutshell, the COIN GSP is built on top of Semantic Web Service technologies which enable basic platform functionality such as service discovery and invocation in a federated manner. The platform is extended to meet the appropriate means to: establish trust and security between the service provisioning stakeholders, provide agent-based (semi-) automated service provisioning negotiation and composition facilities, and enable evolutionary and pervasive aspects based on the usage of P2P service repository and registry. As such, the platform provides the needed functionality to implement envisioned service provisioning business models such as Software as a Service-Utility.

8 http://www.jini.org/wiki/Main_Page 9 http://en.wikipedia.org/wiki/Folksonomy 10 http://jcp.org/en/jsr/detail?id=93

17

References [1] COIN Deliverable D3.2.1b, Evolutionary and Pervasive Service Platform, Final Specifications, 2010 [2] COIN Deliverable D3.4.1b, Business Knowledge and Negotiation Platform, Final Specification, 2010. [3] Dieter Fensel, Holger Lausen, Axel Polleres, et al. Enabling Semantic Web Services: The Web Services

Modeling Ontology. Springer, 2007. [4] Ingo Zinnikus, Xiaoqi Cao, Klaus Fischer. Agent-Supported Collaboration and Interoperability for

Networked Enterprises. In: Marten van Sinderen, Pontus Johnson (Eds.): Enterprise Interoperability. Proc. of the Third International IFIP Working Conference, IWEI 2011, March 2011, Stockholm. Springer 2011, pp. 204-215.

[5] J. Rao and X. Su. A Survey of Automated WebService Composition Methods. Proceedings of the1st Intl. Workshop on Semantic Web Services and Web Process Composition, San Diego, 2004.

[6] Jorge Cardoso (edt.). Semantic Web Services: Theory, Tools and Applications. IGI Global, March, 2007. [7] Klusch, M., Gerber, A. and Schmidt, M. (2005). Semantic Web Service Composition Planning with

OWLS-XPlan. Proceedings of the AAAI Fall Symposium on Semantic Web and Agents, Arlington VA, USA, AAAI Press.

[8] Schahram Dustdar, Wolfgang Schreiner. A survey on web services composition, International Journal of Web and Grid Services, v.1 n.1, p.1-30, August 2005.

18

2.2 The COIN Front End for Generic Service Platform Federation Consuming Michele Sesana1, Sergio Gusmeroli1, Srdjan Komazec2, Davide Cerri2, Drago Trebežnik3

1 TXT e-solutions, Via Frigia 27, 20126 Milano, Italy

{michele.sesana,sergio.gusmeroli}@txtgroup.com

2STI Innsbruck, Universität Innsbruck, Technikerstraße 21a, 6020 Innsbruck, Austria, {srdjan.komazec,davide.cerri}@sti2.at

3Jožef Stefan Institute, Jamova cesta 39, 1000 Ljubljana, Slovenia

drago.trebeznik@ijs.si

Abstract The involvement of users/stakeholders is a recognized key condition for the consumption of the GSP (Generic Service Platform for EI/EC service delivery) federation and its further exploitation as well as the possibility to have a fast and easy way to access the COIN system and to have a prior feedback about the system capabilities to further adopt it in a deeper way. The COIN Front-End is the unique point of access (one-stop-shop) for both technical and non-technical users of the COIN system, providing a set of functionalities for the consumption and evolution of the Generic Service Platform Federation reported in the previous 2.1 chapter of this book. In this chapter two major developments of the COIN Front End are highlighted and described. The first functionality is devoted to IT user/s willing to publish their software products – EI/EC services and/or platforms - through the COIN GSP federation. An editable and customizable model of the federation is supporting the registration of new platforms and services, while an interactive wizard is guiding the IT user step-by-step in the process of downloading COIN “open source” assets – platforms, services, knowledge bases, ontologies - in several forms (source code, binaries, pre-configured virtual machines, open data and creative commons knowledge), configuring and customising them and finally linking them to the existing federation and search-discovery-orchestration-execution functions. The second major development is devoted to generic users, either registered or not registered, willing to know more about the COIN EI/EC services and how to access and consume them. A Google-like semantic and contextual search engine is able to analyse complex queries and find the best matching with COIN service and knowledge bases, while a service try-me experimental facility is providing users with concrete hands-on technical and business use cases.

2.2.1 Introduction The Generic Service Platform Federation described in chapter 2.1 is the upper level of the COIN System, providing a big set of innovative functionalities to handle with registered services. In order to fully exploit the federation capabilities, it is necessary to have a component able to communicate with it in different forms and customised for different users and business cases (automatic or human driven). In particular, in the presence of complex technological artefacts, human factors in accessing and using conveniently the COIN GSP Federation are a key aspect for its successful adoption and take-up: likability, friendliness, usability, but above all clear messages about functionality, costs and business benefits need to be taken in due account; users-stakeholders early and participative involvement could make the federation a real exploitable asset of the project. In this chapter, the COIN Front End is described, a COIN System component focusing on one hand to the consumption of the GSP Federation capabilities and on the other hand to support the evolution of the system itself acting as a facilitator for the involvement of service providers in the system. The COIN Front End supports two access modalities: i) direct access by humans ii) API offered for the usage by other IT systems. In COIN Front End design, two major users have been identified to be part of the system: IT user willing to become service providers of different pieces of software of the COIN System exploiting the evolutionary perspective of the solution and Generic user willing to explore the COIN capabilities like services discovery, invocation, composition, etc.. The Generic User is a non-technical person with few or no IT experience (e.g: a businessman, a manager, a BP designer) without deep knowledge about ontologies preconditions/postconditions and other technicalities of the EI/EC domain which are indeed necessary to deeply understand the services the COIN system is hosting. This book section focuses on the direct access to the Front-End by humans: sub-chapter 2 focuses on the Front End support to IT user, sub-chapters 3 and 4 highlight the access by non-IT

19

people defined as generic users. The following book chapter (2.3) provides a view of the CP Federation accessing the GSP Federation through the COIN Front End API.

2.2.2 GSP nodes and Services provisioning to the GSP Federation A single instance of a GSP can fulfil the requirements of scenarios characterised by limited scale (i.e., in which a single instance can handle all the knowledge, e.g. ontologies and service descriptions, and all the requests) and “closeness” (i.e., in which all the relevant knowledge is available in a single instance, controlled by a single authority). There are however scenarios in which the above assumptions do not hold, and which raise the need to support a distributed deployment. Besides cases in which a distributed infrastructure is needed because of scalability or dependability reasons, but it is still under the control of a single authority, there are scenarios in which different GSP instances are established independently by different providers or groups. These providers can then want to allow users of one GSP to be able to use also services provided by the other ones, and therefore to federate their GSPs. In particular, we can distinguish between “emergent” and “planned” distributed approach. An “emergent” approach is one in which different GSP instances are established independently and grow and evolve in a Platforms ecosystem, e.g. because they are owned by different providers / groups / consortia. A “planned” approach is one in which the owner of a GSP decides that a single instance is not enough (e.g. for scalability reasons, but also for different business models), and therefore needs to deploy a distributed platform architecture which includes multiple instances. The two approaches can be implemented at multiple levels: a “distributed instance” resulting from the planned approach can act as a single node of the federation in the emergent approach. They are however different, both technically (e.g., the planned approach naturally brings the accent to topics like scalability and self-organisation, while trust between different instances is not an issue) and from a business perspective. The central question to address is whether the knowledge (e.g. the service descriptions) used by each GSP node is “local” (i.e. every instance has its own knowledge, which is not directly available to other instances) or “global” (i.e. each instance has access to the same knowledge, by retrieving it from some “globally” accessible source, that is accessible to all GSP instances). With respect to the two approaches, it is quite clear that in the planned approach the issue of local or global knowledge is mainly a technical choice, because from a higher point of view the distributed architecture is always seen as a single entity. On the contrary, the emergent approach seems to present a much better fit with the “local knowledge” approach, as the owners / users of each instance may want to keep their own knowledge (e.g. their own service descriptions) in their own platform, and make it only indirectly accessible to federated platforms (i.e., through the services provided by the GSP, e.g. service discovery). For this reason, and considering that the “global knowledge” approach would be, due to the technical constrains, hard to realise in COIN GSP, we follow the “local knowledge” approach. This means that each GSP instance has its own repository which is not directly accessible to other instances, but only through the services provided by the GSP. This does not exclude the presence of a more lightweight “global” registry/repository used to store general information about GSP instances (used e.g. in order to “discover” other GSP instances). Therefore, the starting-point scenario is a single instance capable of discovering and invoking Semantic Web Services. Starting from this, we envision the evolution of the GSP along three dimensions: • Goal decomposition and service composition, • ranking based on non-functional properties (nfp), • node federation.

These three dimensions can be used to define a cube, shown in Figure 6, which represents possible evolutionary paths and points starting from the base. We now describe the issues to be addressed in each of these scenarios (i.e., each vertex of the cube).

20

A

D

C

B

E

GF

base

+ federation

+ co

mpo

sitio

n

+ nfp

rankin

g

+ federation

+ federation

+ co

mpo

sitio

n

+ co

mpo

sitio

n

+ nfp

rankin

g

+ nfp

rankin

g

Figure 6 - GSP evolution “cube”

While moving through the cube node the following scenarios and their characteristics are identified: • Scenario A (Base) in which there is a single GSP instance which is capable to discover and

invoke single services that match the user’s goal. • Scenario B (Federation) in which each node must be able to forward the user goal to other

nodes. In larger scale deployments a mechanism to identify a subset of relevant nodes as targets for forwarding the request is needed. Such mechanism can exploit some specialisation of the nodes (e.g. w.r.t. the domain), however, especially in the emergent case, this is not by design. Moreover, all nodes will be capable of offering more or less the same functionalities (discovery, invocation, etc.). Therefore, a lightweight mechanism can be appropriate, based on some simple categorisation (taxonomy or simple ontology). Such a mechanism is called COIN GSP Model and it is described below.

• Scenario C (Single instance with service composition) in which a composition of services that can fulfil the user’s goal, rather than only a single service, can be identified as a match.

• Scenario D (Federation with service composition) which is the composition of scenarios B and C. In this scenario, each node can forward the goal to other nodes as in B, decompose it into subgoals as in C, and forward subgoals to other nodes. Different decompositions may be realised by different nodes.

• Scenario E (Federation with nfp ranking) which is built on top of scenario B (federation), adding ranking based on non-functional properties. The federated architecture implies the fact that multiple lists of matches, coming from different nodes, need to be merged, taking into account ranking.

• Scenario F (Single instance with service composition and nfp ranking) which is built on top of scenario C (single instance with service composition), adding ranking based on non-functional properties. In this scenario, matches can be composed by one or more services, so there is a need to define nfp-based ranks for compositions of services, rather than just for single services.

21

• Scenario G (Federation with service composition and nfp ranking) which is the most complex scenario, built on top of scenarios E and F. It includes all the three dimensions we considered.

It is worth noting that each and every next step is adding additional complexity level, thus asking for advanced solutions when treating interdependencies. COIN project has provided solutions for the scenarios A, B, C and D while the more complex cases, i.e., scenarios E, F and G, are considered as future work. In a federated environment, the different nodes (i.e. GSP instances) of the federation need to be characterised, so that requests can be directed to nodes that can be able to fulfil them. This encompasses two different aspects: • Functional aspects. These cover both the functionalities of the GSP itself (i.e. from

service discovery to service invocation) and the functionalities of the services registered in the GSP. While the former ones can be seen just as regular service platform descriptions (i.e. what a single GSP node is able to do in terms of service discovery-execution monitoring cycle, including intelligence, negotiation and decomposition capability), in order to cover the latter ones, some aggregated and more complex [semantic] descriptions are needed. In the COIN federation this is done through a functional taxonomy: federation nodes are therefore annotated with the categories of services registered at them. These annotations are used for service discovery, in order to decide to which nodes of the federation a goal (i.e. a request to discover services) should be sent.

• Non-functional aspects (e.g., availability, reputation, price). Again, descriptions covering these aspects can be applied both to the GSP itself and as an aggregated “image” of the services registered at the GSP. Non-functional aspects are used together with functional aspects to support the decision process in discovering and selecting Web services, and in particular for ranking purposes. A typical case is when two or more services are functionally equivalent (and thus can functionally fulfil the user’s goal), but they differ in some non-functional aspect (e.g. the price). The problem of how to aggregate and harmonize end-to-end different, heterogeneous non-functional aspects and policies at both platform and service levels is still an open research domain, which COIN is just partially and incompletely addressing.

In order to describe federation nodes according to these dimensions, COIN provides a set of ontologies, as shown in Figure 7. At the top there is the COIN Federation Ontology, which defines fundamental concepts such as “Service Category” and “Federation Node”. On the lower level, the COIN Platform Taxonomy describes services offered by the node itself, the COIN Functional Taxonomy provides categories for registered services, and the COIN Non-Functional Property Taxonomy is used to describe non-functional aspects. All taxonomies are modelled using SKOS [1]; a fragment of the COIN Functional Taxonomy is shown in Listing 1.

22

Figure 7 - COIN GSP model ontology stack

Listing 1: Fragment of the COIN Functional Taxonomy

This model is used in the COIN Front-End by IT User/s, who are able to build and develop their own solutions and to link them to the COIN IT System; the COIN Front-End provides a specific kind of access and set of functionalities allowing him/her to explore the COIN technical assets (source code, binaries and pre-configured virtual machines), to download and customize them

<http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl> rdf:type owl:Ontology ; owl:imports <http://www.w3.org/2004/02/skos/core> ; owl:imports <http://www.coin-ip.eu/ontologies/COINFederationOntology.owl> . :COINFunctionalTaxonomy rdf:type cfo:ServiceTaxonomy , :EnterpriseService rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:topConceptOf :COINFunctionalTaxonomy . EnterpriseCollaborationService rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :EnterpriseService . :EnterpriseInteroperabilityService rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :EnterpriseService . :Messaging rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :EnterpriseCollaborationService . :SMSMessaging rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :Messaging . :EmailMessaging rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :Messaging . :CollaborationNetwork rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :EnterpriseCollaborationService . :DataTransformation rdf:type cfo:ServiceCategory , skos:inScheme :COINFunctionalTaxonomy ; skos:broader :EnterpriseInteroperabilityService .

@prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix cfo: <http://www.coin-ip.eu/ontologies/COINFederationOntology.owl#> . @base <http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl> . @prefix : <http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl#> .

23

and finally to exploit such assets by creating a new federation node and merging it in the COIN GSP Federation (upper cloud of the COIN butterfly model). The human computer interaction primitives have been specifically designed to support a technical person. New services registration functionality is also provided by GSP nodes and briefly described afterwards.

Figure 8 - COIN Assets Download

The previously presented model is provided as a wizard to the IT user through the COIN Front-End; it is pre-configured at the time the user accesses the menu and divided into three different forms. The user has just to complete the template and to insert the new GSP node characteristics. Finally the “submit” form makes the description available to the federation authority that will check and approve/reject it.

Figure 9 - GSP Model Configuration

The node creation process should be mediated by the COIN Federation Authority taking in charge of the control of the compliance of the new GSP node registration to the federation.

Browse

Download

24

Figure 10 - nodes waiting for approval

The prerequisite to register a new service at a COIN GSP node is to build its WSMO [3] compliant semantic description. Such a description dictates, in a formal and unambiguous way, functional (service capability and behavior) and non-functional (e.g., price, reputation, reliability, etc.) service aspects. In order to reduce complexities while building the description COIN has developed a Web-based wizard consisting of five consequitive forms focusing on different semantic Web service description aspects. Apart from the Web form shown at Figure 11 (which provides a user friendy way to define service pre-/post-conditions) the other forms include definition of general Web service atributes (service name and namespace), definition of non-functional properties (e.g., service price), and definition of behavioral aspects (service choreography).

Figure 11 - The Web form for defining service pre-/post-conditions

25

2.2.3 Consume the GSP Federation by a Human Oriented Interface As stated in the introduction, the consuming of GSP federation by non-technical users (e.g. business man, managers, BP designers) is very important to actually exploit the COIN system. The generic user is defined as a person willing to explore through a simple web interface the COIN capabilities like services discovery, invocation, composition, etc. In addition to that, he/she is a non-technical person with few or no IT experience and without any deep knowledge about ontologies preconditions/postconditions and other technicalities of the EI/EC domain and he does not have time/willingness to learn any technical stuff. The COIN Front-End provides this user with a set of functionalities to explore the COIN assets through an interface and features specifically designed to support this kind of non technical person and guiding him through in the COIN assets exploration and understanding. The implementation of the system for the Generic user comprises the GUI by which the user can access the functionalities visible in Figure 12.

Figure 12 – Generic User Functionalities

Services searching by templates allow the user to browse services and interrogate the GSP federation searching for services. Browse&Search (semantic search) are guided by templates: pre-configured goals that the user can easily customize for its searches. The understanding of COIN assets is based on two main streams: on the one hand, knowledge about the service and its reputation is provided; on the other hand the user can try the services (both automatic web services and interactive services) from the user interface. The knowledge is based on the Semantic Media Wiki [2], a free, open-source extension to MediaWiki based on an ontology driving the link between contents. The user is involved in the process with an additional functionality that allows him/her also to subscribe to a news notification service about some goals: for example in case the businessman is not satisfied by found services or he/she did not find anything, he/she can subscribe itself to the goal created (e.g: transformation from Format a to Format b) and receive information on further registered services matching with this goal. Interactions between the COIN Front-End for the generic user and the other components of the COIN System are depicted in Figure 13

26

Figure 13 - COIN Front-End deployment schema and COIN System upper Cloud interaction

The access to the tool could be done anonymously or by a simple registration (username, password and email address to receive notifications about services). The Browse & Search interface (Figure 14) guides the user in the process of easily composing a semantic search; the panel is composed by 5 main parts:

1. Search scope defining the scope of the search (one specific node or the whole federation). 2. Functional Concept Selection this interface allows the user to select, on top of a

functional taxonomy, the desired functionalities that the service should fulfill. Concept can be accessed in three different ways: i) exploring the taxonomy tree ii) typing in the fast search the initial characters of the word iii) insert free text in the proper “free text box” and let the system interpret the text and match it with the taxonomy (please refer to the next subchapter for more details)

3. Template Box: to simplify the creation of the semantic search, a set of templates associated to functional taxonomy concepts are provided; few intuitive clicks by the user are enough to create a correct request for the GSP federation.

4. Suggestion Box automatically at the time a functional taxonomy concept is selected, the system does a fast search to the closest GSP and retrieves some services to be presented to the user. The search is done by a fast SPARQL query. The goal of this box is to provide the user with a fast check about what he/she will retrieve with the further semantic search.

5. Semantic Search based on the selected template, the structure of the semantic search is provided. User has to click on all the trees visualized selecting the concepts closer to his/her wishes. Selecting the roots of every tree the user will create the higher level search available. Clicking on leaves the search will be more specific. The search can be tailored by the user on its need using the non functional properties expressing its own preferences that will rank found services; price, reputation and time are available for this purpose.

27

Figure 14 - Browse & Search interface

Clicking the submit button, a new form shows found services. In this case the search is semantic and involves the GSP federation. The system hides completely the details of the search process that is not relevant for the user. As better visible in Figure 15 results are divided in three different areas: • Exact Match (services marching exactly with user whishes) • Plugin (services more specific in respect with the request) • Subsumption (services less specific in respect with the request)

Figure 15 - detail of the semantic search results

For each service found, the system provides a small description of itself; to let the user understand better the service purpose and capabilities the system provides different functionalities accessible by buttons close to the service description:

28

• Try-me button shows a pop-up able to invoke the corresponding service. The form is created automatically starting from the ontological description of the service returned by the GSP to which is registered.

• Wiki The wiki button drives the user to the second tab of the interface (maintaining all the data in the previous tab) opening the wiki page describing the service. Depending of the service different information is displayed containing in some cases the example I/O files for the service test.

• Trust button displays summary information of the selected service. A global value is provided and four sub values composing the global value are detailed: i) general, ii) capability, iii) measure and iiii) reference

Figure 16 - from the left: try-me button form, trust values and COIN SMW for information on the service

2.2.4 Guiding User Semantic Search by Free Text Wishes Expression - JSI Free Text Wishes Expression (FTWE) service is aimed at helping users to use natural language expressions for efficient search through various text descriptions in COIN platform. The first case in which the service has been used is the natural language search through the extensive COIN services registered. The main feature behind is that the free text query as well as documents contained in the COIN Semantic Media Wiki are being processed through the Enrycher service pipeline. Both constructed triples graphs are then being matched. By using similarity measures the hit ranks are being calculated and presented in a ranked list of hits. Figure 17 presents the main FTWE pipeline which consists of four main service sets that are manipulating texts from the language level to the document level.

���

������ ��������� ���������

��������������

����������

���������������������

���������� ����������

!���"���������

����������

Figure 17 - FTWE pipeline Language–level processing are background services that include sentence splitting, tokenization, part of speech tagging and entity extraction. Entity-level processing services identify potential entities. This is done with anaphora resolution, where pronoun mentions are merged with literal

29

mentions, co-reference resolution that merges similar literal mentions and entity resolution, which links the in-text entities to ontology concepts. Document-level processing operates on the document instead of entities. Here we first construct semantic graphs out of extracted triples using several entity and context matching methods. In such graphs nodes are entities (objects, subjects) that are connected with relations presented by verbs. Such graphs are then being used for matching functionalities in search but also for other more semantically heavy features like ontology construction services, taxonomy categorisation and summarisation. Figure 18 presents the complexity of the enrichment services.

Figure 18 - Enrichment services

This is why all textual documents (templates descriptions in our case) are being processed and enriched and presented as a graph of triples of all descriptions. The created graph is then used to create inverted index that enables fast, cheap and efficient search. FTWE service also includes heavy semantics features like classification, overall semantic graph construction out of n-grams, cross lingual support and reasoning. In the service search case these features are not being used since it would be too costly in respect to the preferences. For other COIN services that are using large scale document repositories like process descriptions, reports, formalised descriptions, external databases, etc, these features can be easily switched on. By including neutral language representation model that are being constructed out from many multilingual aligned corpuses some additional features dealing with cross and multilingualism can be implemented i.e. multilingual search, cross-lingual search, graphs (ontologies) translation, language detection, etc.

2.2.5 Conclusion The implementation and the availability of the COIN Front End for accessing the COIN Generic Service Platform Federation allows the involvement of stakeholders who are not yet connected to the COIN system and supports the loyalty of existing stakeholders in collaborative networks using the COIN Collaboration Platform (see chapter 2.3). The early and participative involvement of final users is a recognized key condition for the success of the GSP federation and for further take-ups and exploitation opportunities. There are two major developments reported in this chapter. The former one is related to the nodes and services in the GSP Federation and supports IT user/s willing to publish their software products through the COIN System, an editable and customizable model of the GSP is provided to support the registration of

30

a new GSP node to the federation and a GUI supports the user in the process of downloading COIN assets in several forms (source code, binaries and pre-configured virtual machines) and of providing new ones. The second major development is the support to the generic user by “Consume the GSP Federation by a Human Oriented Interface” and “Guiding User Semantic Search by Free Text Wishes Expression”. By using this interface non-IT user/s can easily search for COIN services, understand them by accessing related knowledge and experiment them. The COIN Front End has been integrated in the Final COIN System and demonstrated in COIN project reviews. References [1] SKOS Simple Knowledge Organization System Reference, W3C Recommendation 18 August 2009,

http://www.w3.org/TR/2009/REC-skos-reference-20090818/ [2] Semantic Media Wiki – http://semantic-mediawiki.org/wiki/Semantic_MediaWiki [3] Dieter Fensel, Holger Lausen, Axel Polleres, Jos de Bruijn, Michael Stollberg, Dumitru Roman, and John

Domingue. 2006. Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer-Verlag New York, Inc., Secaucus, NJ, USA.

31

2.3 The COIN Collaboration Platforms Federation for Enterprise Networks and Business Ecosystems

Michele Sesana1, Sergio Gusmeroli1, Jens Eschenbächer 2 1 TXT e-solutions, Via Frigia 27, 20126 Milano, Italy

{michele.sesana,sergio.gusmeroli}@txtgroup.com

2 BIBA - Bremer Institut für Produktion und Logistik GmbH, Hochschulring 20, 28359 Bremen, Germany, esc@biba.uni-bremen.de

Abstract In a global economy, Enterprise Collaboration represents the most promising solution for European industry (and SMEs) to stay competitive and to continuously innovate its products and services. IT support to collaboration among the members of a networked enterprise, being it a supply chain, a collaborative network or a business ecosystem, is a central point of the COIN system. The possibility to promptly react to a Business Opportunity (BO) building Virtual Organisations, managing the operational and dissolution phase as well as the support to the interoperability among different partners is addressed by the COIN Collaboration Platforms Federation. In this paper it is presented how COIN supports networked enterprises by the COIN Collaboration Platform (CP) illustrating its functions, characteristics, BPM facilities and the implementation connected to the other parts of the COIN system allowing the injection of a smart support in the construction of the collaborative business processes. At the end of the paper, the concept of Extended Products and Distributed Collaborative Innovation in Virtual Factories is also introduced as a promising future research topic in which the support on networked enterprises by COIN Collaboration Platforms federation could be exploited.

2.3.1 Introduction In the overall COIN Vision, networked enterprises are organized in supply chains, collaborative networks and business/innovation ecosystems. Their collaboration is often supported by IT Collaboration Platforms (CP) and whenever cross-network interconnection is needed the community of CPs in different domains and sectors needs to be supported by an open and trusted federation of CPs. Let’s imagine for instance cross-sector collaborations like those established between textile industry and automotive to build innovative car seats covers, between furniture industry and shipbuilding to build cruise ships interiors resistant to marine environments; or also imagine cross-domain collaborations when a product-oriented collaboration (design, development, production, post-sales, end-of-life) needs to be extended and complemented by a service-oriented collaboration (service life cycle management to be reconciled with the PLM) or by a market-oriented collaboration (marketing & sales, new business and revenue models, online vs. physical selling). In the COIN interpretation, Collaboration Platforms [1] [2] [3] provide utilities for social collaboration (e.g. wikis, blogs, communities, user profiling), knowledge collaboration (e.g. repositories, search engines, up- down-load facility, classification) and business collaboration (e.g. workflow, workgroup and business process management services). A Collaborative Platform is not a monolithic and static entity but it is very modular and easily composable in order to adapt itself to the specific characteristics of the enterprise network, giving to every cluster the possibility to work in a personalized environment built on top of their specific needs such as domain, sector, country, i.e. via the ontology for classifying documents or the ontology for classifying human competencies in the different domains. Next chapters of this paper will show how COIN supports Networked Enterprises and Business Ecosystem by a Collaboration Platforms Federation.

2.3.2 Modelling, executing and outsourcing cross-enterprise collaborative business processes The lower cloud of the COIN System (please refers to the introduction of chapter two for more information) is composed by an incremental set of domain- and sector-specific COIN and non-COIN Collaboration Platforms (CPs).

32

2.3.2.1 The COIN Collaboration Platform: main functions and characteristics The COIN collaboration platform provides a complete set of collaboration functionalies to support the human collaboration on the CP; the basis set of fuctionalites provided natively by the portal is increased by COIN service (both baseline and innovative) that can be plugged into the environment; messaging services, maps about the human collaboration in the portal, blogs, shared calendars are just a part of the big set of collaboration services available. The huge data set of the portal composes the Knowledge Base of the cluster that can be used as base for further smart services. COIN Collaboration Platforms are also addressing web services to implement business processes: such web services allow the integration of legacy databases and legacy system and the direct invocation of EI/EC services. Such web services could be concentrated in the center of the network (hierarchical supply chains) or be fully distributed among the network partners, depending on the organizational form chosen by each network. In any case, a distributed or concentrated Enterprise Service Bus, interoperable with the ESB of the COIN EI/EC Platforms, is the best technical solution to integrate them.

2.3.2.2 The COIN Collaboration Platform in the COIN System: the BPM facility A first key aspect of the COIN System is how to connect the Internet of Enterprises (including hierarchical and non-hierarchical collaboration forms) with the Internet of Services (including clouds of automatic web services and user generated services perhaps generated from linked open data), i.e. to link service providers with service consumers or to finally bridge the gap between IT and Business in the field of EI/EC obviously. For instance, it is foreseen that big ESA (Enterprise Software and Applications) providers will soon put in the public domain or provide at a very low cost their interoperability services/information as an adjunct to their Cloud SaaS offer (e.g. under freemium-like business models); on the other side, the Service Web and Linked Open Services movements will allow non-profit and/or standardization organizations to publish their open standards and specifications to support every single Internet user (SMEs, micro-enterprises but also individual entrepreneurs) in developing and using his/her own EI/EC solution. The COIN system is giving visibility of both Internet of Services opportunities to the Internet of Enterprises. Secondly, in a Future Internet perspective the same challenge could be seen as how to link FI platforms services (in this case EI/EC services) with Smart Socio-technical Applications (in this case Smart Enterprises). In the FI PPP, the so-called Core Platform is providing Generic Enablers to be accessed, composed, customized and used by the chosen Use Cases (ICT for environment, healthcare, transport, mobility, smart city, safety, etcetera). COIN adds a new layer to the Core Platform Generic Enablers with its EI/EC utility services and knowledge, some of them domain-independent (e.g. UBL data transformation services), some others domain-dependent (e.g. Odette or MODA-ML data transformations). In this perspective, COIN can be seen as an additional layer to the FI architecture centered upon the Core Platform. A third key aspect of COIN System is the distinction between service engineering-development platform and service delivery platforms. A service delivery platform is a catalyst for service providers who already developed their own services and just want to give them visibility and access to service consumers (i.e. providing utility services for easy registration, search, discovery, orchestration, composition, execution, authorization-authentication-accounting, monitoring); a service engineering platform is instead providing an Integrated Development Environment for IT professionals (e.g. a Service Development Kit) and/or for naïve providers (e.g. a Mash-up environment) in order to facilitate the creation and development of new services. Indeed, COIN was initially conceived with the notion of being a GSDP (Global Service Delivery Platform) for EI/EC services and the notion of development platform was just marginally addressed. In fact, the COIN view of Plug-Switch-Tap evolution is suitable for industrial end users willing to access EI/EC services, as normal telephony users see the different contracts with

33

operators: in a plug mode you just need the right adapter in order to change operator; in a switch mode you can close your contract with one operator and open a new one on-the-fly and in a seamless way; in a tap mode several parallel contracts do exist and an intelligent decision support system (fully automatic in some cases) is able to dynamically match and select the best offer with users’ requests, also within the same day, the same hour or the same phone conversation. More recently, the convergence between user-oriented development platforms and globally accessible delivery environments (e.g. the so-called Application Stores) as well as the open innovation, crowd-sourcing and co-creation societal trends has inspired in COIN a fourth evolutionary step (named EI/EC Store) where the borders between development and delivery is blurring. In this Store evolution, the need for model-driven architecture methodology and tools to bridge the gap between CIM-PIM-PSM specifications is becoming more and more urgent again, calling for a new revision of EI life cycle under this new “Store” dimension.

The key question of the COIN System is “How to integrate the life of Enterprises with the Internet of Services and simultaneously taking into account the three aspects of: i) The co-existence of Cloud Computing SaaS and Open Services; ii) The architecture of the Future Internet and its first implementations; iii) The Store model and the convergence between

development and delivery platforms?” In the COIN system architecture, the role of zip between the two clouds is played by our Business Process Management facility of the Collaboration Platform. We in fact postulate that business men design and develop their collaborative business processes across organizations and across their information systems, this way encountering and facing collaboration and interoperability gaps. Business Interoperability challenge in COIN is intended neither horizontally (different languages to express BPs at the same level of abstraction, e.g. xPDL or BPEL), nor vertically (same notations/language at different levels of abstraction e.g. CIM-PIM-PSM), but across organizations: how to synchronize internal Business Process across organizations, by avoiding in the meantime interoperability gaps like deadlocks, interface mismatches and synchronism/visibility problems derived from the juxtaposition of BP pieces, which are individually correct but do not work well if put together in collaboration. The COIN BPM facility is therefore facing:

i. The co-existence of Cloud Computing SaaS and Open Services. In the EI/EC domain, there is the co-presence of de-jure open standards, de-facto industrial standards (mostly not open) and a myriad of non-standard solutions which however are the most simple and immediate solution to EI/EC problems. For instance, we have well defined de-jure standards for Automotive, Fashion, Furniture Business Documents interoperability, as well as de-facto standards given by software vendors like IBM or SAP or Oracle. However, both resources solve just a minimal part of the EI/EC problems and in most of the cases, the most simple and cheap method is to look for a similar case and adapt the existing solution to the new requirements or to dynamically compose together micro-services solving micro-gaps into an overall solution. The COIN BP facility shall have an efficient and rigorous access to well coded standards as well as a more intuitive constructionist approach in the absence of standards and in the presence of a myriad of solutions available in the open Internet (e.g. support to the so-called federated approach to interoperability).

ii. The architecture of the Future Internet and its first implementations. In the preliminary FI Architecture, three main functions are deemed necessary to link core services with applicative services: virtualization, self-management and orchestration. The COIN BPM facility represents the orchestration function but with a much wider perspective than just sequence of web services. One important aspect in COIN is the possibility to hide from the business men all the technical details of the EI/EC

34

implementations by providing him/her a semi-automatic decision support for the selection and implementation of the most suitable EI/EC services.

iii. The Store model and the convergence between development and delivery platforms. In the EI/EC domain, it is very seldom that a given automatic service is best suitable for many domains and processes: in most of the cases, a process of adaptation and customization is necessary. In COIN we have automatic web services (to be invoked and executed without any human intervention and control) and more interactive EI/EC services which in most of the cases are development environment of customized and specific EI/EC services (e.g. the semantic reconciliation suite for Business Documents interoperability). The former ones are therefore available in delivery platforms and juxtaposed into BPEL automatic service execution environments; the latter ones are instead activated as intelligent wizards and drive the end-users towards the development of the required service. In this sense, the Store paradigm is implemented in COIN.

For implementing our BPM facility, we’ve identified three possible evolutionary steps: i. Step I, where EI/EC service demand/offer is not supposed to vary along time and also

among different instances of the same business process. In this case, the process of selection-composition-juxtaposition of EI/EC services can be performed once at design time and remains unchanged for long time. The human business user is therefore prompted with the interactive COIN Front End interface where he/she could select the most suitable service and then link it permanently with the business process in question;

ii. Step II, where EI/EC service requirements are supposed to vary along time for instance among the different instances of the same business process. The process in this case is semi-automatic, as the COIN system is invoked by means of automatic APIs, the selection of the best combination of services is manual, while its juxtaposition into the chosen instance of BP is again automatic.

iii. Step III, where EI/EC service requirements either change very dynamically or depend on the execution time of the business process. In COIN, we have identified two distinct Step III scenarios where human collaboration EC services are automatically selected on the basis of the context (e.g. user, his/her location/presence, his/her device) in a project’s meeting life cycle domain; and where data interoperability EI services are automatically composed on the basis of the organizations, their accepted data formats and data access services.

The three steps are to be intended neither incompatible nor exclusive: for instance, in the same BP we could have cases where Step I is more suitable, or Step II, or Step III.

2.3.2.3 The COIN Collaboration Platform implementation The CPs, beyond supporting the collaboration environment for Supply Chains, Collaborative Networks and Business Innovation Ecosystems, provide the industrial user (business man of the companies clusters) with a set of functionalities based on the API of the COIN front end communicating with the GSP federation (please refers to chapter two introduction for more information). Using them, the Industrial user can access to the whole set of COIN system functionalities and services to integrate its collaborative environment supporting the whole product/service life cycle, integrating legacy systems and data and legacy services the COIN services in a smart way. As mentioned above, there are three different integration scenarios connecting the CP functionalities to the other components of the COIN System. The CP Integration Step 1 (Figure 19) is the integration of COIN EI/EC services into some business processes / workflows in the COIN Collaborative Platform. This means that the Industrial User needs to insert by hand the end-points of the services in the lowest level of his/her business process.

35

COIN Collaboration Platform

Knowledge Interaction Social Interaction

Business Interaction

Start End

Service1 EI Service2 Service3 EC Service4

COIN Collaboration Platform Service Bus

Figure 19 - Industrial User - CP Integration Step 1

The CP Integration Step 2 [4] for the industrial User is the integration between COIN CP and COIN EI/EC Platform through the API and interfaces of the COIN Front-End. All the EI/EC Services are brought to the EI/EC Platform and subject to the basic USs of the platforms: search, composition, negotiation, models distribution. In the BPs of the COIN CP, the Industrial User (Business Manager) can inject some Service Requests to be managed by the EI/EC Platform and transformed into service end-points (automatically or semi-automatically). In implementation terms, there is a Business Process pre-processing (preparation for execution) phase at modeling time where all the service requests will be sent and substituted with the relevant service end–points. If some of them are “service generation environments” they will be executed again before the execution time of the BP.

COIN Collaboration Platform

Knowledge Interaction Social Interaction

Business Interaction

Start End

Service1 Service3

SaaS Platforms(legacy systems)

Enterprise Applications

VAs

Service1 Service3

SaaS Platforms(legacy systems)

Enterprise Applications

VAs

SaaS Platforms(legacy systems)

Enterprise Applications

VAs

SaaS Platforms(legacy systems)

Enterprise Applications

VAs

COIN EI/EC ServicePlatform

EIServiceRequest2 ECServiceRequest4EI Service2

EC Service4

Enterprise I/op / Collab.

VAs

GSP UtilityServices

COIN EI/EC ServicePlatform

EIServiceRequest2 ECServiceRequest4EI Service2

EC Service4

Enterprise I/op / Collab.

VAs

GSP UtilityServices

COIN EI/EC ServicePlatform

EIServiceRequest2 ECServiceRequest4EI Service2

EC Service4

Enterprise I/op / Collab.

VAs

GSP UtilityServices

EI Service2

EC Service4

Enterprise I/op / Collab.

VAs

GSP UtilityServices

Service1EI

Service2Service3 EC

Service4

Service1EI

Service2Service3 EC

Service4

Figure 20 - Industrial User - CP Integration Step 2

The graphical User Interface used by the Industrial User to search for EI/EC services is an adaptation of the Front-End interface accessed by the individual User and providing all the functionalities of that interface like: search, invocation, ranking based on non-functional properties, subscription, etc. Finally the user can download the endpoint of the found service in its own business process.

36

Figure 21 - Injection in the business process of a discovered service

The CP Integration Step 3 [5] aims at injecting smartness in the discovery, link, and usage of COIN services in the Industrial User business process. This integration process leveraging on COIN Front-End APIs used to solve in a semi-automatic way a particular set of EI gaps that can be generalized in the future to cover a wider spectrum of gaps. During the project two evolutionary solutions have been experimented.

COIN Collaboration PlatformKnowledge Interaction Social Interaction

Business Interaction

Start End

COIN EI/EC Service Platform

US EI Service2US EI Service2

EI: Service3after Service1?EI: Service3

after Service1?

SaaS Platforms(legacy systems)

Service1Service3

Enterprise Applications

VAs

SaaS Platforms(legacy systems)

Service1Service3

Enterprise Applications

VAs

SaaS Platforms(legacy systems)

Service1Service3

Enterprise Applications

VAs

Enterprise I/op / Collab.

VAs (Tools)

GSP + EI/EC U. Services

EI Service2

EI Service2

Service1Service3

Service1Service3

Figure 22 - Industrial User - CP Integration Step 3

In CP Integration Step 3 for EI aims to solve in a semi-automatic way a particular set of EI gaps that can be generalized in future implementations to cover a wider spectrum of gaps. The basic idea of integration step 3 EI is that some EI Services will be specified and requested to the EI/EC Platform (namely the Value Added EI/EC Services, similarly to Step 2), while some other EI Services are automatically identified and juxtaposed in the BPs. The two steps could be in sequence (first EI/EC VAs discovery and then automatically insert the USs ones) but perhaps the selection of the VAs could be dependent on the USs available, so a closer interaction could be needed. The implementation of the EI scenario has focused on the format transformation case in which the Industrial User could have some format mismatches between electronic business documents and need, in a smart and automatic way to find a solution. The process for the identification and

37

solving of gaps is available as flow diagram in Figure 23 and based on three cross lights. If the process check ends without problems the green light is activated and the process could be executed at runtime. Otherwise gaps identified are warnings or errors. In the first case the gap could be solved manually changing the business process due to the fact that in the CP knowledge base are available the formats to accomplish the cooperative work. In case of red light the services are searched by the COIN Front-End API. If the transformation service is found it is inserted in the business process that will be checked again before to be run. In the other case (service not found) the same interface will automatically search for services able to create that transformation. The generation of the service is manual while the registration of it in the GSP is automatic; at the end of this process the service is searched again, then found and inserted in the business process.

Figure 23 - GAP Identification - Flow diagram

The following picture describes the technical overview of EI Step 3; novel developments are on top of the business process to connect the different items and the connection with the Front-End API.

Figure 24 - COIN Step 2 – Overview

38

1. In the workflow modeler has been created a button; clicking it the XPDL file is sent to the

CBPip web-service (COIN WP5.4) that identifies if there are gaps concerning electronic business document formats to be exchanged by different actors together with the permission to access the CP Knowledge base (KB) in which resides the registry of services of the companies of the cluster. By this KB the service can identify if the mismatch could be solved inside the cluster or if needs a new external service.

2. If there is an identified gap the user can click on the submission button and send the request to the GSP federation to fill the gap (e.g: Input invoice in F1 or F2 and Output invoice in F4 or F5).

3. The GSP federation will search for a direct transformation between formats; if there is a transformation will be returned to the caller to be inserted in the business process. If not the federation will search for a composition of services by usage of just PRE or POST conditions match. If the transformation is found it is returned; null otherwise. The management of the reasoning in the GSP is handled by the negotiation tool.

4. In the worst case (no direct or composed transformation available) the user is redirect to search for a service able to create this transformation (e.g: SP5.2 data interoperability services).

At the time a new web-service able to perform the needed transformation is created the data interoperability service supports, in a semi-automatic way, its registration in the GSP. This allows the further reuse of it, increasing the number of services available in the GSP federation. Without inserting anything the system sends the right credentials to the GSP Federation and shows the output to the user (Figure 25) that can select one service to be linked in the business process to solve the gap.

Figure 25 - Transformation Found

Figure 26 - Available Transformations

Step 3 for EC [5] aims to solve in a semi-automatic way a particular set of EC challenge that can be generalized in the future to cover a wider spectrum of challenges. The focus of the EI implemented scenario is the message notification applied to a virtual meeting process (provided by the MSMS service COIN WP 4.4). The system allows the user to don’t lose time in notifying other meeting participant but the system take in charge of it. In Figure 27 is depicted the architecture of the Integration Step 3 for Enterprise Collaboration

39

Figure 27 - Process Overview

The execution process is composed by several steps:

− The user access to a step willing to send messages to individuals (people). The step has an ontological description that is sent to the Step 3 EC interface based on COIN Front End API with other parameters:

a. virtualTeamID: containing the IDs of individuals targeted; it comes from the COIN CP centralized database;

b. Ontological description: pre/post conditions of the needed service, e.g: messageSent(message, individual, individual)

c. message: string identifying the message to be sent − The interface send the parameters to the expert system that, after a data gathering from

the Knowledge Base, evaluates rules, choose the right terms of the EC ontology, build a goal and send it to the GSP federation

The GSP federation finds the service and execute it passing the message parameter coming from the Step 3 EC interface. In tests the Collaboration services from WP4.1 have been used as targets

Figure 28 - automatic execution

40

2.3.3 Extended Products and Distributed Collaborative Innovation in Virtual Factories The discussion of extended products and distributed collaborative innovation in Virtual Factories raises a complex discussion. Basically it is necessary to briefly introduce the concept of extended products, distributed and collaborative innovation processes in order to discuss their implementation in Virtual Factories.

2.3.3.1 Extended products The origin of the extended product concept can be clearly traced back to product-centric engineering and their relation to service engineering in the nineties. Consequently the basis for the development of the extended product concept was a discussion on product engineering, innovation processes and virtual, extended enterprises which took place in parallel. • The discussion on product and service engineering that took place in the last centuries (Chao,

1993, Aurich et al 2006, Mont 2002, Bowen et al. 1989). Both time-to-market and service-product offer leverage to gain sustained competitive advantage. A paradigm shift is taking place from consumers buying products towards consumers buying solutions and benefits (Thoben 2003).

• Additionally there was an intensive debate on the virtual, extended enterprise concept (Jagdev and Browne 1998, Thoben & Jagdev, 2001; Jagdev & Thoben, 2001).

• Finally innovation processes in distributed setting were subject of many investigation such as Chesborough (2003), Hippel 2005), Eschenbaecher et al, 2005).

These three developments have contributed to the extended product concept which has been introduced in 2001 (Thoben et al, 2001). The extended product can be defined as follows:

An extended products itself describes the bundling of value added products and services to a core product to fulfill customer needs over the whole product lifecycle. As the term extended enterprise comprises more than just a single enterprise, the term extended product should comprise more than just the core or tangible product. Because of these characteristics, our view clearly focuses on extending a formerly tangible product. For that reason, the intangible shells and segments around the tangible product should be in the focus. Accordingly, all services related to an extended product which are relevant for our discussion do have a certain link to a tangible product.

The concept of extend products grounds on the shift of expectations from customers when buying new products and services. Today, many customers are interested not only in products but in a benefiting solution that often go beyond the mere physical core product. In this sense, Extend Products aim at the provision of benefits and may intertwine many tangible and intangible product compounds. As an example one could raise the issue of e-mobility: In the context of e-mobility, the provision of "green mobility" as such would be the main benefit. Customers do get the feeling to contribute to the environment preservation by reducing e.g. CO2 emissions. Figure 29 shows the development from products in a narrow sense, like physical products and components systems, as the electric car itself (i.e. the Mitsubishi iMiev) towards products with a broader perspective (e.g. car sharing service). One major shift is indicated by the transfer from production of products and components such as cars for a sometimes known and sometimes anonymous market towards mobility solutions.

41

Core Product Tangible Product Tangible and Intangible Product Assets

Shift of Business Focus

Provision ofBenefits

Manufacturing of Parts

Offering ofProducts / Systems

Offering of Solutions

Figure 29 - Moving to an Extended Product

2.3.3.2 Evolution towards distributed, collaborative innovation processes The term collaborative innovation or distributed innovation (DIN) has been discussed intensively over the last 10-15 years (O’Sullivan and Dooley, 2008 Kelly, 2006). Within the framework of this concept, innovation is seen as a distributed process that involves the collective efforts and the interaction of heterogeneous organizations. Each actor is specialized in specific activities, technologies and knowledge and innovation is seen as the result of the combination and integration of their competences. Coordination is therefore a key determinant for the viability of distributed innovation stimulating complementary activities across otherwise dispersed competences (Consoli et al., 2007). The following views on DINs illustrate a few varying opinions: • Moller and Rajala (2007) define innovation networks as relatively loose science and

technology-based research networks involving universities, research institutions, and research organizations of major corporations guided by the ethos of scientific discovery. Nevertheless, innovation networks themselves are seen as relatively loosely tied organizations (Freeman, 1991).

• Rampersad and Quester (2009) point out that innovation networks are relatively loosely tied groups of organizations that may comprise of members from government, university and industry continuously collaborating to achieve common innovation goals.

• O’Sullivan (2009) sees DINs as innovation processes that spread across an extended organization. Distributed innovation is the successful implementation of creative ideas, tasks, or procedures by employees in different geographic locations. The global availability of ICT-systems, resources and competencies accelerates the increasing distribution of innovation processes (Cummings, 2008).

There has been a long discussion about both representation and differentiation of innovation processes. The following diagram (Eschenbächer, 2009) differentiates between internal innovation management and in-between innovation management and therefore incorporates two main concepts. These two general concepts can be divided into five general approaches on how to deal with innovation processes. Basically, the model shows evolutionary steps towards greater dynamics of innovation in value creating networks.

42

Figure 30 - Evolution towards distributed, collaborative innovation

• The inventor: The very origin of innovation and the imagination is the inventor, who

represents the “beautiful mind” working in a cellar or garage on new inventions. • R&D department: The R&D (research & development) department is still a pre-dominating

imagination of intra-organisational innovation processes. Even today many companies run R&D departments for the sake of innovating. Nevertheless the trend of open innovation leads to a reduction of such traditional departments.

• Cross-functional teams: Cross-functional teams are of major importance to successful, intra-organisational innovation processes. In contrast to the traditional R&D department, here, many different departments collaborate in a cross-functional manner to enable innovation. This leads to both higher market orientation and increasing complexity of innovative products and services.

• Supply Chain innovation processes: The supply chain innovation processes deliver a good example for inter-organisational and distributed innovation processes. The outside world is integrated into the innovation processes, which leads to distributed innovation processes. Nevertheless, the innovation process is coordinated from a supply chain hub which means complete control by a large MNC (multi-national company).

• Distributed innovation networks: Currently, only very few world class companies such as Apple are really able to work in DINs. Here the main focus is the bundling of the best resources available.

2.3.3.3 Extended products and collaborative distributed innovation in Virtual factories After the introduction of extended products and collaborative distributed innovation it is important to understand their role in virtual factories. We have in mind that any production activity is caused by the needs of a potential customer. Precisely extended products can even help to define or identify new customer needs. Servicing the customer means also to support the customer in deriving new business ideas. The new business ideas can be considered as distributed, collaborative innovation efforts of several companies as shown in Figure 31. Consequently Virtual Factories of the Future have to extend their offerings in a dramatic way. Customers may not be interested in buying products; they may very well be satisfied to obtain an added value and for sure - an innovation. For this reason Virtual Factories of the Future have to

43

collaboratively offer total holistic solutions which might support the customer in achieving these benefits. Extension of products in terms of service-products will often constitute physical products as well as the associated accessories or services. The combined package is supposed to make the purchase of product ‘attractive’ to the customer. Thus, depending on the type and core competencies required to supply the associated services, there may be several business partners collaborating very closely towards the common goal of making the sale of the package attractive. This collaborative arrangement may very well operate in Virtual Factories Ecosystems. We believe that it is necessary to create more than one representation of the service-products. Here the Supplier bundles additional Accessories and Services around the core product to develop an ‘Service-Products” to make the sale more attractive to the Customer, who is the end user/consumer. If we take the picture with the shell we should ask who is providing the “service-products”? It is not just the manufacturer or supplier of the core / tangible product. To provide intangible assets of the product the concept of Virtual Factories Ecosystems comes in. These Virtual Factories Ecosystems are replacing the former single enterprise and take over the lifetime responsibilities for the product. The following shows a representation of this logic. Every enterprise provides some part of the extended product.

Enterprise A

Enterprise C

Enterprise B

Enterprise D

Virtual factories to produceExtended products:-Preparation of extended products-Integration of intra-organizational

processes to an inter-organizationalprocess chain

- Dynamic collaboration (reconfigurablewithin one order)

- Duration: max. 1 order- Allocation of Power: Hub-and-Spoke

(strong centralization of power)- Web-based ICT-support- Externally conceived as one enterprise

Figure 31 - Extended products and collaborative distributed innovation in Virtual factories

2.3.4 Conclusion and Future Work The work reported in this paper has been carried out in the framework of the COIN project by the implementation of the COIN Collaboration Platform and its usage by the COIN end-users. The BPM facility has been deeply adopted by COIN partners allowing them to build up this cross-organisational business processes leveraging on the availability of COIN services put at their disposal. This process allowed the end users to actually measure the business enhancement to their business processes. The work carried out, especially in respect with the so-called step2 and step 3 doesn’t end in the scope of the project but it is just a starting point to be generalised and possibly applied to other domains and circumstances. The COIN view of EC services as utilities could therefore on the one side stimulate the concept of a common Core Platform in the Future Internet embedding collaboration fundamental services, on the other side it could be the basis for a new Enterprise Information System supporting open innovation in collaborative enterprises and SMEs networks.

44

References [1] COIN D3.5.1a COIN 1st Integrated Service Platform – (CP) [2] D3.5.2a COIN 1st Integrated System – (CP2) [3] D3.5.2b COIN Final Integrated System – (CP3) [4] D3.5.2b COIN Final Integrated System – Annex IX – (STEP2) [5] D3.5.2b COIN Final Integrated System – Annex X – (STEP3EI) [6] D3.5.2b COIN Final Integrated System – Annex XI – (STEP3EC)

45

3 COIN Enterprise Collaboration (EC) and Interoperability (EI) Services

The second main objective of COIN was to consolidate and stabilize the ICT results of both EC and EI FP6 research into some Baseline Services (free or charged; open-source or proprietary) which constitute the service foundations for COIN. It was not an easy task to put together in a harmonized and coherent way, so diverse and heterogeneous results, but COIN main partners have been the most active actors in their respective FP6 projects and could therefore be the boost for that. So, COIN effectively built and implemented since the beginning of the project a solid service-oriented Technology Platform for Enterprise (SMEs) Interoperability and Collaboration, by putting together FP6 research results (chapter 3.1 and 3.2). Those results have been then enriched by new innovative services developed in COIN (see chapter 3.3 and 3.4) and in order to improve its usability and accessibility (mostly by SMEs) in different business and knowledge contexts. The Innovative Services in the EC and EI fields, took into account the most recent and promising technology challenges (in the field of Web 2.0, semantic web, space computing) and put them at service of EC and EI purposes. In the field of EC, we deem essential for SMEs some more configurable and flexible (not sector-specific) services for collaborative product development, distributed and participative production planning, co-opetitive multi-project management and finally some standardized services for user interaction and co-operation. In the field of EI, we basically approached most of the Grand Challenges identified in the EI Roadmap and we developed services for semantic, web-enabled business documents interoperability; for Knowledge interoperability and for Business models and policies harmonization and combination.

46

3.1 COIN research results for enterprise innovation - Enterprise Collaboration Baseline Services

Patrick Sitek1, Michele Sesana2, Hong-Linh Truong3 1 Bremer Institut für Produktion und Logistik GmbH, Hochschulring 20, 28359 Bremen (Germany)

(sit@biba.uni-bremen.de)

2 TXT e-Solutions S.p.A, Via Frigia, 27, 20126 Milano (Italy)

(michele.sesana@txt.it)

3 Distributed Systems Group, Vienna University of Technology, Argentinierstrasse 8/184-1, 1040 Wien (Austria)

(truong@infosys.tuwien.ac.at)

Abstract Enterprise Collaboration (EC) is a broad subject. Thus, a variety of different opinions can be formed mainly based on the scientific discipline behind it. In the context of COIN IP project, Enterprise Collaborations are based on inter-organisational relationships between network members, making the analysis and support of those relationships one of our main objectives. To this end, in the first year of the project, we consolidated and harmonised results from previous RTD projects concerned with Enterprise Collaborations to provide the Baseline Enterprise Collaboration (EC) Services for the COIN project. In this chapter, we present our consolidating results in which EC Baselines Services are introduced to support most dynamic enterprise collaborations, like Business Ecosystems, by harmonising individuals and organisations profiles under the same model. Keywords: Baseline Services, Enterprise Collaboration, COIN IP

3.1.1 Introduction Inter-organisational relations are gaining unprecedented momentum for enterprises [9] and are a widely discussed subject. Many researchers reviewed the topic of such enterprise collaborations (EC). In collaboration, parties are more closely aligned in the sense of “working together” to reach the desired outcome, rather than that outcome being achieved through “individualistic” participation constrained by contextual factors such as those imposed by client-supplier relationships and pre-defined roles, like in supply chains. An EC is an alliance constituted by a variety of entities (e.g. organisations and people) that are largely autonomous, geographically distributed, and heterogeneous in terms of their operating environment, culture, social capital and goals, but that collaborate to better achieve common or compatible goals, and whose interactions are supported by computer networks [2]. In today’s society, enterprise collaborations manifest in a large variety of forms, including virtual organisations, virtual enterprises, professional associations, industry clusters, professional virtual communities, collaborative virtual laboratories, etc. EC has been a major catalyst in the 6th Framework Program of the European Commission. It led to several projects aiming at finding new paradigms for enterprises aggregation, synchronisation and cooperation in response to the more and more demanding and complex business opportunities coming from customers. The research done so far focuses on three different collaborative network contexts, from the most static to the most dynamic one:

o Supply Chains, where long term relations and stable organisational and economic structures among enterprises allow the adoption of the most optimised and important IT solutions;

o Collaborative Networks, where the SMEs long term aggregations (i.e. clusters, districts and “breeding environments” of ECOLEAD IP) are finalised to get the members prepared to create and sustain more short term and dynamic alliances based on specific business opportunities (i.e. virtual enterprises, virtual teams);

47

o Business Ecosystems, where SMEs are left free to evolve as they like, just following the market evolutionary law that it is the fittest species which survive (i.e. open networks, de-focused networks) and the ecosystem just supports and encourages this emergent and evolutionary approach by providing SMEs with several services (e.g. legal, organisational, ICT).

Significant results in the field of IT infrastructure and IT support to EC management have been achieved so far. But evidently they could not address properly the problem of EAI (Enterprise Applications Integration) and operational support to collaborative processes in the different industries and application domains.

3.1.2 Related Work Recently, many projects have developed various collaborative systems which could be classified into systems for virtual teams, such as the inContext system (http://www.in-context.eu) or for virtual enterprises, such as ECOLEAD (http://www.ecolead.vtt.fi) or E4 (http://e4.cognovis.de/). The first type of systems is generic enough to be used in team collaboration of cross-enterprises but they are not integrated into real business context of enterprises in collaborative networks. The latter typically includes separate tools for different purposes in different life-cycle-phases of virtual enterprises (following [8], [1], [3], [6]):

1. EC Preparation (Sourcing of partners) 2. EC Formation and Setting up (Legal issues, contracts) 3. EC Operation (Day-to-day management) 4. EC Dissolution and Decomposition

While collaborative services are increasingly used for EC, a platform including well-integrated collaborative services which cover different aspects is missing, forcing the user to utilize different tools in separate ways. A detailed analysis of existing EC tools, in particular from the EU IST 6th Framework Program, has been performed. Table 1 summarises some major tools (a detailed survey can be found in [7]).

Table 1 - Existing EC tools and systems

Category Software Number of Tools

Tool Name

Web application

Tomcat 10 Virtual Breeding Environment Management (VMBS), Professional Virtual Community (PVC) Management and Governance, PVC Rewarding Tool, Requirement Identification Service (refQuest), E4 (Extended Enterprise Management in Enlarged Europe) Platform, Supported Indicator Definition (SID), Collaboration Opportunity Characterization (COC) Plan, Virtual Organization (VO) Model Repository, Partner Selection (PS), VO Formation

Apache Web server

2 Collaboration Opportunity (CO) Finder, Customer Support Service (DISCO)

Microsoft IIS

4 PVC Management and Governance, Planned, Mediated, and Ad-hoc Collaborations

48

Web service Axis 2 Communication Service Set, Activity Management

Database MySQL 9 PVC Management and Governance, PVC Rewarding Tool, Planned, Mediated, and Ad-hoc Collaborations, Communication Service Set, Activity Management, refQuest, DISCO

PostgreSQL 5 VBMS, E4 Platform, CO Finder, COC-Plan, VO Formation

Programming Language

Java 10 VBMS, PVC Rewarding Tool, Communication Service Set, Activity Management, refQuest, SID, COC-Plan, VO Model Repository, PS, VO Formation

C# 5 PVC Management and Governance, Planned, Mediated, and Ad-hoc Collaborations, E4 Platform

PHP 2 CO Finder, DISCO Most of the tools are specific for EC but some are generic, such as the Communication service set and the Activity Management service. Most of the shown tools did not follow the SOA paradigm but Web application, and they are designed to work in an isolated manner with a focus on the end user, not the service integrator. Thus, while useful for Enterprise Collaboration, most of the tools are designed for isolated use, diverse types of data are not integrated and it is difficult to compose different tools and services for newly-emerging collaboration needs. Moreover, the tools focus separately on Virtual Organisations and Professional Virtual Communities, while the business concept presented in this paper concentrates on dynamic enterprise collaborations between organisations and individuals in business ecosystems.

3.1.3 EC Baseline Reference Model The formal duration of EC describes the contractually fixed duration of that collaboration. It can be classified as unique if the intention is to realize just one product/offering based on a specific customer request. The collaboration can be classified as limited if the intention is to realize a fixed series of complex products. To support ability of collaboration and rapid formation of collaborative networks, the researchers came to the conclusion that it is necessary to have potential partners ready and prepared to participate in such collaboration [5]. Therefore enterprise collaborations can be differentiated in different life-cycle phases. This preliminary study on life-cycle phases and on existing EC tools and systems led to the identification of the EC Baseline Reference Model. The different phase of the life-cycle does require various baseline services. Therefore they were the best candidates to be part of the EC Baseline Reference Model. The following picture shows the EC Baseline Reference Model along the EC life-cycle. A set of EC Services has been designed as an IT solution and implemented according to the EC Baseline Reference Model.

49

Figure 32 - EC Baseline Reference Model

During the Preparation Phase of EC interested parties register and are able to define their profiles, e.g. editing administrative, contribution (product/ service), processes and performance data. The innovation lies in the combination in the management of originations and also individual profiles. This combination supports the management of highly dynamic collaborative networks like Business Ecosystems. Life-cycle independent communication web services are implemented to be used to announce news (like new members) and support communication between network members. The further innovative EC Baseline Service provides the possibility to either create a Business Opportunity (product/ service) from inside (based on the network competencies) or optional discovering Business Opportunity by market research. For the creation option a new serious game has been implemented that supports the creative ideation process between networks members. One member opens a creative session to seek for Business Opportunities and is able to sent invitation to other members by the Communication Service. Once the Business Opportunity has been identified the Formation Phase starts and with the Business Opportunity Characterisation Service it is possible to define the Work-Break-Down-Structure (WBS), the tasks to be performed and the special competencies needed. Active members can be rewarded for their activities in seeking for Business Opportunities. Right partners for the characterised Business Opportunity are to find with the EC Partner Search Service following chosen search criteria. While finding the right partners the support of communication, discussion and agreements between members is also provided by the communication service. The selected partners for the specific Business Opportunities are to register and collaboration performance indicators are to be set for the Operational Phase. Enterprise Collaboration Service and Product Management Services (PSM) support the Operational Phase of the collaborative network where the added value for the customer is to be realised. The PSM Service provides a structured storage in catalogues of all relevant product information and documentation to be realised. Complex products can be stored in different configurations. Following the (WBS), planned and mediated tasks can be defined for each

50

network partner. Ad-hoc task force teams can be set up in critical collaboration situations. The execution of the defined tasks is supported by an activity service, which links acting people with used resources, and tracks the state of each task. Exchange of product data and progress information related to the tasks are supported by the communication service again. Good collaboration performance can be rewarded and has a positive impact on the member’s profile. Finally during the Dissolution Phase it is possible to gather feedback from all active partners and the end customer and store the collaboration experience gained for a reuse in future Business Opportunities. Finally the end customer receives access to the product catalogue and product information.

3.1.4 Conceptual architecture Based on the analysis of existing tools in the field of Enterprise Collaboration, a conceptual architecture for a Baseline IT-Platform has been designed that follows the SOA model. The following picture shows the architecture that includes data, service and tool layers which aims at integrating and harmonising existing EC tools and services.

Figure 33 - Conceptual architecture of the COIN Baseline EC software services and tools

Data, services, and tools for EC that was previously created in an integrated way including strong relationship between presentation, business logic and data access layers are decoupled in these

51

three layers and integrated through SOA principles and technologies. Through the integration, a core set of services and tools has been realized available for use; services previously integrated and used by one tool now can be reused by other services or composed to support more complex scenarios. The central point of the EC Baseline IT services is the centralized model implemented as a database; data layer provides necessary data for any activities performed in the four phases of the EC lifecycle and the Business Opportunity to be achieved. In the next picture the process of decoupling is shown from a software built to be used alone (on the left) where the three levels are integrated in the same environment to a software where layers are completely separated; the business logic is provided as web service and data is gathered by usage of a centralized model.

Figure 34 - Example of decoupling of an existing software

During the decoupling the attention focused on the harmonisation of concept that previously have been taken completely separated: the organisation world (organisation, Virtual Organisation, cluster, etc) and the individual world (individual and virtual teams). The result is a model more than 60 entities implemented in 80 database tables allowing tools to share data in an easy way. In order to allow user to experience the whole EC Baseline services and tools has been provided a single point of access to the entire system: user should access to a portal based on Liferay by a single sign on mechanism based on Central Autenthication Service (CAS). On the website are displayed circles representing baseline services available for the user role; by clicking on that the user can access to the desired tool.

52

Figure 35 - Baseline IT Services Portal

The extension of the baseline IT service by inclusion of other services is easy because on the access of the common model allows new services to interact with data provided by existing services without knowledge about their internal processes.

3.1.5 Conclusion and key benefits Organisations need IT solutions that are able to support dynamic enterprise collaboration involving many organisations, individuals, resources and software services. First, due to the dynamics of collaboration and rapid formation of collaborative networks, these networks require different services for different collaboration phases [2]. By combining the management of organisations and individuals and their virtual forms, this approach supports the formation of highly dynamic collaborations including business ecosystems because rich sources of common data, such as profiles, product/service, processes and performance data, is linked and available in a common data-as-a-service. Converged collaboration services are provided by composing different services, i.e., communication services with other services to support realtime information dissemination among collaborators. Furthermore, a business opportunity (product/service) can be created from inside (based on the network competencies) or discovered through third party services. Third, business opportunities and collaborations are manageable through activities associated with individuals, teams, and their competencies and processes, and relevant product information and documents. Finally, through the portal, feedback can be collected and evaluated in a coherent way from individuals, organizations, customers and also from many software services to evaluate the success of collaborations. Such evaluations are valuable for determining trust and plans in future business opportunities. The portal enables the composition of commodity EC services: many existing EC services are common because we can use them for different purposes. With such a portal, new EC services can be created through the composition of common EC services. The portal enables the acquisition of rich data sources for understanding collaboration interactions and performance evaluation. Without such a portal, it is very difficult, to obtain different kinds of data characterising interactions for analysis. With the portal, profiles, activities, operations, contexts,

53

etc., can be logged and retrieved through a Web services-based platform, supporting many research activities, such as trust analysis and collaboration adaptation, which rely on realistic data for experiments. Acknowledgment This work has been partly funded by the European Commission through ICT Project COIN: Collaboration and Interoperability for networked enterprises (No. ICT-2008-216256). The authors wish to acknowledge the Commission for their support. We also wish to acknowledge our gratitude and appreciation to all the COIN project partners for their contribution during the development of various ideas and concepts presented in this paper. An early version of this paper appeared in the International Conference on Concurrent Engineering - ICE 2009 conference. References [1] Camarinha-Matos, L.M. and Afsamarnesh, H. (2005) “Collaborative networks: A new scientific discipline”,

in Journal of Intelligent Manufacturing, Vol.16, No.4-5, pp.439-452 [2] Camarinha-Matos, L.M. and Afsamarnesh, H. (2006) “Collaborative networks – Value Creation in a

knowledge Society”, in Proceedings of Prolamat 2006, Shanghai, China [3] Eschenbächer, J., Graser, F. and Hahn, A. (2005) “Governing Smart Business Networks by Means of

Distributed Innovation Management”, in: Smart Business Networks, Springer Verlag, Berlin Heidelberg New York, S. 307-323

[4] Eschenbaecher, J. (2008) Gestaltung von Innovationsprozessen in Virtuellen Organisation durch Kooperationsbasierte Netzwerkanalyse“ Dissertation an der Universität Bremen (to be published)

[5] Romero, D. and Molina, A. (2010) “Virtual organisation breeding environments toolkit: Reference model, management framework and instantiation methodology”, in Production Planning & Control, 21: 2, pp. 181-217

[6] Seifert, M. (2007) „Unterstützung der Konsortialbildung in Virtuellen Organisationen durch perspektives Performance Measurement“, Dissertation an der Universität Bremen

[7] Sitek, P., Eschenbaecher, J., Sesana M., Truong, H.L., Aguilera, C. (2008) “D4.1.1 – State of the art and baseline EC services specification”. COIN Consortium

[8] Thoben, K.-D. and Jagdev, H. S. (2001) “Typological Issues in Enterprise Net-works”, in Journal of Production Planning and Control, Vol.12, No.5, pp.421-436

[9] Zhao, F. (2000) “Quality and Collaborative Quality Management in Cooperative Research Centres”, in Conference Proceedings of 4th International & 7th National Research Conference, Sydney

54

3.2 COIN Innovative Enterprise Collaboration Services Kim Jansson 1, Michele Sesana2, Florian Skopik3, Alberto Olmo4

1 VTT, Technical Research Centre of Finland, kim.jansson@vtt.fi

2 TXTe-solutions S.p.A., Italy, michele.sesana@txtgroup.com

3 Distributed Systems Group, Vienna University of Technology, Austria, skopik@infosys.tuwien.ac.at

4 ISOIN, Ingenieria y Soluciones Informaticas, Spain, aolmo@isoin.es

Abstract The COIN project has developed services for Enterprise Collaboration. Based on the analysis of industrial needs and market available enterprise collaboration tools COIN has identified missing services on the market. A special focus has been put on identifying the needs of SME networks. COIN has specified, developed and delivered services in the following domains: Collaborative Product Development, Collaborative Production Planning, Collaborative Project Management and Collaborative Human Interaction. This chapter provides an overview of the methodology and workplan used together with an overview of the developed services. For each individual service the main innovations and progress beyond state-of-the-art are presented. Keywords: Enterprise Collaboration, Enterprise Interoperability, Innovative Services, Product Development, Project Management, Production Planning, Human interaction

3.2.1 Introduction Today Internet technology has made it possible to establish different types of Collaborative Networked Organisations (CNO). The costs of using modern Internet technology is no longer an obstacle for a large scale take up of collaboration services. The COIN Project develops services for European SMEs enterprise aggregation, synchronization and co-operation in response to the demanding and complex business opportunities coming from the global market [COIN]. In particular the COIN project develops services for Enterprise Collaboration (EC) and Enterprise Interoperability (EI). Based on analysis of industrial needs and identification of missing services on the market, COIN has further specified, developed and delivered services in the following domains. • Collaborative Product Development (c-PD) • Collaborative Production Planning (c-PP) • Collaborative Project Management (c-PM) • Collaborative Human Interaction (c-HI) In the COIN context the developed services to support the above mentioned domains are called Innovative Enterprise Collaboration Services. This article first describe, in section 2, the methodology and workplan used in COIN to identify needed services. Section 3 will briefly go into the background and previous research on the EC topic. Section 4 gives an overview of the functionality in the COIN innovative EC services. More detail can be found in the corresponding COIN Deliverables listed in the References section. The most important part of this article is the section 5, which presents the main innovations in the services and the innovative ways of using the services.

3.2.2 Methodology and Workplan The COIN project has used a research approach that relies on previous research projects and market available solutions. The development of COIN EC services has been guided by the following principles: • Build on state-of-the-art knowledge and previous results from research and development.

55

• Be continuously open for adopting new emerging and breakthrough technologies and de-facto standards.

• Take advantage of existing work and avoid inventing the wheel again. • Favour open source and free of charge solutions. COIN has used a user-centric (and SME-oriented) approach in the development work. The industrial partners’ networks have a crucial role in ongoing interaction with the research and development parties. A two-cycle spiral approach has been followed. Each of the two cycles has delivered independent prototypes for EC services followed by integrated versions. The main industrial evaluation and feedback was scheduled between the iteration cycles. However the on-going interaction, between developers and the industrial partners, throughout the project has encouraged the development of innovative service features also within the iteration cycles. The following Figure 36 illustrates the overall development strategy, where the second development cycle in the approach is followed by an industrial take-up and demonstration phase.

Figure 36 - COIN overall development strategy

3.2.3 Background and Previous Research In the European CNO research cluster VOSTER, two main concepts for inter-enterprise collaboration were identified according to the objective and duration of the collaboration [12]: • Network / breeding environment which is a more stable, though not static, group of

organisations which have developed a preparedness to co-operate. • Virtual organisation (VO) / virtual enterprise which is a temporary consortium of partners

from different organisations established to fulfil a value-adding task, for example a product or service to a customer.

The ECOLEAD-project has enhanced previous frameworks for understanding the relationships between entities in a CNO [12]. Software tools developed in e.g. the ECOLEAD as well as other projects have been aggregated into COIN forming the Enterprise Collaboration Baseline Services, explained in the previous article of this book. They support the collaboration life cycle for both long-term, mission-driven and short-term, opportunity-driven collaboration [3].

56

3.2.4 Results - Overview of Developed Services As stated in the introduction section COIN has developed innovative services for c-PD, c-PP, c-PM and c-HI Services. The first three groups of services directly support the corresponding operational functions; product development, production planning and project management, in a CNO, while the fourth group of services are more general and not specifically dedicated to a function in the CNO. The c-HI services encompass services for human collaboration and data sharing and can be utilized as supporting services, for example in the c-PD, c-PP and c-PM. Figure 37 gives an overview of the functionality in the COIN innovative EC services. The individual services are explained in some more detail in the following section.

Production Planning• Production Planning Portal & Service

• Quality Management• Supply Chain Information& Text enrichment

Project Management• Project Alignment

• Social Gantt building• Project Meeting Process Management

Human Interaction Support• Collaboration Visualization• Trusted Information Sharing

• Trusted Online Help & Support

Product Development• Semantic Cluster Management

• Automatic Ontology Building• 3D Viewing & Annotation

Figure 37 - Overview of developed services

3.2.4.1 Services for Product Development (c-PD) Product development is a very wide process, covering different activities from the original ideas and requirements collection to partner search for production, first prototype building, architecture and design, product manufacturing, testing, deployment and maintenance. Collaborative Product Development is the application of team-collaboration practices to an organization’s total product development efforts. It is concerned with creating the necessary environments for effective, free flowing information and ad-hoc collaboration among peers involved in these mostly external knowledge worker partnerships [13]. Often used tools include computer-aided design (CAD), computer-aided engineering (CAE), computer-aided manufacturing (CAM), enterprise resource planning (ERP) and product data management (PDM) systems, that can be integrated to support intra- and inter-enterprise collaboration. The following innovative services have been developed: • Semantic Cluster Management Services (SCMS). • Automatic and Intelligent Construction and Instantiation services (AICIS). • Collaborative 3D Designer Service (C3DDS).

3.2.4.2 Services for Planning Support (c-PP) Production Planning is a large concept and could be defined as the function for the efficient planning, scheduling, and coordination of all production activities. In this function a huge number of variables are involved: resources, planning horizon, costs, capacity constraints, bill of materials, warehouse availability, quantity, delivery dates, etc. The configuration of production planning system requires the set-up of a large set of parameters comprising the input data related to the company structure, the environment on which production takes place, and the

57

configuration algorithms for the master production scheduling creation. For those reasons, these services have been created in complex professional systems for enterprises. The information flow and the collaboration among actors of the value chain to coordinate their work are also included in the definition of production planning. The following innovative services have been developed: • PnP Collaborative Production Planning Portal (C3P). • SaaS Production Planning Service (PPS). • Collaborative Quality Management Service (cQMS). • Supply Chain Intelligence Service (SCIS). • Service-oriented Text Enrichment Services (SOTES).

3.2.4.3 Services for Project Management (c-PM) Project Management (PM) is the discipline of planning, organizing, and managing resources to obtain the successful completion of specific project goals and objectives, while adhering to classic project constraints; scope, quality, time and budget. Collaborative Management of projects involves, shared and delegated project management responsibility, often self-organized and trusted approaches, non-hierarchical and participative management organization. The discipline of project management is well established and an application area well supported by software solutions. However development within Internet technology, social media, participative co-creation, and Web 2.0 applications also enables new working methods on the PM area. Based on industrial requirements and from analysing the current state of the art and research progress in the area of CNO, PM and Web2.0, COIN has recognized a real need for development in the area of Collaborative Project Management (c-PM). The developed c-PM innovative services are grouped into the following three tools with the objective to support “social and collaborative internet based project management”

1. Project Alignment Booster (PAB). 2. Collaborative Project Meeting Process Management (PMPM). 3. Collaboration for Project Management (Coll4PM).

3.2.4.4 Services for Human Interaction Support (c-HI) Web-based collaborations and cross-organizational processes typically require dynamic and context-based interactions between people and services. Product development, production planning and project management are supported by services and tools developed by partners as well as market available complex professional system. However, there is currently only little support and a lack of solutions to tackle problems arising from dynamic aspects of execution, e.g. how to handle exceptions and deviations from the planned progress. These situations often require a human intervention. Thus, there is a need to monitor on-going collaborations, characterized by human interactions in the operational phase of a virtual organization to retrieve a holistic view about the performance of a collaboration scenario. The developed c-Hi concepts and tools support dynamic human interactions in cross-organizational environments. People use these services to interact in a context-aware manner. Interactions are monitored by using logging services. On top of logged interactions, trust relations can automatically be inferred using a rule-based interpretation of interaction metrics. Using these concepts the following c-Hi services are provided:

1. Collaboration Visualization Tool (CVT). 2. Trusted Information Sharing Service (TIS).

58

3. Trusted Online Help and Support (TOHS).

3.2.5 Innovations The previous chapter contained on overview of the developed EC services. This chapter will present the main innovations in the services and the innovative ways of using the services.

3.2.5.1 Progress beyond State-of-the-Art in Semantic Cluster Management Services (SCMS) Heterogeneous tools and multiple designers are frequently involved in collaborative product development, and designers often use their own terms and definitions to represent a product design. Thus, to efficiently share product information, a designer’s intentions should be persistently captured and the semantics of the designer’s terms and intents should be interpreted in a consistent manner. For this purpose, a standardized data format is a prerequisite. The objectives of the Semantic Cluster Management are to support engineering knowledge management to enable the search of right partners for product development, with the needed sub-products or services, and with the needed competences. The Semantic Web supports integrated and uniform access to information sources and services as well as to intelligent applications by the explicit representation of the semantics buried in an ontology. The SCMS extends the collaborative product development ontologies to the companies that form a CNO (be it supply chains, collaborative network or business ecosystems), to improve collaborative product development through a formalised description of companies, competences, services, products and documentation. The main innovation of this ontology is its interest for diverse end users that can model their knowledge domain with a more generic tool than those currently available. Figure 38 shows an example.

Figure 38 - Healthcare sector ontology draft

This service is complemented with Automatic and Intelligent Construction and Instantiation Services (AICIS), which is explained in the next section.

3.2.5.2 Progress beyond State-of-the-Art in Automatic and Intelligent Construction and Instantiation Services (AICIS) The SCMS has been complemented with automatic and intelligent semantic web services that deals with 1) automatic building of the ontology, based on relational databases used in the cluster

59

or on unstructured data and 2) automatic instantiation of the ontology, based on cluster documents. The service aims at providing intelligent searching and browsing through crawled data about cluster companies. The main part of developed services has been integrated in the free accessible ontology management environment OntoGen [2]. The innovation in COIN is to implement OntoGen services to function automatically i.e., to build up ontologies automatically from a given set of documents. A part of the ontogeny services has been redeveloped to offer the option of unsupervised ontology learning. Unsupervised learning is based on clustering methods from text-mining where the clusters of instances from selected concept are treated as sub-concept suggestions.

3.2.5.3 Progress beyond State-of-the-Art in Collaborative 3D Designer Service (C3DDS) 3D collaborative product development is essential in current industrial processes. Proprietary file formats have traditionally locked 3D CAD users into one vendor. The technology of Web services opens new opportunities for CAD applications, enabling viewing and sharing 2D and 3D designs, without the need to download or install any software, allowing the collaboration of any user with the only requisite of accessing the Web. With the C3DDS prototype, the following objectives have been addressed:

− Online viewing of 3D files, including a wide variety of formats and de-facto standards. − Web service architecture, avoiding the need to install software. − Online annotations, to enable “virtual meetings” to comment 3D designs. − History of annotations and authoring of annotations.

Adaptation of C3DDS to different types of CNOs (collaborative networks, supply chains, business ecosystems) has been the object of development.

3.2.5.4 Progress beyond State-of-the-Art in Collaborative Production Planning Portal (C3P) Production Planning systems give to the user a great amount of functionalities concerning product managements, company resources management, scheduling algorithms, warnings and errors can be defined and evaluated through a graphical user interface (GUI) , and so on, as shown in figure 39. Employees of the same company can easily work together on company data and solve internal problems. What is missing in these systems is the collaboration among different organizations of the supply-chain; this is due to several factors: • Different production planning systems do not give mutual access to company data. • Production agreements between partners (orders) are exchanged in different structures and usually exchanged by archaic methods (FTP, email). • Collaboration on data is performed only through old communication channels (telephone, emails, face-to-face meetings, etc.). • There are few data available to actors to solve exceptions and warnings and partners do not have information about other partners’ internal processes. • Unavailability of production planning systems for some partners (mainly SMEs).

60

Figure 39 - Collaborative Production Planning

These factors cause an enormous loss of time, that means money, in order to make systems connected (data exchange, format harmonization, manual data insertion from one system to another), to solve misunderstandings, exceptions and warnings. SMEs without an interconnected IT infrastructure (or without any production planning) experience these problems more than big industries, and their risk is to stay outside the market. The innovations in C3P include: • The implementation of a Collaborative Production Process composed by internal actors’

processes by which different companies can share their production planning to collaborate with other parties of the chain: collaboration is put on top of arrows connecting different private blocks of different companies and managed by virtual rooms.

• Possibility to have shared changes at public (inter-organisations) or private level (intra-organisation).

• Implementation of a collaborative bill of material. • Agent negotiation implemented through the adoption of the COIN agent negotiation services

generated at the end the agreed order in the UBL standard format. • Possibility, through the collaborative production planning process to start different

negotiations at the same time with different competitors and select the best one. • Native support for the communication among individuals through the inclusion of the virtual

team concept on top of virtual rooms and the integration of human communication services.

3.2.5.5 Progress beyond State-of-the-Art in Production Planning Service (PPS) Production planning is usually a module of Enterprise Resource Planning (ERP) solution, both open source and commercial, that are widely adopted and used since decades by enterprises. ERP systems are widely adopted by medium/big enterprises but not by SMEs that cannot afford the costs and the complexity of the software. The innovation of PPS is to provide a simple Production Planning system as a Software as a Service (SaaS) service able to provide common functionalities such: • Data Import service. • Execution of algorithms to calculate the feasibility of the production and needed time/price. • Data output service. • Warning and Exception service.

61

The availability of this service by web interfaces leverages SMEs from any cost related to the required technical infrastructure and can be easily adopted by them. The service is natively integrated in C3P.

3.2.5.6 Progress beyond State-of-the-Art in Collaborative Quality Management Service (cQMS) Inter-organisational relations result in inter-organisational interdependencies which make new demands on managing quality in enterprise networks. Managing interdependencies in enterprise networks, means to understand that the work, changes in processes and output of any single network member might have consequences for the work, processes and outputs of other members in the network. These consequences, if not identified in sufficient time, might result in not reaching the initial customer requirements and failing in quality of the network product. cQMS suggest an innovative approach to analyse interdependencies between enterprise network members by analysing their competence profiles [4]. By combining the information entities product/service, business processes and technologies a representation of the competence as definition is given. Each actor’s unique combination of products, resources and activities constitutes its identity as competence. The competence defines the actor’s specific need for information to be exchanged. In cQMS a similarity algorithm approach is used to compare the partners’ competence descriptions. Through cQMS network members make use of a word comparison algorithm, which determines the similarity of two word sequences using the dice coefficient and reveals, in this way, potential interdependencies. With the introduced cQMS members of CNO receive a comprehensive approach that enables them to investigate inter-organisational interdependencies based on their competence profile descriptions stored in the C3P [5].

3.2.5.7 Progress beyond State-of-the-Art in Service Oriented Text Enrichment Services (SOTES) Service oriented Text Enrichment Services (SOTES) have been developed because they present the basic infrastructure for many planned and future semantically enriched services. With SOTES the content is being enriched with the large contextual information that then provides far better results in semantic services ranging from machine learning algorithms, data, text and Web mining, social software, network modelling tools to semantics and reasoning. Content is being enriched through many different types of information ranging from domain specific, common sense knowledge, technical, multilingual, etc. SOTES presents a unique approach that gathers together many technology innovations in a software stack for automatic content enrichment.

3.2.5.8 Progress beyond State-of-the-Art in Supply Chain Intelligence Services (SCIS) Traditional logistics and corresponding Supply Chain Management (SCM) systems rarely use algorithms from the area of artificial intelligence (AI). This is why they are using very deterministic approaches that can just partly take into consideration the complexity of a logistic system. The functionalities that are usually covered are; planning, monitoring and offline re-planning in the case of problems. There are two main innovative features in SCIS: • Implementation of new features for prediction, trend detection and anomaly detection.

Services are based on various methods that have been developed to handle vast amounts of data in real-time.

• Integration of top-down (knowledge driven) methods and bottom-up (data driven methods) for the SCIS. Here the main innovative features comprise among others knowledge formalization of SCIS domain, justifying methods with reverse reasoning, and integration

62

with a knowledge base and formalized representation of a vast quantity of fundamental human knowledge: [14].

3.2.5.9 Progress beyond State-of-the-Art in Project Alignment Collaborative project management requires that the participating organizations and people share a common commitment and understanding of project objectives, requirements and practices, and that the partners have sufficient competencies and skills for the project tasks. PM software is a term commonly used to cover software targeted to aid the project managers in managing their projects. This type of software usually cover functions for scheduling, budgeting, forecasting, resource allocation, progress monitoring, quality management, communication and documentation. The developed methodology and the Project Alignment Booster services include the following innovations and new development: • The project alignment process. • Collaborative and participative definition of unified and shared project work processes. • A self-evaluation methodology to announce partners’ capability and engineering

competence. • Possibility to analyse gaps between project demanded skills and capabilities offered by the

project partners. Based on the analysis, the collaborative project management can identify the need for additional capabilities and competencies. The monitoring of deviations assists in detecting project risks and possible timing problems.

• The Project Alignment Model (PAM) is a configurable framework that describes for alignment tasks and elements different levels how they can be carried out. The PAM is configurable and more flexible than existing Maturity Models as CMMI.

• Inclusion of organisational culture elements into the PAM.

3.2.5.10 Progress beyond State-of-the-Art in Collaborative Projects Meeting Process Management (PMPM) The development of the PMPM is based on the vision that global collaboration project organizations need distributed meetings. Distribute meeting should be conducted more efficiently than a traditional local meeting, through new processes and IT tools. The main concept of the developed services is to support the management of the whole long meeting processes. The process extends from the planning of the meeting all the way to finalization of the meeting, e.g., from agenda planning to distribution of meeting minutes. The individual steps in the meeting process will invoke existing tools and services, preferably opens source based services. An example is illustrated in Figure 40.

Figure 40 - Example of meeting process and steps

The development contains the following innovations: • Support of the management of asynchronous and long meeting process involving steps e.g.

participative definition of agenda, call for participation, scheduling, standard agenda,

63

contribution asynchronously in advance, reminding of meeting, online meeting, follow up. The innovation is in the management of the whole meeting process.

• Establishment of application domain specific process libraries for typical project meetings, for example complex engineering projects.

• Integration with the COIN GSP to find most suitable meetings services. The best suited tool to be used in each step is based on the partners “on-line” status, role in project, importance etc. The tools used in the various steps can be defined on forehand or dynamically selected during the process execution.

3.2.5.11 Progress beyond State-of-the-Art in Collaboration for Project Management (Coll4Pm) The Collaboration for Project Management Service (Coll4Pm) focuses on the collaborative management of a collaborative project, taking as a central point of the application the Gantt chart on which users coming from different environments and backgrounds can socially collaborate. There is a wide availability of tools (both open source and commercial) on the market giving the possibility to work on Gantt charts. Interfaces are mature and the user experience is also mature. Building and managing a Gantt, in a CNO is a complex task. The complexity is related to the discussions behind the decision summarized in the Gantt file. Focusing on the collaborative management of collaborative projects the innovation aspect of the Coll4Pm service is to provide a collaborative environment in which social interactions among humans takes place based on trust relationships among humans. To provide this, a number of innovations have been created: • A social integrated web environment in which people can collaborate on Gantt charts. • A personalised notification system by news feeds of events occurred in different

project/discussion rooms. • A social collaborative management of changes based on Web2.0. • Availability of human/company profiles and the management of social relationships among

them by assessment of co-workers, integration of communication services and injection of trust based mechanism coming from COIN c-HI services in project management.

3.2.5.12 Progress beyond State-of-the-Art in Collaboration Visualization Service (CVT) Trust relies on previous interactions and collaboration encounters [21]. Recently, trust in social environments and service-oriented systems has become a very important research area. SOA-based infrastructures are typically distributed, comprising a large number of available services and huge amounts of interaction logs. Therefore, trust in SOA has to be managed in an automatic manner [9]. Although several models define trust on interactions and behaviour, and account for reputation and recommendation, there is hardly any case study about the application of these models in service-oriented networks. Fundamental research questions, such as the technical grounding in SOA and the complexity of trust-aware context-sensitive data management in large-scale networks are still widely unaddressed. Depending on the environment, trust may rely on the outcome of previous interactions. Trust is not simply a synonym for quality of service. Instead, metrics expressing social behaviour and influences are used in certain contexts. Utilizing interaction metrics, in particular calculated between pairs of network members, enables the incorporation of a personalized and social perspective. Progresses beyond the State of the Art include: • Trust models for service-oriented cross-organizational collaborations using data collected

through common human interaction services, such as e-mail or IM; thus, unburden actors from managing relations manually.

64

• Exploiting trust networks to support actor discovery (e.g., in social campaigns) and compositions (e.g., team formation) in highly dynamic networks that are frequently updated based on occurring interactions (and not only based on manual relation definitions).

3.2.5.13 Progress beyond State-of-the-Art in Trusted Information Sharing Service (TIS) In collaborations, activities are the means to capture the context in which human interactions take place. Activities describe the goal of a task, the participants, utilized resources, and temporal constraints. Studies regarding activities in various work identify patterns of complex business activities, which are then used to derive relationships and activity patterns. Studies on distributed teams focus on human performance and interactions even in Enterprise 2.0 environments. Based on log analysis, human interaction patterns can be extracted [21]. Trusted information sharing, as applied in COIN, is related to selective dissemination of information (SDI), that deals with questions regarding which (parts of) data are shared with others, and mechanisms to disseminate data. TIS adopts the concepts of SDI, such as the representation of information through mechanisms to process XML-based data. However, SDI does not deal with underlying social models to control sharing of information. Progresses beyond the State of the Art include: • Trusted information sharing can be considered as a soft access control model that allows only

trusted partners to see one’s private profile or uploaded business documents. Once configured, TIS adapts the amount of shared information flexibly without human intervention based on dynamically changing trust relations.

• TIS can be used in social campaigns, e.g., to control the dissemination of invitations based on interest profiles and expertise levels. This way, spamming individuals with documents and messages that are definitely not of interest for them is avoided.

3.2.5.14 Progress beyond State-of-the-Art in Trusted Online Help and Support (TOHS) Service-oriented Architectures (SOA) typically comprise software services only. Many collaboration and composition scenarios involve interactions between human actors as well as software services. Current tools and platforms offer limited support for human interactions in SOA, therefore Human-Provided Services (HPS) are introduced. HPSs are offered by human actors. Web services technology is used to describe HPSs and to enable interactions with real people. HPSs can be used in various collaboration settings on the Web to facilitate expert discovery and interactions in a service-oriented manner. In COIN, the concept of HPS enables the expert seeker to discover the right collaboration partners [7] [10]. Compared to other tools and approaches applying expert discovery, THOS does not demand for manually maintained skill profiles that need to be frequently updated by the user. The used approach is based on dynamic profiles and collaboration behavior. Dynamic profiles are based on monitoring of interactions and analysis of relations. Progresses beyond the State of the Art include: • Unified view on human and software services capturing characteristics of humans, Human-

Provided and Software-based Services. It enables the specification and matching of multidimensional service descriptions which is essential in the context of Human-Provided Services. Such an approach is beyond current state-of-the-art and opens up unprecedented opportunities for future platforms.

• Context model capturing social and community aspects. Social information includes friend networks and can be used to recommend services or compositions. Community aspects describe the evolution of, for example, preferences and interests, at a global level.

65

3.2.6 Conclusions and Key Benefits The developed services support key operational functions in a CNO. In this respect, the COIN project has gone beyond current work by not only building on various existing work, but also introducing new innovative concepts and services that support dynamic collaboration models in networks of enterprises. The COIN Innovative Enterprise Collaboration services have been successfully demonstrated in real life industrial settings in a number of cases. The process of analysing the usability and take-up of the services as wells as the process of bringing COIN to the market and creating value for the various stake holders is being described in a later section of this book. References [1] Ollus M., Jansson K., Karvonen I., Uoti M. Riikonen H. “On Services for Collaborative Project

Management” Taylor & Francis, Production Planning & Control. ISSN: 1366-5871 (electronic) 0953-7287 (paper)

[2] OntoGen. Text-Mining Software. http://ailab.ijs.si/publications/ accessed 16.6.2011 [3] Sitek, P., Sesana, M., Truong, H-L. (2009), On Baseline IT-Services to Support Enterprise Collaboration, in

Proceedings of the 15th International Conference on Concurrent Enterprising (ICE2009), Sofia Antipolis, France

[4] Sitek, P., Seifert, M., Thoben, K.-D. (2010a) Towards an inter-organisational perspective to manage quality in temporary enterprise networks, in International Journal for Quality and Reliability Management, Volume 27, Issue 2, 2010, pp 231 – 246

[5] Sitek, P., Seifert, M., Thoben, K.-D., Cannas, V. (2010b) Impact of Inter-Organisational Inter-dependencies on collaborative Quality Management in Enterprise Networks, in Proceedings of the 16th International Conference on Concurrent Enterprising (ICE2010), Lugano 2010, Switzerland, ISBN 978 0 85358 2700

[6] Sesana M., Taglino F., Cannas V., Gusmeroli S., Production Planning and Knowledge Interoperability Utility and Value-Added Services in Aerospace Domain , in proceedings oft he eChallenges 2010 conference 27-29 October 2010 Warsaw - Poland

[7] Schall D., Truong H.-L., Dustdar S. (2008) Unifying Human and Software Services in Web-Scale Collaborations,

[8] IEEE Internet Computing, vol. 12, no. 3, pp. 62-68, May/Jun, 2008. [9] Skopik F., Schall D., Dustdar S. (2010). Modeling and Mining of Dynamic Trust in Complex Service-

oriented Systems. Elsevier Information Systems Journal (IS), Volume 35, Issue 7, November 2010, pp 735-757. Elsevier.

[10] Skopik F., Schall D., Psaier H., Dustdar S. (2011). Adaptive Provisioning of Human Expertise in Service-oriented Systems. 26th ACM Symposium On Applied Computing (SAC), March 21-25, 2011, Taichung, Taiwan. ACM.

[11] COIN Project Portal: http://www.coin-ip.eu/ accessed 20.5.2011. [12] Kurumluoglu, M., Nostdal, R., Karvonen, I. 2005. Base concepts, in Camarinha-Matos, L., Afsarmanesh,

H., Ollus, M. (eds.), Virtual organizations. Systems and Practices, Springer-Verlag. 2005; 11-28. [13] Mills, A. (1998). Collaborative Engineering and the Internet: Linking Product Development Partners via the

Web. Society of Manufacturing Engineers, Dearborn, Michigan. [14] CycKB The Cyc Foundation. http://www.cyc.com/ accessed 20.5.2011. [15] COIN Deliverables D4.2.1b c-Product Development Services, 2009 [16] COIN Deliverables D4.2.2b c-Product Development Services Prototypes and Factsheets, 2009 [17] COIN Deliverables D4.3.1b c-Production Planning Services, 2009 [18] COIN Deliverables D4.3.2b c-Production Planning Services Prototype and Factsheets, 2009 [19] COIN Deliverables D4.4.1b c-Project Management Services, 2009 [20] COIN Deliverables D4.4.2b c-Project Management Services Prototypes and Factsheets, 2009 [21] COIN Deliverables D4.5.1b c-Human Interaction Services, 2009 [22] COIN Deliverables D4.5.2b c-Human Interaction Services Prototypes and Factsheets, 2009

66

3.3 COIN Enterprise Interoperability Baseline Services Enrico Del Grosso1, Gorka Benguria2, Francisco Javier Nieto De-Santos3, Francesco Taglino4,

Brian Elvesæter5 1TXT e-Solutions, Italy (enrico.delgrosso@txt.it)

2ESI, Spain (Gorka.Benguria@esi.es)

3ATOS, Spain (francisco.nieto@atosresearch.eu)

4CNR-IASI, Italy (taglino@iasi.cnr.it)

5SINTEF, Norway (Brian.Elvesater@sintef.no)

Abstract Enterprise Interoperability [3] is a relatively recent term that describes a field of activity with the aim to improve the manner in which enterprises, by means of information and communications technology (ICT), interoperate with other enterprises, organisations, or with other business units of the same enterprise, in order to conduct their business. This paper describes part of the work that COIN project has performed in the context of Enterprise Interoperability. Starting from past experiences in European projects, COIN has developed a set of baseline interoperability services that aims to solve and cover most of the Interoperability problems that SMEs are currently facing. Keywords: COIN, enterprise, interoperability, services, ATHENA, baseline, EI service framework

3.3.1 Towards Enterprise Interoperability services Experiences from piloting activities in the ATHENA project suggested that Enterprise Interoperability is very challenging and that the expected gains from interoperability research will consist in finding technologies and methods that will fasten interconnection of applications through standardised Web infrastructure for software application communication and for collaboration [1]. The research projects on interoperability in the European Commission Sixth Framework Programme have developed a vast set of standalone software products and tools, as well as some Web-based services to address interoperability issues. However, some of these solutions are difficult to integrate and use for SMEs because of the lack of technology background. Furthermore, numerous architectural frameworks and sector-specific specifications have arisen from the standardisation arena. Moreover, the service-oriented computing paradigm and service-oriented architecture (SOA) have emerged as a major evolutionary step, with Web services, Grid services and peer-to-peer (P2P) services comprising the major trends. This has been joined by developments in Semantic Web Services, enterprise modelling, as well as other modelling and process languages to describe business processes and their executions. Today, the market is saturated with technology-based solutions that claim to support interoperability for enterprises, with several commercial middleware solutions among the most prominent. Within the context of an enterprise, flexibility, fast development and re-configuration are important properties for software applications. This implies to avoid as much as possible the intervention of software engineers and developers, and to prefer direct parameterisation and configuration by software users. This also implies accurate ways to architecture enterprise applications that facilitates publication of information managed by the application, publication of services made available by the application for other applications and finally publication of services made available for the human users. Finally such architectures should make it possible to manage coherency of the application systems despite numerous existing interfaces and adaptation of the application systems within the whole enterprise.

67

In the COIN context, Enterprise Interoperability (EI) services provide functionality for applying IT solutions that overcome interoperability gaps between two or more enterprises and thus enabling them to set-up and run collaborations. The main goal of the EI services is to improve enterprise interoperability, mainly for SMEs, which means to reduce the costs of data reconciliation, systems integration and business processes synchronization and harmonization. Typical indicators will be in the cost of service composition and of data mediation and reconciliation.

3.3.2 COIN EI framework The COIN EI Services Framework adopts the ATHENA Interoperability Framework (AIF) [1]. A framework is a structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed. An interoperability framework provides a set of assumptions, concepts, values and practices that constitutes a way of viewing and addressing interoperability issues.

3.3.2.1 ATHENA Interoperability Framework The interoperability reference model relates the solution approaches coming from the three different research areas of ATHENA, namely enterprise modelling, architectures and platforms, and semantic mediation and ontology. Figure 41 illustrates the reference model that focuses on the provided and required artefacts of two collaborating enterprises. Interoperations can take place at the various levels (enterprise, process, service and information/data).

Enterprise

(Business)Processes

Services

Information/Data

Cross-OrganisationalBusiness Processes

Collaborative EnterpriseModelling

Flexible Execution and Composition of Services

Information/DataInteroperability

Mod

el-D

riven

Inte

rope

rabi

lity

Sem

antic

Med

iatio

n In

tero

pera

bilit

y Enterprise

(Business)Processes

Services

Information/Data

Provided Required

Figure 41 - Interoperability reference model

An interoperability reference architecture relates a set of interoperability levels and a set of interoperability approaches. An interoperability level denotes the capability level of two or more collaborating entities to support interoperation. • Interoperability at the enterprise level should be seen as the organisational and operational

ability of an enterprise to factually co-operate with other, external organisations in spite of e.g., different working practices, legislations, cultures and commercial approaches.

68

• Interoperability at the process level is the capability to make proper external views of enterprise internal processes synchronised by a collaborative inter-enterprise business process.

• Interoperability at the service level is concerned with discovering, ranking, selecting, composing, orchestrating and executing various applications implemented as a service.

• Interoperability at the information/data level is related to the exchanging and sharing business documents among organizations, by filling interoperability gaps related to the payload (format and content) and to the messages and/or structures to be exchanged.

The interoperability approaches help us to support interoperations at the various interoperability levels. A model-driven interoperability approach that cuts across the four interoperability levels implies that models are used to formalise and exchange the provided and required artefacts that must be negotiated and agreed upon. ATHENA defines a set of meta-models and languages that can be supported by tools and methods to construct the models in question. To overcome the semantic barriers which emerge from different interpretations of syntactic descriptions, precise, computer processable meaning must be associated with the models expressed on the different levels. It has to be ensured that semantics are exchangeable and based on common understanding in order to enhance interoperability. This can be achieved using ontologies and an annotation formalism for defining meaning in the exchanged models.

3.3.2.2 COIN EI services framework After a preliminary study of the services and tool that constitute the state of the art, 6 EI service categories have been chosen from the AIF model:

1. model-driven 2. enterprise modelling 3. business process 4. service* 5. information/data 6. semantic mediation

Enterprise

(Business)Processes

Services

Information/Data

Cross-OrganisationalBusiness Processes

Collaborative EnterpriseModelling

Flexible Execution and Composition of Services

Information/DataInteroperability

Mod

el-D

riven

Inte

rope

rabi

lity

Sem

antic

Med

iatio

n In

tero

pera

bilit

y Enterprise

(Business)Processes

Services

Information/Data

Provided Required

*Serviceinteroperability

is addressed bythe COIN Service

Platform (SP3)

Figure 42 - Baseline categories according to AIF

Since the service interoperability is being addressed by the COIN Service Platform the COIN EI Services Framework adopts five service categories for EI:

69

• Model-driven interoperability services support enterprises to formalise, exchange and align models that are relevant to set up collaborations.

• Enterprise modelling interoperability services support enterprises to factually co-operate with other, external organisations in spite of e.g., different working practices, legislations, cultures and commercial approaches.

• Business process interoperability services support enterprises to make proper external views of enterprise internal processes synchronised by a collaborative inter-enterprise business process.

• Semantic mediation interoperability services support enterprises to apply ontology-based techniques for semantic mediation such as semantic reconciliation of business documents in order to support interoperability among heterogeneous software applications.

• Data interoperability services support enterprises to exchange and share business documents among organizations, by filling interoperability gaps related to the payload (format and content) and to the messages and/or structures to be exchanged.

3.3.3 Enterprise interoperability baselines Services to include in the COIN EI Services Framework have been chosen according to a precise methodology. First step has been the analysis of existing state of the art. A lot of work has been done in the field of interoperability by past European Projects, so all the existing work have been evaluated to choose which one to include and how. As a result of this first step, a list of sub-service categories has been found for each framework categories. These sub-service categories represent specializations and specific domains of each EI service framework category. Final step of the process has been the definition of the services to implement for some of these sub-service categories. The ratio used to select the services to implement derived from end user requirements and available software from previous works. The following table shows the list of services that constitute the COIN EI Services Framework.

Table 2 - COIN EI Baseline Services and descriptions

# Baseline EI service Service description

1 COIN Model Transformation Service Engine

The engine will be a service entry point for storing model transformations that are aimed at aligning the huge diversity of models used in the design, integration and implementation tasks of enterprise applications and systems.

2 COIN POP* Transformation Service

The service will provide the functionality of modelling in the context of POP* to JPDL transformation. The results of the transformation should be published into the open source JBPMN platform.

3 COIN Enterprise Interoperability Maturity Assessment Service

The service will help to assess an organization's maturity level concerning the use of enterprise models as well as the capability of these models to enable the company to be part of collaboration. Based on this assessment, companies will be guided to choose the right concepts for improving their capabilities, by taking into account actual market and enterprise challenges.

4 COIN Semantic Business Process Modelling Service

The service will help to reduce the complexity of tasks related to transformation between different BP models as well as transformation in executable process models with semantic annotations.

5 COIN Semantic Business Process Management Service

The service will manage the life cycle of deployed Business process models independently on the underlying engines actually executing the model.

70

6 Athos Ontology Service

The service will provide functionalities for ontology management. Ontology is a pre-requisite for semantics-based mediation and reconciliation of business documents.

7 Astar Semantic Annotation Service

The service will provide functionalities for management of semantic annotations. Semantic annotation allows digital resources to be described in terms of a common reference represented by a domain ontology. Such an activity represents a first identification of semantic and structural mismatches among different information structures, which is needed for fulfilling interoperability issues among heterogeneous information systems.

8 Argos Semantic Transformation Rules Service

The service will provide functionalities for management of transformation rules service. Transformation rules represent the semantic mapping able to drive the mediation and reconciliation.

9 Ares Semantic Reconciliation Service

The service will represent the final step towards the actual mediation and reconciliation of business documents among heterogeneous information systems.

10 COIN Massive Data Interoperability Service

The service allows communication among a set of multiple data providers and a set of multiple data consumers. In a multi-point communication, the interoperability problem grows exponentially according to the number of entities involved in the communication. The service will allow the data providers to “map” their data structure to the requested schema and “fill” the schema itself with the data coming from their data sources.

11 COIN Transactional Data Interoperability Service

The service allows the communication between two actors; a customer and a supplier. The scenario of the communication is the exchange of business documents in the order to invoice procurement process.

In this other table are listed the sub-service categories of each EI service framework category and which services correspond to each sub-category.

Table 3 - COIN EI Baseline Services according to framework category

© Sub-service category Service Name Model-driven interoperability services

Metamodelling - Language engineering - Model mapping and transformation COIN Model Transformation Service Engine Method engineering -

Enterprise modelling interoperability services

Enterprise modelling - Enterprise models interchange COIN POP* Transformation Service Enterprise model deployment Enterprise interoperability maturity assessment

COIN Enterprise Interoperability Maturity Assessment Service

Business process interoperability services

Cross-organizational business process modelling

-

Semantic business process modelling COIN Semantic Business Process Modelling Service Semantic business processes management

COIN Semantic Business Process Management Service

Business process monitoring - Business process analysis -

Semantic mediation interoperability services

Ontology editing Athos Ontology Service

71

Ontology engineering and maintenance - Semantic annotation Astar Semantic Annotation Service Semantic transformation rules building Argos Semantic Transformation Rules Service Semantic reconciliation engine Ares Semantic Reconciliation Service

Data interoperability services

Data mapping COIN Massive Data Interoperability Service Data infrastructure framework - Business document modelling - Business document interchange COIN Transactional Data Interoperability Service Business document process integration -

References [1] ATHENA A4, "D.A4.2: Specification of Interoperability Framework and Profiles, Guidelines and Best

Practices", ATHENA IP, Deliverable D.A4.2, 2007a. http://interop-vlab.eu/ei_public_deliverables/athena-deliverables/.

[2] B. Elvesæter, G. Benguria, A. Capellini, E. Del Grosso, F. Taglino, “COIN D5.1.1 – State-of-the-Art and Baseline EI Services Specifications”, July 2008.

[3] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, "Enterprise Interoperability Research Roadmap, Final Version, Version 4.0", July 2006.

72

3.4 COIN Innovative EI Services Enrico Del Grosso1, Fabrizio Smith 2, Hannes Suttner 3, Francesco Taglino2

1 TXT e-solutions, Via Frigia, 27 – 20126 Milano)

2 Istituto di Analisi dei Sistemi ed Informatica “A. Ruberti”, Viale Manzoni, 30 – 00185 Roma)

3 Siemens IT Solutions and Services, Gudrunstraße 11 – 1101 Wien

Abstract To create added value in a highly competitive, global market, nowadays organisations – especially Small and Medium-sized Enterprises (SMEs) – more than ever have to cooperate with appropriate business partners, identify state-of-the-art business processes and select the best technologies available. This business environment positively affects demand for Enterprise Interoperability Services (EIS) aiming to provide services to facilitate co-creation, and services to surmount or even to prevent interoperability issues. The COIN project adopted the ATHENA EI reference framework which addresses interoperability at different levels. COIN adapted and substantiated the established concepts, and implemented several services particularly with regard to information interoperability, process interoperability and knowledge interoperability. This summary highlights a few out of the many COIN results in the EI domain, i.e. semantic reconciliation of business documents, introduction of the visibility rules concept, business process gap detection, as well as knowledge sharing of key competences and skills of enterprises cooperating in a cluster. Keywords: Enterprise Interoperability, Semantics, Business Process, Information Interoperability, Knowledge Interoperability, Process Interoperability

3.4.1 Introduction Enterprise Interoperability [3] is a relatively recent term that describes a field of activity with the aim to improve the manner in which enterprises, by means of information and communications technology, interoperate with other enterprises or organisations to conduct their business. In the COIN context, Enterprise Interoperability (EI) services provide functionality for applying IT solutions that overcome interoperability gaps between two or more enterprises and thus enabling them to set-up and run collaborations. The main goal of the EI services is to reduce the costs of data reconciliation, systems integration and business processes synchronization and harmonization. The COIN project adopted the ATHENA EI reference framework (see Chapter 3.3 – Baseline EI Services), which addresses interoperability at different levels, by using two main approaches (i.e., model-driven and semantics-based). In particular, in this chapter we focus on the following three interoperability levels: • Information/data level which is related to the exchanging and sharing business documents

among organizations, by filling interoperability gaps related to the payload (format and content) and to the messages and/or structures to be exchanged.

• Process level which is the capability to make proper external views of enterprise internal processes synchronised by a collaborative inter-enterprise business process.

• Enterprise (knowledge) level which refers to the organisational and operational ability of an enterprise to factually co-operate with other, external organisations in spite of e.g., different working practices, legislations, cultures and commercial approaches.

In the rest of this chapter, COIN interoperability services are presented. In particular, in section 2 Information Interoperability services; in section 3 Process Interoperability services and in section 4 Knowledge Interoperability services. Then, Section 5 presents the main innovative issues of the COIN Interoperability services.

73

3.4.2 Information Interoperability services Information Interoperability services are focused on enabling enterprise information systems to exchange business documents (e.g., invoices, purchase orders) even if they are not natively conceived for this purpose. In the COIN project, this activity was mainly devoted to allow: • Exchanging business documents written in UBL (Universal Business Language) in new

interoperability spaces, evaluating several possibilities of exchange: 1:1, 1:n and n:m. • Semantic annotation of business object documents in order to automatically derive the

mediation rules necessary for the semantic reconciliation of formats and contents. • Study how to create federated spaces where the business documents can interoperate each

other without the needs of a common reference models. In the rest of this section, a description of the main aspects of the information interoperability services is presented.

3.4.2.1 Data Payload Services Data Payload services consider the interoperability among business documents in UBL format at payload level. Payload means that only the content of the document is considered (and not the structure). Data Payload services apply a rule based logic to manage the change of content in the different documents. Users can write their own business rules using a graphical tool that translate such rules into an engine specific XML based language. A dedicated engine applies then all the rules defined according to specific business logic, like the role of the rule creator or the sender/receiver of the business document.

3.4.2.2 Semantic Reconciliation services The semantic reconciliation approach [19]is based on the use of domain ontology as common reference for the harmonization of heterogeneous data. This harmonization is accomplished into two different moments: a preparation phase and a run time phase. In the preparation phase, the schemas of the documents from the software applications are mapped against the reference ontology. The mapping starts from the semantic annotation and ends with the building of two sets of semantic reconciliation rules for each document schema: a forward and a backward set of rules, which allow data transformation from the original format into the ontology representation and vice-versa, respectively. The run-time phase concerns the actual exchange of data from an application to another. For instance, when an application, say, SA1, wants to send a document to another application, say, SA2, the reconciliation between the format of SA1 and the format of SA2, is done by applying first the forward rules set of SA1, and after the backward rules set of SA2.

3.4.2.3 Federated Interoperability Federated interoperability is a special approach to interoperability that aims to avoid the use of any kind of reference model. The interoperability domain is the structure of document, but instead of putting a middle reference model (ontology) between the two documents, federated approach is based on the application of several micro-services. Micro-services are atomic functionalities that apply on single pieces of documents, transforming them into other format.

3.4.3 Process Interoperability services Cross-organisational Business Process Interoperability (CBPip) Services aims at ensuring a successful business process collaboration of participating enterprises. In the COIN project, we concentrated on two services [18]:

74

• One service is rule-based transformation of private business processes into public processes. The public processes of different organizations are then joined together thus forming the cross-organizational business process which defines the way the organizations cooperate.

• The other service is to identify and eliminate interoperability gaps in CBPs.

3.4.3.1 Private2Public Process Transformation The aim of the Private2Public transformation is to produce a public view of a private process of a given company, in order to hide all the private and critical data of the private process, resulting in a simplified process. To this end, we adopted the SBVR (Semantics of Business Vocabulary and Business Rules) [3] business rule language in order to describe the visibility of different process elements of a private process. Among the several existing rule languages, SBVR allows a representation of rules in structured English, which is easily understandable by humans. The proposed approach and developed services allow describing how a public view should be produced from a private process, by way of business rules. This is achieved through three principles: • A Vocabulary (in SBVR) which describes the semantic of Process elements, as well as

the roles of partners in a CBP. The vocabulary defines noun-concepts related to the modelling of Process elements (Activity, Data) or to their semantics (Sales Department, Customer, etc.), as well as verb-concepts to specify associations.

• The SBVR rules are linked to specific elements of Processes. Indeed when reading a rule, the transformation service needs to know which elements are described in the rule.

• Business rules which specify what should be public. By default, nothing is shown to partners11 . The rules are then based on the RBAC principle (Rule-Based Access Control [4]). The business rules are based on the verb-concept “is visible to”, and tell which element in the process should be visible to which kind of partner.

Once a private process has been described by rules, its public view can be extracted. This step is performed by an ATL [5] transformation, which reads the visibility rules in SBVR and operates on the XPDL representation of the process.

3.4.3.2 Gap Detection COIN defines Business interoperability as the capability of two or more systems to cooperate using exchanged information, and an interoperability gap is a situation when interoperating business processes do not deliver the expected results while each of the business processes does. The following kinds of interoperability gaps are addressed by COIN: • Deadlocks: According to the literature [2], deadlocks are situations in which a “certain

instance of the model (but not necessarily all) cannot continue working, while it has not yet reached its end)”. Deadlocks are classified in the following way: Loop deadlock, multiple source deadlock, improper structuring deadlock.

• Interface Mismatches (e.g., Number of Messages Interface Mismatch, Message Types Interface Mismatch) which are serious impediment that prevents two separately-modeled business processes of successful interoperation due to different design assumptions.

3.4.4 Knowledge Interoperability services In the COIN project, Knowledge Interoperability refers to the capability of exploiting at best the knowledge of each cooperating enterprise, leveraging on their complementarities, avoiding unnecessary overlapping. To this end, the main functions of the Knowledge Interoperability

11 This is in fact not described in SBVR, but rather implemented in the transformation itself

75

Services are based on the possibility of identifying the key competences and skills of each enterprise, matching and contrasting such knowledge among the partners cooperating in a cluster, identifying missing knowledge to allow for a target enlargement of the cluster. According to that, Knowledge Interoperability services have been developed for: • acquiring, gathering and organizing knowledge about Competencies and Skills (CS) in a

collaborative network (CN) in the form of a reference ontology (Social Ontology Building and Evolution service [6]);

• describing enterprises’ CS by means of ontology-based semantic profiles (Enterprise Semantic Profiling service), in order to represent all the enterprises in a CN in terms of the same common and shared reference Angelucci et al., 2010];

• reasoning on profiles, through semantics similarity techniques, to assess the actual CS asset of the network, and the impact and added value on the CN due to the entrance of a company in the CN (Enterprise Semantic Matchmaking service [7]).

In the rest of this section, a brief description of the SOBE service is given.

3.4.4.1 Social Ontology Building and Evolution The Social Ontology Building and Evolution (SOBE) service supports the building of ontology about competencies in the context of a cluster of enterprises. SOBE is characterized by three main aspects: • Automatic knowledge extraction from unstructured enterprise documents, by using natural

language processing techniques [8]. Enterprise documents indeed, are pregnant with enterprise knowledge. They are data containers that record and drive the processes of the company.

• Social participation of a community of experts. Social aspects during ontology building and evolution are required since an ontology needs community acceptance. To this end, SOBE enables the community of experts to validate, discuss about for reaching a consensus, and enrich the results of the automatic extraction [9].

• Step-wise approach that, for reaching the final aim of a domain ontology construction, goes through intermediate results (i.e., lexicon, glossary, taxonomy).

3.4.5 Main innovation issues This section underlines what are the main innovative issues introduced by the interoperability services developed in the COIN project.

3.4.5.1 Information Interoperability services Concerning the Information Interoperability services for semantic reconciliation of business documents, the main innovations, with respect to existing solutions [15], [16] [17], regard the automatic support to the mapping process and the adopted pattern-based approach. This approach hides to the end user the technicalities of the logic-based underline representation, and allows the definition of complex data transformations through the instantiations of a limited set of patterns. Considering the federated approach for information interoperability, based on application of micro-services in sequence, compared to the semantic approach, it has both pros and cons. The main pro is that reconciliation is simpler and more immediate, making this approach suitable for quick, one shot transformations. The main con is that the format of the document should be comparable (ideal situation is different versions) in order to have an effective transformation. This makes semantic approach more complete and general, even if the creation of the middle ontology can be a very complex work.

76

3.4.5.2 Process Interoperability services COIN introduces the concept of Visibility Rules, which specify what process elements are visible to which partner. There are two innovation aspects concerning those rules. Firstly, Visibility Rules are specified in SBVR, which allows a representation in Structured English. This means that it is easily readable and understandable by business actors, and provides a very high usability and friendliness profile. Secondly, such rules are specified in a separate file, and are not specific to a particular private process: they can be applied to the whole set of private processes a company has. COIN allows defining several public views from a single private process, without any change needed in neither the private process nor the Visibility Rules. This is because the transformation takes into account three parameters: the private process, the Visibility Rules, and, most important here, for whom the public process is generated for (e.g. a “customer”, a “finance department” or a “supplier”). This means that the company can easily parameterise the transformation to its needs, without having to redefine its strategy concerning the choice of what is private/public.

3.4.5.3 Knowledge Interoperability services With respect to [10], [11], the SOBE service presents the complete ontology evolution process and provides a detailed description of the collaborative process (i.e., debating, and voting) and clear indication of the needed steps and relative milestones. Furthermore, SOBE introduces automatic supporting tools trying to integrate at best human and software-based activities. Considering the existing proposals of frameworks for enterprise modelling [12] [13] [14], they are in general rather complex, trying to capture within a single framework all the different aspects and dimensions that characterise an enterprise. For this reason, enterprise semantic profile is here represented as a CS profile in the form of an Ontology-based Feature Vector (OFV) [7], which is basically a set of concepts from the reference ontology adopted by the enterprise cluster. It avoids entering the complex theory of enterprise frameworks and it concentrates on the production capacity of an enterprise, synthesized by its competencies and skills (CS). Representing each profile as an OFV guarantees the uniqueness of the interpretation representation. The fact that the representation is not ambiguous derives from the nature of the terms appearing in the vector(s), which are representative of ontology concepts (hence, ontology-based feature vectors). This non ambiguity of the representation implies that the represented enterprise’s CS are universally intended within the enterprise cluster with a (unique) meaning accessible to all because connected to the cluster’s ontology.

3.4.6 Conclusions In this paper, we presented the Enterprise Interoperability services studied and developed within the context of COIN project. The research work produced a set of services that can be applied in different kinds of interoperability domains. Current services have been developed following the ISU (Information Service Utility) idea, and have been thought to be put in clouds of other services to be found, orchestrated and executed in different kind of processes according to the needs of the users. At the moment, these services can be seen as working prototypes that demonstrate that the ISU idea can be applied to interoperability, and that general services can be developed to address several kinds of problems in different domains. The next step in this path will be the development of smart services that can auto-configure themselves according to the specific problem they are facing. References [1] [Li, et al. 2006] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, "Enterprise Interoperability

Research Roadmap, Final Version, Version 4.0", July 2006. [2] [Awad and Puhlmann, 2008] Ahmed Awad and Frank Puhlmann: Structural Detection of Deadlocks in

Business Process Models, BIS 2008, LNBIP 7, pp.239–250, Springer-Verlag Berlin Heidelberg 2008

77

[3] [SBVR, 2010] Semantics of Business Vocabulary and Business Rules, version 1.0, OMG, http://www.omg.org/spec/SBVR/1.0/, last visited: 16.04.2010

[4] [RBAC, 2010] http://www.techstreet.com/standards/INCITS/359_2004?product_id=1151353. [5] [ATL, 2010] ATLAS Transformation Language, version 3.0.0, http://www.eclipse.org/m2m/atl/, last

visited: 16.04.2010 [6] [Angelucci et al., 2010] Angelucci D., Barbagallo A., Di Mascio T., Missikoff M., Taglino F.: A social

platform for enterprise ontology building. Proc. of Open Knowledge Models Workshop. October 2010, Lisbon, Portugal.

[7] [Formica, 2010] Formica A., Missikoff M., Pourabbas E., Taglino F. : Semantic Search for Enterprises Competencies Management. Proc. of KEOD 2010.

[8] [D’Amadio, 2008] D'Amadio P., Velardi P., Navigli R. Mining the Web to Create Specialized Glossaries - IEEE Intelligent Systems, 2008

[9] [Barbagallo et al., 2010] Barbagallo A., De Nicola A., Michele Missikoff: eGovernment Ontologies: Social Participation in Building and Evolution, in the Proceedings of Forty-Third Annual Hawaii International Conference on System Sciences, IEEE Computer Society Press, 2010

[10] [Tempich et al., 2007] Tempich C., Simperl E., Luczak M., Studer R., Pinto H. S.. Argumentation-Based Ontology Engineering. IEEE Intelligent Systems 22(6): 52-59 (2007).

[11] [Karapiperis and Apostolou, 2006] Karapiperis S. and Apostolou D.. Consensus building in collaborative ontology engineering processes, Journal of Universal Knowledge Management 1 (3), 2006.

[12] [CIMOSA, 1996] CIMOSA - Open System Architecture for CIM, Technical Baseline; Version 3.2 CIMOSA Association, private publication (March 1996).

[13] [Zachman, 1987] "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax.

[14] [Williams, 1998] Williams T. J. PERA and GERAM - Enterprise Reference Architectures in Enterprise Integration. Proceedings of the IFIP TC5 WG5.3/5.7 Third International Working Conference on the Design of Information Infrastructure Systems for Manufacturing II table of contents Vol. 144 archive, pp. 3 - 30 (1998)

[15] [Kerrigan et al. 2007] Kerrigan, M., Mocan, A., Tanler, M., & Fensel, D. The Web Service Modeling Toolkit - An Integrated Development Environment for Semantic Web Services. Proc. ESWC 2007, Innsbruck, AU.

[16] [Mocan et al. 2007] Mocan, A., & Cimpian, E. (2007). An Ontology-based Data Mediation Framework for Semantic Environments. International Journal on Semantic Web and Information Systems , 3 (2), 66-95.

[17] [Kabak et al. 2009] Kabak, Y., Dogac, A., Ocalan, C., Cimen, S., & Laleci, G. B. (2009). iSurf Semantic Interoperability Service Utility for Collaborative Planning, Forecasting and Replenishment . eChallenges Conference. Instanbul, Turkey.

[18] [Huber, et al. 2011] S.Huber, C.Carrez and H.Suttner. “Development of Innovative Services Enhancing Interoperability in Cross-organizational Business Processes”. IWEI 2011, Lecture Notes in Business Information Processing, Volume 76, Part 2, Part 2, pp. 75-88, Springer Berlin Heidelberg, 2011.

[19] [Missikoff et al., 2010] Missikoff M., Smith F., Taglino F.: Semantic Services for Business Documents Reconciliation. Chapter in the book "Interoperability in Digital Public Services and Administration: Bridging E-Government and E-Business". Ed. Yannis Charalabidis. 2010. ISBN 978-1-61520-887-6 (hardcover); 978-1-61520-888-3

[20] [Angelucci et al., 2010] Angelucci D.., Barbagallo A. , Taglino F D5.3.1b – Innovative Knowledge Interoperability Services Final Specifications (Deliverable COIN project).

78

4 COIN Demonstrators

4.1 The COIN EI/EC Services in industrial Supply Chains The impact of COIN Project has been spread on four Supply Chains. Supply Chains are the most static and long-lasting collaboration form addressed by the project; here is where long term relations and stable organisational and economic structures among enterprises allow the adoption of the most optimized and important EI solutions, where optimization and efficiency are of key importance This chapter focuses on the four COIN supply-chains pilots, two in the Western Europe: the EIEC Pilot in an Automotive Supply Chain (ACS) and the Aerospace pilot in the Lazio region in Italy and two in the Eastern Europe: the Pilot in a Railways Supply Chain (KTU) and the pilot in a Construction Supply Chain (UPB).

79

4.1.1 An EI/EC Pilot in an Automotive Supply Chain Simon Oman¹, Dušan Bušen2

1 Polycom d.o.o., Poljane nad Škofjo Loko 76 d.o.o., Polycom d.o.o., Poljane nad Škofjo Loko 76, Slovenija, simon.oman@polycom.si

2 GIZ ACS, Dimičeva 9, 1000 Ljubljana, Slovenija, dusan.busen@acs-giz.si

Abstract In business environment where supply chains strive to remain flexible, data exchange with the use of information systems represents a competitive advantage. Ontology has been proposed as an important concept of business collaboration so as to achieve interoperability of information systems in the supply chain. This paper presents internet based collaboration in the automotive supply chain. Enterprise Collaboration and Interoperability (EC & EI) brings a new concept of business collaboration into the automotive supply chain, namely the so-called computing in the clouds. At the same time, the paper demonstrates a prototype solution presenting a model of data exchange in the Automotive Cluster of Slovenia (ACS). The presented prototype solution facilitates the companies in the Cluster to operate more swiftly and ensures a more reliable flow of information. Keywords: collaboration, interoperability, automotive supply chain, pilot solution

4.1.1.1 Brief History of Automotive Cluster of Slovenia The market conditions pose an additional challenge to the Automotive Cluster of Slovenia (henceforth also referred to as the ACS), in particularly, to adapt to the renewal of certain processes. Companies representing the association in the ACS, therefore, pay more and more attention to research and development with an objective to keep pace with the development in the most rapidly growing industry in the world, so as to ensure the introduction of new products and technologies and thus affect the increased volume of demand. The objective is clear, effective and profitable growth. Potential for scientific and technological breakthrough in the automotive industry proves to be extensive and extremely diverse. Collaboration and interoperability, integration and constant search of potential partners in the construction of electrical machinery and devices represents a huge potential breakthrough for the ACS. In the search of new partners focus is paid on equipment and systems of power electronics, systems and algorithms for the management, supervision and management. Furthermore, the ACS wishes to streamline in the development of methods for rapid prototyping, as well as the design and integration of different information technology systems. The latter affects not only the events in business environment, but also acts decisively on setting strategies, reeling business processes and organization of companies. Information technology provides valuable contribution to the replacement of more expensive production since the creators of cheaper, established, more effective connections between processes facilitate simpler and more reliable integration between processes and thus contribute to value added in designing new products. Information technology improves business processes by modifying or transforming activities taking place within the process, thereby replacing expensive or less efficient process with cheaper and more effective ones. It still proves extremely important for the Slovenian automotive industry to strengthen its position in the world markets, namely through innovation and investment in knowledge and technology. This should be done now when there are many possibilities for the Slovenian suppliers arising from the transfer of R&D and manufacturing capability of the vehicle manufacturers to suppliers of systems. Therefore, the ACS intends to accelerate and enhance the development of more complex products, such as electronics in the passenger compartment interior, pedal box, hand brake, brake system, body and lighting equipment, systems, doors, mirrors, exhaust system, suspension, window systems washer, air conditioning, heating, seats cooling, steering and safety systems, engine and transmission components (including castings

80

and forgings). Simultaneously, the ACS seeks to establish the development infrastructure for the development of new solutions for the electrification of vehicles, internal combustion engines, security and comfort, and technological and manufacturing excellence. In order to provide the integration of the Slovenian and international associations, the ACS shall upgrade network connections to share and acquire new skills. By providing extremely flexible environment with the concentration of development resources on specific development areas the ACS shall seek to position itself as a flexible development and pre-development suppliers to global vehicle manufactures. Successful implementation of all R&D projects is a lengthy process that requires a lot of cooperation and may take several years before its objectives are fully accomplished. As stated above, in addition to single R&D projects and their objectives, great attention should be paid to the establishment of strong horizontal and vertical, as well as physical and intellectual integration, taking into account the specificities of various environments and in accordance with the principle of partnership and concentration. In this way, R&D projects have an additional positive effect on the ACS as well as in other fields and areas.

4.1.1.2 Description of relevant facts Modern manufacturing companies need to establish an efficient strategic cooperation with the purpose of improving their competitiveness on the market [4]. While attention was paid to optimisation of production processes in the previous decade, now proves to be the right time to align supply chain all the way from suppliers to customers [1]. The objective of managing the supply chain is faster and more flexible coordination among customers and their suppliers [7]. Suppliers operating in the manufacturing field, in particularly, small and medium-sized companies (SME) call for constant improvement of their operations in the business environment, thus setting such companies in more favourable economic position [8]. So as to improve organisational interoperability into a complex adjustable system definitely proves as a challenge and at the same time almost an impossible undertaking. The existing approaches to modelling a company (e.g. UEML, ARIS), modelling of business processes (e.g. SCOR model) and work process modelling (e.g. BPEL) definitely strive towards establishing integration among companies [8]. Increasingly present software allows large and small-sized companies to join computing in clouds. Services in clouds ensure connectivity of databases and form a part of information infrastructure allowing companies and organisations to move or integrate a particular quantity of data on the location in the cloud. Disadvantage of such integration is the difference among the companies and organisations wishing to collaborate. In particularly, a question arises as to how collaboration of companies using different software may be improved. Empirical studies [3,6] show that the integration of supply chain ensure better operative and business success. In order to make use of all advantages offered by the integration of supply chain, it is important to reorient operations into an exchange of information among companies [2]. There are many sub-suppliers in automotive sector using simple software to manage information flow. However, different translators are used to meet the needs of collaboration. The role of small and medium-sized companies in the automotive sector has been increasing dramatically the fact being that they provide various support to large companies. In doing so, they constantly face with software technology, which proves extremely expensive and hard to manage for small and medium-sized companies, bearing in mind that software with its maintenance is becoming more and more expensive, while the needs for staff and knowledge on managing such software are becoming ever greater. Alignment of processes for joint projects proves extremely important since the collaboration and alignment of operation in the supply chain brings valuable value added. The existing solutions represent provision of comprehensive

81

information support for company’s internal processes [5]. Said processes are generally roughly divided into commercial and technical processes both requiring intensive collaboration. Commercial process (Figure 43) is characterised with the fact that most orders and call-offs are received with the help of software which enables computer data exchange. All orders and call-offs are recorded and archived in business information system and allow the company to make necessary and required forecasts.

Figure 43 – Commercial Process

Technical process, on the other hand, requires that business information system accepts development detailed lists elaborated on the basis of the CAD/CAD/CAE technical system. Each production detailed list contains all component parts of the tool for injecting thermoplastic material. Each semi-manufactured product is accompanied with the order system or work order system. Calculation of needs for material and cooperation is performed on the basis of semi-manufactured product status. Calculation facilitates elaboration of purchase orders (needs for cooperation and material). This is followed by processing technology which, in principle, represents the drawing up of technical processes and work instructions. Feedback serves for reporting on the status of work order or, in this case, for reporting on the status of tool, however, it is important to emphasise that technical process envisages managing of data on different levels which includes also the production of electrodes for a particular semi-manufactured product and cooperation (Figure 44).

Figure 44 - Technical process

- BOR (Book Of Requirements) - BOM (Bill Of Materials)

4.1.1.3 Presentation of pilot solutions A developing software feature enables large and small-sized businesses to take part in computing in the clouds. Services in the clouds provide database connection and are a part of the IT infrastructure, enabling companies and organisations to connect or integrate an amount of data

82

on the location in the cloud. All the aforementioned allows the Automotive Cluster of Slovenia to offer a business model which provides a variety of open source solutions (orders, call-offs, plans, preview of 3D models, etc.) on the market. These open source services shall allow an integration of businesses that are different in manpower and industrial branches in the supply chain. Advantage of business model provides various benefits such as: • new business opportunities; • connections with partners who do not have internal IT platforms (SMEs & smaller); • connections with partners who have different and/or unrelated IT platforms (SMEs &

smaller); • better communication between partners who have different SW or without it (for example

CAD); • safe work on common documents that are on the same platform; • time savings in product development (henceforth referred to as PD) phase; • reduce total cost of PD phase; From technical point of view the solution provides a new mental dimension which shall be presented hereafter. First of all, a joint ACS server with different services installed (orders, call-offs, plans, preview of 3D models, etc.) needs to be set up. Each company shall be able to integrate these services into their business processes. However, the users shall be divided into two groups: • legacy system users • non-legacy system users Legacy system users are those users who use one of the legacy systems (SAP, Navision, Baan, etc.). Nonetheless, there are also non-legacy system users, who fail to have the aforementioned ERP systems yet use only the Internet Explorer. Due to the said reason the system of integration of individual users shall be different.

4.1.1.3.1 Process of integration As mentioned before, the users shall be divided into the legacy system users and non-legacy users. The characteristic of the legacy system users is that both parties send information to the ACS server providing the COIN (Enterprise COllaboration & INteroperability) services. This is followed by the alignment of information on the ACS server with the help of COIN service. When information is aligned, the information on agreement is created. This is followed by a feedback indicating the confirmation of the already agreed data.

83

Figure 45 - Integration process for the legacy system users

It is characteristic for the non-legacy users that one of the clients is not using the legacy system but uses the Internet Explorer for the purposes of alignment. In such a case only one client sends information to the ACS server containing the COIN services. The information on the ACS server uses COIN services and offers them for the preview also to the non-legacy system user. This is followed by alignment of information on the ACS server as is the case with the legacy system users. Mutual alignment or coordination between the clients ends when the agreement is concluded. At the end feedback information is provided indicating a confirmation of already aligned data.

Figure 46 - Integration process for the non-legacy system users

4.1.1.4 Conclusion The companies in the Slovenian automotive industry establish that cloud computing may follow the technological trend well, while it is necessary that the said technology is integrated into business processes as swiftly as possible, with the purpose of maintaining the companies

84

competitive advantage with their apposite vision of development and business ethics of global operations. The COIN system provided represents a group of applications that reduces total costs of ownership and may assist companies in the automotive industry of Slovenia to adapt more rapidly to the more and more demanding business environment and global markets. There are also some disadvantages such as data safety in the clouds, as well as control and reliability of services offered. References [1] Abele, E., Elzenheimer, J., Liebeck, T., Meyer, T. (2006), Reconfigurable Manufacturing Systems and

Transformable Factories – Globalization and Decentralization of Manufacturing, 1st edition. Springer. pp. 4–5.

[2] Cagliano R., Caniato, F., Spina G.(2004), Lean, agile and traditional supply: how do they impact manufacturing performance? Journal of Purchasing & Supply Management, 10 (4–5), 151–164.

[3] Frohlich M.T., Westbrook R. (2000), Arcs of integration: an international study of supply chain strategies, Journal of Operations Management, 19 (2), 185–200.

[4] Humphreys, P.K., Lai, M.K., Sculli, D. (2001), An Inter-Organizational Information System for Supply Chain Management, International Journal of Production Economics, 70, 245–255.

[5] Panetto H., Arturo Molina A.(2008), Enterprise integration and interoperability in manufacturing systems: Trends and issues, Computers in Industry, 59 , 641–646.

[6] Rosenzweig E.D., Roth A.V., Dean J.W. (2003), The influence of an integration strategy on competitive capabilities and business performance: an exploratory study of consumer products manufacturers, Journal of Operations Management, 21 (4), 437–456.

[7] Teruaki, I., Mohd, R.S. (2000), A Blackboard-Based Negotiation for Collaborative Supply Chain System, Journal of Materials Processing Technology, 107, 398– 403.

[8] Weichhart G., Feiner T., Stary C. (2009), Implementing organisational interoperability—The SUddEN approach, Computers in Industry, 61, 152–160.

85

4.1.2 Production Planning and Knowledge Interoperability Services in the Lazio Aerospace Cluster

Vittorio Cannas1, Gerardo Lancia1 1 Filas SpA – Aerospace Technological District,

Piazza della Liberà 20, Rome, 00192, Italy, +39 06 32885257, {cannas,lancia}@filas.it

Abstract This paper reports the work done in the adoption of innovative Production Planning and Knowledge Interoperability Services in the end-user business processes. With knowledge interoperability it is here intended to exploit at best, by using semantics-based technologies, the knowledge of enterprises cooperating in a cluster, leveraging on their complementarities, and avoiding unnecessary overlapping. With Production Planning it is here addressed the enhancement of collaboration among cluster partners in the creation of production plans and complementary activities. The work is applied to a test case in the aerospace technological district located in the Lazio region of Italy. The test case has been extensively documented with a particular focus on the description of scenario challenges and on the expected benefits coming from the adoption of COIN services. Results and business benefits are presented. Keywords: Enterprise Interoperability, Enterprise Collaboration, Collaborative Production Planning, Knowledge Interoperability, Aerospace Domain

4.1.2.1 Introduction One of the trends in the global market is the increasing cooperation among enterprises. Organisations have to flexibly and continuously react to (imminent) changes in markets and trading partners. Large companies but also small and medium enterprises (SMEs) have to cope with internal changes from both a technical (e.g. new information, communication, software and hardware technologies) and an organisational point of view (e.g. merging, re-organisation, virtual organisations, etc.). In this context, the competitiveness of an enterprise depends not only on its internal performance to produce products and services but also on its ability to seamlessly collaborate and interoperate with other enterprises. The past decade has seen significant advances in enterprise collaboration and interoperability areas. Numerous paradigms, architectures (e.g., Service Oriented Architecture frameworks [1]), enterprise modelling and process languages to describe business processes (e.g., BPMN [2]) and their executions (e.g., BPEL [3]) have arisen. However, more than a decade after, interoperability and collaboration issues are still concrete problems for enterprises, causing indirect costs due to lost business during down time, lost productivity of staff, inability to build products, and loss of company image, and so on.12 In this paper, production planning and knowledge interoperability services from the COIN IP project perspective will be described. Services will be presented in the context of a complex environment like the Technological Aerospace District in the Lazio Region.

4.1.2.2 Business Case Description: The Filas test case The Technological Aerospace District (DTA) located in the Lazio Region of Italy sees a major concentration of large, medium and small enterprises involved in the aerospace supply chain. This position has been strengthened during the last two decades by specific government commitment at national, regional and local levels. The large industrial companies and smaller enterprises operating in the Region are characterised by strong technical capabilities, high quality productivity and broad diversification in national and international projects. Filas, the financial investment agency of the Lazio Region, which coordinates and promotes the activities of the

12 http://www.smartgridnews.com/pdf/SGNInteroperabilityWhitePaperJune2007.pdf

86

technological aerospace district, focuses on the management of tools related to innovation, acting as the regional instrument to support the socio-economic development and full employment of Lazio. The technological aerospace district shows a five Billion Euro turnover with 30,000 employees, 250 prominent sized companies concentrated in different areas of industrial expertise, 10 Research Centres, 5 Technological Parks, 5 Universities, 4 Engineering Faculties, 3.000 professors, researchers and specialists involved in aerospace R&D activities, incubators and support services for technology transfer and start-up creation. Test cases are structured in the aerospace domain and aim at demonstrating end-users benefits deriving from the adoption of innovative collaborative and interoperability COIN services. Here two test cases are described: the first has to do with collaborative production planning (c-PP) of satellite antennas and the second with knowledge interoperability applied to competence and skill management mapping of DTA’s stakeholders. The test case scenario of c-PP sees the involvement of a DTA enterprise which main business is to produce satellite antennas for high-speed trains for a major European railways company. Specifically, such SME operates in a supply chain network and manages a network of worldwide suppliers producing antennas components. Such SME assembles tests and ships antennas to a final client. The SME has the need to improve its production planning process in order to increase the production density and make more efficient and effective all business processes, for example in negotiating orders terms, in selecting antenna components suppliers, in planning the whole production process, in producing and shipping final products. The SME business needs have been identified by depicting as-is and to-be scenarios and by listing performance indicators that elicit real business benefits resulting from the use of innovative COIN services. In particular, COIN innovative services allow the selected SME to have effective collaborative tools that overcome traditional inefficient management of supply chain networks. Generally speaking, SMEs in the DTA do not make use of innovative collaborative tools to support their business processes and therefore, the set-up of such test case could eventually represent a best-practice in the aerospace domain. The test case on knowledge interoperability has to do with competences management of the enterprises in the DTA. In particular, Filas manages a DTA web portal 13 where actors (enterprises/research organizations), working in the aerospace sector, can register themselves, declaring their main fields of interest (i.e., products, components, technologies). Currently, this activity is performed manually and the accuracy of the provided information is poor and scarcely usable for inferring information on the value of the DTA as whole. In fact, the objective of the web portal is to create a large community of DTA actors wishing to display their business activities and technological competencies in order to establish business synergies. To this end, the introduction of knowledge interoperability services will aim to ease the whole company registration process (i.e., enterprise profiling) in the DTA web portal. By doing that, Filas could significantly increase the quantity and quality of information inserted by enterprises and research organizations into the web portal. This would allow to better map actors needs in order to address specific measures, policies and incentives to support DTA actors’ business development. This would in turn increase competitiveness and create new business opportunities for DTA cluster actors.

4.1.2.3 COIN solutions

4.1.2.3.1 Knowledge Interoperability pilot

13 Aerospace Technological District. WWW page. http://www.lazio-aerospazio.it

87

Knowledge Interoperability is here intended as the way to exploit at best the knowledge of the enterprises cooperating in a cluster (e.g., Collaborative Network), leveraging on their complementarities, and avoiding unnecessary overlapping. To this end, a fundamental aspect is the representation of the enterprises’ knowledge. Many existing proposals for enterprise modeling, such as Zachman [4], CIMOSA [5], GERAM [6] are in general rather complex, trying to capture within a single framework all the different aspects and dimensions that characterise an enterprise. We take advantage of the POP* [8] framework focused on Products, Organization, Processes, and we concentrate on Organization, and in particular on the production capacity of an enterprise, synthesized by the competencies and skills it is able to deploy and put at work to produce value. Evaluation of COIN EI services has been performed by using the COIN service platform equipped with the following innovative EI services: i) Enterprise Semantic Profiling service (ESPS), ii) Enterprise Semantic Matchmaking service (ESMS) iii) Collaborative Network Semantic Assessment Service (CNSA), iv) Semantic Assessment of Company Entrance in the Collaborative Network (SACE). ESPS service is for representing the knowledge asset of the single enterprises in the cluster. For a given enterprise, a semantic profile is built in order to represent the competences of the enterprise at best. To build an enterprise semantic profile, the service uses knowledge extraction techniques applied to a corpus of documents specific of the given enterprise, and semantics-based matching techniques to suggest the feature vector. A human validation of the feature vector will allow the desired enterprise semantic profile to be defined. ESMS service: enterprise semantic profiles are used as input by a semantic matchmaking service that allows their comparison in order to identify semantic similarities and coverage of two profiles. The above services will be at the basis of the CNSA and SACE services providing: • Semantic assessment of the knowledge asset of the whole enterprise cluster, in order to

detect: (i) the Competences and Skills (CS) requested by the cluster, and covered by the member enterprises; (ii) the CS requested by the network, but not currently covered by any enterprise in the network (CS gap); (iii) the CS strongly and poorly owned by the network.

• Semantic assessment of company entrance in the cluster, in order to evaluate the impact on the cluster due to the entrance of an enterprise.

By doing this, transfer of new competencies gained by a Virtual Organization formed by enterprises in the cluster to the cluster itself is then performed. Figure 47 shows a schematic view of the interactions in the Knowledge Interoperability pilot.

����������

!�� ��������

��������������������������������

Figure 47 - Knowledge Interoperability Pilot

88

4.1.2.3.2 Collaborative production planning pilot This pilot has been developed in the context of the collaborative Production Planning (c-PP) paradigm of the COIN project. Services tested and evaluated are: i) Collaborative Production Planning Portal Service (C3P); ii) Production Planning Service (PPS); iii) Collaborative Quality Management Service (cQMS). These services are cross-used in several satellite antennas production planning business processes. The major collaboration targets are the agreement on a collaborative production plan, the plan update, and the support on the exception handling which are very often raised in the real environment. To our knowledge, such support it is not well structured in similar existing systems and there are several research directions aiming to create collaboration systems among value-chain actors [7] [8]. C3P service is used to support collaboration among different organizations that have different production planning systems. The major collaboration targets are the agreement on a collaborative production plan, the plan update, and the support on the exception handling which are very often raised in the real environment. PPS service is used to provide a production planning system according to the software as a service (SaaS) paradigm, able to unburden SMEs of the workload related to software installation, maintenance and update. PPS represents the manager of production plan information of different actors and it has been integrated into C3P services. cQMS enables enterprises in the cluster to investigate inter-organisational interdependencies based on their competence profile descriptions stored in the C3P. This service helps enterprises to prevent production planning errors. Figure 48 shows a schematic view of the interactions in the c-PP pilot.

���������������� ���������� �

!������������ !����������������� ����

�� ������������������ ��������������

Figure 48 - Collaborative Production Planning Pilot

4.1.2.4 Results and Business Benefits Final evaluation of COIN innovative services have highlighted that the adoption of EC&EI COIN services can increase business benefits through adoption of the SaaS paradigm and without increasing IT systems costs. Key business indicators for demonstrator’s activities have been identified. Specifically, regarding the indicators of EC pilot, the process of gathering requirements implies a faster collection of several typology of information in the whole supply chain network. By using C3P and PPS, all actors (client, supplier and sub-suppliers) share all project information and communicate in a faster and simpler fashion. Also, the process of assessing resources through a proper planning of work activities implies a cost saving both in human resources and in production processes. At present, enterprises involved in the pilot do not

89

use any collaborative tool and they complain a poor performance of their production planning process. Concerning EI pilot, the indicators are focused on governing the Filas aerospace cluster performance. The process of governing cluster rules makes the cluster information more reliable and easily accessible as it conforms to certain common standards for all cluster actors. COIN services allow a better performance control by increasing reliability of cluster competences information. Govern cluster information means improve its dissemination to the whole cluster. The possibility to speed up information collection and cluster competences mapping, increases the frequency of information dissemination to the whole cluster network. In fact, communicate the value added coming from a new company entrance in the cluster is very important. This also implies that the cluster itself is able to be continuously updated allowing a better response to business opportunities. Presently, competence and skill management mapping in the DTA is done without any use of knowledge interoperability services and DTA cluster recognises the poor of the present solution.

4.1.2.5 Conclusions The presented services are the final version of COIN collaborative platform prototype. Some lessons learnt can be depicted from analysis of the addressed scenario. First of all the aerospace domain has been recognised as a suitable case for Production Planning and Knowledge Interoperability services that can be very effective in this sector. In particular collaboration in production planning is strongly required by SMEs mainly for the fast recovery in case of failure, production delays and in production rescheduling due to customer support (maintenance). In these tasks, SMEs are able to significantly enhance efficiency and effectiveness of processes that is reflected in a reduction of planning time and faster answers to customers needs. As to Knowledge Interoperability services, the analysis of the Filas scenario gives positives expectations with respect to their application and effectiveness. In fact, a very large district, like the DTA, in a very complex and heterogeneous domain, like the aerospace one, needs some instruments for maintaining an up to date map of the knowledge asset of the involved enterprises, in order to be able to understand how the needs of the cluster and the capabilities of the enterprises in the cluster itself evolve with respect to those needs. References [1] Erl T.; Service-Oriented Architecture: Concepts, Technology, and Design. Pearson Education Ed (2005). [2] OMG: Business Process Model and Notation. Version 2.0, August 2009,

http://www.omg.org/spec/BPMN/2.0. [3] Business Process Execution Language. See: http://www.oasis-open.org/specs/#wsbpelv2.0 [4] "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems Journal, vol. 26,

no. 3, 1987. IBM Publication G321-5298. [5] CIMOSA - Open System Architecture for CIM, Technical Baseline; Version 3.2 CIMOSA Association,

private publication (March 1996). [6] Williams T. J. PERA and GERAM - Enterprise Reference Architectures in Enterprise Integration.

Proceedings of the IFIP TC5 WG5.3/5.7 Third International Working Conference on the Design of Information Infrastructure Systems for Manufacturing II table of contents Vol. 144 archive, pp. 3 - 30 (1998)

[7] Quan L., Hui M. - A Collaborative Production Planning Model for Multi-Agent Based Supply Chain - 2008 International Conference on Computer Science and Software Engineering

[8] Hyun Joon S. – Abstract - Collaborative production planning in a supply-chain network with partial information sharing – Int J Adv Manuf Technol (2007) 34:981-987 DOI 10,1007/s00170-006-0664-6 (C) Sringer-Verlag London Limited

90

4.1.3 An EI/EC Pilot in a Railways Supply Chain (KTU) Valentinas Kiauleikis, Nerijus Morkevičius, Mindaugas Kiauleikis 1

1 Kaunas University of Technology, Computer Engineering Department,

Studentu st. 50, LT-58631 Kaunas, Lithuania

Abstract Pre-manufacturing business processes, i.e. customer order analysis and evaluation, ordering from manufacturing partners, and agreements signing in enterprise producing railway parts, are analyzed in this paper. Main purpose of this research was to analyze possibilities of putting into practice EI/EC services on COIN platform. Three appropriate use cases were extracted and gathered to show how business scenarios change when modern EC/EI services replace traditional communication means and what benefits are expected in such cases. Specifics of currently used Enterprise Resource Planning (ERP) systems in Lithuania and requirements to develop and implement services on COIN platform are introduced. Possibilities to implement EI/EC services and potential benefits for other industrial areas (food industry) are also discussed. Finally lessons learnt from taking part in consortium to research and develop COIN and appropriate services are presented at the end of the paper. Keywords: Enterprise Interoperability services, Enterprise Collaboration services, Supply Chain, Ordering-invoicing processes

4.1.3.1 Introduction Current state of Lithuanian SMEs could be defined as: • transitional to market intercourse with “…revolutionary changes in thinking, practices,

products, processes or organizations...“ [2], maintaining by young generation of businessmen which has grown after Lithuania went out from Soviet Union, as well as stimulating by best practices of western enterprises which became visible and available after Lithuania was join with EU;

• active implementing of newest technologies, including ICT, to keep European standards and qualities and to withstand competition with advanced countries Lithuanian products and services.

ICT-based technologies, ERP systems, accounting systems in local networks of enterprises entrenched in Lithuania until 2000. Currently the quick Internet covers all Lithuania country including rural areas; internet-based communication means (e-mail, Skype) replace traditional inter enterprise communication means (mail, phone). EI/EC e-services [1], [3], [4] could be welcomed, but such services are unknown and incomprehensible for Lithuanian businessmen. These services could be introduced starting from the most advanced enterprises, and the most helpful cases. Considering before-referred state and tendencies an EI/EC Pilot in a Railways Supply Chain was chosen. It should be noted that any other industrial area (food, garment, furniture, building trade, etc.) could be chosen for Pilot; this choice was determined by high computerization level of VAE Legetecha, variety business partners as well as close relationship with KTU (representatives of KTU at COIN consortium are Legetecha‘s ERP system developers and supporters). Use cases for Legetecha‘s Pilot were constructed and developed thus they could be applied in any other industrial areas without crucial reconstruction. This is discussed in the last section of this paper.

4.1.3.2 JSC VAE Legetecha as the EC/EI Pilot VAE Legetecha is a manufacturer of railway parts such as turnouts, base plates, crossings, etc. [http://www.voestalpine.com/vaelegetecha/lt.html]. These railway parts are complex products, have large amount of parts and are manufactured in series of stages. Some parts are bought from suppliers, some parts are manufactured by VAE Legetecha and some are sent out to be modified by other enterprises. Fragment of manufacturing process of VAE Legetecha is shown in Fig. 49

91

To create the EI/EC Pilot preproduction stage in Legetecha was analyzed, i.e. order receiving, bill of materials and cost estimate making, orders to suppliers preparing as well as negotiation process and preparation of agreements between customer and suppliers. Workflows of these processes contains operations which can be replaced or reconstructed by EI/EC services, thus preproduction processes can be improved in respect of time, quality and employment criteria. A few use cases (UC) for testing were proposed and three of them which use essential COIN services were developed: • Order (Legetecha acts as supplier) analysis and evaluation • Legetecha (acts as customer) orders from manufacturing partners • Order preparation and agreement signing (Legetecha acts as customer and supplier)

Raw material suppliers

Service suppliers

Buyer of semimanufactures

Buyers of final product

Railway parts manufacturer JSC VAE Legetecha

Manufacturing of parts

Assembling of semimanufactures

Assembling of final products

Figure 49 - Manufacturing process of “VAE Legetecha” (fragment)

COIN service called Collaborative Production Planning Portal (C3P) was chosen as central, “integrating” entity in Pilot solution design. C3P service provides a platform where manufacturing partners can easily join collaborative manufacturing process, invite other partners and cooperate on the preparation of Production Plan, collaborate on ordering, manufacturing and shipping exceptions and other issues common in manufacturing process. In Pilot implementation C3P service is central point where all manufacturing partners meet, plan their work and collaborate. All exchanges of business documents (production plans, orders, and bills of materials) between ERP systems of supply chain partners are done through C3P services.

4.1.3.3 Use cases: gaps and services 3.1 Order analysis and evaluation. This use case starts when Legetecha receives order from customer to produce final product. Legetecha’s sales manager transmits the order to internal offices (design, production, financial, general manager) for initial estimation. If order was preliminary accepted by these offices, Bill of Materials (BOM) and Cost Estimate is made and negotiation process between supplier and customer starts. Use case ends when order is refined and accepted as well as loaded into Legetecha’s ERP system. List of semimanufactures and appropriate Technical Requirements (TR) for semimanufactures are prepared and loaded into Legetecha’s ERP

92

Nowadays there is no electronic exchange of order document between customer’s and Legetecha’s ERPs. Legetecha’s staff must manually enter it to their ERP system for evaluation and planning purposes. From speed, efficiency and error rate point of view it is useful to use COIN collaboration services to transform electronic order document from internal C3P format (Universal Business Language (UBL) order format) into format supported by Legetecha’s legacy ERP system and load this transformed document on demand to ERP system. Legetecha’s ERP system is custom application based on traditional client/server architecture using Borland Interbase Database Management System (DBMS). Preliminary orders from customers in this system are represented by records in some relational tables. COIN service should be able to load data from UBL Order document to corresponding records in relational database. The ERP system is available for testing purposes, so COIN service can directly access database tables using standard interfaces (JDBC, ODBC or BDE). Implementation of this services and new model of activities into order analysis and evaluation processes could bring a growth of productivity in this business stage at about 30%. 3.2 Legetecha orders from manufacturing partners. This use case starts when Legetecha’s negotiation with customer is finished and all documents, i. e., BOM, list of semimanufactures and TR for them, are prepared to start looking for suppliers of semimanufactures. Legetecha starts with searching for potential suppliers, puts forward a proposal to potential suppliers and considers received answers. Potential suppliers of semimanufactures analyze possibilities to pursue the order confining all required conditions (TR, financial limitation) and to give one’s okay as preliminary agreement with customer what really is the postcondition of this UC. Activities to search manufacturing partners and to prepare to negotiate contracts using COIN services could reduce time of this stage from two weeks to 7 days, i.e. about 40%. Two requirements for new services should be met in this use case: • Requirement 1. It should be possible to transform electronic order document from internal

C3P format (UBL order format) into formats supported by suppliers’ legacy ERP systems and load this transformed document to ERP systems on demand. Two legacy ERP systems used by Legetecha’s manufacturing partners were chosen. These ERP systems are “Rivilė” and “Centas”, widely used by many Lithuanian SMEs. “Rivilė” is commercial application developed in Lithuania using MS Visual FoxPro. For data storage it uses standard FoxPro DBF files. This application also has special interface for import and export of business documents and order is one of supported documents. Format used for import/export is similar to XML, but does not follow all requirements of XML specification. This interface could be used to import order documents from COIN C3P service. “Rivilė” is available for testing purposes as demo application with some restriction on functionality. “Centas” is commercial ERP application developed Lithuania. For data storage it can use standard Paradox DB files or work in client/server configuration using Advantage Database Server DBMS. Most Legetecha’s partners are still using cheaper configuration using Paradox DB. Preliminary orders from customers in this system are stored as records in several relational tables. COIN service should be able to load data from UBL Order document to corresponding records in database. “Centas” is available as demo version with limited functionality for testing purposes. COIN service could directly access database tables using standard interfaces (ODBC or BDE)

• Requirement 2. COIN service should provide interface capable to convert production plan and BOM document created in Legetecha’s ERP system to format compatible with C3P service’s BOM format, and means for loading this document into C3P service on demand. Legetecha is using its legacy ERP system to perform Material Requirements Planning (MRP) and to find out time and quantity of required semimanufactures for final product. This information would be useful for BOM preparation in COIN C3P service. Time and error rate would be reduced if special interface capable of converting production plan information residing in Legetecha’s ERP system to one compatible with C3P service is provided. BOM

93

document loading to C3P service would be also very useful. All related information in Legetecha’s ERP system is stored as relational tables’ records, so COIN service can directly access database tables using standard interfaces (JDBC, ODBC or BDE).

3.3 Order preparation and agreement signing. Preconditions of this UC are: BOM’s and Cost Estimate of final product, list of semimanufactures suppliers and preliminary agreements with them are prepared and loaded into ERP of Legetecha. Until the start of manufacturing processes, agreements between Legetecha and semimanufactures suppliers have to be signed by their general managers. Preparing of final agreements, introducing it to general managers of all sides participating in this business, and signing these agreements complete this UC and UC‘s dedicated to pre-manufacturing stage scenarios at all. The core of this UC is collaboration between Legetecha’s purchase/sales managers and corresponding parties of customer and semimanufactures suppliers. They collectively discuss orders and prepare corresponding sell/purchase agreements’ projects. General Managers of all participating sides approves prepared agreements and sign them. If required, other working groups, such as production or financial groups may take part in this UC. In this process many discussion and document exchange sessions between management and technical working groups may occur. These tasks are supported by COIN collaboration platform, using document management system for document exchange and baseline collaboration services for instant messaging, voice conversation, etc. Services to transform electronic order document from internal C3P format into formats supported by suppliers’ legacy ERP systems and changes between Legetecha and partners ERP should be repeatedly used. Expected benefits from implementation of final order preparation and agreement signing services are time reduction of this business stage to one week, i. e. about 42%.

4.1.3.4 Benefits for majority SMEs Gathered use cases are typical in preproduction stages of majority industrial enterprises which produce and sell any products in the local and international market. Generally objective benefits can be evaluated only for particular cases. Looking for cases with valid benefit of EI/EC services, we performed exploration of Lithuanian SMEs focusing on ones where replacement of traditional communication means by EI/EC services could bring elimination of redundant staff, equipment like office computers, phones, production costs as well as production and services quality betterment, time economizing etc. Results will be presented in the wider reports or research papers. Only some aspects which were observed looking for possibilities to attract an attention of businessmen to ITC novelties for SMEs are mentioned here. EI/EC services apparently demonstrate their benefits in food industry where hundreds of orders, invoices and claims are “running” between every day food (meet, milk, bread) producers and shops. Interoperability services could eliminate big part of staff engaged in ordering-invoicing-claiming operations with their phones, computers and workplaces thus reducing mistakes and total business costs. Benefits from implementation of interoperability services could be calculated using simple arithmetic. Collaboration services can replace traditional communication means and provides some benefits, main of which is time saving as well as respectively money saving. Businessmen present number of facts from their business experience where delays caused by bad communication bring big loss. That is why implementation of collaboration services is useful and important for majority of SMEs. Usefulness of collaboration services and loss warning can be established or determined by modeling where output parameters are possible losses (decision making and action delay, profit, potential orders, entering a tender, and so on) as well as input parameters (for example emerged by season or fashion demand of some goods, growing of competition, prognosis of cost dynamics, information delay and so on). Analytical model and modeling results as well as methodology to clarify possible benefit of EI/EC services for SMEs will be presented in scientific conferences and papers.

94

4.1.3.5 Lessons learnt and conclusions A number of meetings, workshops and discussions with businessmen to analyze current problems on improvement their business activities using modern ICT helped us to understand and gather needful e-services which should be developed looking at the next five-seven years. The best practices of this will be useful in future working on new EC/EI scenarios for new industrial and social areas on the COIN base. COIN strategy and technological basis as well as participation in creation and testing of modern e-services increased skills and provided knowledge which will be deliver to students and used in the new projects and research works. Working together with skilled partners of FP7 integrated project COIN consortium gave us a lot of lessons how to solve collectively matured problems. This takes authors on trust to integrate into new projects providing new skills and new ideas. References [1] Duin Heiko, Hofbauer Peter, Karacan Ömer, Markl Erich, Withalm Josef, Wölfel Walter, Zand Darius,

Collaborative Demand Capacity Planning, ICE2009 - Proceedings of the 15th International Conference on Concurrent Enterprising. Collaborative Innovation: Emerging Technologies, Environments and Communities. Leiden, The Netherlands, 22-24 June 2009.

[2] European Commission CORDIS, Future Internet Enterprise Systems (FInES) Research Roadmap, June 2010 [http://cordis.europa.eu/fp7/ict/enet/documents/fines-researchroadmap-final-report.pdf].

[3] Fischer Klaus and Zinnikus Ingo, Agent-Supported Collaboration and Interoperability for Networked Enterprises, Proceedings of the 4th ATOP Workshop at the 9th International Conference on Autonomous Agents and Multiagent Systems, May 2010.

[4] Karvonen Iris, Conte Marco, Supporting and facilitating the Enterprise Collaboration (EC) & Enterprise Interoperability (EI) solution take-up, ICE 2010 16th International Conference on Concurrent Enterprising – Lugano, June 2010.

95

4.1.4 An EI/EC Pilot in a Construction Supply Chain (UPB) Aurelian Mihai Stanescu, Mihnea Alexandru Moisescu, Ioan Stefan Sacala1

1 University “Politehnica” of Bucharest, Faculty of Automatic Control and Computers

313 Splaiul Independentei, Bucharest, Romania, +40.21.4029167, ams@cpru.pub.ro mamihnea@gmail.com, sacalaioan@yahoo.com

Abstract The paper is concerned with reporting the progress of the work done in the area of innovating services for Collaboration and Interoperability within the Romanian Civil Engineering test case. The as-is situation in Civil Engineering is presented with regard to the COIN objectives. The to-be situation, with regard to the implemented COIN solution, is then addressed. The main focus of the to-be scenario is the two use cases: Use Case 1 - Order construction materials from suppliers and Use Case 2 - Collaborative project planning and change management. Identified business benefits are presented with regard to the proposed Value Reference Model within the COIN project. Keywords: Enterprise Interoperability, Enterprise Collaboration, Civil Engineering Domain.

4.1.4.1 Short Description of Civil Engineering Case, As-is situation One of Romania’s most important development directions is concerned with the development of infrastructure facilities including highways, roads and bridges. Complementary to this direction are major civil engineering private investments in the area of housing projects. There has been an important increase in the demand for ICT services to support project collaboration and management within the project consortium. In this context, COIN collaboration and interoperability services along with the Generic Service Platform will provide a solid development pillar for sustaining the development of comprehensive ICT support facilities for the civil engineering domain development. The “as-is” Romanian business case for civil engineering includes major government founded infrastructure projects and a lack of ICT support to facilitate the implementation. The “as-is” Romanian business case for civil engineering includes major public founded infrastructure projects and a gap in ICT support to facilitate the implementation. The civil engineering sector is characterized by a necessity of intercompany collaboration. Such cases can include: • Consortiums of project development and management oriented companies formed to

undertake major construction projects. • Consortiums of companies which undertake subcontracted activities form large infrastructure

projects. • Civil engineering project planning Special factors which influence the civil engineering sector include: • A highly multinational spectrum of companies in the area of consulting, project planning and

management. • Local companies involved in project execution tasks. • Highly regulated policies for public founded projects.

4.1.4.2 Objectives and Expectations from COIN The “to-be” scenario will include the implementation of collaboration and interoperability services providing the necessary ICT support. The COIN innovative services for Civil Engineering will have an impact in the following areas:

96

• facilitate the integration of Romanian SMEs within the European common Business Ecosystem

• facilitate the access to Romanian and EU business opportunities by providing Enterprise Collaboration tools

• promote the development of mixed European (including Romanian) SME networks by providing Enterprise Collaboration tools

• optimize “border-less” mixed SME networks by offering the access to Enterprise Interoperability services

• experiment and assess the project results into a developing Business Ecosystem using real industrial and SME networks experiences.

University “Politehnica” of Bucharest (UPB) facilitates the demonstration of COIN innovative services impact on Romanian Civil Engineering with the help of Digital Bit, a Romanian SME partner in ARCHES Living Lab. Digital Bit is the ITC service provider for Astaldi Romania, member of Astaldi Spa, a major contractor for the Romanian civil engineering infrastructure projects. To demonstrate the COIN innovative service impact, four business use cases have been selected within the civil engineering projects: UC1: Order construction materials from suppliers, UC2: Collaborative project planning and change management, UC3: Construction project monitoring, UC4: Construction Planning for Civil Engineering. The first two use cases will be discussed in this paper.

Figure 50 - University “Politehnica” of Bucharest COIN implementation strategy

4.1.4.3 COIN solutions identified and used In this section two use cases will be discussed: Use Case 1 - Order construction materials from suppliers and Use Case 2 - Collaborative project planning and change management Use Case 1 - The use case starts when Astaldi opens a new construction site. In this context, in order to acquire new materials, there is a necessity to buy new products. In order to select the best supplier, the appointed project manager selects from 2 collaborative services the needed materials according to the suppliers’ description and competences / ontology for profiling and matchmaking, using collaborative service. The acquisition department and the suppliers work in

97

a safe and secure environment, using Trusted Information Sharing Service. The use case ends with the selection of the best offer from the suppliers.

Figure 51 - The process of ordering materials from suppliers

The innovative services selected for ordering the construction materials from the suppliers are: Enterprise Collaboration Services: Semantic Cluster Management Service (SCMS), used in choosing the materials from a list of suppliers; Online Meeting Service (OM) and Trusted Information Sharing (TIS), used for contract negotiation in a secure environment Enterprise Interoperability Services: Enterprise Semantic Matchmaking Service (ESMS) used to facilitate the search for the right supplier and Enterprise Semantic Profiling Service (ESPS) used for defining the profiles of suppliers. Use Case 2 - The use case starts with the necessity to collaborate on the project planning phase. After developing the project plan in a collaborative way, the project manager and the company management discuss all the problems and the risks using collaborative services. After all the changes have been done in the project plan, the plan is finalized.

Figure 52 - The process of collaborative project planning and change management

The services selected for collaborative project planning and change management are: Enterprise Collaboration Services: Collaborative for Project Management (Coll4PM) enable the project manager and the enterprise management to realize the project plan in a collaborative manner.

98

Coll4PM + new service will enable for the project manager to: monitor the entire evolution of the project in real time, implicate the entire management team in the development of the plan, monitor the entire evolution of the project, modify the project plan in real time and notify the persons involved.

4.1.4.4 Measured Business Benefits In order to measure the business benefits a series of Key Process Indicators have been identified for each use case, using the Value Reference Model as developed within COIN project: Use Case 1 includes processes in the area of “Planning and Supply Chain” regarding the assessment of resources. The identified indicators are used to assess the impact of requirements. The measured indicators refer to the elapsed time for the cycle of a given process, cost for a given process and frequency of planning analysis as a measure for adaptability. Use Case 2 includes processes in the area of “Create Plan, Supply Chain”. The identified indicators are used to assess the course of action regarding supply chain planning. The measured indicators refer to the value of assets dedicated to a specific process, total cost and elapsed time of a specific process. Several business benefits have been identified with reference to the COIN results: Business Benefit #1 – Reduce time for ordering products from suppliers There is no electronic platform in ordering the construction materials from the suppliers. All the materials are ordered by phone or by mail from a list of suppliers and all the offers are received by fax. The communication is slow and the time in receiving the materials is very long. Therefore, the need of COIN services is more than necessary to facilitate the communication. Business Benefit #2 – Improve efficiency of co-operation process for project planning There is no electronic platform in creating the project plan in a collaborative way and the status of the project cannot be monitored. If any change appears, the project manager acts instantly, based on his experience, with no pre-planned steps. Business Benefit #3 – Reduce time for project monitoring and reporting The project manager monitors the execution of project plan by on-sight inspection and collaborative services. Business Benefit #4 – Improve efficiency of construction planning The project manager uses collaborative services to develop the construction plan and to establish or modify deadlines.

4.1.4.5 Conclusions The presented use cases and services are currently being implemented in order to experiment and demonstrate the COIN system and EI/EC new developed innovative services. The implementation of COIN services has been planned according to the developed COIN methodology for enterprise collaboration and interoperability. The conclusions identified during this implementation stage prove the efficiency of the COIN collaborative and interoperability platform in solving the identified problems within the civil engineering sector.

References [1] Stanescu, A.M.; Ionescu, L.M.; Georgescu, V.; Badea, L.; Moisescu, M.A.; Sacala. I.S.; (2010) Toward

Digital Business EcoSystem Analysis In Gunasekaran,A.; Sandhu,M. (Eds): Handbook On Business Information Systems, World Scientific Books, 2010

[2] Stanescu,A.M.; Dumitrache,I.; Pouly, M.; Caramihai,S.I.; Moisescu,M.A; (2007) Towards a General Systems Theory approach to design the future of Concurrent Engineering Science, In Loureiro,G.; Curran,R.; (eds.) Complex Systems Concurrent Engineering Collaboration Technology Innovation and Sustainability, pp 3-10, Springer Verlag 2007

99

4.2 The COIN EI/EC Services in Collaborative Networks Nowadays, it is usual to find business processes and situations in which several parties need to collaborate in order to achieve common objectives. These collaborations require a good level of understanding between different parties, as well as collaborative tools which enable and facilitate communication and interaction in different moments and activities of the business process. One of the objectives in COIN is to enable enterprise collaboration by creating a set of services which will be invoked during the business process execution. These services are mainly focused on solving two problems: improve the understanding between different parties and enabling the direct collaboration working together. Some of the COIN partners defined and implemented four scenarios where enterprise collaboration was a key aspect in order to carry out the activities in business processes: an aeronautics cluster, an ICT cluster, a marine shipping network and a logistics network. In all the mentioned cases, COIN services were applied where collaboration was necessary at different levels. 3D collaborative design, document sharing, communication and collaborative visualization services were used, highlighting the role of the semantic mediation services, improving collaboration in each case. This chapter explains in detail the context and scenarios, and how COIN solved the problems found.

100

4.2.1 An EI/EC Pilot in Andalusia Aeronautics Cluster (ISOIN) Jesús Sánchez, Alberto Olmo1 1Ingeniería y Soluciones Informáticas, ISOIN

Abstract The Andalusian Aeronautic Cluster, one of the Spain's main aerospace production regions, promotes research and innovation processes, supporting enterprise collaboration as a core part of the regional ‘Strategic Plan for the evolution of the Cluster’. The participation in COIN is considered a key step towards the collaborative networked business vision, as an effective instrument to enforce this positive evolution and increase its competitiveness in the global market. Indeed, COIN has shown to be really useful in supporting collaboration and interoperability services for the networked enterprises, designing and developing a pervasive, adaptive Service Platform to host Baseline and Innovative COIN services, and demonstrating and assessing the project results into realistic Industrial Scenarios. The application of the SaaS business model overcomes some of the problems encountered in previous software implementations, helping companies to adapt a new tool, with the necessary reduction in time and costs for the implementation. Keywords: Collaboration, Interoperability, Aeronautics, SaaS.

4.2.1.1 Introduction and background The Andalusian Aeronautic Cluster has a consolidated position in the European aircraft Industry, operating since 1930. Strategic projects strengthen the importance of Andalusia as one of the Spain's main aerospace production regions, such as production of structural components of the A380 program and the final assembly of all-new A400M military aircraft. Besides the final assembly line, the excellence centre in sheet metal production and composites are the key services provided to the aeronautic industry. The Aeronautic Cluster of Andalusia brings together prime contractors of the aeronautic world with about 125 subcontractors and supporting entities (Universities, Research Centres and Regional Government). Most of the companies are located in the provinces of Seville and Cadiz at the South of Spain. The main prime contractors of the cluster are EADS-CASA and AIRBUS, although other prime contractors like BOEING, EUROFIGHTER, EMBRAER or BOMBARDIER are also starting businesses activities with the companies of the cluster [6].

101

Figure 53 - The Andalusian Aeronautic Cluster main competences and entities.

The cluster main goals are to increase and to diversify its activities, attracting a higher number of prime contractor companies or counting with Tier 1 Andalusian companies. Another important objective is increasing the productivity with the coordination of innovation activities among the cluster companies. The advanced Virtual Organization paradigm is pursued, in order to increase process efficiency and collaboration opportunities while fostering innovation in a sustainable structure [9].

4.2.1.2 Collaborative network creation and current management overview The network has established collaboration initiatives since its origin, evolving to the current situation (structured as a Foundation, 2002) promoted by the Regional Development Agency to foster collaboration activities and improve the cluster competitiveness in the European aeronautic market. The regional aeronautical sector has dramatically multiplied the number of companies, personnel and turnover, increasing to 125 companies, 6206 employees 850 million Euros. The entities related to the aeronautic sector currently operate under an Extended Enterprise model, with common supporting ICT infrastructure, derived from an ERP model (SAPECMA and SAPORTAL), together with methodologies, services, and tools for facilitating the delivery of supplied parts [8]. ISOIN promotes research and innovation projects in the cluster, supporting collaboration processes together with Hélice Foundation [5]. Its activities in the context of the regional ‘Strategic Plan for the evolution of the Aeronautic Cluster of Andalusia’ cover: • Definition of the technological capabilities and readiness for the evolution to the advanced

networked structure, as a key factor to achieve world-excellence in the global market. • Definition, launch and execution of research and development activities to foster innovation

in the cluster, • Provision of suitable infrastructure to match collaboration demand and offer, based on

collected competencies and availability.

102

COIN [1] continues currently with this vision, supporting collaboration and interoperability services for the networked enterprises, designing and developing a pervasive, adaptive Service Platform to host Baseline and Innovative COIN services, and demonstrating and assessing the project results into realistic Industrial Scenarios offered by 6 test cases among which it is included the Andalusian Aeronautic Cluster [9] [4].

4.2.1.2.1 COIN Service Test Workflow creation The test phase involved the evaluation of COIN EC/EI innovative services. Four workflows have been created to support this phase. The workflows were called tailored because they are directly derived from scenario uses-cases. ProcessMaker [2], an open source business process management software and workflow software, has been used for developing the four workflows. These workflows derived from real use-cases gave values to several indicators measured concerning business performance. COIN services have been added to the workflows and, this way, the business context has been taken into account into the innovative tools. This has given the possibility to understand the possible business benefits of theirs usage inside the end-users environment, making easier the indicators measuring, once that COIN has been used in the cluster.

Figure 54 – Workflow example

Analysis of requirements and services selection There is a need for the Andalusian Aeronautic Cluster to be open to other prime contractors, other clusters and other business opportunities. It is necessary to have a collaborative product development portal, where products and services of different clusters, companies and prime contractors are offered, in order to find the best partners to develop a product. As a way to increase collaboration inside the cluster, and with other external clusters and prime contractors, a formalised description of companies, competences, services, products and documentation is required. This is necessary to enable exchange of information about products

103

and services, and searching for existing knowledge, in order to enable the possibility of reusing this information for new projects. There is also a need for an online viewer for aeronautic products, open source software or software as a service which can perform an historic version control of aeronautical product 3D designs, enabling on-line annotation, and linking these functionalities with project management tools. In the Aeronautical Cluster of Andalusia, 3D design process is mostly performed with CATIA and ENOVIA, standardized by AIRBUS to the companies in the cluster. This makes it difficult for another company to work without these proprietary formats in the cluster. Aeronautical companies find particularly useful these tools. Interoperability of 3D format and online access to these services are ranked as the most interesting functionalities. Online annotation is also seen as particularly useful for working with a 3D design. It was also suggested by the companies that these services were associated with the tasks of project management. Some of the innovative COIN services studied are: • Semantic Cluster Management System The objectives of the Semantic Cluster Management Service (SCMS), in relation with the Andalusian Aeronautic Cluster, are to provide:

o Have access to the entire set of products, services, companies that exist in the in the cluster, in order to speed up the process of setting up a collaboration with the right partner online and using SaaS, avoiding the installation of proprietary database software.

o Semantic search for products or services that are needed in the product development process, based on the product structure ontology.

o Semantic search for companies that provide the required product / service in a product development process, taking into account related competences.

o Semantic search for products or services that exist in the cluster, giving the possibility to the end user to rank them, and propose new requirements or new business opportunities.

• Collaborative 3D designer Service With Collaborative 3D Designer Services (C3DDS) prototype, the following specifications have been addressed, taking into account the needs of the Andalusian Aeronautic Cluster:

o Online viewing of 3D files, including a wide variety of formats. o Web service architecture, avoiding the need to install software and contributing to

collaborative processes, making use of SaaS advantages. o Online annotations, to enable “virtual meetings” to comment 3D designs

development. o Historic of annotations and author of annotations, to enhance the product

development process. • Interoperability Spaces With Interoperability Spaces problems of interoperability in the negotiation of contracts and problems with different formats in documents is addressed:

o Allowing online negotiation of contracts among companies of the cluster that want to set up a VO.

104

o Speeding up the negotiation process among companies inside and outside of the cluster. This way is possible to reduce the loss of time in such kind of process, which are very common in the cluster.

• Semantic Reconciliation Suite With Semantic Reconciliation Suite (SRS) the aim is to provide functionalities for document format reconciliation, aiming to the cluster requirements in:

o Exchanging orders and invoices in different formats, a very usual problem occurring in the Andalusian Aeronautic Cluster.

o Conciliating different ERP systems used by different companies inside the cluster and allowing the exchange of documents with different formats among them.

o Conciliating different ERP systems used by different companies outside the cluster and allowing the exchange of documents with different formats among them.

• Cross-organizational Business Process Interoperability Gap Detection Service The aim of Cross-organizational Business Process Interoperability Gap Detection Service (CBPiP) is to analyze and detect interoperability gaps (deadlocks, interface mismatches) in cross-organizational business processes. This SaaS tool addresses the following cluster needs:

o Scanning the CBP processes (xPDL file) of companies. o Detecting deadlocks based on flow analysis of the CBP processes. o Analysing MessageFlows where documents are exchanged between companies. o Detecting interface Mismatch based on analysis of MessageFlows. o Allowing the companies to check the compatibility of their processes before

starting business collaboration. The most important feature comes from the application of a SaaS business model, which overcomes some of the problems encountered in previous software implementations, namely the difficulty of companies to adapt a new tool, with the costs and time needed for that purpose

Figure 55 - Some COIN Innovative services tested. Collaborative 3D designer service (left) and

Interoperability Spaces (right) have been tested, for product design and contract negotiation, respectively

4.2.1.3 COIN experience in the Andalusian Aeronautic Cluster Some of the competitive advantages and benefits COIN has preliminarily shown into the Andalusian Aeronautic Cluster are: • Openness for the cluster, to other prime contractors and other business opportunities.

Relation with other clusters. • Open call for tender processes. Competence selection of partners.

105

• SaaS business models used in software implementation reduce costs, time and difficulty for companies in the use of new services. Some examples are:

o Percentage demand-offer matched (the percentage of offers that a company can access successfully) increases.

o Time to set up a VO is reduced, with the use of services to search for partners. o €/Project in the quotation and performance of the project decreases. o Fixed costs are reduced, due to the fact that companies can collaborate remotely. o Time/project is decreased in all phases.

The ROI (Return on investment) is significantly increased, due to the following reasons: o The value of investment in SaaS business model is not high. o The benefits obtained are improved, as can be deduced from last points

• Increase collaboration in business opportunities among companies, sharing valuable information without neglecting security.

• Increase communication between companies, University and research centres. • Increase Interoperability among companies of the cluster and outside the cluster, facilitating

the use of these services to the end user. SaaS can use accepted standards in aeronautics and by main software developers, enabling the integration of applications and platforms.

4.2.1.3.1 Measured business benefits Selected COIN services have been tested after the development phase performed, with following the generic conclusions. After analyzing the different COIN services results and their relation with the workflows in the Andalusian Aeronautic Cluster and the business involved in it we can conclude about the processes and indicators:

A relevant number of indicators relevant to the cluster can be improved with the use of COIN services, being the most important ones:

o Number of companies that have access to a BO o Time spent in partner search and forming a VO o Time needed to process an order or invoice o Reduction in errors / complaint per project o Cost reduction in product development

In the following table the summary of the different performance indicators, with the as-is and foreseen to-be situation are summarized.

106

Table 4 - Foreseen benefits of COIN use in the Andalusian Aeronautic Cluster Some of these indicators have already shown improvements when using COIN services within the cluster, however it’s still needed more testing to reach the foreseen benefits shown in the Table 4.

4.2.1.3.2 Lessons learned Apart from the innovation shown by COIN services in the first tests beds developed in the Andalusian Aeronautic Cluster, the success in many cases will depend on the maturity, risks and reduction of costs when using the specific tool and the entire COIN platform. The Andalusian Aeronautic Cluster has shown an increased investment in R&D year in, year out, mainly in the auxiliary companies; this investment has seen its trend changed after year 2008, but it improved again its figures in the last year. In 2010 the indicator related to the R&D investment of the auxiliary companies of the cluster shown the best values ever within the cluster.

Indicator 2009 2010 Rate (%) % R&D Investment / Turnover 4,3 9,0 109,3

However, in comparison with all the activities performed by the cluster’s companies, the R&D sector still has the lowest growth rate in the latest years. The figures of this R&D activities have risen only 0,2% since the 2009 (taking into account the number of employees), so this situation represents that in the Andalusian Aeronautic Cluster is still not as open as it would be desired [3]. Several issues have arisen when integrating COIN services with legacy systems from the cluster. The lack of openness in some legacy systems doesn’t permit COIN to show its real performance, as for example in the case of the private portal of the main contractor of the cluster, where business opportunities are published and communication among the main contractor and other companies of the cluster is held through private services. Should COIN being run completely integrated within the companies’ processes and services, this will provide real feedback about its improvements in the Andalusian Aeronautic Cluster. This way, the previous indicators shown in Table 4 will provide real values of the results expected. An analysis of the Andalusian Aeronautic Cluster presents advantages towards the COIN vision, as the listed below:

Metric Typology AS-IS Foreseen Benefits

Number of companies / BO 22 50%

% demand-offer matched 10% 30%

Time reduction to send a VO quotation 10 d 8%

Reduction of time for partner search 7 d 8%

Time to send/receive an order 8 d 12,5%

Time to send/receive an invoice 15 d 50%

Invoice errors / project 4 25%

Number of complaints / project 9 36%

Cost reduction in Product Development - 5%

107

o The sector is very specific, and the industrial network is more than 100 years old in the region.

o Three main long-term projects assure the continuity of the activities in the cluster. o Six airports within the region, being two them high-capacity ones. o Positive growth rate in the sector every year since its beginning.

On the other hand, some disadvantages came up with this analysis, and they could have direct consequences in the future adoption of COIN system and platforms [7]:

o Technological profiles of the auxiliary companies need improvements. o The size of auxiliary companies presents limitations and their activities are

affected by these. o Low number of alliances among the auxiliary companies. o Low private investment in R&D activities.

In many cases, the future exploitation and use of a service will depend on the refinement and consolidation of the services, with individual contracts between companies interested and developers. The success of other services will also depend on the overall adoption of the platform, and the number of customers that will finally use it. This will be properly addressed in final assessment phases.

4.2.1.4 Conclusions The Andalusian Aeronautic Cluster continues promoting research and innovation projects in the cluster, supporting collaboration processes with research projects such as FP7 COIN. These new business models, based on Software as a Service bring the following benefits to the Andalusian Aeronautic Cluster: • New Business Opportunities Openness of the cluster to other prime contractors and other business opportunities, which will access to the published services of companies. Open call for tender processes, with competence selection of partners and relation with other clusters. • Costs reduction due to interoperability Interoperability of formats will suppose a cost reduction as long as the formats are compatible with the aeronautical standards used by prime contractors. • Increase of project profitability Project profitability will increase, as the companies will not have to change their ERP tools, having the support of software developers to use the collaborative and interoperability web services, reducing costs of implementation and training. • Increased turnover, due to the previous mentioned facts. References [1] COIN project (FP7 IP 216256). COllaboration and INteroperability for networked enterprises. 2008.

www.coin-ip.eu. [2] Colosa, Inc. ProcessMaker Workflow Simplified. 2011. http://www.processmaker.com/. [3] Fundación Hélice. «Sector Aeroespacial Andaluz Informe estadístico 2010.» Sevilla, 2010. [4] Galeano, Nathalie, y otros. «VBE pilot demonstrators.» En Methods and Tools for Collaborative

Networked Organizations, de Luis M. Camarinha-Matos, Hamideh Afsarmanesh y Martin Ollus, Part 6. Springer, 2008.

108

[5] Ingeniería y Soluciones Informáticas S.L., ISOIN. «COIN: collaboration and interoperability for greater competitiveness in the Andalusian aeronautical sector.» Aeronáutica Andaluza. Sevilla: Fundación Hélice, Septiembre-Diciembre de 2009.

[6] Junta de Andalucía. Datos del sector Aeronáutico en Andalucía. 11 de Diciembre de 2009. http://www.juntadeandalucia.es/compromisos20082012/principal_noticia.php?id_noticia=4046.

[7] Junta de Andalucía. «Programa de Acción Sector Aeroespacial 2010-2013» Sevilla, 2010. [8] Parque Tecnológico y Aeronáutico de Andalucía, Aerópolis. Fundación Hélice. 2009.

http://www.aeropolis.es/opencms/opencms/es/serviciosAvanzados/fundacionhelice/.

[9] Romero, David, y Arturo Molina. «Virtual organisation breeding environments toolkit: reference model, management framework and instantiation methodology.» Production Planning & Control 21, Issue 2 (2010): 187-217.

109

4.2.2 An EI/EC Pilot in The Hungarian ICT Cluster (IND) Szabolcs Kátai (IND/IVSZ), Zoltán Mózes (IND)

Abstract IVSZ, acting as an end-user business network, has participated at an FP7 research project - COIN - which intends to develop supporting software services in a networked environment. IVSZ role was to provide business requirements, follow the development process and test the services developed. For this purpose IVSZ has chosen one particular innovative project - the "developing other industry relations and market development" project - and defined two test cases which can demonstrate the potential benefits of some EI/EC innovative services developed in the COIN project. In the test process three COIN service classes were tested, namely Collaborative project management services, Collaborative human interaction services and Knowledge interoperability services. It has been shown that these services can effectively increase productivity and intensify the involvement of members in the business network.

4.2.2.1 Introduction

4.2.2.1.1 IVSZ IVSZ, the Association of Hungarian IT, Communications and Electronic Companies was founded in 1991. By today IVSZ has grown to be the only major ICT National Trade Association in Hungary. With more than 300 members - composed of SMEs, large Hungarian companies and multinationals representing over 70% of the total annual output of the Hungarian ICT sector - it represents the interest of the Hungarian information, communication technology and electronics sector.

4.2.2.1.2 The IVSZ Innovation Programme The IVSZ Innovation Program was launched early 2007 with the purpose to bring together and support those Hungarian innovative ICT companies that see the key of their competitiveness in continuously developing products and services and they actively do act for this goal. Two main objectives were identified: "innovation capability building" and "developing an innovation friendly market environment, market development". A number of activity areas - many of them involving collaborations - were defined [1] and implementation of some of these has started in the IVSZ Innovation Working Group composed of more than 40 IVSZ member companies.

4.2.2.2 Business Case Description: The IVSZ test case

4.2.2.2.1 ICT industry background The ICT industry is one of the fastest developing industry sectors, wider and wider utilization of info communications technologies is the main tool for economic growth, increasing competitiveness as well as better life quality. The European Commission estimates that roughly 50% of [2] all economy growth originates from ICT. As for the future, ICT technologies penetrate more and more into everyday life as well as in all different industry sectors. Consequently ICT continues to be a primary growth sector - especially taking into account that ICT is one of the most innovative industry sectors. ICT industry has a multiplicative effect, which means that all other industries where ICT technologies are used become more competitive as a result of efficiency gains among other factors.

110

4.2.2.2.2 Business case background The argument that ICT technologies are enabling technologies for other industries is a very strong one. Intuitively, this is felt by the majority of professionals and on a large scale demonstrated in many industries [3]. However, on a smaller scale this needs to be demonstrated at a practical level. This is not a very easy task, however, it also provides opportunities for those being able to demonstrate this. The above line of thought has lead to the emergence of an IVSZ project within the Innovation programme. This project is called "developing other industry relations and market development", and aims at turning the above statements into practice and provide opportunities for smaller companies as well in order to increase the ICT penetration in a number of industry segments [4]. In the earlier phase of the project the methodology for the process of creating new business opportunities for ICT companies has been defined. The process has the following phases for each industy approached • Bringing together clusters from ICT and the other sectors • Understanding each other and existing challenges • Exchanging information on experiences and knowledge • Defining ICT based innovation projects This process aims not only at encouraging the establishment of business contacts on a one-on-one basis, but also on a cluster-to-cluster basis, elevating the conversation and understanding to the industry level. This innovative approach provides far larger benefits than the traditional one-on-one approach, if successful.

4.2.2.2.3 Challenges and COIN expectations However, we find several challenges when successfully implementing this methodology. Though the process steps do not seem very difficult, working at a collective level is far more complex than working at an individual level. Figure 56 shows the identified challenges and the expectations about how the COIN project [5] supports overcoming these challenges.

Figure 56 – Challenges and COIN Expectations

The COIN services which implement the solutions for the IVSZ challenges can be grouped into three of the COIN service classes:

111

• Collaborative project management services • Collaborative human interaction services • Knowledge interoperability services For the exploration of the possible support that COIN services can provide, five business use cases have been developed and from these two test cases have been set up. One of the test cases describes the process of creating a project group for cooperation with another industry organisation. This case has the goal to initiate a new project, where there is an interest for forming a new group to explore potential business relations with a group of companies from another industry segment (other than ICT). Currently, many of the activities in this test case are performed manually, dominantly using knowledge "in the head" of project managers. The expectation using COIN is that the process becomes partly automated and some knowledge is externalised, becoming available within the network. The test case involves services from all three COIN service classes, namely the "Collaboration for project management" service, the "Collaboration visualisation tool" and the "Enterprise semantic matchmaking service". The other test case describes the process of creating and updating an ICT Ontology and company semantic profiles. This case on the one hand has the goal to create - or at an annual or semi-annual basis update - the ICT ontology used to describe the competencies and experiences in the IVSZ network of companies. On the other hand, it has the goal to create and regularly update the company profiles. Currently this process is done manually and requires great effort from IVSZ member companies. As it is a tedious exercise, IVSZ members are relluctant to update profiles, so information is not updated or it is missing, leading to mismatches and waste of time. The expectation is that the process becomes partly automated and that the workload of IVSZ member companies greatly decreases. The test case involves services from the knowledge interoperability service class, namely the "Social ontology building service" and the "Enterprise semantic profiling" service.

4.2.2.3 COIN solutions

4.2.2.3.1 Project initiation test case The test case focusing on initiating a new project involves dominantly two types of activities. One is to find potential companies which are expected to be interested in the particular intustry segment that the new project intends to focus on. The other is to involve these companies effectively into the project. For the support of the search type of activity, the COIN Enterprise Semantic Matchmaking service is integrated into the test case. This service provides a semi-automated company recommendation solution based on semantic keywords of an ICT ontology. In order to utilise this service, the prerequisite is that an ICT ontology needs to be built and company semantic profiles need to be created.

112

For the support of the involvement type activity, the COIN Collaboration for Project Management service and the COIN Collaboration Visualisation tool are integrated into the test case. These tools make it easier for companies selected by the project manager to communicate with each other, to look at what other IVSZ members are involved and how they relate to these companies. Such services encourage the active involvement of companies by pointing out potential partnerships right from the beginning and by increasing the level of trust withing the group under formation. The prerequisite for the Collaboration Visualisation services to operate is to build a database of inter company communications.

4.2.2.3.2 Creating/updating ontologies and company profiles test case The test case focusing on creating/updating an ICT ontology and company profiles is in fact a "back office" service providing the background information for other IVSZ services. It involves analysing company information, extracting keywords and arranging these into an ontology. For the support of the ontology creation the COIN Social Ontology Building Service is used. This tool makes the analysis of information about a large number of IVSZ member companies in a semi-automated way, and provides an effective tool for the collaborative creation of an ontology, which utilises the business knowledge of several professionals. For the support of the company profiling, the COIN Enterprise Semantic Profiling service is used. This tool provides a semi-automatic method to create a profile of an IVSZ member company, which a project manager is able to do. This alleviates the need to ask each IVSZ company member to create/update their own profile and reduces this task to asking them to check that their profiles are correct.

4.2.2.4 Results and Business Benefits For the evaluation of the effectiveness of the COIN solutions they were integrated into the processes of the "Developing other industry relations and market development" project. This also involved the integation of these services with the existing IT systems of IVSZ where necessary. Results were evaluated from two points of view. One point of view was the business benefits that COIN services can provide to IVSZ when applied to the IVSZ processes. The semi-automation of processes accelerates these processes and at the same time allows more systematic selection based on a broader selection base. The enhancement of communication and the provision of more "pre-digested" information allows more efficient communication and information seeking. These result in time savings in the processes and, even more importantly for IVSZ, in a better involvement of member companies and a feeling of higher satisfaction from IVSZ services. The possibility of integrating different COIN services provides potentially cost savings. The other point of view was the current "business-readiness" of the COIN services. From a technical perspective, it seems that - contrary to the fact that these services have been developed within the framework of an FP7 research project and thus concentrate more on developing new technology and less on developing market-ready products - services show considerable values not only in their technology background but also in their usability. Nevertheless, different services are at different levels of readiness and can benefit from further development at the late stage of the COIN project. Regarding usability or user experience, services are on a good track, however, easiser integration into existing company systems could increase adoption. Services effectively support cooperative working, nevertheless, more automated processes would further

113

increase productivity. In order to encourage the widespread adoption in a multilingual Europe, the extention of multi language support would be beneficial.

4.2.2.5 Conclusions IVSZ, as a professional association and a business network in the ICT industry domain, tested software service prototypes designed for collaborative working in a software as a service environment. It has been concluded that the services which were tested within the IVSZ test cases can potentially provide tangible benefits both for the association itself (ie. the network manager organisation) and for the individual members of the network as well. The test example of the "Developing other industry relations and market development" project, in particular, can potentially benefit from COIN services by gaining tools to better assess, reach and mobilise IVSZ member companies (through a faster and more systematic partner selection process and through more efficient communication tools), to reduce organisational processes duration and costs (through (semi-)automatic information analysis tools and through collaborative working tools). From a technical perspective, it seems that COIN services show considerable values not only in their technology background but also in their usability. Nevertheless, in order to develop these into fully market ready services a number of factors still beed to be considered. Technically such factors include for example robustness, scalability, ergonomy and multilinguality. From a business perspective such factors include for example business model, maintenance services and legacy integration services. In addition to the particular benefits gained from the COIN system, by participating in this project, IVSZ has been confronted with a number of innovative technologies for enterprise collaboration as well as with several other collaborative groups. This has allowed IVSZ to gain a better understanding of collaborative working environments, challenges and opportunities. The IVSZ Innovation group will have an opportunity to improve its own operations towards becoming a better service provider to its own members. As IVSZ participates in several "national technology platforms" (eg. NESSI HU, Artemis HU, Multimedia and Mobility), these practices can be communicated towards these as well. References [1] IVSZ Innovation program (in Hungarian): http://ivsz.hu/tagsag/munkacsoportok/innovacio [2] European Commission: “i2010- First Annual Report on the European Information Society”, Brussels May

2006 [3] "A transformational agenda for the digital age - DIGITALEUROPE's vision 2020", DigitalEurope, 2010 [4] "Other industry marketdevelopment program" (in Hungarian), http://ivsz.hu/projektek/hazai-projektek/mas-

iparagi-piacbovites [5] COIN project (FP7 IP 216256). www.coin-ip.eu

114

4.2.3 An EI/EC Pilot in a Marine Shipping Network (UCY) Achilleas ACHILLEOS, George SIELIS

and George PAPADOPOULOS 1 1 Department of Computer Science, University of Cyprus,

Nicosia, 1678, Cyprus

Tel: +357 22 892700, Fax: + 357 22 892701

Email: {achilleas, sielis, george}@cs.ucy.ac.cy

Abstract The COIN platform allows exposure, combination and integration of interoperability and collaborative services for their application to specific business domains. The objective is the exploitation of the COIN platform’s technological capabilities and services to the Cyprus maritime shipping sector; together with our industrial partner Donelly Tanker Management. In particular, two highly suitable business use cases have been identified on the basis of which the pilots have been developed using the COIN platform and the provided COIN services. The development of the pilots demonstrated how the COIN platform and its offered services can aid in simplifying and expediting the processes of the maritime shipping domain. On the basis of the pilots initial results are presented in this chapter. Keywords: Enterprise Interoperability, Enterprise Collaboration, Civil Engineering Domain.

4.2.3.1 Introduction to Cyprus Shipping Sector and Business Use Cases The contribution of the shipping industry to the Cyprus economy is as high as 5.5% of the Gross Domestic Product (GDP) –ship management and ship owning combined–, a value higher than in most other European countries [6]. The Cyprus Registry is classified as the 10th largest merchant fleet globally and third in the European Union, with approximately one thousand shipping vessels; gross tonnage in excess of 19 million [6]. Limassol is considered to be the largest third party ship-management centre in the EU and one of the largest in the world (in excess of 130 ship-owning, management and other shipping related companies maintain offices there). The European merchant fleet capacity was significantly increased upon Cyprus accession to the EU, with the island contributing 15% – 25% of the EU fleet [8]. Among the ship-owning/management companies established and operating in Cyprus, it is estimated that 87% are controlled by EU (including Cypriot) interests. Approximately 4.500 persons are employed ashore and 40.000 seafarers of different nationalities are employed onboard vessels controlled and/or managed from Cyprus [6]. The distributed nature of partners involved in the marine shipping domain and the complexity of managing such processes calls for technological developments that will simplify these processes and reduce the time required to carry out this processes. For this reason, two business use cases have been identified and the developments necessary for building the pilots using the COIN platform and services were performed. The first use case describes the actions undertaken by DTM and other parties (e.g. charterers) to complete the voyage pre-fixture. Initially pre-fixture queries, a prerequisite for the voyage fixture establishment and completion, are issued and subsequently standard documents (i.e. standard charter party forms) are formulated after negotiations between United Product Tankers (UPT) and charterers. The outcome of these negotiations is a “recap” document, containing details of the cargo such as ‘laycan’ dates, loading and discharge ports and speed advisories. Once formulated, the recap must be made available to the vessel’s captain for any final queries or clarifications.

115

Figure 57 - Use Case 1: Formulating the Recap Pre-Fixture Document

Figure 57 shows in the form of a UML use-case diagram the aforesaid tasks performed for formulating the recap pre-fixture document. As illustrated in the figure, the Charterers and UPT (United Product Tankers) negotiate the standard charter party forms in order to produce the recap document. The recap document is then distributed to DTM who in turn sends this to the vessel’s captain for any outstanding clarifications or queries. Using the recap, DTM may already instruct the captain of the ship to begin the voyage towards the general geographic area identified (e.g. Eastern Mediterranean). At this point DTM will request precise voyage orders that contain more specific details, such as the specific load/discharge ports, details regarding the cargo (e.g. exact tonnage) as well as issues like draft restrictions at the load port (e.g. depth of port).

Figure 58 - Use Case 2 – Creation and Settlement of the Proforma Disbursement Account (PDA)

The second business use-case refers to the process executed so as to formulate the Proforma Disbursement Account (PDA). The PDA details the estimated costs that a Port Agent will have to pay for the vessel to have a smooth and quick turnaround at the port (e.g. harbor and pilot

DTM

Port agent

Accounts dept.

Provide pre-arrival documentation

Notify accounts for payment of agent (CVT)

Provide port details (berthing, cleaning)

Captain

Negotiate agency fees and PDA (ISS)

Notify agent appointment

Create PDA

Provide updates + feedback to DTM

Select and appoint port agent (CVT)

Charterers

Request Voyage Orders

Negotiate standard charter party forms (CVT, ISS)

UPT

Create recap document

DTM

Distribute recap document to DTM (CVT, TIS)

Review/confirm recap

Captain

116

dues, towage expenses). DTM identifies and appoints a suitable Port Agent on the basis of skills such as personal trust, voyage management, voyage establishment, etc., with whom the DTM operator negotiates the terms of the PDA. The main article up for negotiation between DTM and Port Agent are the agency fees. Once PDA terms are agreed the DTM operator notifies the DTM accounting department for arranging the payment of the fees related to the appointment of the Port Agent and forwards the PDA to the captain. The process continues by direct communication between the captain and the Port Agent for the execution of the loading and discharge procedures at the starting and destination ports. Furthermore, daily updates are communicated to DTM by both the captain and the Port Agent. After completion of the process described above, the Port Agent sends the final disbursement account to DTM (the PDA is an accurate estimate of costs). At this point DTM can “close” the voyage using the DA-Desk legacy system. Figure 58 presents the UML-based use-case diagram, where DTM and the Port Agent negotiate the terms of the PDA. First, the agent is commonly appointed by the ship owner, i.e. DTM operator, to begin negotiations with. The main article up for negotiation between DTM and the port agent are the agency fees. When agreement is reached, DTM uses the DA-Desk system to notify on the appointment of the specific agent. Then, the DTM operator forwards the PDA to the captain. Once the PDA is finalised, DTM notifies its accounting department for settlement of the fees. The process continues with communication between the captain and the port agent for execution of the discharge and turn-around procedures. Upon completion of the process, the port agent sends the final disbursement account to DTM. Thus, DTM closes the voyage in Da-Desk.

4.2.3.2 Objectives The objectives of this work are to validate, test and establish the efficiency and effectiveness of the COIN platform by reducing the time and simplifying the execution of the processes in the maritime shipping domain. In particular, through the selected use cases, the aim is to simplify and expedite the establishment and management of a voyage, which involves highly interactive processes executed by several parties of a highly distributed team. The weaknesses identified are related to the current communication methods used in tasks such as voyage terms negotiations, information and documents trusted sharing, chat and voice communication, etc. In particular, these tasks are accomplished mainly by exchanging emails and phone calls. This is a major weakness not only because the task of exchanging emails is time consuming but also because it becomes difficult for the mediator party (i.e. DTM operator) to coordinate and organize correctly the communication between the involved parties. Therefore, it was deemed essential to perform the necessary technological developments, in order to drive the required business processes and allow executing efficiently these complex processes.

4.2.3.3 Supporting the Maritime Sector using the COIN platform On the basis of the use cases described in Section 1, the necessary COIN services provided by the COIN platform were identified. Moreover, additional extensions/services were developed in order to achieve smooth integration with COIN services and support as a result the specificities of the maritime shipping domain. Thus, specific services were selected that can aid and simplify tasks of the processes that are namely: negotiations of voyage terms, information and documents trusted sharing and management of relations of the human collaboration team. From the pool of services [4] provided by the platform a number of COIN Enterprise Interoperability (EI) services were chosen. These services are: Interoperability Space Service (ISS) [3], Trusted Information Sharing (TIS) [1] and the Collaboration Visualisation Tool (CVT) [2]. Furthermore, the COIN Baseline Communication Services were used to support efficiently the necessary communication tasks. Foremost, the ISS service provides the capability to exchange and negotiate details and terms of various documents in Universal Business Language (UBL) format. Also, the TIS service offers flexible sharing of business-related information and documents based on the strength of relations

117

established from previous business interactions [7]. In specific, the TIS service allows sharing parts of documents by defining different sharing rules for diverse partners, on the basis of relations. The CVT service is highly-related to the TIS service since it provides a tool that visualises the human collaboration network; COIN users and their discovered relations. Relations may rely on prior joint activities and interactions (e.g. voyage management). Finally, the COIN Baseline Services allow direct communication amongst partner using different communication formats such as email, group chat, Skype instant messaging and Skype voice call. Direct communication is crucial during the execution of the maritime processes and thus is provided in tasks such as informing partners that a new task has been assigned to them or discussing with the vessel captain that requires some clarifications on the voyage.

118

Figure 59 - Use Case 1 – Formulation of the Recap Voyage Document using ProcessMaker

Figure 59 illustrates part of the formulated workflow process for the first business use-case that refers to the “Formulation of the recap voyage document”. As aforesaid, the business process is defined using the ProcessMaker application [5] of the COIN platform, which allows creating, assigning and executing business tasks. These tasks (e.g. Voyage Selection) can be associated with forms, users and web service triggers (i.e. invoking COIN services), so as to carry out successfully business processes. For instance, the primary task shown in Figure 59 (i.e. Voyage Selection) is assigned to a DTM employee and is associated to the form shown in Figure 60. This enables a DTM employee to start a new business use-case (see Figure 60), as soon as a new voyage fixture arises and needs to be negotiated and decided. Figure 60 showcases actually that

119

the assigned DTM employee acts a business use-case partner, rather than a developer, using though the same COIN service platform portal.

Figure 60 - Initialisation of the recap document business use-case

4.2.3.4 Business Benefits The benefits provided by the COIN platform, in terms of collaboration and interoperability, can be measured by identifying relevant business indicators. This allows measuring the changes and improvements in business process parameters, on the basis of the business indicators. Using the Value Reference Model (VRM) [9] and on the basis of the developed pilots, the proper business indicators have been identified and selected that aid the quantification of results.

Table 5 - Preliminary Results using the VRM model processes and metrics

VRM Process Meaning Metric Value Before Using COIN

Expected Benefit

[%]

Expected Value After Using COIN

BUC1 GS03 – Govern Supply Chain Information

Time to complete process plan

Velocity 24 – 72 hours 30 17 – 50 hours

A5 – Place Order Negotiating/distributing/reviewing/confirming recap

Velocity 16 – 48 hours 30 11 – 34 hours

BUC2 GS03 – Govern Supply Chain Information

Time to complete process plan

Velocity 24 – 72 hours 30 17 – 50 hours

A5 – Place Order Negotiating/distributing/reviewing/confirming PDA

Velocity 16 – 48 hours 30 11 – 34 hours

VRM supports key issues and gears together processes within and between individual units of networks for the benefit of: (i) Planning, (ii) Governing and (iii) Execution (information - financial - physical flows). The model’s objective is to increase the total chain performance and support evolution [9]. In particular, VRM employs a common, process-based language of syntax and semantics and enables the successful application of SOA-enabled practices. On the basis of the VRM model the following business benefits have been identified: (i) reduction of lead time in decision making and reaction to arising problems, (ii) improve the efficiency of processes and (iii) reduce barriers of a geographically distributed team. These benefits drive the selection and measurement the velocity metric defined in the VRM model [9]. At this point the initial pilots have been implemented and tested with the following preliminary results shown in Table 5.

120

4.2.3.5 Conclusions and Lessons Learned One of the most important objectives in the maritime sector (or any other logistics sector for that matter) is fast decision making and reaction in arising problems. Reducing communication time between partners using COIN Baseline Communication services, will lead to the successful management of multiple voyages through timely completion of individual tasks. Furthermore, the use of the COIN platform’s EI Services can improve in overall the efficiency of collaboration and interoperability processes executed by these partners. Thus, negotiation (ISS), information and document sharing (TIS) and collaboration (CVT) services as part of the COIN EI services can contribute to the overall efficiency of processes. The management of shipping voyages overlaps geographical barriers. This means that vessels managed by DTM can be in different locations. Also the charterers and the agents can be in any country in the world. Hence, DTM has to be in continuous communication with the vessel as well as the charterers and the agents. Also, DTM may need to monitor negotiations between other parties, which are not located at the same place. Consequently, the use of the common COIN portal and the provided (selected) services can reduce the barriers faced by such a geographically distributed team. References [1] COllaboration and INteroperability (COIN) EU IP 2010a, “Deliverable D4.5.2b – Annex III – Trusted

Information Sharing Service (TIS) Final Factsheet”. [2] COllaboration and INteroperability (COIN) EU IP 2010b, “Deliverable D4.5.2b – Annex I – Collaboration

Network and Visualization Tool Service (CVT) Final Factsheet”. [3] COllaboration and INteroperability (COIN) EU IP 2010c, “Deliverable D4.5.2b – Annex I –

Interoperability Spaces Service (ISS) Final Factsheet”. [4] COllaboration and INteroperability (COIN) EU IP 2011, “Service Terminology – COIN Services

Repository”, Available Online: http://www.coin-ip.eu/intranet/wiki/cross-wps/service-terminology?searchterm=service+termino.

[5] Colossa, Inc. 2000, ProcessMaker Workflow Simplified, Available Online: http://www.processmaker.com. [6] Cyprus Shipping Chamber (CSC) 2010, “Cyprus: A Leading Maritime Center”, Available online:

http://www.csc-cy.org/tmp/28433223.pdf. [7] Skopik, F., Schall, D., Dustdar, S., 2010, “Trust-based Adaptation in Complex Service-oriented Systems”,

IEEE International Conference on Engineering of Complex Computer Systems (ICECCS). [8] PriceWaterhouseCoopers (PWC) Cyprus 2010, “Cyprus shipping: A sea of opportunities”, Available

online: http://www.pwc.com/cy/en/publications/assets/pwc-cy_shipping_sep10.pdf. [9] Value Chain Group (VCG) 2004, Introduction to the Value Reference Model (VRM), Available Online:

http://www.value-chain.org/en/cms/1960/.

121

4.2.4 An EI/EC Pilot in a Logistics Network (LODER) Gulcin Buyukozkan, Leyla Arsan, Aslihan Kagnici, Mehmet Tanyas1 1 LODER - Turkish Logistics Association (www.loder.org.tr) - e-mail: gulcin.buyukozkan@gmail.com

Abstract Turkish Logistics Association, LODER, is the COIN project partner for industrial implementation of COIN Enterprise Collaboration (EC) and Enterprise Interoperability (EI) services in logistics industry. The business case scenario of LODER is defined in the Chemical/Paint sector and it addresses the subject of the collaborative transportation of paints from paint manufacturer to its customers. The objective of this scenario is to increase the customer services to the highest level by decreasing the logistics costs. After identifying logistics requirements for COIN EI and EC services for the defined scenario, the general development process and the expected business benefits are summarized and concluding remarks are underlined.

4.2.4.1 Introduction The logistics industry is one of the several domains addressed by the COIN European Project. Within the scope of the COIN project, Turkish Logistics Association, LODER (www.loder.org.tr), is responsible to test the applicability of COIN Collaboration (EC) and Enterprise Interoperability (EI) services [1] [4] [2] to identified logistics business processes. LODER was founded in 2001, representing 450 individual members including academicians, professionals (working both in logistics services providers and logistics service recipients companies), information technology experts and armed forces members. The mission of LODER is to contribute on the logistics operations to be efficient and effectively under the concept of supply chain management. Following this mission, LODER expectations from COIN project are determined as improving the use and the adoption of interoperability services, especially in Turkish logistics SME companies, and improving the cooperation activities between logistics stakeholders. In Turkey, total logistics sector business volume is € 70 Billion and total logistics and transportation companies’ business value is € 40 Billion [3]. Logistics expenses have been increased by 3 times in the last 5 years in Turkey and the share of outsourcing logistics services has been increased by 5%. According to the GDP (Gross Domestic Product) values in 2009, transport, storage and communication sub-sectors constitute 13% of total GDP value. There are approximately 280,000 companies under the sub-sector of road transport in Turkey and 95% of all of these companies is considered to be SMEs. The use of information and communication technologies (ICTs) in the logistics sector, especially in the category of SMEs, is in extremely low level. The processes are generally carried out by the office programs, fax and e-mail. When the company begins to grow, the accounting and payroll programs, the track and trace systems, hand terminal systems, transport management, warehouse management and optimization software start to be used. As a result, the companies have to use different software for each logistics business process which is very costly especially for SMEs. Since the SMEs in logistics sector in Turkey have not adequate facilities for doing R&D, LODER will lead the R&D on behalf of SMEs by developing new services on COIN services according to the SMEs’ needs. In this study, we present the initial findings of the LODER as the pilot implementation of COIN project services for logistics domain.

4.2.4.2 Short description of LODER business cases The scenario is defined in the Chemical/Paint sector and addresses the subject of the collaborative transportation of paints from paint manufacturer to its customers. The objective of this scenario is to increase the customer services to the highest level by decreasing the logistics costs. The case was selected regarding the availability with high level of knowledge of the

122

SMEs. In this scope, Dincer Lojistik, which is an SME and a member of LODER, was selected. Dincer Lojistik is located in İstanbul and provides logistics services in all over Turkey. The case contains the relation between Dincer Lojistik and its clients, clients of clients and the carriers (cf. Figure 61). The clients of the Dincer Lojistik have strong legacy systems such as SAP, LOGO MS, AXAPTA, AS/400 and Dincer Lojistik uses LATMS software. The integration between LATMS and the other legacy systems is provided by the interfaces and the web services in the business processes during data transferring.

Figure 61 - Dincer Lojistik business network for collaborative transportation

The business processes of the case include 13 steps within the constraints of logistics as domestic transport, packaged goods (IBS) and a process without storage. In the scope of the business processes of the case, first of all, Dincer Lojistik makes an agreement with its clients and during this agreement it carries out the each project management. Before the order-delivery processes, contract management between Dincer Lojistik and its clients is realized. In this scope Dincer Lojistik prepares a work plan in MS project and generates the address list of the clients of the clients. Then contract management between Dincer Lojistik & Vehicle Owners and the clients of clients is made by the contract documents. After the order-delivery processes, the clients make the performance measurement controls and reports according to the performance indicators. After the contract managements, the order-delivery processes begin: Dincer Lojistik receives the orders from its clients (Polisan in our case) and groups the orders by date and by location. Then Dincer Lojistik plans the freight and routing according to its own properties and rental vehicles and sends the vehicles to the Client’s loading place. The vehicles depart from the client by receiving the deliveries. In the meanwhile Dincer Lojistik tracks and traces the vehicles. When the vehicles arrive to clients of clients’ (such as distributors, construction market chains, hard ware dealers and construction yards) delivery place, they are unloaded. If there are any returned and empty containers, they are separated. In the next step, Dincer Lojistik reports to its clients about the delivery and then prepares and sends the invoice. The business processes end when the clients send the payment to Dincer Lojistik. (cf. Figure 62). From the whole case, six use cases which have the strong requirements for interoperability and cooperation were separately defined. These use cases address the business network between Dincer Lojistik’s client, namely Polisan with Dincer Lojistik. The selected use cases (UCs) are: UC1. Project Management, UC2: Receive the order of Polisan, UC3. Plan the freight and routing and send the vehicles to the Polisan’s loading place, UC4. Load the vehicles and receive the deliveries and vehicles depart from Polisan, UC5. Track and trace the vehicle, and UC6. Unloading the vehicles in the delivery place and reporting to Polisan.

123

Figure 62 - The general business processes of Dincer Lojistik for use cases

4.2.4.3 COIN solutions identified and used LODER selected six UCs, where the problems are mostly seen and time consuming and high logistics cost occur, from the general business process of the scenario (cf. Table 6)

Table 6 - LODER Use Cases and COIN Services Requirements

UCs COIN Services Requirements COIN EI-EC Services UC1 A collaborative management tool

requirement. EC Services: Collaborative Project Management (Coll4PM)

UC2 Time consuming and data loss because of two different formats of the orders. Wrong infromation matches because of using Turkish characters and different typing.

EI Baseline Services: Massive Data - MDIS for format transformation EI Innovative Services : Data Interoperability Services - ISS / Semantic Reconciliation Suite + LODER Dincer Lojistik Ad-hoc Web Service, LODER Polisan Ad-hoc Web Service, LODER UBL Converter

UC3 More reliable and verifiable communication tools requirement.

EC Baseline Services: CS-ES/IMS/NS/CP/SWS.

UC4 Different interfaces for automatic information receiving for each client / The clients matching problem because of using different tax numbers.

EI Baseline Services: MDIS + LODER Dincer Lojistik Ad-hoc Web Service, LODER Polisan Ad-hoc Web Service, LODER Dispatch Converter

UC5 More reliable and verifiable communication tools requirement.

EC Baseline Services: CS-ES/IMS/NS/CP/SWS.

UC6 Time consuming and data loss because of two different formats of the orders. Wrong infromation matches because of using Turkish characters and different typing.

EI Baseline Services: MDIS + LODER Dincer Lojistik Ad-hoc Web Service, LODER Polisan Ad-hoc Web Service, LODER Report Converter

Three of the UCs, UC2 (Order Process), UC4 (Dispatch List Process) and UC6 (Delivery Report Process) have the strong requirements for interoperability. Therefore existing COIN EI services are selected to be tested and extended. LODER defined four main requirements and carried out the development activities for these requirements which are; Integration of the MDIS (Massive

124

Data Transfer Information Service) [1] for format transformation and ISS to provide negotiation on top of an UBL (Universal Business Language) order to the existing legacy systems, Turkish Characters Management, Creation of the interfaces between SAP and LATMS and Realization of automatic transformation of the formats for reports. The common most important problem for all these three UCs is that since Dincer Lojistik and its clients use different services, there are two different formats of the formats and they need to be converted twice while transferring the orders. This file converting process obviously causes time losses. To solve this problem, LODER carried out the development activities and created the web services in order to provide the automatic transformation between the formats by using the COIN Services. More precisely, LODER created web services to deal with both Polisan and Dincer Lojistik legacy databases importing and exporting three business documents (order, dispatch list and delivery report) from/to legacies systems. By usage of the semantic suite the generated transformations convert the XML format of the buyer company to UBL format which will be used on negotiation stage in ISS. This last service will be used to convert back the UBL format to the seller company's XML format after negotiation which will be passed again to the ad-hoc web service of the seller company to be saved in the legacy system. These ad-hoc services are also used to convert the dispatch list and delivery report from one company's XML format to the other's (cf. Figure 63).

Figure 63 – General development process for order transformation

4.2.4.4 Measured Business Benefits To measure the expected business effects of COIN project, based on the UCs, firstly, the processes are selected according to the Value Reference Model (VRM) (www.value-chain.org). VRM priority dimensions and KPI’s are then determined and the measurement of the “as-is situations” before using COIN services is realized. Table 7 summarizes briefly the LODER UCs business benefits.

Table 7 - Expected business benefits related to LODER UCs

UC’s VRM Process Dimension Metric Unit Expected Benefit

Value before

125

(%) using COIN UC1 GS03 (Govern Supply

Chain-SC, Information) Cost Cost, Govern

Information SC € 10%-15% 80000 - 100000

A04 (Acquire, Negotiate Contract)

Cost Cost, Negotiate Contract

€ 10% 3000

Reliability Ratio, Successfully Negotiated Contracts

% 5% 20%

UC2 A06 (Acquire, Receive Order)

Cost Cost, Receive Order € 20%-25% 45000 - 50000

Reliability Orders, Receipts Error Free % 5%-10% 80% - 85%

UC3 PS4 (Create Plan, SC) Velocity Cycle Time, Create Plan SC

Hours %20 3-6

UC4 F05 (Fulfill, Fill Order) Cost Cost, Fill Order € 20%-25% 45000 – 50000 UC5 GS03 (Govern SC,

Information Cost Cost, Govern

Information SC € 3%-5% 40000

UC6 F07 (Fulfill, Deliver Order)

Cost Cost, Deliver Order € %20-25 45000 – 50000

4.2.4.5 Lessons learned and concluding remarks Within the selected six businesses UCs of LODER, the both selected COIN EI and EC services are tested and the required development is realized according to the defined logistics requirements. In this context, MDIS, ISS and Semantic Reconciliation Suite of the EI services and Coll4-PM and Communication Services of the EC services are tested and evaluated in order to be able to use them in the test-bed demonstrations. Regarding to the result of the LODER evaluations of the COIN services, in general, the effectiveness, efficiency and understandability of the services are at high level and satisfaction, attractiveness, learnability, memorability and use preparation and maintenance of the services are at medium level. ISS is very useful and easy to understand; the concepts and terminology are understandable for our organization and in line with other COIN services. Most of the functions of the service such as building a new negotiation, creation, deletion and application of personal rules are very beneficial for the companies in the logistics network. The outcome of the service will save time and cost by accelerating the process of negotiation on the orders. MDIS is a very useful supporting tool for the XML legacy format transformations. The usage of the MDIS accelerates the process of the creation of the ad-hoc transformations from the legacy database systems. One of the most attractive features of the service is that it is very easy to take up also for SME. Since the most important problem is the order format transformations between the legacy systems of the companies, Semantic Suite Reconciliation service, which allows exchanging of the documents automatically by generating a specific web-service in the run-time translation of the documents, is the most beneficial service for the order receiving process. References [1] [Elvesaeter et al, 2008] B. Elvesaeter, G. Benguria, A. Capellini, E. D. Grosso, and F. Taglino. State-of-the-

Art and Baseline EI Services Specifications. Technical report, COIN Project Deliverable, 2008. [2] [Facca et al, 2009] F.M. Facca, S. Komazec, C. Guglielmina, S. Gusmeroli, COIN: Platform and Services

for SaaS in Enterprise Interoperability and Enterprise Collaboration, Semantic Computing, 2009. ICSC '09. IEEE International Conference, .543-550.

[3] [MTC 2011]. Ministry of Transportation and Communications, Republic of Turkiye, http://www.ubak.gov.tr/.

[4] [Sitek et al, 2008] P. Sitek, J. Eschenbaecher, M. Sesana, H.-L. Truong, and C. Aguilera. D4.1.1 State of the Art and Baseline EC Services Specifications. Technical report, COIN Project Deliverable, 2008.

126

4.3 The COIN EI/EC Services in Business-Innovation Ecosystems The main novelties for today’s innovation ecosystems compared with earlier times can be found in ICT systems and the internet [4]. Across a wide range of industries today any entrepreneur with a good idea can, despite of geographical location, launch a successful business application [1]. On the other hand small and medium sized enterprises (SMEs) are nowadays faced with an overwhelming complexity when it comes to weave together systems in real-time manner as a means to offer superior products to consumers [4] and subsequently grow their business in a dynamic knowledge-based global economy [3]. The demand for an infrastructure that supports the collaboration of several players in this field and the interoperability of heterogeneous environments opens opportunities for service solutions that allow cost efficient, fast and reliable systemic results without major integration efforts. The COIN system offers such a public, distributed pervasive environment – a “utility-like capability that enterprises can invoke on the fly in support of their business activities” [2]. Featuring four initial strategies of COIN pilot partners for positioning within their specific target industry sector this chapter aims at demonstrating the COIN EI/EC Services approach in different Business-Innovation Ecosystems. References [1] Andersen, Jørn Bang. What Are Innovation Ecosystems and How To Build and Use Them. 05 16, 2011.

http://www.innovationmanagement.se/2011/05/16/what-are-innovation-ecosystems-and-how-to-build-and-use-them (accessed 10 04, 2011).

[2] European Commission. "Enterprise Interoperability Research Roadmap Update Version 5.0 FINAL." 03 05, 2008. ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/enet/ei-research-roadmap-v5-final_en.pdf (accessed 10 04, 2011).

[3] Nachira, Francesco. "Innovation Ecosystems: Una strategia europea per l’innovazione e lo sviluppo economico." 05 30, 2005. http://www.gencat.cat/economia/ur/doc/doc_30272549_1.pdf (accessed 10 04, 2011).

[4] Tuck Communications. Innovation Ecosystems: Is there a Cost to Collaboration? 03 2011. http://www.tuck.dartmouth.edu/news/articles/innovation-ecosystems-is-there-a-cost-to-collaboration (accessed 10 04, 2011).

127

4.3.1 An EI/EC Pilot in a Healthcare Ecosystem (VEN) Andrew Faughy1 1VEN Process Ltd, VEN

Abstract Wellbeing and healthcare is a global business providing worldwide trading opportunities for regional businesses and international competition. However, competition can be difficult as, for example, with manufacturers and service providers in the fields of medical technology equipment and devices, a small number of multinational players dominate. The opportunity can be taken to integrate different customers, consumers, providers, partners and their solutions in the developing healthcare ecosystem. Networked enterprises with a focus on Enterprise Interoperability and Enterprise Collaboration can supply directly or collaborate, being more enabled by access and interoperability as a capability. The wellbeing and healthcare sector is potentially a major engine of wealth creation especially the NHS (National Health Service) in the UK with its primary and secondary care infrastructure. This is increasingly expanding to include encouragement of preventative actions by the NHS, Governmental and other bodies. Healthcare is in essence a utility service, providing both local and national services to widespread and diverse customer base with a growing provision of solutions (part or total) and prevention activity by the private sector.VEN wishes to assist in enhancing the provision of local services and the achievement of a health dividend through enhancing the ability to tackle continuing wellbeing and ill-health at source, and thereby limiting demand for health services would help the NHS transform the balance of its role and improve effectiveness. Keywords: Collaboration, Interoperability, Healthcare, SaaS, VEN, Innovation.

4.3.1.1 Introduction and Background

4.3.1.1.1 Introduction to VEN a services and application intermediary VEN operates in the Healthcare, Engineering, Digital, Environmental and Chemical sectors. A specific focus for COIN exploitation is placed upon the healthcare sector; with a focus upon primary care, which includes the growing ‘personalised care’ arena. Our customers are of two kinds: • End users (or final customers): Ecosystem, Virtual Organisation (VO), Professional Virtual

Communities (PVC), Virtual Breeding Environment (VBE), and their members including low tech and mobile users.

• Providers of the services, for example the healthcare commissioners, suppliers, doctors etc. Role in the COIN VEN’s role in COIN is a minority partner defining the business requirements for a healthcare scenario, supporting the development of appropriate applications and testing these applications with real end users. This document is summation to date; of the thinking, high level service design, testing and interaction with its own end user community and work with colleagues in the COIN Project.

4.3.1.1.2 Introduction to UK Healthcare Eco-System The Healthcare eco-system under test with VEN; is based upon the engagement of Citizens in the provision of their local social and healthcare services; it attempts to address community engagement, consultation, service design and creation, service improvement and delivery of social and healthcare services by ecosystem service providers. It is considered that the available COIN services with some modification and customization can support a beta type of eco-system. The selected services are intended to present a low risk to the

128

eco-system members and to COIN by avoiding complex Clinical and NHS centralized services such as national patient records systems, whilst demonstrating COIN services with real community and identify business benefits [3]. The ecosystem consists of: Enterprise networks (SMEs & Large Enterprises) + public organizations (government bodies, regional development agencies, hospitals, charities) + Research Centres (Academia, others) + Individuals (brokers, consultants) + Customers (citizens, patients, cross-age, cross-IT literacy). The COIN project goal of addressing Innovation; in particular Open (‘to All’) Innovation, is attempted in the service design business use case [3]. The focus is to develop innovative support services in a participative way, with a citizen-centric approach, akin to a Living Lab-like ethos. The Ecosystem is considered to be a real breeding environment for all the participants, giving them voice to express their ideas and to see them implemented by COIN supported services.

4.3.1.2 Context

4.3.1.2.1 Healthcare Market Context The UK Healthcare market is considered by incumbent practitioners as not a commodity that can be produced by means of the investment and deployment of capital and labour resources. They argue; if it was then the United States, which devotes immense resources to health, would be the healthiest place in the world. Health can only be produced by engaging people and encouraging them to take active control of their own health. Of course the production of health care can be seen as a business. A business in which capital is invested and from which people earn their living. At the level of the individual concern there must be skills and approaches which would improve efficiency. The incumbents continue that the discipline of the market is not going to work in the NHS; the fundamental reason is that market discipline is centred on growth and failure. Selling more goods and services more profitably than your competitors is the only criteria for success in the market. But in public services success is more complicated. A successful health system would produce less health care, not more. [1]

4.3.1.2.2 COIN - Relevant market factors The mobilisation and incubation of target Citizens, community groups, SMEs, universities to develop local healthcare work plans which address the design, creation and improvement of existing services require the following goals to be observed by COIN. • Gain the input of large numbers of local people, business and community groups to

developing local healthcare work plans. • Improve the quality of health and social care delivery • Improve the competency of carers • Improve the training of community and care workers Potential benefits to SMEs are low cost access to COIN services, provision of easy start-up for SMEs in the area of collaboration. VEN can benefit as a Service and Application Intermediary attracting prospective members from additional channels and acquisition of business and market intelligence from the data sharing consortia, forming model for other SME’s to follow. Primary Healthcare Care market trends & requirements: • Move to patient centred view of the world

129

Eliminate fragmented and un-integrated care services • Commission by output, if not outcome • Relate to local planning • Reflect local circumstances

o Existing investments o Geographical locations o Other related developments e.g. Local Investment programme / Private + Public

schemes • Address issues re pace of change / commitment to full change

o Acute & Primary Care agendas o Role of Clinicians / GPs / Nurses o Financial - payment frameworks

4.3.1.2.3 Healthcare Market – Challenges Three long-term trends have been identified by McKinsey & Co; which is reaching a tipping point that will fundamentally transform the UK: an aging population, societal shifts altering what households look like, and economic factors slowing the expansion of wealth. As these trends sweep across Europe, to varying degrees they will impose pressure on consumption growth and dramatically change economic effect parameters. What are the fundamental questions for COIN to address in healthcare?

1. How to provide high-quality and affordable in dispersed healthcare networks. 2. Cater for patients at the heart of healthcare service procurement and delivery. 3. Crowdcommissioning – commissioning of healthcare services by the community 4. Introduce the COIN healthcare services whilst reducing costs and improving efficiencies

of services.

4.3.1.3 COIN Business Use Case requirements

4.3.1.3.1 Supporting social care networks in the ecosystem Final end users (patients, professionals, suppliers, citizens) members of regional associations called ‘Links’ are utilised for testing of COIN Services. These associations were originally formed in April 2008 and total 150 representing the English region of approximately 56m people. Their task is to communicate and represent their local communities in primary healthcare and social care delivery. Their operational concerns are primarily the ability of the Links to communicate with each other and the large scale public audience effectively and with an added barrier; that a large percentage of the community are unwilling or unable to access a computer (25 to 60% of the population). Additional operational concerns: management and maintenance of records between the Links organisation and its communities, recording incidents, management of complaints and monitoring activity outcomes.

1. Every link is designed to suit its locality – Rural/Suburban

130

2. Establish close working relationships with central healthcare commissioners for both service and policy delivery.

3. Co-ordinate logistics of visiting services including inspection visits to people in their home – mobile workers with little IT support

4. Design and implement Service improvement work plans, usually targeting key themes. 5. Manage Public enquiries including complaints about health and social care services

delivery. Community ICT Maturity Issues:

1. Effective communication between Links and communities 2. Use of emails as primary system – poor record retention 3. Access to & selling the network to the community ‘member’ 4. Need to assess competency of carers – broad vocational skill base 5. Mobile workforce 25-60% do not use a computer but have a mobile phone 6. Managing and monitoring treatment event management – Quality of care and its

effectiveness 7. Developing Election and Governance processes for members 8. Managing event and awareness management to attract the wider community 9. Managing funding received from local authorities and dept of health. 10. Delivery of Personalisation of health care spend for each individual patient

Other activity for the Links is to collect and manage feedback from their local communities, assemble this feedback into a local work plan which defines the desired range of services for the community; this work plan is then managed by the Links core groups. This activity is expected to create a large volume of records which need to be effectively managed; in addition performance management of the work plan needs to be catered for including incident reporting with a performance dashboard.

4.3.1.3.2 Requirements for Personal healthcare services Smart Health [2] described the overall COIN value propositions to the stakeholders involved in a regional Healthcare Ecosystem. In essence the COIN Smart Health is a SaaS-U Service. The value proposition moves away from traditional price and supply ‘sourcing’ chain models and introduces on-demand Enterprise Collaboration and Innovation value adding networks as the primary driver for increasing SME and local community market opportunities. It leverages SaaS models with advances in internet commerce, cloud computing and broadband adoption and linking into regional/national social, innovation and technology programmes. Through its activities it creates social capital and addresses long term regional, national and community social and economic benefits.

Table 8 - Example of COIN Smart Health Services developed for low intensity ICT ecosystems (greater detail available in COIN Business Use Case public deliverable [3])

Business Use Case Functionality Current Services – Existing Solutions

New Services – COIN Utility and Value Add

Ecosystem Operation (Horizontal Services):

Managing information and events.

• Web site • Blog • Social

• Generic Service Platform -security, search

131

1.Market Links & Recruit Members 2.Manage Events & communication 3.Form Interest Grp 4.Improve Service Levels 5.Deliver Training

Sign up community members, Formation of interest groups, Improvement planning and performance management

Networking • Excel/Word • Email • Bulk

Emailer

and discovery. • Legacy data

services - CRM • Human

Interaction (HI) services: trust, visualisation, user taxonomy • Knowledge

I/O services – web analytics and HI integration • Open

Innovation service – creative data analytics • Competency

Development

Personal Care (Vertical Services): Service User manages budget and sources care products and services

Manage budgets, Define funding sources and develop support plan. Purchase products and services.

• Web application – Personal Care

In addition to horizontal services: • Semantic

Support Services – Semantic search, reconciliation and supplier negotiation • Collaborativ

e Product Development Service • Quality of

Service and Dispute Management

Personal Care (Vertical Services): Service Provider manages a catalogue of products and services

Manage product catalogues, multiple price lists, private catalogues

• Web application – Personal Care

In addition to horizontal services: • Semantic

Support Services – Semantic search, reconciliation and supplier negotiation • Collaborativ

e Product Development

132

Service Quality of Service and Dispute Management

4.3.1.4 Discussion: past and present challenges, concerns and solutions

4.3.1.4.1 Preliminary results - Consolidated view of Services tested by VEN Typically the COIN services tested are at a development stage, future work would enable these services to fully operate in a production environment. The COIN services would benefit from an interchangeability statement for each service relative to each other and to aid selection and combination with other services. A number of services require a degree of expertise and prior knowledge, which may limit the take up rate of these services. Logic flow of some services is suitable for developers; however testing with non-specialists requires more information in help guides and installation and set-up phases. COIN services should fully exploit a ‘corporate’ identity; in addition some services should be released in advance of full implementation of the COIN system to provide process improvements and opportunities for market adoption. Access to COIN Service(s) installation and maintenance aspects and secondary services architecture is needed; as a function of customer support activity. Ongoing work for the usability will aid take up and adoption and address a number of bugs and usability issues. Preset templates would improve usage, with the use of bulk data updates since current ‘lab’ versions rely upon manual setups this is not suitable for production environments. The degree of data input and transaction complexity varies from service to service. Company own data formats are not typically considered as is the lack of multi language versions of the COIN services. However the COIN Services show potential if a strong co-ordination of current and future development is maintained. Greater detail in relation to user testing results can be found COIN public deliverable [4]. COIN Challenges • COIN services development into a production environment • Completion of integration phase and ongoing maintenance of interoperability • Management of 3rd party applications with coherent development roadmap • Maintaining concurrency of COIN services to market developments • Definition of COIN service costs and ongoing management costs • Identification of initial COIN operator • Mitigate the risk that COIN is trying to serve too many markets and applications • Addressing the increasing legacy spectrum, by such a wide array of service offerings • Implement Help and Support for COIN Services There is no direct competing package of Services at present, however due to the broad nature of COIN, its component services compete with a wide range of open source and commercial software packages. COIN will need to differentiate upon its collective value proposition; rather than compete head to head on pricing, the goal being to demonstrate: • Go-it-alone investment costs reduced

133

• Easier to establish new venture start-up • Broader offer than standard software, including collective intelligence/experience in its initial

design • Provide EU wide network access • Lower infrastructure cost of ownership – using a SaaS-U business model

4.3.1.5 Conclusions First, initial indications suggest that it is possible to describe the SaaS business model for service and application intermediary in a Healthcare ecosystem. It is also concluded that incubating the business model within the ecosystem with little relationship between members is possible, but will require the intervention of facilitated process by SaaS-U and COIN Health specialists. Secondary the review of market context has indicated that the timing for SaaS Healthcare business models is co-incident with a number of developing trends in healthcare and the wider economic climate; in that: • EU ICT and e-Health policy positions require a pan European solution. • UK Government Policy – requires a fundamental growth strategy to offset the economic

recession in the UK, driving open local, national and cross border market creation. • UK growth can be driven by UK public procurement directed to SMEs, with Healthcare the

greatest multiplier of all the public spending bodies. • The nature of the current recession; is the poor become poorer and exposed to greater

hardship. The Healthcare policy shift to the Health Dividend can potentially reduce the overall Healthcare bill and offset the need for greater levels of taxation.

• Growing use of Personalised Care Budgets for long term and end of life conditions within the healthcare arena presents a market opportunity for local SMEs and Social Enterprises, as increased outsourcing to local providers by the NHS and Local Authorities.

• The general trend of Customer demand for aggregation of spends – fewer 1st tier suppliers • Increased market for on-demand services where the initial start-up infrastructure is low or

non-existent. • Global sourcing and the need for harmonized structures and contracting • On-demand innovation processes and systems. • On-demand management processes and systems. • Increasing need to manage complexity by integration of many to many relationships both

supplier and customer. Continuous review of the service design business model process is mandatory, since this action research combined with the use of mental modal allows unrestricted forward or backward movement through the modelling process; in this case the methodology is seen as a landscape rather than a linear sequence of steps. The level of time and effort invested into the research; especially creation of service and business model frameworks, strongly effects the outcome and acceptance of the business model. Secondly creation of the business model framework is greatly improved by the review of the ‘As-Is’ condition and the ‘To-Be’ condition of the selected business/sector context with actors from the context selected. The definition of the benefits is essential at the outset to retain input from ecosystem actors and develop the business model with greater usability.

134

The initial service & business model process; required a level detail from the use of context(s) to establish scenarios. The COIN project has a vision and exploitation plan; however such a complex ecosystem requires the input of end users, policy makers and economic reality each with their own perspective and interpretation. This counters the tendency to create either a system without a market (technology led) and enable end user involvement in the service design and hence at least one major variable of the business model. Additionally correlation is needed between the stakeholders, market influencing factors and influencing variables within the process. This step allowed the refinement of the business model to reflect more closely the overall vision, in this case COIN, producing a ‘as-is’ and ‘to-be’ condition. The use of face to face dialogue with ecosystem actors was essential since the low technology maturity of the sector dictated this approach, it is concluded that future approaches would be more productive if a maturity assessment is conducted prior to engagement, but this should not be used to select convenient sectors or ecosystems, but as guide to the engagement process. References [1] Socialist Health Association – www.sochealth.co.uk [2] COIN project (FP7 IP 216256). Smart Health – COIN Deliverable D6.2.1a, 2008 [3] COIN project (FP7 IP 216256). Business Use Case – COIN Deliverable D6.1 [4] COIN project (FP7 IP 216256). Final End User Testing, Demonstration and Take-up – COIN Deliverable

D6.6x

135

4.3.2 An EI/EC Pilot in Pöyry business eco-system Timo Syrjänen, Mikko Höynälänmaa1

1{timo.syrjanen, mikko.hoynalanmaa}@poyry.com

Abstract This chapter describes the pulp & paper case of COIN represented by Pöyry. The context is engineering of large capital products, like pulp & paper mills in a multi-partner, multi-location environment. The main focus is on supporting collaborative project management.

4.3.2.1 Short description, as-is situation Pöyry is a global consulting and engineering company, dedicated to balanced sustainability. Pöyry offers its clients integrated management and consulting, total solutions for complex projects and efficient design and supervision. Pöyry has 7000 experts operating in about 50 countries, locally and globally. Pöyry's net sales in 2009 were EUR 674 million. Pöyry has project experience in more than 100 countries and conducts 17 000 projects annually. Typically a pulp and paper mill project costs are 100 - 1000 million € including engineering work about 1 – 10 million €. Project duration is normally 6 – 36 months, involving 10 – 150 engineers (100-1500 person months) and 10 – 30 different actors such as owner, suppliers, engineering consultants, authorities etc. Project work is typically globally distributed.

4.3.2.1.1 Pöyry Business Ecosystem Figure 64 illustrates a typical cluster or Business Eco-System with actors in facility engineering projects. Collaboration between the actors is essential and needed in every project. The project structure and organization can be different in each project.

Figure 64 - Business Eco-System with actors in facility engineering projects

Currently a transition process to global operation is taking place. Projects and organizations are geographically distributed. The objective is to be close to the customer and to move work not people. The ultimate target is a system of global shift work with work moving around the globe

136

on a daily pace through Asia, Europe and the Americas. Time schedules will be substantially shorter and cost can be reduced as a result of significantly competitive labour rates. At the same time information and knowledge sharing will result in a maximization of expertise. The challenges in global collaboration and interoperability comes from a distributed organisation involving different languages & ontologies, cultural differences, different time zones and latitudes, work ethics and different legal systems. Communication is the key to overcome these differences. In addition to engineering offices which partly belong to Pöyry company, the ecosystem involves also other actors, like customers, suppliers and authorities.

4.3.2.2 Objectives and Expectations from COIN The Pöyry case in COIN addresses Knowledge Interoperability in Pulp & Paper Ecosystems aiming to experiment, trial and demonstrate COIN innovative project management services focusing on multidisciplinary project management and continuous project alignment in industrial projects. In the Pulp & Paper case the developed COIN project services can help and improve challenges in global collaboration and interoperability such as aligning different practices, identification of training needs, creating common understanding of project objectives and requirements, monitoring the project status, identification of deviations as early as possible, pro-acting to prevent delays and other risks. Figure 65 illustrates the main areas where COIN project services can be an important factor supporting the new Pöyry vision and strategy. COIN services can accelerate the transition to global operation and networked engineering. The three key areas are: • Maturity of the network • Collaboration and communication • Project management services

Figure 65 - Accelerate transition to global operation and networked engineering

Pöyry's vision for 2020 is to be “the global thought leader in engineering balanced sustainability for a complex world”. Engineering has always been at the core of Pöyry and for decades the company has been involved in projects with sustainable dimensions. The key difference with the new company vision is that sustainability is placed at the heart of everything Pöyry does. Pöyry sees a balanced approach to sustainability as the best way forward for the company, its clients and society.

137

The COIN project directly supports the Pöyry future vision and strategy. And the developed services and assets can be utilised to achieve this new vision.

4.3.2.3 COIN solutions identified and used As a starting point Poyry was most interested in the development and take-up of Collaborative Project Management services. The main services in this area taken by Pöyry were Collaborative Project Alignment, composed of several subservices, and Meeting Process Management Services. For these areas Poyry had some preliminary requirements and expectations for the services. However, during the project additionally some new services were identified useful (services, which were not in the requirements in the beginning). These were for example social ontology building service (SOBE) and the collaboration maturity model (ECMM). As a whole, the coverage of the services was one of the strengths of COIN.

4.3.2.4 Business Benefits The main services used by Pöyry in COIN are the Collaborative Project Management (c-PM) services. The c-PM services can make the project management more efficient, but the main benefit is coming from the better project execution. Thus even if the project management can be performed with lower resources using the COIN services, this is not the main benefit. The main benefit is coming from that the engineering project can be carried out with improvements in costs, time, quality and decrease of risks. Consequently, in the benefit identification also the processes affected by the supported processes should be viewed to see the total benefits. The comparison of “as-is” and “to-be” proved to be challenging for some processes. This is because the take up of the COIN services not only changes the existing processes but they may create totally new processes, which may include parts of some previous processes, but are not identifiable in the previous processes as such. Even if the focus area of COIN was Collaborative Project Management and therefore the viewpoint of project management was strong, we see that all the partners in the business ecosystem can benefit of the services. The collaborative approach for the management allows the partners to participate more in the management and thus utilize better their knowledge and resources. The more aligned execution of projects makes the whole ecosystem more competitive in the engineering market.

4.3.2.5 Lessons learned

4.3.2.5.1 Legacy System Integration Some of the COIN services are so innovative that there is not yet sufficient information for them in the legacy systems. Examples are the alignment data required by the alignment booster and the trust data required by the human-interaction services. The data required for the testing and demonstration was collected manually in this phase. In the future some of this information may be available in legacies.

4.3.2.5.2 Future expectations Pöyry prefers in the future to consume services from a cloud and also having data in a cloud. However, there are some exceptions, like projects for high security customers. All customers will not accept the data in a cloud.

138

As a business model SaaS is preferred. Pöyry would also like to have engineering tools as SaaS, using them from the cloud, and also supporting the engineering process. There is a need for new developments and new services in this field. The main challenges for the rollout in the business ecosystem come from the heterogeneity of the partners. The capabilities are not at the same level in the business ecosystem. In some locations, like China, also the physical network is a challenge so far.

139

4.3.3 An EI/EC Pilot in an Agro-Food Living Lab (WirelessInfo) Karel Charvát1, Otakar Čerba1, Pavel Gnip1, Karel Charvát jr1

1 Wirelessinfo,Litovel, Czech republic

charvat@wirelessinfo.cz

Abstract In this chapter factors influencing farm management and profitability of agriculture are described. There are introduced two services, which are being developed with aim to increase profitability of farmers. The services are Tactical production planning and Search for providers of machinery. Part of these services is using solutions developed in COIN project.

4.3.3.1 Introduction The agriculture sector is a unique sector due to its strategic importance for both European citizens (consumers) and European economy (regional and global) which ideally should make the whole sector a network of interacting organisations. There is an increasing tension, which is not experienced in any other sector, between the requirements to assure full safety and keep costs under control. Food safety and food security is now a strategic interest not only of Europe but worldwide. The balance between food safety and food security will be an important task for future farming worldwide, but also for farming decision making. There exist a number of external drivers, which will have potential influence on the farming sector in the future. We can consider the following groups of drivers, which will have an influence on farm management and which eventually will stimulate new demands on knowledge management: • Climate changes • Demographics (growing population, urbanisation and land abandonment) • Energy costs • New demands on quality of food (Food quality and safety) • Aging population and health problems (ethnical and cultural changes) • Innovative drivers (knowledge based bio economy, research and development, information

and communication, education, investment) • Policies (subsidies, standardisation and regulation, national strategies for rural development) • Economy (economical instruments, partnerships, cooperation and integration and voluntary

agreements) • Sustainability and environmental issues (valuation of ecological performances, development

of sustainable agriculture) • Public opinion (press, international organisations, politicians) In accordance with FutureFarm we can consider three levels of farm knowledge management: • Macro level, which includes management of external information (for example about market,

subsidies system, weather prediction, global market and traceability systems), • Farm level, which includes for example economical systems, crop rotation, decision

supporting system, • Field (micro) level including precision farming, collection of information about traceability

and in the future also robotics. The basic principles of interrelation can be expressed by Figure 66.

140

Figure 66 - Interrelation of different knowledge levels

4.3.3.2 Open agriculture services The practical experience demonstrates that main research is currently focused on precision farming methods, which are mainly related to operative decision on micro level. On the other side it was documented, that the right decision on the base of macro level information has a main influence on the profitability of a farm. The goal of COIN OAS in the agrifood sector is to develop a collaborative adaptable and interoperable solution, where the users will be able to share interoperable data and information using trusted methods for information sharing, which will protect information against potential competitors (important for agriculture). OAS, which are being developed, introduce a new model for effective agricultural e-collaborative knowledge management. Some parts of Open Agriculture Services are being developed as a part of other projects, or outside projects. In OAS two services have been identified as the most suitable use cases for the COIN projects: • Tactical planning for next seasons • Search for provider of machinery Tactical production planning The COIN tactical planning module is focused on introducing new methods oriented on tactical planning for the next seasons. The main goal of tactical planning is to recommend optimal production and land use for the next seasons to maximize expected profits. The goal for tactical planning is to recommend production for the next season, eventually also some vision for the next (two till five) seasons. The decision problem could be described in this way: A farmer has a number of parcels with different properties available for his production. It is possible to grow different kinds of products on these lands. On each of these lands it is possible to grow at maximum one product using one of two methods: • Production without using variable fertilizer application. • Production with variable fertilizer application.

141

Due to many reasons, for example crop rotation and field localization, it is not possible to grow each of the products on each of the lands in the next season. In this approach optimal production plan and profit for each scenario has to be computed. The key problem for the decision is the existence of data. In case of farmers, who were using precision agriculture in the past, it is possible to estimate many data values with quite high accuracy. Obviously most of the information does not exist in farm information systems in the form requested by the model. The interoperability of data is missing; we need tools transforming data into the required form. To get values of some data it is necessary to create procedures, which will calculate the values from available data. However some of the data values have probabilistic character. Selling prices of each product kind is very difficult to predict. The yields per hectare of some products and costs also bring some uncertainty into the decision problem. The approach which is used in case of parameters, which are difficult to predict, is creating several scenarios for factors, which are affecting values of these parameters. For generating scenarios a lot of external information is needed. Mainly in case of prices, we probably are not able to do without services of agricultural analysts. We will consider two approaches to scenarios. In the first approach the optimal production plan and profit for each scenario has to be computed. For each of these production plans, the value of profit in case of all other scenarios is expressed. Then a suitable method of choosing one of the production plans is used. The second approach is based on multiple criteria mathematical programming. In multiple criteria mathematical programming problems, there is more than one objective function. In case of our problem, the individual objective function represents profits in different scenarios. Solutions found by solving multiple criteria mathematical programming are called compromise solutions, because most of the problems don’t have a solution providing the best values for all objective functions in the same time. For these purposes, it is necessary to use some of the available modelling systems and optimization solvers. These tools have to be integrated with the current Prefarm SaaS information system using COIN MDIS. Purchasing commercial software belonging to these categories is usually very costly. In this moment we are using the modelling system PuLP with a modelling library created in Python. The basic system architecture is divided into three layers

Figure 67 – Three Layers Architecture

Liferay interface guarantee communication with end users, but also authorisation and authentication. Layers of portlets or iFrames guarantee communication with single components or databases. Database and service layers is layer, where single components really interact. From component point of view architecture could be characterised by next components:

142

Figure 68 – System overview

Architecture allows discovering and selecting information sources from existing services - precision farming database, sensors and other existing databases and combining selected information into form of Web Feature Services (GML format – version of XML for Geographic Data. The geographical data are shared using services defined by Open Geospatial Consortium. For optimisation processes it is not necessary to use directly spatial representation of objects (areas, etc). For optimisations it is necessary to transform data into tabular form protecting only identifier of graphical object. This identifier is later used for merging optimisation results with graphical object for visualisation. In MDIS there is defined transformation model for transformation data into interoperable form. Own development is focused on Optimization module which is generating variants of production plan. This information is transferred into graphical form and visualised using visualisation client. Search for machinery providers The main purpose of the use case Search for provider of machineries is to enable a farmer to search for machinery providers in his region. The farmer will be able to search providers, who registered their offer of machinery and services in the catalogue connected with an advisory system. The machinery provider will have to fill in data, which are necessary for a farmer to choose the most suitable offer. The machinery can be offered in two ways: • Pure machinery • All inclusive (with operating staff) Main target is to support using geo-information technologies to enable building communities and efficient cooperation making for cost reductions in agriculture sector. The main functionality based on COIN SCMS is semantic searching of producers, owners, products (agriculture machines and tools) based on specification of the weights of importance of different parts of

143

query. Other functionality is on-line updating of knowledge base (ontology) describing the products and tools. The system is composed of three main parts (except external communication modules): ontology (knowledge base, described in OWL 2.0 format), semantic searching system (SCMS), editor tool (making possible to modify or add source data stored in ontology) and semantic searching tools. The system should cooperate with Maplog – system used to cars (or machines) control.

Figure 69 - Architecture of Machine searching

4.3.3.3 Conclusion Now let’s try to evaluate the impact of the new services, which are being developed. Existing farm management systems were mainly focused on operational decision about fertilizers, amount of pesticides, etc. Long-time analysis demonstrates, that this operational decision could increase farm profitability around 15%. On the other side last year’s market development demonstrates, that the changes in price of agriculture productions from one year to next could change about 200 or 300 percent. So from this fact it is clear, that right production planning could significantly influence farm profit and that the incensement of profit from tactical planning could be bigger, than from operational planning. The new system generates new possibilities for advisory services related to market data analysis and recommendation preparation for farmers. These types of services have not been used until now, because current systems don’t allow sharing data and don’t offer instruments for such a type of services. Open agriculture services (OAS) will improve cooperation in production, consultancy and supply chain, because they will support better collaboration and information exchange. Sharing of data and services will increase quality of collaboration, common workspace will give possibility for better communication among farmers, farmers and services and farmers and consultants. OAS will give chance for better utilization of machinery like harvesters, spreading machinery and others, which are used only for a small part of the season. The system will help farmers having such machinery to sell parts of their machinery capacity as services.

144

The pilot experiments demonstrated, that interoperability of agriculture information is one from key problems for future knowledge systems. Transforming available information into unified data model for taking tactical decision provided by MDIS module helps to use information for effective decision. The development and population of ontology focused on agricultural sector based on the ontology published in COIN project helps to search more effectively for information and will help to more effective utilisation of investment and machinery. References [1] Cerba, O., Charvat, K., Charvat, K. jr., 2011. D7.1.4 COIN - EEU EC services Annex III -Wirelessinfo

services, Report from COIN project [2] Charvat, K., Charvat, K. jr., 2011. D7.1.3 COIN - EEU EI services Annex I -Wirelessinfo services, Report

from COIN project [3] Charvat, K at all D1.2.3 Visions and recommendations for knowledge management, Report from

FUTUREFARM project. [4] Charvat, K., Gnip, P. and Mayer, W., 2009. FutureFarm vision, IPCA congress 2009, Wageningen. [5] Charvat, K., Gnip P.,Vohnout, P., Charvat, K. jr. VISION FOR A FARM OF TOMORROW, IST Africa

2011, Gaborone, Botswana [6] Gnip, P., Charvat, K. and Krocan, M., 2008. Analysis of External Drivers for Agriculture, IALD WCCA

INFITA congress 2008 Tokyo. [7] Jensen, P. A., Bard J. F. 2003. Operations Research - Models and Methods. John Wiley & Sons.

145

4.3.4 An EI/EC Pilot in a Digital Media Living Lab (FAVIT) Konstantin Hristov

Abstract In near future every SME in Europe will realize the need to adopt suitable digital media tools for the purpose of their digital content marketing and act as a media in order to engage target communities around selected topics. On the other hand the media companies will have to change drastically in response to the challenges posed by the decentralized, social web. The line between the media company and the SME will merge to large extent as only the nature of the distributed content would make the difference, but not the technology and tools used. This will create the need for both company types to use collaboration and interoperability services and work patterns engaging efficiently with external consumer communities as well as partners and experts outside the business entity.

FAVIT is conducting real situation trials, using the business cases of one Bulgarian SME and one classic media company to test the usage of collaboration and interoperability tools created by COIN in connection with the favit platform that is a powerful real-time content distribution tool. In the process of the live trials the test team measures critical feedback against a set of specifically developed indicators. The results will contribute to the validation of functionality set, implementation patterns and exploitation strategies of the tools allowing business entities to easily and efficiently collaborate and interoperate.

4.3.4.1 Collaboration and interoperability tools used within a digital media environment FAVIT, an innovative web technology development company and a founding member of the Digital Spaces Living Lab (DSLL) located in Sofia, Bulgaria is conducting a live trial, combining selected COIN baseline services with FAVIT’s cloud based platform for real-time content distribution with the aim to deploy and test collaborative business processes on top of an interoperating platform that shall improve the efficiency of digital media ecosystems built in and around SMEs. With the selection of the actual business use cases as test beds for the live trials, FAVIT is aiming to address the challenges that SMEs from the EEU are currently facing and would face in mid-term perspective within the digital media space. Although massively adopting the social media channels (predominantly blogs, social networks such as Facebook and Myspace, micro blogging platforms such as Twitter and networking platforms such as Linkedin), SMEs are the frank losers in the social media revolution. SMEs of all industries are still unable to successfully establish a social media presence, nor utilize social media technology and web 2.0 tools and technologies and are largely unable to use various social media channels to engage and communicate efficiently with the online communities. The self-stated reasons are:

1. Size: too small (insufficient resources to create content and traction) 2. Capability: lacking resources outside the core business activity to manage online

communities With the help of our partners within the DSLL we have analyzed the situation/trends related to the implication that the ever expanding digital media/technology domain causes on the SMEs from all sectors and decided to conduct live trials involving two SMEs of different types:

1. A media company that faces the challenge to adapt to the new real-time content distribution, optimizing internal structures and drastically reducing cost in the process

2. A hospitality company that offers touristic services and infrastructure that aims to make the transition from conventional marketing towards digital marketing relying heavily on new digital media technologies and compensating lacking in-house skills through collaboration with external partners

146

In its first use case, with the help of selected collaborative COIN tools in a useful bundle with the functionality provided by the FAVIT platform we are effectively addressing the challenges faced by the media companies not only from Bulgaria, but globally:

1. Providing up-to date content on specialized editorial topics (time relevance) 2. Providing trustworthy content in real time (credibility) 3. Providing quality content in real time (enthralling, accurate and exhaustive) 4. Ensuring broad geographical coverage at a minimum cost 5. Ensuring the desired skill set within the editorial team (talent recruitment and

management) 6. Reducing costs

The following indicators are used in order to measure the effect of the live trial: • Reaction times • News delivery time • Cost per news piece • Time relevancy of news content • Content reach • Channel relevance • Media competitiveness The second live trial tests an innovative concept in the digital media domain: the collaborative crowd sourced curation as main part of the corporate content marketing. It is about collaborative curation of business related digital content and multi-channel distribution of that content as part of the organization's content marketing and advertising strategy. The trial partner is creating and distributing content like live feeds from slopes and events, news pieces, movies and images as part of its content marketing. The corporate goal is to:

1. Channel more relevant proprietary and non-proprietary content 2. Achieve a bigger reach of/for that content 3. Perform very efficient campaigns promoting its services

The indicators that shall measure the success/failure of the second live trial are: • Volume of relevant content • Content reach. Number of channels and depth of penetration • Volume and quality of Interaction (likes, comments and re-shares) • Number of subscribers

4.3.4.2 COIN solutions identified and used The Bulgarian digital media use cases support the COIN vision that its most efficient exploitation form is as a federated platform rather than a “walled garden” solution. In this vision COIN is developing towards an ecosystem consisting of many collaborative platforms interoperating in sync and accessed through a unified search and distribution interface. Furthermore, every one of these collaborative platforms acts as an access point to the baseline services hosted on the central COIN cloud.

147

FAVIT is conducting live trials not only to test several parameters of the already prototyped collaborative COIN tools but is also fore-playing the interconnection between the COIN platform with external collaborative platforms. In the process of business analysis we have identified the following baseline services to be used for the purposes of the Bulgarian digital media case: • Trusted Online Help and Support (TOHS) –helps employers, project managers and others to

dynamically find the right person based on situational awareness; e.g., discovery of and interaction with an expert who can assist to solve particular problems, requiring specific skill set.

• Interoperability Space Service (ISS) is a negotiation tool for exchanging and negotiating business documents in UBL format.

• Collaboration Virtualisation Tool (CVT) visualizes relations and trust levels within a given human collaboration network. The tool serves as a complementary tool to TOHS and support decision making prior to expert engagement and forming of virtual teams. CVT determines the quality of relations based on previous joint activities, interactions such as communication, coordination, execution etc.

Creating seamless bridges between the COIN and FAVIT platforms is essential for our scenarios. In the process of trial preparation several gaps have been identified. Their rectification would increase the future exploitation potential of the COIN platform and will make it better suitable for commercial use. • COIN search interface misses the specific digital media ontology • Interface for dynamically exchanging data between COIN and FAVIT through a standard

COIN API

4.3.4.3 Measured Business Benefits The following metrics measure the success/failure of every business use case that we conduct:

The business level targets were jointly defined with the trial partners. For the media company use case they are as follows: • Decrease time to market for news pieces - factor of 8 decrease

148

• Decrease cost per news piece - factor of 11 decrease • Increase in daily traffic - 45% For the touristic use case they are as follows: • Increased community membership - Factor of 5 increase • Increase of communication reach - Factor of 4 increase • Increase in accommodations - 3%

4.3.4.4 Lessons learned During the preparation of the use cases, the integration, the actual prototype testing and test bed execution the FAVIT team has acquired considerable feedback that could be categorized as follows:

1. Collaboration requires a huge shift in mentality: as EEU companies enter into collaborative groups driven by the fear of being wiped out by someone bigger, or enter with the expectation to abuse the collaboration for their own benefit.

2. Interoperability is handicapped by fear of being exposed and vulnerable through the data sharing and the usage and storing sensitive company-related information in the cloud.

3. The User Interface of all COIN tools shall follow strict guidelines. Building bridges of familiarity between well-known Microsoft Office derived interfaces and the COIN tools will ease up adoption.

4. Unified help section structure.

4.3.4.5 Exploitation One account for all the COIN tools and platforms within the COIN ecosystem is a must. Trade-off between case/tool usage simplicity and company commitment to adopt collaborative tools Future COIN marketing/dissemination

1. We have identified a huge marketing potential in the eventual collaboration between COIN and established (though declining) SME specialized software publishers like SAGE/DATEV/DAVILEX/AVANQUEST in Europe or INTUIT in the US.

General lessons 1. Living Labs - a great platform to mix academia and the tech industry with the real

business. Very suitable as a multiplier platform. 2. The bigger player – not always a good entry point for research projects, but always good

as a multiplier (dissemination and exploitation hub) References [1] Social times http://socialtimes.com [2] The COIN portal http://www.coin-ip.eu [3] Software shortlist http://www.softwareshortlist.com

149

5 COIN in the Business

The Enterprise Interoperability (EI) concepts and paradigms are being widely accepted as a mean to improve European Industry competitiveness with respect of the globalized world and markets. The research activity in this domain, especially the one supported by the European Commission, has led to significant results and the main technological gaps have been removed or at least addressed. The COIN EI / EC services are devoted to support the life-cycle of business-oriented collaborations, from their preparation in proper long-term environments, to their formation matching business opportunities with possessed competencies, to their operations and management by measuring and governing proper performance indicators, till to their dissolution and the re-use of the experience gained. In this chapter the experience and the scientific activity of the COIN Project is reported in view of future market applications from adoption of EI / EC Services at supply chains, collaborative networks and business ecosystems level to new form of business models addressing such challenging novel technologies. The development of enterprise software as Service-Utility can offer viable commercial business propositions addressing enterprise interoperability and collaboration as well as new methodologies (inspired to maturity model) to assess organizations in their readiness for adopting EI / EC Service in networked environments. In this chapter: "Supporting EC&EI Services usability and take-up", "SaaS-U Value Proposition and Business Model", "Bringing COIN to the Market", "Enterprise Collaboration Maturity Model".

150

5.1 Supporting EC&EI service usability and take-up Iris Karvonen, VTT

Abstract The paper focuses on supporting the take-up of Enterprise Interoperability and Collaboration Solutions in supply chains, collaborative networks and business ecosystems. Software service usability, organization maturity and participatory development and take-up process are seen as requirements for end user success. To achieve the expected business benefits, technical development and implementation is not sufficient, but also organizational implementation and end user involvement is needed. This has been performed in COIN through cross teams of research, development and end user organizations. The process has been supported by usability assessment, collaboration maturity analysis and guidelines for the implementation process.

5.1.1 Introduction Information technology is today not only a support function to make intra- or inter-organizational processes more efficient but also an enabler for many business and non-commercial activities. IT, developing towards Future Internet systems, enables also SMEs to participate in global activities as part of supply chains (SC), collaborative networks (CN) or business ecosystems (BE). In COIN project, solutions to support Enterprise Collaboration (EC) and Enterprise Interoperability (EI) were developed, as described in chapter 3. Achieving the benefits by taking up IT services, is, however, not automatic even in one organization. In an inter-organizational environment the challenges are even higher because of heterogeneity and mutual dependencies. The development of IT towards Future Internet Enterprise Systems (FInES) with software offered as services and utilities, is expected to remove some difficulties of IT utilization. FInES are expected to offer more flexible configuration, scalability and openness and decrease technical barriers [6]. On the other hand, Future Internet does not remove the need to take into account organizational aspects, especially in cases where several users, functions or organizations are affected by the system. The main prerequisites affecting the success of the solution implementation in an organization / network have been identified as: • adequate usability of the EC & EI service / solution • appropriate inter-organizational implementation process (also affecting the solution fit) • sufficient maturity for collaboration and IT usage in the network. The factors are dependent on each other and about the scope of the IT implementation. For example, the maturity of the enterprise affects both on what is usable for each case and how the implementation should be carried out. The usability requirements are higher for a company with low experience about collaboration and usage of IT tools (low maturity). Also the inter-organizational implementation process is dependent, in addition to the service scope also about the level of collaboration in the network or business ecosystem. If the collaboration maturity is low, additional actions are needed to create the base for successful implementation. COIN has supported these three aspects by reviewing and assessing usability, taking a user-involved approach in the development, developing take-up process guidelines and methods to analyze and support EC & EI maturity. This paper discusses the first items, analysis of collaboration maturity is described in chapter 5.4.

5.1.2 Barriers and Challenges for IT take up Information technology providers claim remarkable gains when using their services. However, for companies, especially SMEs, it is challenging to achieve the expected benefits by IT take-up. It may be difficult to understand how to use the technology and how the processes should be

151

changed. The high resources, knowledge and capabilities required for the take up seem to restrain the adoption of IT in SMEs: “Often small and medium-sized companies will not have the knowledge or resources available to carry out the configuration, adaptation, or integration work by themselves” [5]. “The actual implementation of use of ICT in business processes, especially those involving customers and suppliers, remains limited.” [6]. Especially SMEs suffer of unfinished IT projects, unrealized savings, delays and exceeding the take-up costs. Experiences gained in earlier implementation projects affect the future user’s attitudes for a new implementation project [12] and may hinder the will to start new implementations. Lack of awareness of the possibilities and benefits that ICT could offer is also considered as one barrier for ICT adoption by SMEs [6]. The technology and vendors with approaches from onsite to cloud-based solutions make many SMEs confused and willing to wait until the market settles down [19]. On the other hand, when always following others’ the enterprises cannot be in the lead, gaining the potential competitive advantages [14]. Recently, supporting business innovation has been seen to become an important objective for future enterprise systems [7]. In collaboration networks, in an inter-enterprise environment the challenges of IT take-up are higher than in single organizations: • The partners are independent enterprises, they have greater autonomy [15] and the decision-

making is distributed. It may be difficult to reach a common decision about the IT take-up and understanding about the new processes. Take-up of systems or services supporting collaboration is not fully successful if all partners are not interested and capable of using them.

• The systems or services are not always as beneficial for each enterprise – for some they may create benefit, while for some others the system may mean only additional work.

• Inter-enterprise environment has additional complexity because of more units, functions, and locations.

• There are differences in concepts, cultures, processes, practices, skills and management styles between network partners.

• Openness is not always accepted between organizations. Thus more careful specification of access rights is needed than inside one organization.

• Companies may collaborate within several networks. They are not willing to take up and use many parallel systems, processes and practises.

Thus, the organizational implementation process needs to be extended to an inter-organizational process. Inter-organizational ICT implementation may be defined as the process and actions required to adopt the ICT tools & services into operational use in the network, including the necessary process changes and end user participation. On the other hand, the emergence of new IT technologies, like Future Internet Enterprise Services, is assumed to facilitate the IT utilization. The visions in Future Internet Enterprise Systems and cloud computing foresee services to be available “on-fly”, with low cost and with more flexible configuration, scalability and openness [6]. The services will be available through generic service platforms and the need for local technical software set-ups will decrease. Thus, the technical barriers for IT utilization are envisaged to decrease. The availability of low cost services should also remove some economic constraints, at least for “mass-services”. Still, understanding how to use the “on-fly” services in the organization and between organizations, is needed. This should be built in the take-up process in collaboration and interaction of the actors. Showing the full benefit of the ICT thus requires that not only technology but organizational aspects are taken into account in the take-up process. One method is the involvement of different stakeholders in multi-disciplinary teams (cross-teams). It is

152

foreseen that “the power in the development of future enterprise systems will progressively move from IT specialists to business experts” [7]. As the technology is expected to evolve into easier and more usable systems and services, the significance of the organizational take-up process will increase.

5.1.3 Development approach: Cross-teams The development of services in COIN was performed with two main cycles, from end user requirements through development and testing to take-up and demonstration. Six end users, representing Collaborative networks (CN), supply chains (SC) and Business Ecosystems (BE) were involved in the development. At a later phase of the project, 6 additional test cases were taken to the project. These are described in chapter 4 of this book. To ensure the interaction of research and development and end users, cross-teams were organized around each end user scenario. The end users acted as the cross team leaders. In addition to informal interaction the development process was supported by usability assessment of the developed services, performed by end users. The assessment was built on existing approaches for usability, adapted for the context of Enterprise Collaboration & Interoperability and taking into account the requirements of end users. The consolidated feedback as recommendations for development were shared and discussed with the developers, to make improvements in the next development cycle. To support also future users, not only the partners involved in the development phase, guidelines for the take-up of COIN services were developed. The development was based on the identification of implementation challenges, both from the previous research and from the experience of COIN end users, reviewing the existing models for software lifecycle and implementation process and development of success criteria for COIN context [11].

5.1.4 Contributing to usability in EC &EI context

5.1.4.1 Usability definition As discussed before, usability of a service or a system is seen as an important condition to achieve end user acceptance which is needed for realization of benefits. There are different definitions for usability. Abran, et al. [1] and Seffah et al. [17] present collections of usability definitions from different standards. ISO9241-11, 1998 defines usability as “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” “Software is usable when it allows the user to execute his task effectively and with satisfaction in the specified context of use.” In addition to different standards, there are also other usability frameworks or metrics, like MUSiC (Metrics for Usability Standards in Computing), DRUM (Diagnostic Recorder for Usability Measurement), QUIM (Quality in Use Integrated Measurement) consolidated model [17], Enhanced Usability Model [1], Hornbaek [8], Shaw et al. [18], Leung (2001) and iSURF-project approach [20]. The usability attributes of the different frameworks are quite similar. Effectiveness, efficiency and satisfaction are present in most frameworks, some attributes, like understandability, learnability or memorability are not as common. Different attributes for take-up and maintenance are presented (portability, adptability, flexibility, customisability). Some approaches identify safety, security or reliability as part of usability, for some it is not included. Definition and contents of usability is dependent on the context. To support the usability assessment of COIN services, a COIN specific definition of usability contents was created. The definition of usability in COIN had 7 dimensions: • Effectiveness– the benefit / value to the company/ network . • Efficiency- the performance of the service. • Understandability - how understandable the service is for the user.

153

• Satisfaction & Attractiveness – do the users feel satisfied with the service? • Learnability, memorability - How easy it is to learn to use the system and return back after a

break in usage. • Use preparation & maintenance – How easy the service is to take into use and maintain. • Suitability to network/collaborative environment– How well the service fits to network

environment. The dimensions and the the background information is presented in more detail in [3].

5.1.4.2 Usability assessment in COIN The seven dimensions were developed further into a usability assessment excel-tool to support COIN service development. In this way user feedback on usability was received during the development phases, to support going towards simplification and usability of the solutions. In the test phase, end users gave also recommendations for the service development. To support the interaction in the cross-teams, and to ensure, that the developers are aware about the end user views, the recommendations were consolidated and circulated among the developers and the developers were asked to give their response for each recommendation: what they plan to do with it. Most of the services were tested by more than one end user and similar recommendations appeared in the feedback of different users. The most repeated recommendations related to: • more guidance and training; 18 recommendations dealt with this • understandability, learnability, user interface, visualisation; 10 recommendations • usage of local language: 5 recommendations • supporting data input/ creation: 4 recommendations • addressing legacy systems: 3 recommendations • security and safety: 2 recommendations Additionally service-specific proposals were given. The recommendations were used for further development.

5.1.5 Development of COIN take-up guidelines

5.1.5.1 COIN end users’ experience before COIN COIN end users represent different industrial fields and collaboration forms. To review the challenges and practices of IT take-up in their collaboration environment a collection of the end users’ experience before COIN was performed about: • barriers hindering the take-up: which factors decrease the interest of enterprises to start the

implementation process? • challenges in the take-up process: what kind of experience do the end users have about

implementing IT services in their environment? The barriers and challenges are of course interlinked, as many of the barriers come from challenges experienced in earlier projects. The main barriers identified were: • The benefits of IT take-up are not seen clearly enough, the potential is not known or the

benefits go to someone else. • There is a resistance to change and the take-up is considered too complex. • The take-up is expected to have high costs and cause too much additional work.

154

• There is a risk of failure, delays and even dropping out of the business. • The enterprises need to believe in the security of the solution and to be convinced about the

sustainability of the solution and the solution provider. To overcome these barriers the end users expressed a need for success stories, visibility, strategic approach and demonstration of benefits. Demanding customers may act as an important driver for the end users to take steps towards IT utilization. Experienced challenges included: • lack of information or understanding of the tool and lack of training, • slow progress of implementation, excessive functions, tool structure, volume of data • communication problems, problems with multi-disciplinary teams • user attitudes, too low readiness for the take-up, and end users unwillingness to use the new

tool, cultural behaviour and aspects Based on the experience, requirements for success involved sufficient communication, management commitment, end user acceptance, user support, customised training, roll-out project planning and management etc. It was essential to ensure the business continued operating whilst implementing a new system. The following recommendations for IT roll-out were identified: • Agree IT strategy and benefits, assess complexity of implementation, calculate costs based

on worse case scenario, assess skills and resources to implement, engage core team for implementation, and formal training in place.

• Management support is needed; 100 % top management commitment which is also visible, is essential.

• Define responsibilities, clear business case, ensure programme delivery personal and structures are in place, maintain a global common approach, and allow for local practice. Large scale deployments require dedicated teams to deliver.

• Technological issues have to be in order, language problems have to be taken in account, definition of super users and key users. Testing data and interoperability of systems, ensure larger portion time is taken for testing and de-bugging.

• For distributed systems engage local champions as part of the design process, check the compatibility to the local culture. Check the status of the infrastructure.

• Capture the tacit knowledge of the end user but don’t allow the old system to be designed into the new system, due to local ’job protection’.

These end users’ recommendations have been used to develop the critical success factors presented in chapter 5.1.5.3.

5.1.5.2 COIN end users’ lessons learnt of COIN process During the second piloting phase and while starting the demonstrations a collection of preliminary lessons learnt from COIN end users was organized. One of the topics was COIN process from requirements to testing. The lessons learnt are described more in [4]. COIN started with the identification of requirements of end users. In COIN, a novel approach of “serious gaming” was used. All the end users regarded the approach very interesting, supporting the innovative thinking and bringing together people from different industrial fields. There were some suggestions to improve the approach, for example by specifying the available services and integrating them into the gaming scenario or focusing more on covering the real aspects of the business.

155

The two cycles of COIN (requirements, development and testing) were considered necessary by the end users to affect the service development. It was proposed that, instead of following the same approach for both cycles, the first one should be more focused on the conceptual testing: how the tools should be used and how well the tools support, how they change the processes, not so much about technical testing. The technical testing should be done in the second phase. The cross-team approach of COIN, where the research partners, developers and end users collaborated in different COIN phases, received many comments from the end users. All end users considered it as a good and necessary approach. The cross-team approach was not defined and started in the beginning of the project, but only after the first requirements phase. This was partly because in the beginning of the project it was left open for the users which services they are interested to test and demonstrate. Several end users, however, proposed that the cross teams should start immediately in the beginning of the project. They also suggested that the work packages could be organized around the cross teams, that the cross team structure should be more simple and that the cross teams could have “a double-lead” of end users and R&D partners. Also some proposals aiming for higher innovation, not limiting the cross teams by predefined rules were given. The cross-team approach was also seen beneficial to be used at a larger scope, for example in regional development (e-technologies based regions). There were some comments about training: The training activities are considered “a must” for the end users. Training should be more focused on end users or there should be specific training events and material for users. Now the first training event was considered to be too much IT technology. Also the approach of lectures on the training site is not sufficient for users. There was a suggestion that the end users could themselves be involved in the creation of the training material, supported by cross teams. This would also support the learning process.

5.1.5.3 Critical success factors OF EC & EI take up To support successful implementation, IT research has identified best practices as critical success factors, guiding the activities of organizations in the implementation process. Critical success factors (CSF) are defined as “the limited number of areas in which results if they are satisfactory, will ensure successful competitive performance of the organization” [16] or “key areas of performance that are essential for the accomplishment of a mission or project, i.e. the fields in which satisfactory results ensure the attainment of goals” [2]. Thus CSFs describe the activities and conditions for success, not only being in time and budget but also achieving the expected benefits. As part of COIN guidelines, critical success factors for EC & EI context were defined. The definition was based on enrichment and adaptation of CSFs from previous research, and using the experience of COIN end users received in COIN workshops (see chapters 5.1.5.1-2). The resulting list of 23 factors was grouped to 6 categories:

1. Management and vision 2. Solution selection 3. Organization of take-up 4. System and process adaptation 5. User involvement into the take-up process 6. Take-up phases

The factors were validated with a questionnaire to the end users. The questionnaire asked the end users to assess for each factor the importance of the factor in the context of IT supporting collaboration and interoperability and the current level of practice in the end users’ organization: Is the factor currently considered and put into practice in the network/ ecosystem of the end user organization when taking up IT solutions? The results of the questionnaire showed that all the

156

success factors proposed were assessed important in this group of collaborating enterprises and that for many factors the level of practise was quite low even if the importance was recognized. The critical success factors are described more in [11] and in [4].

5.1.5.4 COIN take-up process and guidelines There are different descriptions of the software lifecycle presenting the main phases and tasks to be performed in each phase. European Commission has recently published an e-Business guide for SMEs [5]. The guide focuses on the selection of e-Business solution and the solution provider; additionally software introduction phase is described. The introduction phase includes activities like configuring the product, training, carrying out organisational changes etc. One of the most used description of best practices covering the whole software product lifecycle is ITIL® IT Infrastructure Library, [9]. The viewpoint is that of the end user IT management. The system is quite heavy even for large enterprises and would need simplification for SMEs. Both ITIL- SW service management description and the e-Business guide [5] describe the situation from the viewpoint of one single company. The IT selection or management is the decision of a single company. However, in a collaborative environment there may be a need to make common decisions or harmonize the decisions, even if the companies are autonomous. This means that the take-up process includes also collaborative activities. To support guideline creation, a reference implementation scenario, with end user requirements, was first defined in COIN. Further this scenario was developed into a COIN take up process, describing the different phases of the take up. The aim was to slightly simplify the scenario and utilize the terminology and the experience gained during COIN. The resulting take-up process is described in Figure 70. COIN guidelines are built on this take-up process [4]. The guidelines are directed to potential users of EC & EI services, both for COIN end users and potential newcomers. For each phase of Figure 70 guidance was developed, giving for each phase a description of: • prerequisites or needed inputs, • actions needed in this phase, methodologies which can be used • output of the phase • information about COIN tools and material which could support the phase • influence of collaboration environment (COIN context) • success criteria relevant in the phase. As the starting point and reasons for taking up EC & EI services may be different in different cases, also the scope and scale of the take-up may vary. The need and extent for each phase depends on the scope. If the objective is just to solve a single, well defined collaboration or interoperability problem, the take up process may be quite concise. The larger the scope and scale, the more analysis, planning, designing, training and communication resources are required. Also, the borders between the different phases are not clear; what is performed in which phase also depends on the context and situation (for example if the services to be taken up are known already in the beginning or not).

157

Start of process: -Problems/gaps in collaboration identified -Changes of business (products, partners, globalization)

Decision and pre-planning: - decision about EC/EI service take-up in CN/SC/BE - Preliminary planning and process set-up

Baseline analysis & requirements & goals: - as-is business process modeling, -Requirement identification - set up of objectives /collaborative vision

To-be processes, service selection and data: -EC &EI service search and identification - to-be processes, workflow set-up

EC &EI service set-up and rollout through the CN/SC/BE - creation of ontology, identification of data, legacies

Further improvement and maintenance - follow-up and modification of processes

Figure 70 - COIN take-up process

5.1.6 Conclusion This paper describes experience and guidelines to support the utilization of IT solutions and services in the COIN context, with the end user viewpoint. The COIN context is the development and take-up of Enterprise Collaboration (EC) and Enterprise Interoperability (EI) services in the Future Internet environment. The vision is that the EC & EI tools and services are developing towards commodity, service utilities, which can be called easily and with low cost from the Internet. While the cost of software is expected to decrease in the Future Internet environment, the cost of the implementation and maintenance is coming crucial for the enterprises. Even now in many cases the costs of take-up process are higher than the cost of the software. In future, this will be further stressed. The FInES Position Paper 2011 [7] includes a vision about user-generated business applications and puts even more weight to the users in the take-up process: “The power and control in the development of future enterprise systems will progressively move from IT specialists to business experts.” In this paper the following prerequisites for successful IT implementation in a network have been identified: • adequate usability of the EC & EI service / solution • appropriate inter-organizational implementation process (also affecting the solution fit) ; a

cross-team approach is recommended. • sufficient maturity for collaboration and IT usage in the network. This paper discusses the challenges in the first two themes and develops approaches to overcome them.

158

References [1] Abran, A., Khelifi, A., Suryn, W. (2003) Usability meanings and Interpretations in ISO standards. Software

Quality Journal, 11, 325-338. [2] Araujo, I. (2006), Critical Success Factors for ERP Deployments in International Federation for Information

Processing, Volume 205, Research and Practical Issues of Enterprise Information Systems, eds. Tjoa, A.M., Xu, L., Chaudhry, S., (Boston:Springer), pp.319-324.

[3] COIN 2009. COIN (EU-FP7-216256) Deliverable D64.1a EC &EI inter-organizational implementation methods. November 2009. www.coin-ip-eu.

[4] COIN 2011. COIN (EU-FP7-216256) Deliverable D64.1b EC &EI inter-organizational implementation methods. June 2011. www.coin-ip-eu.

[5] EC (2008) eBusiness Guide for SMEs. eBusiness Software and Services in the European Market, European Communities 2008. http://ec.europa.eu/enterprise/e-bsn/ebusiness-solutions-guide/docs/eBusiness_Guide_for_SMEs.pdf, accessed November 2009.

[6] FInES (2009) Position Paper. Final version 1.9.2009. Future Internet Enterprise Systems (FInES) Cluster. European Communities 2009.

[7] FInES (2011) Position Paper on Orientations for FP8. A European Innovation Partnership for European Enterprises. Version 3.0 21.1.2011. Future Internet Enterprise Systems (FInES) Cluster. European Communities 2011.

[8] Hornbaek, K. (2006) Current practices in measuring usability: Challenges to usability studies and research. Int. J. Human-Computer Studies 64 (2006) 79–102.

[9] ITIL 2007. An Introductory Overview of ITIL® V3. Best Management Practice. itSMF; The IT Service Management Forum.

[10] http://www.itsmfi.org/files/itSMF_ITILV3_Intro_Overview_0.pdf. accessed March 2009 [11] Karvonen, I. (2011). Towards Achieving Benefits of IT Utilization in Collaboration Networks, Proceedings

of Pro-VE 2011, Sao Paulo, Brazil, October 2011. [12] Koskinen,M. (2006). On the Role of Interpretation Schemes in Organizational IS Implementation. In

Proceedings of the 39th Hawaii International Conference on System Sciences. [13] Leung, H. K.N. (2001) Quality metrics for intranet applications. Information & Management 38 (2001)

137-152. [14] Li, M-S.: Enterprise activity in the Future Internet Assembly. 2010. FInES cluster meeting 2.6.2010.

http://cordis.europa.eu/fp7/ict/enet/fines-meeting-20100602_en.html 2.7.2010 [15] Munkvold, BE. (1999). Challenges in IT implementation for supporting collaboration in distributed

organizations. European Journal of Information Systems (1999) 8, p. 260-272. [16] Remus, U. (2007). Critical success factors for enterprise portals. A comparison with ERP implementations.

Business Process Management Journal. Vol 13, No 4, pp538--552. [17] Seffah, A.., Donyaee, M.,Kline, R.B. (2006) Usability measurement and metrics: A consolidated model.

Software Quality Journal 14(2006): 159-178. [18] Shaw, N., Farhi, N., Taylor, P., Sambasivan, N. (2009) Initial usability criteria. The Bijou Crew.

http://www.cc.gatech.edu/~nithya/initial.html, accessed 11.5.2009. [19] silicon.com: The practicalities of unified communications and collaboration. 2009.

http://www.silicon.com/special-features/unified-communications/2009/11/17/unified-comms-what-it-needs-to-succeed-39653038/ .

[20] Vieira, H. M., Ferreira, F.L., Kennedy , J., Jardim-Goncalves, R. (2008) Evaluation and Testing as support for a consistent Architecture development. eChallenges 2008. Paper For Workshop Session " Isurf: An Interoperability Service Utility For Collaborative Supply Chain Planning "

159

5.2 Saas-U Value Proposition and Business Models Man-Sze Li1

1 to complete

Abstract This paper presents the COIN research into interoperability as a utility-like capability as articulated by the Interoperability Service Utility (ISU) concept of the Enterprise Interoperability Research Roadmap, and instantiated in COIN as “SaaS-U”. The paper explores the following key research questions: What is the value proposition for Enterprise Interoperability / Enterprise Collaboration in the forthcoming decade? Are utility services in principle economically viable in ICT? What is an Integrated Value Proposition of Enterprise Interoperability? What are the conclusions of applying the notion of Open Innovation in the field of Enterprise Interoperability? Does the utility-based business model support enterprise innovation? The paper concludes that the value proposition for Enterprise Interoperability and Enterprise Collaboration will become increasingly distinct and different in the coming years. Experimentation of the SaaS-U business models is needed and should be encouraged.. Keywords: Interoperability Service Utility, utility services, value added services, value proposition, business models, ICT, Future Internet

5.2.1 Introduction The scope of the COIN research on SaaS-U Business Models, as for COIN as a whole, is that of networked enterprises with a focus on Enterprise Interoperability (EI) and Enterprise Collaboration (EC) as established in the Enterprise Interoperability Research Roadmap, the original version of which was published in 2006. The specific areas include: why enterprises need to interoperate, how enterprises interoperate, as well as what constitutes interoperability as a capability. Enterprises need to collaborate in order to compete, and there will be many different forms of collaboration. Collaboration will be key to enterprise innovation, enabled by interoperability as a capability. Increasingly, the only comparative advantage that an enterprise will enjoy will be its process of innovation. The standpoint is that enterprises must be the primary beneficiaries of Enterprise Interoperability solutions. This scope has been further affirmed in the report on Value Proposition for Enterprise Interoperability published by the European Commission in 2008. In particular, that report demonstrates that interoperability as a utility-like capability is essential for enabling business innovation and value creation. Moreover, Future Internet technologies will re-shape interoperability as a capability, leading to the need to reappraise interoperability between enterprises. The report introduces “Future Internet Enterprise Systems” (FInES), which are “very much part of the Future Internet paradigm”. The notion of interoperability as a utility-like capability is described by the concept of the Interoperability Service Utility (ISU), as published in the Enterprise Interoperability Research Roadmap and summarised in the following table.

160

FInES Cluster meeting, Brussels, 12 November 2009 5

Interoperability Service Utility - ISUSource: Enterprise Interoperability Research Roadmap

• Delivery of IT as services• Interoperability as a

– utility-like capability for enterprises – a public good

• ISU as a basic infrastructure that supports– information exchange between knowledge

sources, software applications and Web services

– a new generation of self-* services and e-business services

– connection between islands of interoperability

– especially SMEs and start-up companies• ISU is independent of, rather than an

extension to, EI solutions on the market

Internet

Web

ISU

Value-added and proprietary IT services

Collaborating Innovation EcosystemsCollaborating Enterprises

Telecommunications

Conceptual View of the ISU

Figure 71 – ISU Summary

The ISU is a Utility Infrastructure. It comprises Utility Services, with the following key properties: • Cheap and near universal access • Seamless Quality of Service across multiple providers • Well understood, regulated and monitored service properties • Potentially high internal complexity, but limited external configurability/heterogeneity • Well-defined and standardised interfaces for utility usage and control • Ease of use. Utility services are to be contrasted with value added services, provided by a third party over an ISU inspired infrastructure and makes use of one or more utility services of the infrastructure. A Value Added Service provides added value to specific user(s) of this service. In COIN, SaaS-U is an instantiation of the ISU, from the perspective of business models. Specifically, within the context of COIN, SaaS-U is a business model which postulates an evolutionary path from software as a service (SaaS) to the provision of such services as utilities, with a focus on EI and EC Services. The key research questions are: • What is the value proposition for Enterprise Interoperability / Enterprise Collaboration in the

forthcoming decade? • Are utility services in principle economically viable in ICT? • What is an Integrated Value Proposition of Enterprise Interoperability?

161

• What are the Conclusions of applying the notion of Open Innovation in the field of Enterprise Interoperability? Does the utility-based business model support enterprise innovation?

To answer these questions, the research has explored a number of business scenarios and models for the implementation of the SaaS-U concept, in the following application domains, to complement the research into implementing the ISU as a business proposition: • SaaS-U @ Energy • SaaS-U @ Health • SaaS-U @ ESA – Enterprise Software and Applications.

5.2.2 Assumptions and Hypotheses Our basic assumptions for the research, as for COIN in general, are as follows: • ICT as a whole is a critical infrastructure for all enterprises14 • Enterprise processes will be subject to increasing commoditisation • IT capabilities will be subject to increasing contextualisation in order to better serve business

needs • EI and EC services in the 2020 vision of the COIN project are key services to be provided in

the Future Internet Enterprise Systems (FInES), which could be variously applied in and across specific application domains using a combination of ICT technologies. The developments of such technologies are increasingly aligned with developments of the future of the Internet.

Our overall hypotheses for all business-related outputs of COIN are: • SaaS will undergo further transformation as existing service paradigms evolve and

potentially disruptive new service paradigms emerge • All IT applications may be delivered as services and available via SaaS as a business model • Interoperability (in particular Enterprise Interoperability and Enterprise Collaboration as

defined within the COIN Project as in “the two sides of the same coin”) – realised as a commoditised technical functionality, delivered as services, and independent of particular IT deployment – is key to the infrastructure of a new generation of software-based services and applications

• That infrastructure potentially constitutes a new level of functionality that forms part of the Future Internet architecture

• That infrastructure enables new forms and mechanisms of innovation • New relationships between supply and demand in the application domain will emerge.

5.2.3 ISU Value Proposition and Business Model The ISU Opportunity Our research indicates that the ISU opportunity could be summarised by three arguments: • The economic argument: ICT trends towards commoditisation, continuously eroding the cost

base of providing services

14 On the basis that the Future Internet represents the future of ICT, this could be elaborated as the Future Internet will provide a critical infrastructure for all enterprises, which is itself an articulation of the FInES Cluster vision of the Internet being a universal business system.

162

• The public interest argument: some services offered over the Internet are part of the fabric of the economy and society, essential for all businesses or for minimum “quality of life”

• The competition argument: a level playing field in basic (utility) service provisioning for advancing open competition, greater transparency and unfettered innovation through new, value added services.

Why the ISU is Important The original main motivation of the ISU was to increase the capability of SMEs to join new markets, based on the observation of low ICT adoption by European enterprises in general, and SMEs in particular, beyond basic Internet connection and a footprint on the Web. Since then, the ISU motivation has been further extended by linking a universal service utility infrastructure with the development of the Internet, and specifically the need for such an infrastructure to catalyse the development of new types of value added services and new models for the provisioning of such services. Thirdly, software and service enabled value creation has been linked to enterprise business model experimentation to deliver innovation at the business level. In other words, the ISU is potentially enabling a new set of relationships between the ICT industry and enterprises. Fourthly and most importantly, the main argument for the ISU, just like the Internet, is innovation – purposive or serendipitous. In particular, the ISU enables a positive feedback loop for innovation by providing unbounded and potentially unlimited opportunities of value creation that benefit the end users. The ISU and the Future Internet With reference to the development of the Future Internet, the ISU potentially constitutes a fundamental shift in terms of: • The way in which the Internet will operate and serve its users, particularly the enterprises

which is the focus our research15 • The business models for the provisioning of services, including service infrastructures and

services enabled by those infrastructures • The Internet’s technical structure. Ultimately, the ISU must have a positive impact on the capabilities of enterprises as end-users. This has several major implications in respect of the role of the ISU, the paradigm of the ISU, the openness of the ISU and the positioning of the ISU in the Future Internet, as follows: • The ISU is an enabler both for service provision and service consumption, as well as

interaction between provision and consumption including “pro-sumption”. The technologies and services that comprise the ISU are means to serve the needs of users; they are not ends.

• At the service infrastructure level, the paradigm of the ISU must be any-to-any. The services at this level must be commonly shared, transparently discoverable, and capable of living in an open and dynamic environment. Accordingly, they must have properties that comply with those characteristics and consistent levels of performance that can be guaranteed to the user (see Section 2).

• The ISU infrastructure itself must be open, in the sense that: (1) it is not locked into any technology paradigm or service platform; (2) it is not owned or controlled by any entity; (3) its development and growth is based on participatory input, as opposed to being channelled

15 It should be borne in mind that enterprises are one category of users of the Internet. Users of the Internet may be categorised in different ways – critically, this depends on the definition of the “Internet Market”. However, as of to date, no authoritative and definitive definition of the Internet Market exists. The European Commission is launching a study to develop such a definition.

163

through makers of the infrastructure; and (4) it has no bias towards business models or service ecosystems, existing or emerging.

• The ISU infrastructure is part of the Internet of the future. It should enable and allow for seamlessness of information, applications, services, networks, provisioning and usage to the edge of the network. The ISU should not make a priori assumptions about function placement which restrict business model experimentations by providers or users.

• Just like the current Internet, the serendipitous and disruptive innovation predicted in a variety of Future Internet visions will not be borne out of chaos, but instead rest on a combination of emerging common and standard infrastructures and the opportunity of creativity this enables.

For whom the ISU is Important The value of the ISU lies in the value it offers to enterprises as end-users - it stems from the ISU’s positive impact on the capabilities of enterprises. In other words, the demand and supply value creation equation of the ISU must have a positive balance in favour of the demand side. But the full ecosystem of the ISU is vast and still nebulous. However, for the purpose of value attribution and accretion, we may broadly identify six categories of stakeholders, subject to the following caveats: • A particular entity could be present in one or more categories • A particular entity could be simultaneously both a utility service provider and a value added

service provider • The demarcation between supply and demand, while important for the accounting of value

accretion, could be blurred from the point of view of a stakeholder. In particular, service “pro-sumption” blurs the distinction between providers and consumers of particular services

• Given the scope of this document, we have considered only enterprises as end users; there are of course other groups of end users including notably public sector organisations

• Public authorities as potential investors and regulators and more are presently not included in the stakeholder categories. We will be addressing the role of public authorities in the next phase of the research.

The stakeholder categories are presented in the following figure.

164

EnterprisesCollaborationNetworks

Service &Application

Intermediaries

ServiceProviders

Platform Providers

InfrastructureProviders EnterprisesCollaboration

Networks

Service &Application

Intermediaries

ServiceProviders

Service &Application

Intermediaries

ServiceProviders EnterprisesCollaboration

NetworksPlatform Providers

InfrastructureProviders

ServiceProviders

Platform Providers

InfrastructureProviders

ServiceProviders

Platform Providers

InfrastructureProviders

Service &Application

IntermediariesEnterprisesCollaboration

NetworksInfrastructure

ProvidersService

ProvidersPlatform Providers

Supply Demand

InfrastructureProviders

Platform Providers

InfrastructureProviders

ServiceProviders

Platform Providers

InfrastructureProviders

Service &Application

Intermediaries

ServiceProviders

Platform Providers

InfrastructureProviders

CollaborationNetworks

Service &Application

Intermediaries

ServiceProviders

Platform Providers

InfrastructureProviders EnterprisesCollaboration

Networks EnterprisesCollaborationNetworks

Service &Application

IntermediariesEnterprisesCollaboration

NetworksService

Providers

Service &Application

IntermediariesEnterprisesCollaboration

NetworksPlatform Providers

InfrastructureProviders

ServiceProviders

Platform Providers

InfrastructureProviders

Added Value

UTILITIES

Platform Providers

InfrastructureProviders

ServiceProviders

Platform Providers

InfrastructureProviders

Service &Application

Intermediaries

ServiceProviders

Platform Providers

InfrastructureProviders

CollaborationNetworks

Service &Application

Intermediaries

ServiceProviders

Platform Providers

InfrastructureProviders EnterprisesCollaboration

Networks

Service &Application

Intermediaries

ServiceProviders

Platform Providers

InfrastructureProviders

IND

UST

RY

DO

MA

IN

APPLICATION DOMAIN

TECHNOLOGY DOMAIN

Figure 72 – ISU Stakeholder Categories

As already mentioned, the ISU enables a new set of relationships between stakeholders, including those within the ICT industry. Recognising that the structure of the ICT industry is already changing, most recently triggered by so-called Cloud Computing, it should nevertheless be emphasised that the incumbents, under existing classifications, could become key providers of both utility and value added services. The ISU is not premised upon a re-invention of the ICT landscape; rather, it enhances that landscape by opening up new possibilities and value proposition. The following table provides an illustration of example ISU providers and their classification.

Table 9 - Example ISU Providers and their Classification Utility Service Providers Value Added Service Providers

(Aggregators) Value Added Service Providers

(Integrators)

• Specialised software companies • Large companies with

specialised service capabilities • Web 2.0 companies • Telcos, ISPs and other current

web infrastructure providers • Hardware companies • Focused startups

• First generation B2B companies • Industry hubs • Large companies with

specialised service capabilities • Web service hosting and

management companies • EAI vendors • System integrators • Focused startups

• Software vendors • System integrators • Hardware companies • Web 2.0 type (user)

communities

As the utility services are defined as being provided at very low or even nil cost, defining the cost of utility services is key to building the investment profile. Using conventional economics of supply-demand, two cost models have been identified, as illustrated in the following table.

165

Table 10 - Cost Models for ISU Profitability cost: the loss in profits incurred by the operator due to the utility services Measurement Compare the profit levels of the operator under the alternative market equilibria: with and

without utility services

Problem • Based on pure accounting argument • Comparison only meaningful where prices and market structure are assumed to be

constant with or without utility services • Assumption that the operator accrues no direct benefits from serving “non-profitable”

consumers • Assumption that the operator accrues no direct benefits from leveraging the utility

services (e.g. some form of bundling with value added services) • Assumption that the operator faces no profit constraint or the profit constraint is constant

Welfare cost – the loss of total surplus (consumer plus producer) implied by the Utility Services Measurement Compare the total surplus achieved at a hypothetical equilibrium without the Utility Services

with the total surplus realised with the Utility Services Problem • How to determine the hypothetical equilibrium

• Result dependent on technique used to maximise total surplus (e.g. the efficiency argument, where the “market” price equals marginal utility)

• Have no means to take account of price and benefit differentials along the long tail • Have no means to balance the efficiency-based cost against redistributive benefits which

depend on the weights of the different groups in the public authority’s social welfare functions (e.g. SMEs, ICT start-ups)

• Comparison only meaningful where prices and market structure are assumed to be constant with or without utility services

However, neither of the above is ultimately appropriate in that neither takes into account: • The cost of “creating” the ISU • The pressure on price due to commoditization • The possibility of subsidies, tax and other direct or indirect economic incentives • The characteristics of the economics of information goods (intangibles) • Co-creation, pro-sumption, open source models, and other “new” phenomena In conclusion, building the investment profile for the ISU is a highly non-trivial exercise and is fraught with problems even at the theoretical level. Specifically: • The model cannot rely on pricing based on traditional supply-demand and Pareto Optima • The model cannot rely on efficiency – equity trade-offs • The market is not competitive-neutral, whether it can become so in future is an open question

(and some would consider this as a circular argument because open market competition for service-based applications is itself dependent on the availability of the ISU)

• The market structure cannot be assumed to be static (our first hypothesis of the ISU). Therefore, in order to develop a meaningful investment profile for the ISU, there is a strong argument for a new economic model to define the cost and price schemes of utility services. This economic model/argument needs to be aligned with a public interest model/argument and a competition model/argument (the three arguments which comprise “The ISU Opportunity” as defined above). We have moreover identified a large number of input variables for building a business model for the ISU, as indicated in the following table.

16

6

Tabl

e 11

- IS

U B

usin

ess M

odel

s – In

put V

aria

bles

Bu

sines

s-Ec

onom

ics

Tech

nolo

gy

Polic

y O

ther

s

Gro

wth

of

th

e se

rvic

e se

ctor

of

ec

onom

y Pu

blic

web

serv

ices

A

ctiv

e co

me

back

of t

he st

ate

Dig

ital N

ativ

es,

Gen

erat

ion

Y /

Z

IT sp

endi

ng b

y en

terp

rises

D

evel

opm

ent

of

Web

2.

0 to

ols

and

Ente

rpris

e 2.

0 C

ompl

etio

n of

Dig

ital S

ingl

e M

arke

t En

terp

rise

attit

ude

tow

ards

“IT

doe

sn’t

mat

ter”

IT sp

endi

ng b

y SM

Es

Dev

elop

men

t in

pr

o-su

mpt

ion

of

softw

are

base

d se

rvic

es

Polic

y fo

cus o

n In

nova

tion

Dev

elop

men

t of

ad

vanc

ed

ICT

infra

struc

ture

s in

urba

n ar

eas

Bro

adba

nd ro

llout

D

evel

opm

ent o

f C

loud

Com

putin

g (e

sp

mig

ratio

n of

func

tiona

lity)

C

ompe

titio

n Po

licy

tow

ards

Mon

opol

y,

Olig

arch

y et

c

Publ

ic a

ttitu

de t

owar

ds “

soci

al m

arke

t ec

onom

y”

Gro

wth

of S

aaS

Tech

nolo

gies

to

enab

le n

ear-u

nive

rsal

Q

oS &

ava

ilabi

lity

of Q

oS m

etric

s at

th

e se

rvic

e le

vel

Ente

rpris

e Po

licy

on S

MEs

Pu

blic

at

titud

e to

war

ds

redu

ctio

n in

en

viro

nmen

tal f

ootp

rint

Mar

ket

strat

egy

of

incu

mbe

nt

ICT

vend

ors

Dev

elop

men

t of

th

e FI

Te

chno

logy

Fo

unda

tion

(Cor

e Pl

atfo

rm a

nd G

ener

ic

Enab

lers

ther

ein)

Ente

rpris

e Po

licy

on v

entu

re f

unds

&

start-

ups

Gro

wth

of

en

terp

rise

colla

bora

tion

(eco

syste

ms /

net

wor

ks)

Dev

elop

men

t of F

I Use

Cas

es

Publ

ic p

rocu

rem

ent p

olic

y on

OSS

Gro

wth

of “

user

driv

en in

nova

tion”

D

evel

opm

ent

of

adva

nced

(P

an-

Euro

pean

) tes

ting

infra

struc

ture

s Po

licy

on

ICT

stand

ards

&

sta

ndar

disa

tion

Gro

wth

of b

usin

ess m

odel

s bas

ed o

n th

e op

en so

urce

con

cept

A

new

Inte

rnet

arc

hite

ctur

e Po

licy

on in

telle

ctua

l pro

perty

in IC

T

Cos

t of “

softw

are

deve

lopm

ent”

“M

obile

Inte

rnet

” IC

T po

licy

on N

et N

eutra

lity

/ USO

Cos

t of t

elec

omm

unic

atio

ns

Mul

tiple

“In

tern

ets”

Ta

x in

cent

ives

on

ICT

infra

struc

ture

de

velo

pmen

ts

Cos

t of c

omm

unic

atio

n ne

twor

ks

New

kill

er a

pps

Ava

ilabi

lity

and

choi

ce o

f PPP

mod

els

C

ost

of

faul

t to

lera

nt

and

scal

able

se

rver

s

167

Our research further indicates that while there are different competitive models, each would create issues and concerns for utility services, as summarised as follows:

Promising, but �

StructuralSensitive to local circumstances, difficult to implement in practice

Facilitates incentives to interconnect, competition in horizontal part across vertical segments, economies of scope are preserved

Separation into essential parts

EssentialBehaviouralAnd/or structural

Possible lack of profit motive reduces incentive to innovate

Facilitates control of discrimination & anti-competitive behaviour

Operational separation

Has potentialStructuralClub may seek to exclude outsider, may led to collusion

Eliminates incentives for discrimination

Club ownership

Yes, but �StructuralPotential loss of economies of scope, may require costly & arbitrary separation

Eliminates incentives for discrimination

Ownership separation

NoBehaviouralRequires active regulatory intervention, need to monitor & control capacity

Certain economies of scope is preserved

Access regulation

Applicability to service utility

ApproachDisadvantageAdvantagePolicy

Figure 73 - Applying Competitive Models to the Supply of Utility Services

(adapted from OECD 2001)

5.2.4 Conclusions The research that we have carried out shows that the value proposition for Enterprise Interoperability and Enterprise Collaboration will evolve quite considerably in the forthcoming decade. EI / EC are at present both at the bottom end of innovation curve. The development paths for EI and EC will diverge rather than converge. EI will be subject to further, continuous commoditisation. EC will instead develop along the path for increasingly value add and especially value add to support enterprise innovation. There is however one exception for EC services in this general trend: collaboration IT services are already a commodity and will almost certainly remain so. In other words, the value proposition for EC and EC will become increasingly distinct and different. It would increasingly make little commercial sense to supply EI and EC as a single solution. Instead, they will be very much part of more generic service and application offerings that leverage Internet technologies. For individual enterprises who would need to collaborate even more in order to compete, their focus would be on the value add dimension of EC – for dealing with the more pressing day-to-day business operation - rather than on the utility aspects of EI.

168

Enterprise support and use of IT services for purely EI purposes will only attract strategic attention and especially investment at the end of a long process of IT development and maturity. EI generally will be absorber into the generic infrastructure for the Internet, which will be increasingly service centric and service focused. Our research strongly suggests that utility services are in principle economically viable in ICT (the Mozilla web browser is a case in point). However, the development of a system of utility services (such as the ISU) will take a long time, beyond the COIN 2020 horizon. The key question is whether EI & EC services would become both utility services and economically viable. The conclusion is that the utilitisation of EI and EC services as a commercial proposition is highly unlikely to happen without a degree of public intervention. A very relevant analogous example is the provision of the technology foundation for the Future Internet (FI-WARE technology platform). The successful market rollout of this platform in the planned 3 to 5 years’ timeframe will itself have a major impact on the prospect for the development of application level utility services especially regarding EI services. Our research confirms the validity of the FInES Cluster’s Enterprise Interoperability Value Proposition framework. As we have seen, that framework includes multiple dimensions covering both micro and macro business and economic aspects. Specifically, the application of that framework in business model analyses, as carried out in our research (including in specific business cases as fully described in D6.2.2b), demonstrates that it makes no commercial sense to offer EI as standalone solutions. We also conclude that innovation, and especially the much popularised “Open Innovation”, is vital for enterprises to reap the full benefits of ICT including EI and EC. If our assumption that the ISU leads to openness is correct, then open innovation is essential for the field of EI. Utility-based business models support and enable many fundamental aspects of ICT development, without which innovation would be much harder to thrive, as well as industrial enterprise innovation. However, market forces might foreclose the openness of the ISU (leading, for example, to “islands of ISU” along the SaaS-U paradigm). Under these circumstances, the potential benefits and effects of innovation for enterprises would be much harder to materialise, and severely curtailed. In other words, the ISU as innovation may help prevent market integration only if other conditions which guarantee the openness of the ISU apply. Such conditions should be the starting point for considering the governance model for the ISU. They are explored in the accompanying COIN Deliverable D6.2.2b, specifically in relation to business roadmapping for realising the ISU. The ISU has disruptive potential, particularly for the incumbents. The ISU paradigm shows promise as a business proposition in support of new applications and services that add value to particularly those sectors already in transition due to changing business climates, market re-structuring and that are open to new players. New business models based on the utility paradigm are in principle possible and should be guided by the quest for the interconnected dynamics of innovation and value creation. However, the ISU on its own will not ensure the openness of social or societal innovation. Conversely, innovation is not an intrinsic business value. ICT-enabled innovation services do not necessarily lead to business innovation. Moreover, for businesses, innovation is not an end in itself. Innovation is a business strategy towards achieving a business goal in support of certain business values. Business support for openness needs to be viewed through the lenses of that strategy. The notion of business values is currently under major review worldwide. The outcome of that review will ultimately determine the kind of ICT that is most needed to support future enterprises. We believe that an ICT utility infrastructure such as the ISU will be very much part of that vision and will help bring that vision one step closer. In that regard, it is important to

169

emphasise that the ISU is not premised upon a re-invention of the ICT landscape; rather, it enhances that landscape by opening up new possibilities and value proposition. At the end of our research, we strongly feel that there is a lack of innovative scholarship and literature on the future of enterprises and how a new generation of business value and business model analyses might impact on such a future. For example, comprehensive assessment is needed to ascertain what might happen if the status quo of market development merely continues (even though what the status quo might be now makes little sense in view of huge volatility within and across markets locally and globally). What exactly is meant by “market failure” is not entirely clear either. How to exit from the current business to “jump” to the ISU? The ISU is not a pre-determined destination. Its economics are not proven. Indeed, its economic foundations are at this stage uncertain. Established economic models and assumptions are not particularly helpful in providing the conceptual basis for utility services. Specifically, utility services lack an economic basis premised on conventional cost-based and price-driven supply and demand. New technologies and business models allow greater discrimination and differentiation in pricing, quality of service, content and other aspects of valued services. Because different value propositions are needed for different target groups, some form of discrimination is necessary for encouraging investments, and for possibly also efficiency and equity. There is no fixed economic formula for determining value or value proposition. There is no “standard” value proposition or “win-win” business model for SaaS-U. Noting the preceding points, SaaS-U on its own, no matter how attractive as a business model in theory, is highly unlikely to sustain sufficient market traction or create payback that would satisfy most businesses given the existing financial structures and conventional expectations for ROI. Experimentation of the SaaS-U business models is needed and should be encouraged. It goes without saying that the only valid testing of any business model is in the marketplace, not in research.

170

5.3 Bringing COIN to the Market Daniel Field1, Francisco Javier Nieto1

1ATOS

Abstract Finding appropriate business models for novel technologies is ever a challenging task. In COIN this was no different. This chapter presents how a method for describing business models through labelling value chain activities as revenue-generating or cost-generating activities permitted easy contrast of business models suggested within the consortium. Examples from COIN are given showing how alternative configurations of these types of activities give way to the diverse business models for subsequent analysis. It is shown how experimenting with these assignations to a generic value chain of a novel technology allows a structured approach to identifying possible business models. The application of the technique to existing businesses may lead to the discovery of novel business models.

5.3.1 Challenges The COIN project presented a complex problem to the team of business analysts tasked with bringing COIN to the market. The project is large and complicated. It is based on a long term vision encompassing many trends. In fact the full COIN solution is designed to be implemented in a futuristic scenario where many of the current day practices of the industry will have changed significantly. This vision is wholly part of the ISU and SaaS-U model [7] which foresees software services becoming split along a spectrum between value-added services and utility services. The concept is that ubiquity and commoditization will drive the price of many basic software services towards zero. Companies providing these services must provide these services at low, or no cost because they are widely used to enable an ecosystem on top of which value-added services are provided. It is from these value-added services that such companies will derive their profits and compete on differentiation. Of course such a world does not yet exist, although signs are there that the trends and conclusions which underpin this model are continuing as foreseen. This presents the challenge that the final COIN solution must understand both the future destination of the solution, where value is maximized, as well as the situation at present, for COIN must be commercialized now in order for the future value to be created. What is more, the two visions; short term and long term, must be compatible in order for a pathway between the two to be possible. In addition to the challenge of the industry characteristics, the COIN business team has had to confront a typical challenge in technology driven research projects: how does one move from an architecture and system design, based on a implementation in a collaborative situation, where organizations that may compete in the marketplace are co-providers, to a commercial offering? The collaborative research atmosphere is isolated from the market forces such as profit maximization, fluctuating costs, profit distribution and complex clients with multiple needs requiring different solutions. As a consequence the business team first worked on the 2020 vision of the project, elucidating the value chain for the technology solution built in the project. They then proceeded to analyse the project for the more immediate applications – the so-called low hanging fruit which would allow the project to create a beachhead in the industry – with a reduced version of the solution according to the instant needs of the customers, from which COIN could grow towards the 2020 vision.

5.3.2 Logic adapted With a view to working around these challenges frequently found in projects, a methodology that which has been developed within Atos’ research and innovation department was further refined and applied. Full details of this are given in a whitepaper [5] and in the context of COIN, are explained below. The method has been developed in for the exploitation of large technology-led projects as typified by integrated projects funded by the European Commission’s framework programme programme, of which COIN is a prime example.

171

In essence the method is to formally recognise the value chain or system of the project based on the assets or technical innovations which have been prepared and to develop scenarios for commercial delivery based on activities which are aligned with the competences and business model of each participating organisation In practice this means recognising the supply chain leading to the delivery of each asset, the value proposition of each component to the next in the chain and the number of different roles which could feasibly be part of a business scenario to establish a generic system value chain. Once this has done the different exploitation visions of the participants must be mapped on to the generic value chain and the source of value, or overriding value proposition, of that vision recognised. From this it is possible to recognise when differing visions are indeed different perspectives of the same vision, and when they are distinct scenarios. It is possible to distinguish between trivial differences and those that change the definition of the value proposition or business model. It is possible to identify the true client (he who provides revenues) from other actors that may use or benefit from the system, and it is possible to make some assertions regarding critical success factors, business models, long term strategy and potential risks and mitigation strategies.

5.3.2.1 Identification of assets The identification of assets should start early in the project lifecycle for both for exploitation and non-exploitation reasons. In terms of technical management it is necessary to have a global picture of the projects components and how they work in order to build a holistic system. In terms of project management it is necessary to know where resources are being spent and when things will be developed so that the progression can be monitored. From the exploitation perspective it is necessary to know not how they work but what they do and which components they interact with. This is fundamental in order to derive the value chain and define the value proposition for them. The team took detailed diagrams from COIN from across the different workpackages in order to build up a picture of how the components interacted and created value. In particular through this exercise and interviews with leading developers, we were able to build up a detailed value chain of the system.

5.3.2.2 Identification of the value chain Having identified the assets and the components of a project it is necessary to carry out value chain analysis on the assets in order to derive a generic value chain from which our business scenarios are constructed. It is assumed that the reader is familiar with general value chain analysis and in this section we focus on the specific challenges within the context of large collaborative ICT projects. This section is abridged from the above referenced whitepaper. From the list of assets and components described above, these were reorganised into a flow which represents the service that each component or provides. First we needed to separate the components and assets into two categories – the core technology and the peripheral assets. In applying this method, in the core technology we typically find elements of a core platform upon which peripheral assets operate. Among the list of peripheral assets we also tend to find non technical elements alongside technical ones, these may include such as business model research, consultancy models, additional services and other tools and pieces of software that can be used in certain use cases but are not essential to the delivery of the key project objectives.

172

Figure 74 - Core and peripheral assets

Next we analyse the core technologies for the value activities contained within them. In order to do this we carry out value chain analysis as introduced to the literature by Michael Porter [8]. Porter’s work focused on a single business and the analysis of its activities according to the value they create rather than their way they operate. Essentially, for this exercise there are two types of value activity. The first are those which perform a concrete function adding value to the input to provide an output with an added value. This would be for example a transformation of the service or good which is the final output of the core technology. For example in the case of a technology that allows intelligent objects such as sensors and devices to be discovered, ranked against historical data and deployed, these three value activities would be considered concrete value functions. We call these vertical value activities. The second group of activities are those which do not have an explicit logical order but which enable the vertical actions to be used or to function. These are horizontal value activities and include such things as the interface (allowing the user to discover and select the devices, the security features which ensure the user has the right to do so and the platform which manages the retrieval of data from the database and execution of the ranking algorithms, for example. These are then placed pictorially into the core technology value chain, with the vertical activities in a logical order, forming the top portion of a horizontal chevron and the horizontal activities placed in the bottom half of the chevron showing that they act throughout the entire core technology. The chevron points to the right and the vertical activities logically proceed left-to-right. In the case of the COIN project, the central technological value activity revolves around the platform and the activities of service discovery and deployment that it provides. This is shown below:

Figure 75 - Value Chain for the core COIN technology

173

Having reached this point it is necessary to then extend the value chain with all the roles and the goods or services that are required in order for that component or asset to function, and the roles or services that are enabled as a result. This is an extension of the rent chain concept espoused by Baron [1], subsequently generally mixed with the original value chain concept of Porter and now referred to simply as a value chain. It is very similar to the concept of a supply chain, but based on value adding activities. In situations where there are more than one input or output to a process it is possible to have value chains in parallel. This is quite common. In the full value chain of COIN, shown below, we see a complex array of value activities. Providing input to the core technologies shown above we see the parallel chains of infrastructure and services, isolating the creators and the providers of each. The output of the core is a chain encompassing IT providers who will install and maintain the system on behalf of the user, if necessary, then the users, which use the system, and finally their clients. In the vertical dimension the value chain expands to include non-technical horizontal value activities including marketing and management, and the possibility of federating the platform with third party platforms. There are ancillary roles including consulting, training and reselling, and finally an occurrence of prosumers, where the same actor is potentially both a provider and a consumer in the same value chain.

Figure 76 - The complete value chain for COIN

At this point we have the value chain from end to end, defining the ‘end’ as beyond the sphere of influence of the future provider of the project technology, as well as any ancillary roles.

5.3.3 Development of business scenarios At this point we needed to start developing business scenarios for the exploitation of the system, and this is where the work in deriving the value chain pays off. The value chain becomes the basis of the formalisation of scenarios so that each can be discussed in detail without losing track of the central business premise at the heart of the scenario. Whilst many collaborative projects start exploitation assuming that they must control all activities of their value chain and select the generic business model that is most familiar (often open source or a cloud implementation), in COIN we wanted consider that as each activity of our value chain is by definition an value-creating activity that adds value, a business scenario could be based on any one of them. In theory each activity could be carried out by a separate organisation with its own business model in a complex ecosystem. In practice of course it is unlikely any innovative technology could get off the ground requiring such complexity of

174

business relationships to be engineered in advance. As always, the answer lies in finding the happy medium. This gives us our first question: What parts of the value chain could we deliver as an organisation, leaving other activities to incumbents in the industry or to newcomers? Already the answer to this question will give us some ideas for shaping possible business scenarios. However, before doing so we also posed the second question: Of the activities we provide, which is/are the one(s) we base our business model on, and which ones do we provide because we have to? It is this second question which will give us the greatest variety of business scenarios for our system. There is no single answer to the question and workshop participants should be encouraged to be bold and challenging as possible.

5.3.4 Type of Activity In answering the second question posed above, our exploitation method considers various types of activity. The first distinction of activity types is whether it is a revenue-generation activity (which we term a Revenue Generation activity, or RA) or whether it is merely an obligatory activity (which we term a Cost Activity, or CA). For example, in our method, in a typical business the product or service that is being sold would be considered a RA activity and the marketing activities used to drive the sales would be classified as a CA activity. However, not all cases are so clear cut. It is by playing with these activities controlled by the main exploiting organisation and the way that they are carried out that we can discover new business models and more innovative ways of providing the technology. There is a third distinction of activities. Although we should assume that in all business scenarios all value chain activities are potentially present, in some scenarios we may recognise that the business model is driven by a third party actor or role upon whom the profitability of our exploitation scenario is wholly dependent. We may wish to underline the nature of this role in defining the business scenario. A common example of this is a marketplace. In the case of eBay, the profitability of eBay itself is driven by the trading of goods by third parties outside the control of the eBay company. If we were inventing the business scenario of eBay from scratch, it would be valuable to acknowledge this formally in the model so that subsequent aspects of business planning take this into account. In this example we would designate these third party traders as a “3rd party RA” value activity. In order to show these different types of value activity pictorially on our value chain, we have adopted the following convention as shown below.

175

Figure 77 - Legend for value chain activities

5.3.5 Scenarios in COIN In COIN this method was applied and 8 distinct scenarios were developed, which could be competing or complimentary. The first scenario was based on making the core technology (the large chevron) the RA function, in which users would pay to use the platform, for example through a subscription pricing model. Once this subscription was paid for, subsequent use of services would not be charged, making the service provision a cost activity. We likened this to a Facebook where users were charged a monthly subscription for access but then had access to all services (messaging, games, etc.) for free. This is shown below.

Figure 78 - Facebook Scenario 1

176

The next scenario turned this on its head a suggested providing access to the platform for free but charging users for access to the services. Again we likened this to a Facebook, where instead of a platform subscription, users were charged each time they used a service, as shown below:

Figure 79 – Facebook Scenario 2

In both these scenarios we considered that the infrastructure could be outsourced to a third party provide without changing the scenario, and that consultancy could be provided as an optional extra. However it is exactly this consultancy which provided the third scenario: what if all of the COIN system was provided for free, with the providers relying on consultancy and training to generate revenues. This we likened to an open source model as increasingly seen in many software products – such as Ubuntu, provided by Canonical ltd under this model.

Figure 80 - Open Source Scenario

177

When we started exploring what would happen if COIN did not control the service provision, leaving this entirely open to third parties, with COIN merely acting as the marketplace and deployment platform, we came up with a new scenario which we likened to eBay. In this scenario access to the platform is free but each time a service is deployed, the user is charged. Therefore we considered the vertical activities of the core technology to be RA, whilst the provision of horizontal activities were merely costs incurred by the provider. As the provision of services by third parties, under their own business model is central to definition, this was also indicated on the value chain, as shown below:

Figure 81 - Markeplace Scenario 1

The next scenario was the franchise model. Another innovative model, here it was conceived that third parties could host sector-specific instances of the platform, for example in health, automobile, finance. Services common to these sectors would be provided by third parties under their own business model (mixture of free and SaaS). The COIN partners would receive revenues for the management of the IPR, the marketing and the central management of sector-independent development, similar to the way that franchises work in other sectors. A key and interesting point here is that it makes the management and sales functions of the value chain into the point of value capture. In nearly all chains these function are costs.

178

Figure 82 – Franchise Scenario

In the course of this work, several other scenarios were also developed and analysed further. The next step for the team of business analyst was to investigate the long term implications for each scenario. Several scenarios were dismissed at this point, and at the time of writing, the exploitation team is developing business plans for the remaining viable scenarios.

5.3.6 Conclusion This chapter has described how faced with a complex situation and very unclear exploitation path, based partially in the future, the application of a simple method focused on determining first the value chain and subsequently exploring business scenarios based on, the exploitation team of COIN have been able to explore creative and innovative routes for the future commercial exploitation of the project. At the time of writing the exploitation team is developing the franchise scenario, which we think could be the optimum way for a COIN deployment in the future. As aspects of the COIN 2020 vision emerge, and the observations and trends that led to that vision strengthen and become more relevant, we believe that COIN could indeed licence out the use of the IPR behind COIN so that independent organisations, ideally agile SMEs and SME associations could run a profitable business serving their sector. No doubt so of these would be self financing, perhaps running their instance as a marketplace, whilst other s may be publically funded to potentiate clusters of businesses. Irrespective of the business model of the franchisee, it is clear that as each COIN instance creates value this can flow back into the COIN management, in return for ongoing IPR updates, bug fixing, improvements, marketing, management and the growing ecosystem of services available through the autonomous COIN instances. In addition we find many of the pilots, described in [3] wishing to further develop commercial scenarios around the COIN platform are looking into the various scenarios as the backdrop for their pilot. For example some, such as FILAS and ICZ are looking at marketplace-based scenarios for their sectors. [2]; [4]. In the process of developing this methodology is has been seen that just as in COIN, the process of scenario elucidation can be applied to many technology-push projects. A forthcoming paper [6] explores the application of this methodology in the commercial domain, for retrospective applications. From the experiences in projects and the commercial examples, it is seen that permuting the assignation of RA and CA in a generic value chain is a structured approach for

179

identifying potential business models. Consequently this method is recommended for the identification of possible business models when exploiting new technologies. References [1] [Baron, 1995] Baron, D.P., The Nonmarket Strategy System, Sloan Management Review, Fall 1995 [2] [COIN, 2010] COIN Consortium, Field, D., and Gil, B., (eds): D2.2.1b – Exploitation Report – M24, Self-

published 2010. [3] [COIN, 2011a] COIN Consortium: D6.5.x.a ‘Test Bed Report’ series of deliverables from COIN. Self-

published 2011 [4] [COIN, 2011b] COIN Consortium, Field, D., and Ay, E., (eds): D2.2.1d – Exploitation Report – M48,

forthcoming, 2011. [5] [Field, 2011] Field, D., Identification of business models through value chain analysis: A method for the

exploiting large technology projects, Self-published (Creative Commons), 2011 (http://www.scribd.com/doc/66408751/Identification-of-Business-Models-Through-Value-Chain-Analysis-A-Method-for-Exploiting-Large-Technology-Projects-A-Whitepaper)

[6] [Field, 2011b] Field, D., Describing and Identifying Business Models from Generic Value Chains for Technology Systems, eChallenges e-2011 Conference Proceedings Paul Cunningham and Miriam Cunningham (Eds) IIMC International Information Management Corporation, 2011, ISBN: 978-1-905824-27-4

[7] [Li, 2011] Li, MS., (ed.) Eschenbächer, J., Gusmeroli, S., Suttner, H., Weber, J., Faughy, A., Eley, M., D6.2.1b - Integrated EI Value Proposition – M46 issue, Self-published 2011.

[8] [Porter, 1985] Porter, M.E., Competitive Advantage, ISBN 0684841460, Free Press, New York, 1985.

180

5.4 Enterprise Collaboration Maturity Model Juncal Alonso1, Leire Orue-Echevarria1, Mikel Vergara1

1 TECNALIA, Parque Tecnológico 202 E-48170 Zamudio, Bizkaia, Spain

{Juncal.Alonso, Leire.Orue-Echevarria, Mikel.Vergara}@tecnalia.com

Abstract The Internet is undoubtedly permeating and transforming all aspects of our economies and societies. It is a remarkable catalyst for creativity, collaboration and innovation and more broadly for the development of our economies and societies [7]. In this context, collaboration and interoperability are pervasive subjects today as organizations strive to achieve competitive advantage in the global market fostered by the development of the new economies of scale. In the COIN IP project [IST-216256], a strategy based on readiness assessment to adopt best collaboration and interoperability practices has been implemented following the maturity models approach. The aim of this paper is to present a methodology inspired on maturity models. This methodology shows the approach used to assess organizations on their readiness for collaboration and interoperability and to guide those organizations to adopt best practices for collaboration and interoperability in networked environments.

5.4.1 The problem description Collaboration and interoperability are key issues for today’s organizations in the current globalized and networked society. As professed in the introduction to the COIN IP project, both concepts are different but they are so interconnected that can be considered two sides of the same COIN [4]. In this new situation where enterprises have shifted towards networked enterprises, companies need to adopt innovative forms of collaboration in order to compete and maintain their position in the global market. These new ways of collaboration are mainly based on Information Technologies and therefore interoperability capabilities at different levels have become crucial to create value and success, combining technology and business approaches to catalyze and sustain added value for enterprises and customers. New economic activities have arisen alongside with new classes of networks and services, new forms of enterprise collaboration, new business models and new value propositions. Business has changed as well [8]. As stated by the European Commission in its published Enterprise Interoperability Value Proposition, economies of scale can now reach world wide, allowing firms to tap into the narrowest parts of the long tail of demand. In fact, collaboration is one of the global trends in business nowadays and collaborative practices are gaining importance in firms. These collaborative practices are being carried out in different forms, from cohesive and stable networks like Collaborative Networked Organisations (CNO) to more ephemeral and occasional cooperation like (VBE) Virtual Business Ecosystems. Existing literature points out different definitions and analysis of new types of collaboration forms [6], as well as numerous enterprise interoperability types and practices [2]. There are also existing proposals on readiness for certain types of collaborations forms, like the Aricon approach [1], where a methodology for Virtual Enterprises and Product development is presented. However, for enterprises, it is still a hard task to identify best practices and improvements to start implementing collaboration and interoperability practices inside different types of networked environments. Presuming that an organization is collaborating in any type of the networks aforementioned, the question they face is: how is my company performing alone and in the network, that is, how mature is my organization in terms of collaboration and interoperability and what can be improved to perform better?

181

5.4.2 Objectives and Use of the ECMM To answer the previous question, the Enterprise Collaboration Maturity Model (ECMM) [5] has the main objective of assessing organizations that desire to know their collaboration and interoperability maturity level with respect to a set of best practices. The result of these assessments will present, among other issues, an improvement plan and a roadmap to increase the enterprise’s collaboration and interoperability capabilities, instilling in organizations the benefits of excellence models. In order to reach this main objective, other secondary and more specific objectives have been identified: • Diagnosis the state of an organization’s current practices regarding collaboration and

interoperability issues. • Set improvement objectives and priorities. • Guide for improving projects and organizational processes. • Help ensure stable, capable, and mature processes. • Proposition of Enterprise Collaboration and Enterprise Interoperability technologies and

services that could be useful. ECMM can be applied by external independent evaluators and also internally as a self assessment tool. Regarding the special features for collaboration practices the ECMM should be useful to: • Support the collaboration during the whole life cycle of a Collaborative Networked

Organisation (CNO): from its creation, operation, evolution, to its dissolution. • For an enterprise (that could be part of a CNO or not) in order to evaluate its preparedness for

collaboration (in a specific collaboration or in general) and provide best practices to correctly position the enterprise inside its collaborative network.

5.4.3 ECMM Design Process and Background

5.4.3.1 Maturity Models ECMM follows a CMMI® [3] structure, as it is very clear, well understood and applied within the industry (as a standard “de facto”). A maturity model is a framework that describes, for a specific area of interest, a number of levels of sophistication at which activities in this area can be carried out. Maturity models focus on different disciplines that an organization can address to improve its business. Applying the maturity model approach to assess networked organizations will provide: • A place to start. It is important to identify each organization’s current state, this will help

setting the actions that are necessary to achieve the objectives defined. • The benefits of a community prior experiences, as a model is a collection of industry good

practices proven by experience to be effective. • A common language. Setting a model implies sharing a common dictionary that will assure

that every party involved is using a common language. • A shared vision and a framework for prioritizing actions: A model provides a shared vision

of the improvement path, what the goal is, what is being aimed for and, how it can be achieved.

According to CMMI® definitions Maturity models define a structured collection of elements: Maturity Levels, Process Areas, Goals, Practices, Subpractices, etc. These elements describe characteristics of processes that have been proven by experience to be effective.

182

5.4.3.2 ECMM Domains ECMM is structured in a hierarchy of components to support different users and their needs: 23 Process Areas, clustered into 7 domains and 4 Maturity Levels. In order to diagnose the current maturity level of organizations regarding collaboration and interoperability, 7 domains to which the ECMM can be applied have been defined as follows: • Project and Product Management: Cross-project and product activities related to defining,

planning, developing, risks management and quality assurance. • Business Process and Strategy: Business process management and financial aspects. • Customer Management: Relationship with the customer and evaluation. • Collaboration, Legal Environment and Trust: Legal activities, terms of collaboration

relationships. • Organisation: Management of resources, development of competences, measurement. • ICT infrastructure and Interoperability: Technologies and Services for Interoperability

and Collaboration. • Innovation: All activities related to innovation processes.

5.4.3.3 ECMM Maturity Levels The top-level components of ECMM are the maturity levels (four). According to the CMMI® definition: “A maturity level is a well-defined evolutionary plateau toward achieving a mature process. Each maturity level indicates a level of process capability. Since process capability describes the range of expected results that can be achieved by following a process, the process capability of an organization provides one means of predicting the most likely outcomes to be expected from the next effort the organization undertakes”. The graphical representation of the ECMM Maturity Levels is the following one:

Figure 83 - ECMM Maturity Levels

Following are the details of what each Level means:

1. Performed: Collaboration with external entities is done, but in an ad-hoc and chaotic manner. Collaborative tasks and processes usually exceed budget and schedule, their past success cannot be repeated, and the potential of the technology is not used properly.

2. Managed: The objective is to create a management foundation for collaboration. Network technologies are used to collaborate.

3. Standardized: The objective is to establish a common business strategy and business process infrastructure for collaboration. Business collaboration is facilitated through interoperability technologies and use of standards.

4. Innovating: The objective is to manage and exploit the capability of the CNO process infrastructure to achieve predictable results with controlled variation. Additionally, another objective is to continuously improve the CNO processes and the resulting

183

products and services through continuous capability, and planned innovative improvements.

5.4.4 COIN ECMM Structure and Description

5.4.4.1 Process Areas, goals and practices Maturity levels contain two or more Process Areas. Each process area identifies a cluster of related practices. Each Process Area is structured and contains Specific Goals and Practices. The Specific Goals of each process area summarize its practices and can be used to determine whether an organization has effectively implemented the process area. Typically each Specific Goal consists of a single sentence and a single concept. Each Process Area is described in terms of Practices. The practices describe the activities and infrastructure that contribute most to the effective implementation and institutionalization of the Process Area. For example the purpose of Collaborative Business Process (CBP) Process Area is: “to establish and maintain a usable set of collaborative business process assets and work environment standards”. This Process Area contains three Specific Goals: • SG 1: Analyse Internal Business Processes • SG 2: Establish Collaborative Business Processes • SG 3: Monitor and Optimise Collaborative Business Processes Following with this example, the first Specific Goal (SG1) contains two practices through which the SG1 can be achieved: • SP 1.1 Link internal Business Processes. Partners link their existing internal processes

and resources to achieve an agreed cross-organizational business process. • SP 1.2 Internal Processes Visibility. Each company selectively expose or hide

information about their internal processes, whilst still being able to act in a cross-organizational business process. The level of exposure can vary, as the business relationship develops.

5.4.4.2 ECMM Structure Overview In the following table, the relationship among ECMM Domains, Maturity Levels and Process Areas is depicted, where columns are the seven domains and rows are thee three maturity levels (Level one doesn’t have Process Areas). The intersections contain the 23 Process Areas identified at the ECMM.

184

Table 12 - ECMM Domains, Maturity Levels and Process Areas

5.4.4.3 ECMM Development process ECMM Development has followed an iterative approach in three phases: • Analysis and Requirements. In order to define the requirements an extended analysis has

been performed in the initial research phase, including different sources and approaches that cover:

o Other existing Maturity Models and frameworks. o Enterprise Collaboration and Enterprise Interoperability concepts (mainly coming

from two previous European projects ECOLEAD and ATHENA) have been analysed.

o Not only previous knowledge, projects and frameworks have been taken into account but also end-users vision and needs through online-questionnaires.

• Design and Development. The next natural step within the development of the model is the definition of the preliminary structure of the model and the corresponding building blocks: Domains, Maturity Levels and Process Areas.

• Application into End-Users. In order to follow an iterative approach for developing the ECMM, this phase includes the application and validation of this first version of the maturity model into real use-cases. These piloting activities will allow updating and improving the ECMM based on the input received in the assessments following an iterative approach.

185

5.4.5 ECMM Application into End Users ECMM Application into End Users includes three phases that are described more in detail in the following sub-sections: First assessment, Improvement implementations and Re-assessment.

5.4.5.1 First Assessment The goal of this phase is to analyse the practices of the collaborative network and provide improvement recommendations that help the network to improve its maturity regarding collaboration and interoperability. This phase starts with collecting information about assessment scope and context making use of a context questionnaire (in order to identify the companies of the collaborative network that will be evaluated, the Process Areas, the people to be interviewed, etc.). Assessments can be carried out in different ways, mainly on-site and remote (on–line). If assessments are remote they make use of web-based questionnaires containing both open and close questions. The Web-based questionnaires have been implemented with an Open Source tool called Lime Survey.16 The collected data is analysed by means of an evaluation tool that provides some graphics for representing the Process Areas scores.

Recommendations related toSG1-SG2-SG3

-CBP definition andmodelisation

-Internal processes visibilitydefinition

-CBP monitoting andmeasurement

Recommendations relatedto SG2-SG3

-CBP definition withstandard format

-Quantitative performance metrics

Recommendations related toSG1-SG2

-Internal processes visibilitydefinition

-CBP definition with standardformat

PA GoalsSP1.1 SP1.2

SP2.1 SP2.2

SP3.1 SP3.2

Practices

CBP

SG1

SG2

SG3

PA GoalsSP1.1 SP1.2

SP2.1 SP2.2

SP3.1 SP3.2SG3

CBP

Practices

SG1

SG2

PA GoalsSP1.1 SP1.2

SP2.1 SP2.2

SP3.1 SP3.2

Practices

CBP

SG1

SG2

SG3

Company 1 Company 2 Company 3

Recommendations related toSG1-SG2-SG3

-CBP definition andmodelisation

-Internal processes visibilitydefinition

-CBP monitoting andmeasurement

Recommendations related toSG1-SG2-SG3

-CBP definition andmodelisation

-Internal processes visibilitydefinition

-CBP monitoting andmeasurement

Recommendations relatedto SG2-SG3

-CBP definition withstandard format

-Quantitative performancemetrics

Recommendations relatedto SG2-SG3

-CBP definition withstandard format

-Quantitative performance metrics

Recommendations related toSG1-SG2

-Internal processes visibilitydefinition

-CBP definition with standardformat

Recommendations related toSG1-SG2

-Internal processes visibilitydefinition

-CBP definition with standardformat

PA GoalsSP1.1 SP1.2

SP2.1 SP2.2

SP3.1 SP3.2

Practices

CBP

SG1

SG2

SG3

PA GoalsSP1.1 SP1.2

SP2.1 SP2.2

SP3.1 SP3.2SG3

CBP

Practices

SG1

SG2

PA GoalsSP1.1 SP1.2

SP2.1 SP2.2

SP3.1 SP3.2

Practices

CBP

SG1

SG2

SG3

Company 1 Company 2 Company 3

Figure 84 - ECMM Results: Comparison between the three companies

The graphic represents an example of the evaluation of a Process Area depending on the fulfilment of each of the specific goals of the Process Area. In the first company recommendations are provided for all three goals (SG1, SG2 and SG3), in the second company for two goals (SG2 and SG3) and in the third company are related to SG1 and SG2 goals. 16 www.limesurvey.org

186

The following marks are used for representing Process Areas Scores: • Red: The purpose of the practice is judged as absent or poorly tackled in the set of

established practices. Deficiencies or problems have been identified and these issues will prevent the performance of the goal in case the deployment might be done in this way along the network.

• Yellow: The purpose of the practice is judge as correctly tackled in the set of established practices along the organisation but it has not been clarified the possible establishment in the enterprise network. Deficiencies or problems have been identified and these issues could prevent the performance of the goal in case the deployment might be done in this way along the enterprise network.

• Green: The purpose of the practice is judge as correctly tackled in the set of established practices so it would allow the performance of the goal in case the deployment might be done in this way along the enterprise network

• Not yet: The practice has not still performed because the collaborative project has not reached the appropriate point in the life cycle.

• Empty: It has not been established a mark because the evaluation has not collected information.

To close this phase the assessment reports are presented to the companies. They include both the improvement recommendations and the Process Areas scores.

5.4.5.2 Improvement implementations The main goal of this phase is the implementation of the new practices for collaboration and interoperability in the collaborative network making use of COIN services . This phase includes: • Design, test, communication, training and dissemination of new practices in the collaborative

projects. • Remote support (via email, phone teleconference, etc.) of the implementation of new

practices for collaboration and interoperability. In some cases improvement recommendations are supported by COIN services. In order to support the implementation of improvements a mapping between the COIN services and the ECMM Process Areas has been developed. An extract of this mapping is represented in the table. It is based on the final specifications of the COIN services.

187

Table 13 - Mapping COIN Collaboration Services – ECMM (extract)

COIN WP4.1 Baseline EC Services ECMM Process Area

Service for Maintaining Competencies

Ensure all the information related to membership applicants of the cluster is appropriately registered, storing their competences into a database, supporting the publication and sharing of information between cluster members.

Training and Competency Development

Develop the skills and knowledge of people in a collaborative way so they can perform their roles in the network effectively and efficiently.

Service for Matching Competencies with Business Opportunity

These services support the VO formation phase, with the characterization of the Collaboration Opportunity, search for possible partners and identification of the most suitable ones based on their competences.

Collaboration Agreement

Set up the terms in which the collaboration takes place as well as the management of the collaboration activities throughout the whole life of the collaborative enterprise.

IPR

Protect the works the members of the collaborative enterprise create and exploit.

Service for Tracking VO Members Progress

These services support the VO management and operation by providing a catalogue of pre-defined indicators, estimating partner satisfaction, aiding collaborative design or supporting human interaction in the planning and scheduling

VO management & Operation. ICT support for project management, human interaction, product development, and production planning

Measurements and Analysis

Develop and sustain a measurement infrastructure that is used to support business management information needs in order to help making decisions that affect collaborative business outcomes.

Interoperability and Collaboration Technologies

Establish tools, techniques and methods for interoperability and collaboration

Service for Maintaining Knowledge and Training

Maintain knowledge and training and fulfil an inheritance function.

Training and Competency Development

Develop the skills and knowledge of people in a collaborative way so they can perform their roles in the network effectively and efficiently.

For example the following recommendation has been provided for the “Collaborative Business Process” Process Area: “Recommendation. Model collaborative business processes following a standard format and modelling notation. Model the exchange of information linking the internal processes among the members of the network. The model of the collaborative business processes should cover: Work processes, Management processes and Support processes”. This recommendation is linked to the COIN Service: “PnP Collaborative Production Planning Portal (C3P)” that allows model the business process using a formal notation language. Regarding the link between COIN services and ECMM Process Areas, different cases have been found: • The link is very clear, i.e. “Service for maintaining knowledge and training” and “Training

and Competency Development” Process Area.

188

• Different granularity. ECMM Process Areas have a broader scope and COIN Services provide concrete solutions to specific Collaboration and Interoperability problems. Sometimes 1 COIN service = 1 Specific Practice. For example “Service for matching competencies with Business opportunity” links to the practice “SP 1.2 Select Collaborators” of “Collaboration Agreement” Process Area.

• The link is very “light” or requires some kind of interpretation. For example “Service for Maintaining Competencies” links to “Training and Competency Development” Process Area. In the service the term “competencies” refers to the information of the companies in the cluster. By the contrary in the Process Are the term “competency” applies to knowledge of people. It can indicate that Process Areas should be refined in order to better cover the COIN services approach and/or that new COIN services should be developed to better cover the Process Area.

5.4.5.3 Re-assessment The goal is to measure the practices of the collaborative network for a second time in order to check if the implementation of the improvement practices has achieved the expected results. The (self)-assessment will make use of the online web-based questionnaires previously developed or if the option selected is on-site assessments, the evaluator team will carry out the reassessments by attending the customer’s premises. The final assessment results and lessons learned will be reported, including wherever possible a comparison between the previous situation and the current one. Finally this phase aims to update and improve the ECMM with the input received making use of a feedback questionnaire.

5.4.6 Conclusions This chapter has presented the research, basis and structure of the Enterprise Collaboration Maturity Model (ECMM) developed in the context of the COIN IP project during last years. The maturity model showed in this chapter is based on other excellence frameworks and models that are standardized in today’s industry. The work carried out has allowed us to establish the initial content, structure as well as a stable definition of specific goals and practices of each of the identified process areas. Simultaneously, the assessment method has been defined, as well as the initial set of questions needed to be asked during these assessments. Final work includes the validation of the model in enterprises belonging to a CNO, a supply chain or a virtual business ecosystem. As the validation of the complete ECMM is not viable, pilots have focused on a predefined set of process areas that the enterprises select as critical for their business. These piloting activities allow us to update and improve our model based on the input received in the assessments following an iterative approach. References [1] ARICON Project

http://cordis.europa.eu/data/PROJ_FP5/ACTIONeqDndSESSIONeq112242005919ndDOC eq1905ndTBLeqEN_PROJ. htm, 2008.

[2] ATHENA Consortium (IP-507849). Guidelines and Best Practices for Applying the ATHENA Interoperability

[3] Carnegie Mellon, Software Engineering Institute, CMMI Product Team, “CMMI® for Development, Version 1.2”, 2006.

[4] COIN Consortium (IP-216256). Collaboration and Interoperability for Networked Enterprises. Anex I-Description of work, 2007.

[5] COIN Consortium (IP-216256). Maturity Model for SME collaboration. Deliverable D6.3.b, 2010.

189

[6] ECOLEAD Consortium (IP-506958). A reference Model for Collaborative Networks. Deliverable D5.2.3,2007.

[7] ERCIM News: Future Internet Technology, ERCIM EEIG, 2009. [8] Li, M., Crave S., Grilo, A., van den Berg, R Unleashing the Potential of the European Knowledge

Economy: Value proposition for Enterprise Interoperability. Version 4.0, European Communities, 2008.

190

Conclusions - The heritage of the COIN Integrated Project: how to move forward in the Future Internet Enterprise Systems domain

Besides being a mere “deliverable” in the fourth year of project, the COIN Book was thought not only as a dissemination tool in the FI research community 17 or a simple collection of unrelated scientific papers, but it was also meant as a knowledge tool to understand the state of play of research in the EI/EC domain, to identify on-going parallel domains relevant to the “Future Internet Services for Enterprises” topic, to sketch possible future research streams originated by it in the FInES domain and finally to indicate the roadmap towards a sustainable exploitation of EI/EC services in networked enterprises. This book is meant to pave the way for future research and implementation activities in the Future Internet Enterprise Systems (FInES 18) domain and brings together all the views of the different stakeholders. As a matter of fact, the COIN project contributes significantly to the progress of both scientific research in the area and also to identify business and market elements which we all need to address if we want to be competitive in such a dynamic context. All the views of the different stakeholders were represented, from the IT industry to academia, from the final users (industry, mainly SMEs) to policy makers interested in supporting and facilitating the adoption of the developed applications and services infrastructure. After four years of challenging and exciting work, it is always difficult to summarise the main outcomes and lessons learnt, given the wealth of results produced and the number of issues effectively tackled. However, we may well say that the main effort in COIN was to produce an integrated value proposition for EI/EC services, in which the excellence of the achievements in the IT service concepts was always coupled with a deep and careful analysis of the business models to be adopted, in the interest and for the benefits of potential users. Just to mention the most important impact of COIN in the scientific and business domain, we could cite: from the technical viewpoint:

a. EI/EC services commoditization to be extracted & separated from state-of-the-art Enterprise Applications in order to constitute a Service Utility (ISU) available to all the Enterprises. This COIN heritage outcome complements the servification of ESA (e.g. under the Cloud Computing SaaS paradigm) by adding another enterprise-oriented layer between the baseline FI services like storage, computation, communication and the application layer of CRM, SCM, ERP value added services.

b. Interoperability Service Utility as an essential component of the European Future Internet service infrastructure currently under development in the RTD Framework Programme 7. This COIN heritage outcome anticipates the notion of a FI Core Platform providing applications with basic, universal, available-to-all services, in this case EI/EC services. The Core Platform Generic Enablers could be complemented by enterprise-specific EI/EC commodities to fill the interoperability gaps during enterprise collaboration processes. The ISU is the delivery platform for such services, encompassing not just the usual fundamental semantically enabled service life cycle management functions (search, discovery, compose, orchestrate, execute, monitor, govern), but also advanced facilities for scalable federations of nodes, secure and trusted cross-company collaboration, intelligent and adaptive reasoning and SLAs negotiation.

17 The COIN Final Conference is in fact co-located with the FIS2011 conference, Future Internet Symposium 18 http://www.fines-cluster.eu

191

c. FInES Arch, a new reference architecture for next generation Enterprise Applications, integrating Public and Private Clouds & specific methods & tools for Business Innovation Management. This COIN outcome anticipates the FINESArch task force of the FINES cluster by depicting a new FI-oriented architecture for next generation Enterprise Systems. This view projects the Enterprise Systems from the company dimension to the cloud dimension, passing through the enterprise networks and business ecosystems collaboration forms.

d. Open-Trusted Platform Federation, as the implementation paradigm for evolutionary and scalable distributed architectures of Global Service Delivery Platforms. This COIN outcome provides a solution both to a planned and to an emergent growth of the service delivery nodes as well as an architecture for goals intelligent decomposition & service composition, and for SLAs definition and monitoring based on non-functional properties. In the planned scenario (like in Cloud Computing) , performance and scalability of the solution call for an autonomous optimisation of the necessary number of nodes, of the assignment of nodes to services and of the possible replication of service instances in different distributed nodes. In the emergent scenario (like in the Service Web), new nodes will be added to the federation in order to encompass new domains, industrial sectors or technological solution (e.g. the interoperability service platform of the automotive Odette standard, the collaboration service platform of IBM).

from the business viewpoint: e. SaaS-U Business Models as the original and innovative blending of Utility models with

Software as a Service models, prototyped in energy, healthcare and ICT enterprise systems. The applicability of blended SaaS-U business models outside the COIN application domain shows the generality and validity of our speculations in the domain of utility-based value propositions and business models.

f. Original Public-Private-Partnership Models for an earlier and pragmatic provision and diffusion of Public Utility services in the industrial ecosystem by local/central Public Authorities. COIN foresees an important role of Public Authorities in the adoption and take up of interoperability solutions and standards by SMEs. The legislative and normative field could in fact stimulate or slow down the appearance of utility services in the open internet; as an example the Action 25 of the DAE foresee that IT company should by law license the interoperability information they own.

g. New Business Values promoted and disseminated in the business arena beyond the mere economical ones: e.g. Social Solidarity, Eco-Sustainable Manufacturing, e-Participation. It is widely recognized that the presence of fundamental services given as a public good could stimulate development and entrepreneurship. In some particular cases, the Public Authority could also stimulate investments in open platforms of utility services or even become a provider of them; as an example a Regional Development Agency in a disadvantaged area could decide for social, inclusion, equal opportunity motivations to invest in the development of an ICT infrastructure (e.g. connectivity, open platforms and basic services) and to provide the enterprises of this region with EI/EC services for free or by a political price.

h. Service Innovation, as one of the most promising strategic asset not just for tertiary sector but mostly for Agriculture and Manufacturing Industry. Service Science, Everything as a Service and Value co-Creation with customers founding it. The COIN project addressed service innovation for IT industry in the FI era: assuming some services (EI/EC in particular) to be available in the open Internet for free (or almost free), IT industry is required to renovate architectures, functions and support to innovation of its solutions: as often happens in industrial contexts, the commoditization of some functions obliges stakeholders to innovate in order to stay competitive on the

192

market. Next move is to consider service innovation in other sectors: the MSEE FOF project (Manufacturing SErvice Ecosystem) is aiming at Virtual Factories, while also in the primary sector the service orientation could be very very beneficial.

Furthermore, the COIN project was a cornerstone for some outstanding work developed within the FInES cluster and with its approach it was in a position to contribute to the development of research roadmap for future research in the domain. Also through this book, the COIN project has significantly contributed to the definition of the landscape of the Enterprise Interoperability / Enterprise Collaboration domain and to the identification of all the involved stakeholders and the various players active along the value chain. Finally, we can proudly say that the COIN project provided a significant step forward to achieve more accessible IT service platform for all and to stimulate a wave of future internet-based services using innovative internet technologies.

Bremer Schriften zu Betriebstechnik und Arbeitswissenschaft Herausgegeben vom Bremer Institut für Betriebstechnik und angewandte Arbeitswissenschaft an der Universität Bremen (BIBA)

Prof. Dr.-Ing. G. Goch Prof. Dr.-Ing. D. H. Müller Prof. Dr.-Ing.K.-D. Thoben Prof. Dr. Ing. B. Scholz-Reiter Band 1: Effiziente Angebotserstellung für komplexe Produkte. Konferenzband zum gleich-

namigen Workshop in Bremen, Januar 1995.

Band 2: Berger, U.: Entwicklung eines sensorgestützten Planungs- und Programmiersystems für den Industrierobotereinsatz in der Unikat-, Einzel- und Kleinserienfertigung. Dissertation Universität Bremen, 1995.

Band 3: Vöge, M.: Entwicklung und Erprobung einer partizipativen Vorgehensweise zur Ein-führung von rechnerunterstützten Werkzeugen für die Fertigung und Montage. Disser-tation Universität Bremen, 1995.

Band 4: Effektiver EDV-Einsatz in der werkstattnahen Produktion. Konferenzband zum gleich-namigen Workshop in Bremen, November 1995.

Band 5: Splanemann, R.: Teilautomatische Generierung von Simulationsmodellen aus sy-stemneutral definierten Unternehmensdaten am Beispiel der Integration der Material-flußsimulation in die Planung von Fertigungsanlagen. Dissertation Universität Bremen, 1995.

Band 6: Organisation, Technik, Qualifikation. Schwerpunkte der Aktivitäten des BIBA in der Entwicklung, Einführung und Bewertung von aufgaben- und nutzergerechter technisch-organisatorischer und qualifikatorischer Innovationen. Bremen, Dezember 1995.

Band 7: Theorie- und erfahrungsgeleitete Organisationsgestaltung und Personalentwicklung. Vorgehensweisen, Methoden und Werkzeuge zur integrativen Gestaltung von Organi-sation und Qualifikation. Bremen, Januar 1996.

Band 8: Oehlmann, R.: Ein Informationssystem für das Concurrent Engineering komplexer Produkte. Dissertation Universität Bremen, 1996.

Band 9: Gestaltung technischer, organisatorischer und qualifikatorischer Innovationen. Schwer-punkte der Aktivitäten des BIBA im Jahre 1995. Bremen, Juni 1996.

Band 10: PACE ´96 - A Practical Approach to Concurrent Engineering. Proceedings of Euro-pean Workshop in Bremen, Germany, 16. September 1996.

Band 11: Integrierte breitbandige Telekommunikation. Stand der Technik und Anwendungsfelder. Konferenzband zum gleichnamigen Workshop in Bremen, Dezember 1995.

Band 12: Stumm, Thomas; Seidel, Karsten: The Role and Significance of Small and Medium-Sized Enterprises in the Maritime Sector. Discussing a better integration of maritime SMEs into the framework European policies. Study carried out for The Alliance of Maritime Regional Interests in Europe - AMRIE. Bremen, April 1997.

Band 13: Gottschalch, H.: Mentale Modelle als Grundlage arbeitsorientierter Gestaltung am Bei-spiel von Planungs- und Steuerungsprogrammen. Bremen, April 1997.

Band 14: Führung, Organisation und Qualität in interdisziplinären, internationalen Projekten. Bericht über die Arbeiten des Bremer Instituts für Betriebstechnik und angewandte Arbeitswissenschaft im Jahre 1996. Bremen, April 1997.

Band 15: Marciniak, Z.: Konzept eines Koordinationssystems zur Integration der rechnerge-stützten Produktionsplanungs- und -steuerungsaktivitäten in der verteilten Produktion. Dissertation Universität Bremen, 1996.

Band 16: Spatz, H.: Informationstechnische Unterstützung für Gruppenarbeit im Bereich Planung und Steuerung. Dissertation Universität Bremen, 1996.

Band 17: Beins, G.: Konzeption eines modularen Steuerungssystems für Puffer - untersucht am Beispiel der Automobilfertigung. Dissertation Universität Bremen, 1996.

Band 18: Heeg, F. J.; Hirsch, B. E.; Knackfuß, P. (Hrsg.): Automatisierungstechnik für Produk-tionstechniker. Ausgewählte Lehrinhalte für Studenten und Anwender. Bremen, April 1997.

Band 19: Detken, K.-O.: GSM - „Global System for Mobile Communication“: Der Mobilfunk-standard. (Standards, Protokolle, Techniken, Zukunftsaussichten). Bremen, Juli 1997.

Band 20: Kohstall, T.: Integriertes Managementsystem für kleine und mittlere Unternehmen unter besonderer Berücksichtigung eines Organisationssystems für Sicherheit und Gesund-heitsschutz der Mitarbeiter im Unternehmen. Dissertation Universität Bremen, 1998.

Band 21: Eren, E.: Konzeption und Entwicklung eines mobilen Telekommunikationssystems zur Projektabwicklung in Regionen mit schwacher Kommunikationsinfrastruktur am Beispiel von Bauvorhaben. Dissertation Universität Bremen, 1998.

Band 22: Kompetenzentwicklung, Organisation, Technik. Bericht über die Arbeiten des Bremer Instituts für Betriebstechnik und angewandte Arbeitswissenschaft zur Entwicklung, Einführung und Bewertung von aufgaben- und nutzergerechten, technisch-organisa-torischen und kompetenzförderlichen Innovationen. Bremen, August 1998.

Band 23: Heeg, F. J.; Kleine, G. (Hrsg.): Kommunikation und Kooperation. Arbeitswissenschaft-liche Aspekte der Gestaltung von Kommunikations- und Kooperationsbeziehungen und -systemen. Bremen, Januar 1999.

Band 24: Wisotzki, H.: Stand der Umsetzung und Merkmale von Qualitätsmanagementsystemen in der privatwirtschaftlichen bundesdeutschen Entsorgungswirtschaft. Dissertation Uni-versität Bremen, 1999.

Band 25: Frieß, P. M.: Projektmanagement für den tiefgreifenden organisatorischen Wandel mit-telgroßer Einheiten. Gestaltung eines PM-Modells unter Anwendung neuer system-theoretischer Konzepte zur Verbesserung des Projekterfolges. Dissertation Universität Bremen, 1999.

Band 26: Weber, F. (Ed.): Efficient Bid Preparation in the Construction Industry. How to Win more Bids with less Effort. Bremen, Mai 1999.

Band 27: Esser, M.: Entwicklung von Bausteinen zum Aufbau von modularen Betrieblichen Um-weltinformationssystemen (BUIS) und deren Einführung bei Industrieunternehmen. Dis-sertation Universität Bremen, 1999.

Band 28: Krömker, M.: Werkzeug zur durchgängigen Systemunterstützung der Angebotser-stellung in der Unikat- und Kleinserienfertigung. Dissertation Universität Bremen, 1999.

Band 29: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Müller, D. H. (Hrsg.): Mensch und Technik. Gestaltung von technisch-organisatorischen Innovationen. Bremen, Februar 2000.

Band 30: Ihlenfeldt, F.: Entwicklung eines Vorgehensmodells zur Gestaltung von Dienst-leistungsprozessen im Qualitätsmanagement. Dissertation Universität Bremen, 2000.

Band 31: Bredehorst, B.; Weber, F. (Ed.): Communication and Decision Support in a Concur-rent Engineering Environment. CODESCO – The Final Report. Bremen, September 2000.

Band 32: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Müller, D. H. (Hrsg.): Technik-, Organisations- und Kompetenzentwicklung aus interdisziplinärer Sicht. Bremen, Oktober 2000.

Band 33: Beinhold, F.: Entwicklung und Validierung eines Modells zur systematischen Anfor-derungsermittlung und zur Planung eines kompetenzorientierten Ressourcenmana-gements in projektorientierten Strukturen. Dissertation Universität Bremen, 2000.

Band 34: Koch, A.: Entwicklung und Erprobung eines Vorgehens zur kompetenzorientierten Personaleinsatzplanung und zur Evaluation von Prozessen der Kompetenzentwicklung in projektorientierten Strukturen. Dissertation Universität Bremen, 2001.

Band 35: Windhoff, G.: Planspiele für die verteilte Produktion. Entwicklung und Einsatz von Trainingsmodulen für das aktive Erleben charakteristischer Arbeitssituationen in arbeitsteiligen, verteilten Produktionssystemen auf Basis der Planspielmethodik. Dissertation Universität Bremen, 2001.

Band 36: Heeg, F. J.; Binz, P.; Fafflock, H.; Kaebler, J.; Pracht, J.; Roth, C.; Sperga, M.: Betriebliche Veränderungsprozesse – selbstorganisationstheoretisch reflektiert. Bericht über die Begleitung von organisatorisch-qualifikatorischen Veränderungsvorhaben in Unternehmen verschiedener Branchen. Bremen, Dezember 2001.

Band 37: Zabel, J.; Bönke, D.; Panse, C.: Open Network for Tourism. OnTour – Final Report. Bremen, Januar 2002.

Band 38: Wurst, S.: Konzept für den bedarfsgerechten Austausch von Produktdaten unter weitgehender Nutzung vorhandener Standards und Methoden. Dissertation Universität Bremen, 2001.

Band 39: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Scholz-Reiter, B.; Thoben K. D.: Produktent-wicklung - Von der Produktgestaltung bis zur Fertigungsplanung. Berichte aus Praxis und Forschung. Festschrift zum 60. Geburtstag von Prof. Dr.-Ing. Dieter H. Müller. Bremen, April 2002.

Band 40: Schweiger, S.: Untersuchung zur Qualität von Qualitätsmanagementsystemen in Pro-duktionsunternehmen. Möglichkeiten der Bewertung der Qualität über einen dienst-leistungsorientierten Ansatz. Dissertation Universität Bremen, 2001.

Band 41: Schumacher, J.: Entwurf eines Simulationswerkzeuges für die Planung multimodaler Logistikkonzepte in der verteilten Produktion. Dissertation Universität Bremen, 2001.

Band 42: Klußmann, J.: Entwicklung eines Simulationssystems für die Produktionsplanung von kundenspezifischen Aufträgen unter besonderer Berücksichtigung von Akzidenz-druckereien. Dissertation Universität Bremen, 2001.

Band 43: Zabel, J.; Peters, O. (Ed.): Efficient Bidding and Procurement in the Tile Industry. Practical Trading Tools and Broker Services for the Exchange of Product Charac-teristics. E-bip – A Best Practice Report. Bremen, August 2002.

Band 44: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Müller, D. H.; Scholz-Reiter, B. (Hrsg.): Gestal-tungsfelder der kooperativen Produktion. Bremen, September 2002.

Band 45: Sperga, M.: Kooperation im kleinbetrieblichen Arbeitsschutz. Zur Rollenerfahrung von Sicherheitsfachkräften und Betriebsärzten. Dissertation Universität Bremen, 2002.

Band 46: Thoben, K.-D.; Fritz, S.; Lünemann, M.: Fit für die Maßgeschneiderte Massenfer-tigung durch agile, rekonfigurierbare Fertigungssysteme. Proceedings of the National Workshop within the ARMMS Project. (Stuttgart, Germany, 20 March, 2002). Bremen, Mai 2003.

Band 47: Wunram, M. (Ed.): Practical Methods and Tools for Corporate Knowledge Manage-ment. Sharing and Capitalising Engineering Know-How in the Concurrent Enterprise. CORMA – Assessing Inter-organisational Knowledge Management – A Report on Experiences and Insights. Bremen, Juni 2003.

Band 48: Kaebler, J.: Interventionen für die Organisationsberatung in Flexibilisierungsprozes-sen. Ansätze unter Berücksichtigung der System- und Selbstorganisationstheorien. Dissertation Universität Bremen, 2003.

Band 49: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Müller, D. H.; Scholz-Reiter, B. (Hrsg.): Metho-den für Organisation und Technik des digitalisierten Product-Life-Cycle. Bremen Sep-tember, 2003.

Band 50: Fafflock, H.; Güttler, K.; Lehmann, A.; Bruns, T.; Wicha, I.: Pflegeprozess – Standardisierung und Qualität in der Pflege. Bremen, November 2003.

Band 51: Aumund-Kopp, C. (Hg.): Arbeits- und Organisationsgestaltung in E-Business basier-ten Prozessen am Beispiel der schnellen Produktentwicklung. agepro. Bremen, Februar 2004.

Band 52: Zabel, J.: Referenzmodell der Interaktionsprozesse zwischen Angebotsbearbeitungs-/ Beschaffungsapplikationen und elektronischen Marktplätzen für kleine und mittlere Unternehmen. Dissertation Universität Bremen, 2004.

Band 53: Selk, A.: Konstruktion von Gussformen mit einer rechnergestützten Entscheidungs-hilfe. Dissertation Universität Bremen, 2005.

Band 54: Schwesig, M.: Development of a web based management simulation of knowledge exchange in networked manufacturing organisations. Dissertation Universität Bre-men, 2005.

Band 55: Lemmel, M.: Verfahren zur anwenderoptimierten Auslegung elektrischer Energie-speichersysteme für emissionsfreie Fahrzeuge. Strategien zur Markteinführung. Dis-sertation Universität Bremen, 2006.

Band 56: Echelmeyer, W.: Entwicklung einer modularen prozessintegrierten Anpassungs-qualifizierung in klein- und mittelständischen Unternehmen. Dissertation Universität Bremen, 2006.

Band 57: Hoheisel, J.: Konzeption und Entwicklung eines computerbasierten Simulationsspiels zum Üben von Telekooperation im Anwendungsbereich der verteilten Produktent-wicklung. Dissertation Universität Bremen, 2006.

Band 58: Müller, D.-H.; Gsell, H.: Netzwerk Schiffstechnik 2010 NET-S: Struktur Organisation, Kommunikation. Bremen 2007.

Band 59: Thoben, K.-D.; Baalsrud-Hauge, J.; Smeds, R.; Riis, J. O. (Hg.): Multidisciplinary Research on New Methods for Learning and Innovation in Enterprise Networks: Proceedings from the 11th Special Interest Group on Workshop on Experimental Interactive Learning in Industrial Management. Bremen 2007.

Band 60: Seifert, M.: Unterstützung der Konsortialbildung in Virtuellen Organisationen durch prospektives Performance Measurement. Dissertation Universität Bremen, 2007.

Band 61: Weber, F.: Formale Interaktionsanalyse: Ein Beitrag zur systematischen Gestaltung von Informations- und Kommunikationsstrukturen im Concurrent Enterprise durch die Berücksichtigung von Informationseigenschaften. Dissertation Universität Bremen, 2007.

Fortsetzung der Schriftenreihe unter:

Bremer Schriften zur integrierten Produkt- und Prozessentwicklung

Herausgeben vom BIBA (Bremer Institut für Produktion und Logistik GmbH) Forschungsbereich IKAP (Informations- und kommunikationstechnische Anwendungen in der Produktion) und BIK (Bremer Institut für Integrierte Produktentwicklung)

Prof. Dr.-Ing. K.-D. Thoben und Prof. Dr.-Ing. D. H. Müller

Band 62: Schnatmeyer, M.: RFID-basierte Nachverfolgung logistischer Einheiten in der Kreis-laufwirtschaft. Dissertation Universität Bremen, 2008.

Band 63: Seifert, M.: Collaboration Formation in Virtual Organisations by applyingprospective Performance Measurement, 2009

Band 64: Eschenbächer, J.: Gestaltung von Innovationsprozessen in Virtuellen Organisationen durch Kooperationsorientierte Netzwerkanalyse, 2009

Band 65: Ioannis, F.: An approach to Service Composition for Internet and mobile services based on Knowledge-Based Model-Driven Variant Configuration, 2009

Band 66: Wunram, M. Entwicklung eines störungsorientierten Referenzmodells für Wissensmanagement zur Unterstützung kooperativer Produktentwicklung, 2009

Band 67: Bredehorst, B.: Wissensgemeinschaft-basiertes Vorgehensmodell zur Interaktion zwischen Forschung und Industrie

Band 68: Bemeleit, B.: Risikomanagement für selbststeuernde logistische Prozesse

Band 69: Hans, C.: Konzeption und prototypische Umsetzung eines simulationsbasierten Werkzeuges zur Unterstützung der Konsortialbildung in Virtuellen Organisationen in der Produktion

Band 70: Kirchheim, A.: Verfahren zur Erkennung von sackförmigen Stückgütern für die automatische Entladung in logistischen Prozessen

Band 71: Sitek, P., Gusmeroli S., Conte, M., Jansson, K., Karvonen, I.: The COIN Book Enterprise Collaboration and Interoperability