Apollon - eManufacturing - Impact Assessment

DELIVERABLE Project Acronym:

APOLLON

Grant Agreement number:

250516

Project Title:

Advanced Pilots of Living Labs Operating in Networks

D 4.5 Impact assessment and best practices Revision: Final

Authors: Carsten Puschke (SAP) JoĂŁo Lopes (Fiapal) Manuel Nina (Alfamicro) Fernando Nabais (Ydreams) Andreas Klein (SAP) Zoltan Kabasz (HVEC)

Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level P

Public

X

Apollon – D.4.5

Statement of originality: This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

Deliverable 4.5 Public

2

Final Version

Apollon – D.4.5 Table of Contents 1.

Introduction ........................................................................................................................... 4

2.

Findings from our previous work ................................................................................... 4

3.

The collaboration platform for the manufacturing domain ................................. 5

3.1 The business need ........................................................................................................................ 5 3.1.1 The service provider role ..................................................................................................................6 3.1.2 The service consumer role ................................................................................................................7 3.1.3 The role of a domain specific Living Lab network ..................................................................7 3.2 Technical Setup of the collaboration platform .................................................................. 9 3.2.1 The Knowledge Transfer ...................................................................................................................9 3.2.2 Architectural setup of the collaboration platform ............................................................... 10 3.2.3 Implementation / Installation of the collaboration platform.......................................... 12 3.3 Content provisioning to the collaboration platform .................................................... 14

4. Impact assessment of the manufacturing industry domain specific collaboration platform ............................................................................................................ 15 4.1 4.2 4.3

5.

6.

What does that mean for a networked Europe? ............................................................. 15 SMEs get into new markets .................................................................................................... 15 Living Lab networks accelerating businesses ................................................................. 16

Global business factors / exceptional situations ................................................... 17

5.1 A challenge report from the Hungarian Vehicle Engineering Cluster project partner ..................................................................................................................................................... 17 5.1.1 History and Background ................................................................................................................. 18 5.1.2 Project activities during the Setup phase ................................................................................ 18 5.1.3 Challenges and reasons that lead to a failure of the active participation of the Hungarian project partners ....................................................................................................... 19 5.1.4 Conclusions and Recommendations .......................................................................................... 19

Summary............................................................................................................................... 20

Deliverable 4.5 Public

3

Final Version

Apollon – D.4.5

1. Introduction As described in the previous deliverables the MDI platform has been installed in the German and Portuguese Living Labs.

The selected use cases are now fully implemented and operational.

Energy monitoring use case has been implemented in both Living Labs and enables a real time monitoring of energy consumption. Additionally detailed analysis and preparation of energy rationalization plans are now possible for the partner SME. Asset viewing use case has been implemented in Portugal and enables the monitoring of several workstations with specific characteristics and in a versatile environment. by using the use cases from the first phase of the manufacturing experiment, in this deliverable we present the next steps of collaboration by introducing a platform and evaluating its potential for business collaboration between the partners.

2. Findings from our previous work Until end of 2011 (Month 26) most of the time was spent on the technical evaluation, research results, and findings of Living Lab interoperability and cross-border collaboration with respect to the implemented use cases in the German and Portuguese Living Labs.

Concerning the cross-border activities that were established between SAP and Ydreams, in connection with the use cases implemented on premises of the involved Portuguese SMEs Imeguisa and CENI, full interoperability and technical implementation were achieved, following all defined specifications of the use cases.

According to the initial set goals as listed in the DoW: • • •

Advance the state of the art by adapting the MDI platform to support cross-border services and activities Improve collaboration amongst local SMEs (those that are connected to an individual Living Lab) and help them build services that are useful to relevant manufacturing use cases of interest to all Living Labs Initiate and improve collaboration amongst selected trans-national SMEs such that they can produce as well as consume each others' services using the platform as a basis. Moreover, potential inter-SME activities will be stimulated that are of benefit to all stakeholders (SMEs, Living Labs, and the local economy)

it can be repeatedly said that for the implementation phase of the use cases (the project work as such) everything went as expected.

If we look at the third bullet point saying that we also should focus on the initiation and improvement of the collaboration between the SMEs - this was identified as the area for with the highest potential. Once the business partners know each other and exchanged information of what should be delivered respectively received to/from the other party it's an easy "project game" to play. But making potential business partners aware of each other who are geographically far away is the biggest drawback.

We therefore decided to put our attention on this challenge for the last period of Apollon to introduce another platform which should act as a marketplace not just being a service trading

Deliverable 4.5 Public

4

Final Version

Apollon – D.4.5 platform but also offering collaboration aspects that allows an easier decision making to enter in cross border businesses.

In connection to that we also looked into the aspect how can Living Labs support those transnational businesses.

3. The collaboration platform for the manufacturing domain 3.1 The business need As we started with the Apollon project the WP4 stakeholders came together and were looking into use cases that force cross border activities being either knowledge exchange, technology transfer or operational tasks to be done in order to setup and maintain the use cases for Energy Monitoring and for Asset Viewing (see also D.4.2. and D.4.3.).

Again (as already reported in our previous deliverables) it means that we put business partnerships in place because of the fact that we were forced (in a positive manner) by setup Apollon as such.

In other words the SMEs and LLs involved neither didn't come together to build these use cases as there were mission critical situations at the customer role playing SMEs site to get these use cases into their plants nor as there were SMEs laying the service provider role who were heavily seeking for business opportunities outside their home countries.

For the avoidance of doubt this was not an approach that we started misleadingly with but was done by intention to see and explore what we need in order to facilitate cross border activities in general. Therefore we've chosen a technology platform coming from SAP Research being the starting point for that.

With the partners and the uses cases being in place we were in a project mode from the beginning on and focused 100% on project based cross border activities.

We can say that once the project goal is given and generally set business to business relationships on an operational level were almost easy to manage - even across different countries.

Of course it could be that the "human factor" might play a role at some point of a project but as long as the various stakeholders focus on the project itself and the things to be achieved - in our case the 2 use cases - it is a straight forward work.

Needless to say but what always needs to be in place is a project plan defining who is doing what by when, how and why. Having that said it does not mean that projects always look similar with regards to the formalization of processes. As we outlined in previous deliverables trust and commitment are key to get things done. Business partners who are working a first time together usually formalize things more than partners who are working together since years or in many projects. The same is true for larger projects where much more investments (money, resources,...) being made than in small and focused undertakings. What plays also an important role are references that services providers can come up with which is THE door opener in many projects.

But what about if you know what you want to achieve but cannot make it alone and therefore need business partners who have the right knowledge and technology and are providers of innovative solutions that are maybe even better with their portfolio in comparison to what you've had initially in mind.

On the other hand where are the potential customers and new markets for new SMEs that are these innovative thought leaders and have promising solutions available.

So the question is:

Deliverable 4.5 Public

5

Final Version

Apollon – D.4.5 •

How can be parties brought together that are offering and seeking any kind of services that are ready for transnational projects regardless at which location they are based?

Subsequently we needed to find answers for: •

How can such services be made available in an easy and structured way?

•

How can potential business partners (that are far away from each other) exchange knowledge easily prior to a project starts?

•

How do potential customers get to know about the level of knowledge, project experiences and quality of previously ran projects at the services provider site?

•

Vice Versa: How can service providers describe and display their knowledge, technology and the maturity of these based on projects they did before?

These and other aspects of the business site of cross border projects can be in our opinion only be addressed by instantiating a collaboration platform. This collaboration platform is key in order to identify and trigger businesses in regions that are especially new to SMEs (both - customers as well as service providers) but which are ready to start to go international.

Furthermore - and as Apollon is also looking into the supportive role that Living Labs can play here we looked into this and identified a set of services that can be so to speak exclusively offered by them.

Please find in the following chapters below what the business benefits of such a collaboration platform are, what the different roles of players and categories are and why we believe that it can be seen as a new kind of methodology consisting various tools.

3.1.1 The service provider role Internationalization and the search for new markets are becoming crucial for a SME to survive in present times. The effort required to accomplish this goal through traditional market approaches is frequently difficult to achieve by a SME or, at least, has to be narrowed to specific market segments and geographical regions, obeying a budget restriction necessity. Enlarging the scope of market reach involves a multiplication of budget and resources that configure a high risk not guaranteed to bring a valuable ROI or taking, potentially, longer time than a company can endure. Normally, a growing strategy for a SME encompasses resource intensive activities like market research, participation in industry events, consultancy and PR hiring, among others. All these endeavours may, anyway, be inefficient in their results due to a lack of references or to an imperfect fit to these new customer’s needs.

The possibility to be able to reach new markets in a faster and more effective way is a decisive factor in SME competitiveness. This can be potentiated by the possibilities provided by the new information technologies, especially when established in a way that enhances the normal commercial activity, assembles the right actors in these processes and creates the mechanisms to provide fruitful encounters between these actors. Another important factor is to create an effective granularity of available information that can adapt to the typologies of the services offered, to the requests from potential customers and that allows for the automatic discovery of complementary services.

The matchmaking potential of the platform is the missing link to allow SMEs to expand their commercial activities across a wider range of services and geographic markets.

Deliverable 4.5 Public

6

Final Version

Apollon – D.4.5 3.1.2 The service consumer role Consumers in a Business-to-Business scenario are governed by the same basic principles as the other user categories, they seek to fulfill their needs in a cost-efficient way, fulfilling their requirements and expecting good service quality. If simple, of-the-shelf, tested and proven solutions are available, they will be preferred, but, if tailor-made products or solutions are required, particularly if interoperability issues are involved, the need for trust between partners arises, and of close collaboration in a B2B environment.

Therefore service consumers should not stay invisible until they have found the right services they are looking for but should get the possibility to provide information about their projects / issues / problems that they want to tackle. In our opinion that really increases the value of the collaboration platform which is then no longer a straight service trading marketplace but something where providers and consumers can come together even before the right services are in place and where they can co-create the right solutions.

Several stages can be identified in a B2B relationship:

Portfolio

Tender

Implementation

Follow-up

•First collection of service providers •Portfolio of service provider solutions

•Solution specification •Several rounds of dialogue •Choice of one provider

•Interoperability issues •Close relation between companies

•Maintenance •Technical support •Etc.

Figure 1: B2B relationship lifecycle

In the process of establishing B2B relationships, the collaborative platform has a role to play in Portfolio and Tend phases, by facilitating the showcase of the service providers, presenting their portfolio and allowing for better dialogue between companies.

3.1.3 The role of a domain specific Living Lab network Concerning eManufacturing, the European Network of Living Labs (ENoLL) has a Thematic Sub Group dedicated to Industrial and logistics development. The Domain Network of eManufacturing from Apollon is belonging to that Thematic Sub Group (see Figure 2).

Deliverable 4.5 Public

7

Final Version

Apollon – D.4.5

Council

ENoLL

Thematic Domain Living Labs

Work Groups Thematic Sub Groups

(...)

Energy Efficiency

Industrial and logistics development

Sustainable Energy

(...)

Climate change

APOLLON eManufacturing Thematic Domain Network

Figure 2: Apollon eManufacturing thematic domain network within ENoLL

Pursuing the results of the APOLLON project, Living Labs which are part of the Industrial and logistics development Sub Work Group will be prompted by ENoLL to register their ecosystems in the collaboration platform from APOLLON or to implement such a platform in their own premises, dedicated to their local ecosystem. These ecosystems comprise Companies, SMEs, research institutes, universities and other entities whose activities are related to eManufacturing.

Individual Living Labs which are composed by large clusters of SMEs will be strengthened by the implementation of such a collaboration platform also at local level, enabling them to improve their tools for the showcase and offer of services and products.

The spectrum of what domain specific Living Labs can cover in order to bring SMEs faster to new markets can include almost every kind of services starting from governmental / legal related services up to straight technical services such as early prototyping - depending on the nature of the respective LL. The participating LL in WP4 can be seen as a very good example for the diversity of them.

The SAP Research Future Factory is clearly focusing on technological research and prototyping.

Given the fact that a large enterprise such as SAP needs to make sure that its solution portfolio is able to run in heterogeneous environments it has built various LL for different industry and technology domains. So the SAP Research Future Factory appears completely as a testbed which can be used by its partners either to test hard- and software prototypes at a very early stage (long before it goes productive) or partners want to test their existing (already being in the market) solutions specifically together with an SAP infrastructure as this market (customer segment) is still new to them.

Business models how our partners can to sell their future solutions can be of course discussed but are in general not in focus of these partnerships. The SAP Researchers mainly provide their knowledge and experiences when it comes to technical proof of concepts.

The win-win situation for both - the SAP Research Future Factory and its partners is obvious. As stated above, SAP positions itself as being able to offer software solutions interacting with any kind of soft- and hardware. The partners get high visibility as innovative companies playing in a potential large market segment that they want to step into. Finally not to forget the customers who are exactly seeking for those indicators that SAP partners are not "just" integrating with existing SAP software

Deliverable 4.5 Public

8

Final Version

Apollon – D.4.5 solutions but are also participating in research projects that are looking into the software solutions of tomorrow.

The Fiapal LL is a network supporting businesses in the Portuguese engineering and manufacturing industries with main focus in the automotive sector. It provides direct support to local SMEs by offering technical advice and diagnosis on quality, productivity, ESH, product development and process optimization; Furthermore Fiapal provides support in project management, information exchange and facilitates networking.

As an international partner in the manufacturing industry domain for partner identification and as a reliable facilitator within its existing LL eco-System (OEMs, large enterprises as well as academia and local authorities) it is clearly acting as a local and transnational hub for the region.

Fiapal is also a Test bed for product testing in local SMEs, as proven in the Apollon project.

Alfamicro, as a consultancy company specialized in Open Innovation Strategies, and particularly Living Lab methodologies, provides SMEs and Living Labs with the tools and education in order to leverage and enhance local and international activities.

Using Web 2.0 tools and innovative media strategies, Alfamicro helps SMEs and Living Labs to disseminate their knowledge, services and best practices at National and European level and has specialized services dedicated to project management at local and European level that allow for SMEs, Living Labs, Research Institutes, Universities, etc. to set up RDI projects with an European scope.

3.2 Technical Setup of the collaboration platform The Apollon Collaboration Platform is based on the Open Source Prototype “USDL Marketplace” developed within the Theseus Texo project. It consumes and exposes services described in the Unified Service Description language (USDL), a platform-neutral language for describing business details of a service, such as pricing, service-levels, and legal aspects in a standardized way. This and the central concept of abstract services, which is used to cluster services that comply with a number of predefined description properties, lead to enhancements in comparability and exchangeability of services. The main purpose of such a marketplace is to support service providers and service consumers in the matchmaking phase.

The given prototype of a service marketplace is implemented as a J2EE application based on Jboss’s Seam framework. JBOSS-Seam is a combination of different open source components and comes with a fully-fledged toolset for creating user interfaces, business logic and database persistence.

For the Apollon project a customized USDL Marketplace was set up as an Internet-based platform to the domain networks of Living Labs. Service providers (in particular SMEs) often act within tight budget boundaries, especially for investments in market research, for business development or for promotion/marketing. Thus the Apollon Collaboration Platform offers mechanisms that support trading services across borders in new target markets. In particular when a service provider need to find early adopters and future customers for new products in a market it is not familiar with. The Apollon Collaboration Platform offers help to moderate the processes of finding the right partners, users and future customers to incubate business collaboration.

3.2.1 The Knowledge Transfer To transfer the knowledge how the platform can be used by service providers and service consumers several SAP Connect Sessions were set up. SAP Connect is a conferencing system

Deliverable 4.5 Public

9

Final Version

Apollon – D.4.5 which allows video, web and audio conferencing enhanced with social networking and media sharing. Furthermore SAP offered email as well as telephone support to integrate partners with their offerings into the platform.

The things described under 3.2.2 and 3.2.3 were intensively discussed and improved by using the communication infrastructure mentioned above. During our weekly conference calls that were in place from the beginning on of Apollon we came really fast to the decisions where and how to start with the build-up of our collaboration platform.

3.2.2 Architectural setup of the collaboration platform In the following we want to distinguish between the inner architecture of the Apollon Collaboration Platform and the architecture of the whole system in a productive and scalable deployment environment. While the inner architecture section focuses on the platform and its core components, the deployment scenario section aims on the platform’s interfaces to the outside world and scalability features such as application server clustering and load balancing.

Apollon Collaboration Platform (inner) Architecture: The USDL Marketplace itself provides multiple core components with dedicated functionality. Not all of the available components are actually necessary to realize the Apollon Collaboration Platform Use Case. The components which were used for the Apollon Platform are depicted in the diagram below. Notice that the terms “Service” and “Solution” are used interchangeable here.

Figure 3: Apollon Platform Architecture

As illustrated in the architecture diagram, the Matchmaking component is about discovering and matching offering and demand. It provides functionality to browse the catalogue and search for services as well as shopping cart functionality for services with a fixed price or for services that require an RFQ process in advance. The shopping cart is directly connected to the RFQ&Ordering component which handles everything related to RFQ processing, bargaining, ordering, and delivery management.

Deliverable 4.5 Public

10

Final Version

Apollon – D.4.5 For authentication and authorization of users, the corresponding component is used. It redirects platform users after their login directly to an individual view on the collaboration platform associated with their role on the system (service consumer, service provider and administrator).

While the service consumer’s individual view focuses on matchmaking functions and RFQ/Order processing, the provider’s view on the system mainly targets on service creation and service editing features which are provided by the Administration component. In addition to these service administration features, a user with the Administrator role has amongst others the possibility to maintain service categories, administrate users, and change texts on the user interface.

Productive and scalable deployment scenario for the Apollon Collaboration Platform: The deployment diagram below shows the deployment components for a possible productive system and the communication channels between them. For the communication across network boundaries the protocols and ports to use are listed.

Figure 4: Deployment Scenario for the Apollon Collaboration Platform

The boxes in the Internet Zone list the Platform users and their roles as well as possible external systems. All components hosted in the Internet DMZ, i.e. Apache for load balancing, the JBoss Application Servers where the platform core software runs, the Media Content Repository, and the database may all be deployed to distinct servers, but they can also run on the same machine. This is a configuration option to achieve scalability and reliability.

Deliverable 4.5 Public

11

Final Version

Apollon – D.4.5 3.2.3 Implementation / Installation of the collaboration platform The implementation of the Apollon Collaboration Platform started on an SAP internal development system end of 2011. After the user interface and UI text customization, an appropriate Apollon branding was applied to the platform.

To get a first impression how such a collaboration platform behaves and what functionality is really needed, it is crucial to get an initial set of users and content into the system as soon as possible.

Microsoft Word based templates for service and provider descriptions were provided to the partners to get the content to fulfil this purpose. See a screenshot of the platform’s landing page including the initial content below.

Figure 5: Landing Page Screenshot of the Apollon Collaboration Platform

Fiapal offered to provide the necessary infrastructure to host the collaboration platform in the internet and YDreams was responsible for technical support, in direct contact with SAP. To simplify the installation process and to minimize the administrative tasks a virtualized solution was chosen.

So, the whole platform was installed and configured in a virtual machine running at SAP and was subsequently shipped to Fiapal. How this process was executed is shown in the diagram below

Deliverable 4.5 Public

12

Final Version

Apollon – D.4.5 Platform preparation at SAP • Creation of a virtual Linux machine • Installation of the Apollon Platform Software • Database and Multimedia Repository configuration

Shipment to Fiapal • Upload of the Virtual Machine to SAP Mats which is a tool for transferring large files between SAP people and external parties • Software download by Fiapal

Platform installation at Fiapal •Installation of Virtual Machine Software on a PC located at Fiapal •Import of the Apollon Platform VM in the Virtual Machine Software •Network Configuration of the Virtual Machine Figure 6: Platform installation at Fiapal

The virtual machine itself includes the Apollon Collaboration Platform as well as the databases for its application and media content. After some network settings adjustments, according to the concrete deployment environment, the platform should run out of the box in any virtual environment.

How the productive system was set up at Fiapal is pictured below. The SSH tunnel is an optional component to enable system administrators from outside Fiapal to access the Virtual machine on a system level. This tunnel can be used for maintenance tasks such as creating or restoring database backups, shutting down or starting up the Apollon Collaboration Platform, and potential error analysis.

Deliverable 4.5 Public

13

Final Version

Apollon – D.4.5

Figure 7: Productive Platform System @ Fiapal

3.3 Content provisioning to the collaboration platform In order to feed the collaboration platform properly with information and content we used (as already shortly mentioned under 3.2.3) Microsoft Word based templates for service and provider descriptions. With the given service template we brought the various services fast and easy into the collaboration platform regardless if they were either already used in the different use cases we ran before or if it were brand new services that we "just" uploaded to test how the process works.

Such a template includes the following questions to be answered precisely: • • • • • • • • • •

Service Name Short Description Long Description Price (if it applies) Preview Image Image Provider Name Provider Description Provider Address Service Category

In addition to these service templates the service providers can also attach more detailed information by uploading of detailed data sheets or reference projects that used the same services.

Deliverable 4.5 Public

14

Final Version

Apollon – D.4.5 Furthermore the service template does not only fulfil the requirements to bring an existing service into the collaboration platform but can be also used to by service consumers to provide information about potential services that they need for their businesses.

Finally there is the category of Living Labs which is also offering services that are quite different in comparison to the mainly technical services that are offered and/or wanted by the SMEs. Referencing back to chapter 3.1.3 of this deliverable, the LLs and their network offer businessfacilitating services to the other two categories of service providers and consumers. Nonetheless the way how the LLs are bringing their service offerings to the collaboration platform is the same as the others took by also using the service templates.

As we tried to focus on a simplified way to realize the content provisioning to the collaboration platform we would expect a high adoption rate of it.

4. Impact assessment of the manufacturing industry domain specific collaboration platform 4.1 What does that mean for a networked Europe?

In the context of European manufacturing, the possibility to increase the cross-border networking between SMEs and companies has a major role to play in enhancing the efficacy of the productive processes and RDI. With the dawn of more tightly woven networking, supported by ICT tools such as the collaboration platform that has been implemented in APOLLON, the possibility to allow for new partnerships in one hand, and also to speed up the networking process opens new doors to collaboration can have a huge contribution to increase the resilience and competitiveness of the manufacturing sector in Europe.

The existence of collaborative platforms that act as portfolios and matchmakers at local level allow for easier and faster partner research for companies looking for partnerships and new markets, and represents a step further in open data and networking facilitation tools for SMEs.

4.2 SMEs get into new markets For a SME to enter new markets it implies normally a considerable effort in precious resources and a fine tuned strategy that represents a blocking obstacle to many companies. Specifically within Apollon YDreams international commercial effort has pursued a hard and persistent path that led to offices in Portugal, Spain and Brazil but that encountered the natural obstacles that a traditional approach to new geographical markets presents. These obstacles led to a focus on specific markets segments in those countries, replicating the models from Portugal, not leaving much space to attempt different industries and client profiles. This experience can provide an interesting counterpoint and places YDreams in a comfortable position to assert the potential of a marketplace like the one provided by Apollon.

The potential of such a collaboration platform represents an enormous opportunity for any SME to broaden their commercial activities at different levels. Besides its innate cross border potential, it can provide a cost effective opportunity to test different market segments and the receptivity to new services offered. The design in terms of entity profile, service categorization, management tools and matchmaking functionalities creates a nurturing marketplace for any SME The matchmaking between different complementary actors can expand the economic activity by actively providing modular services, by tailoring the service offer to the requests procured or by matching of complementary service offers with other SMEs.

Deliverable 4.5 Public

15

Final Version

Apollon – D.4.5 A stated above (chapter 3.3) we would expect such a domain specific collaboration platform being an attractive tool for any kind of potential business partners due to the "easy to use" approach.

Nonetheless the most relevant category to be reached are the SMEs. The LEs are already underway in international businesses and the LLs are international too because of the network that they are in.

The SMEs - and that includes all sub-categories - from really small enterprises to mid-size enterprises should be enabled to run trans-national businesses not just by getting the chance to trade their services to other countries via the platform but also by getting support from the LL network into the direction of "to be made prepared" for establishing businesses in other countries and regions than their "own".

4.3 Living Lab networks accelerating businesses A Living Lab is a real-life test and experimentation environment where users and producers cocreate innovations. Living Labs have been characterised by the European Commission as PublicPrivate-People Partnerships (PPPP) for user-driven open innovation. A Living Lab employs four main activities: 1. Co-Creation: co-design by users and producers 2. Exploration: discovering emerging usages, behaviours and market opportunities 3. Experimentation: implementing live scenarios within communities of users 4. Evaluation: assessment of concepts, products and services according to socio-ergonomic, socio-cognitive and socio-economic criteria.

In this way, a Living Lab can act as a technical testbed where members of the local ecosystem can develop and test products and services first, or set up user groups for other companies, external to the Living Lab, to co-design, co-create or test their own services or products. This is a very important tool to cover the so called pre-commercial gap and speed up product roll to market.

Deliverable 4.5 Public

16

Final Version

Apollon – D.4.5

Figure 8: Living Labs – bridging the pre-commercial gap and fostering innovation

At both local and cross-border level, the collaboration platforms act as enablers for business matching and joint ventures for new product and service providers.

At the Living Lab level, the clear and open display of company portfolios and services/products provided lead to a more detailed and comprehensive description of the Living Lab ecosystems, Through the domain network of Living Labs, cross-border collaboration is accelerated and facilitated due to more detailed and comprehensive description of local ecosystems, the resources, companies, solutions and products available, as well as the areas of expertise of composing members are more easily accessed and identified by potential clients or partners.

As also previously described in chapter 3.1.3 the LLs in such a domain specific network can and even should be very different in their nature covering a wide spectrum from being a straight technology driven LL to the end of being a more business consultancy LL to support and help the SMEs with any kind of service they might need to get into transnational businesses.

5. Global business factors / exceptional situations 5.1 A challenge report from the Hungarian Vehicle Engineering Cluster project partner Initially the following Hungarian companies were involved in the activities to start with WP4 of Apollon • • •

Financial guarantor Synergon the Living Lab HVEC several supporting partners or potential supporting partners as listed further down in the document

Deliverable 4.5 Public

17

Final Version

Apollon – D.4.5 5.1.1 History and Background The first Hungarian Automotive Cluster, PANAC started an Automotive Living Lab, however PANAC had no support at all by national, regional and local authorities and other companies were not able (or open) to support the founded LL because of the recession that we were heavily hit in the year of 2008. Despite of that the Hungarian Vehicle Engineering Cluster (HVEC) has been established in 2009 to become the successor of the LL role from disappearing PANAC. HVEC has been founded by six Hungarian SMEs, namely ArraboCAD, ENTAL, Meshining, RaabCAD, SIMGRID and Varinex (all engineering and R&D focused companies in different fields) to better support and initiate local R&D and follow up on promising PANAC activities.

However the new founded organization still faced sometimes a lack of resources - monetary wise and therefore also w.r.t. FTE staffing.

5.1.2 Project activities during the Setup phase With regards to the MDI requirements, we planned to involve factories and logistics partners, which are aware of using agents and tools of the kind that were planned to be implemented in the MDI environment. We planned to put the energy efficiency and effectiveness use case into the productive environment of a supporting partner. As described in Deliverable 4.1. and similar to the efforts of our Portuguese project partners to co-create a project concept and structure we tried to implement the use cases vertically and started to run an IT development and the respective project management scope horizontally.

The development scope partner recruitment was quite an unfortunate effort, since the recession has strongly stroked the overall economy but in particular the Hungarian situation was even more worse as Hungary had many automotive industry suppliers mainly being SMEs which got almost lost of their businesses.

We have met KUKA Robotics Kft., the Denso (manufacturer of Toyota's fuel supply system) and Harmann&Becker (manufacturer of electronic adapters used in cars).

To realize the MDI interface / adapter development and IT cooperation, we have chosen, Synergon (beyond its being guarantor), the company DatenKontor, IQSYS, Unicomp Ltd, Szintézis, Dension, Answer, Grana, SMR, Gestamp, Vonalkód Rendszertechnika Kft. All of them are well experienced with IT system development as they've done many projects with large enterprises inside and outside of Hungary and had the capacities and knowledge in Java application development and implementation which was key for the MDI. We have several personal consultations with the managers of the actors to find the appropriate agent, solution and the process through which we justify the applicability of the MDI. The most promising negotiations were lead with KUKA Robotics, and Denso and they have expressed their intention to participate the project.

KUKA has robots for precise metal cutting, on which the biggest issue to change the edge in time, to proceed imprecise cutting and the occurring waste. The edge sharpness is measured eventually by a person assigned to, using physical measuring equipment. The intended project scope we have planned to apply was a laser measurement tool to be made capable for an agent node in the MDI. We wanted to measure and set adjustable values, via an online measuring process extended by an automated reporting solution with alert functions. In theory this use case was following the overall asset viewing use case as generically outlined in previous deliverables of WP4 (D.4.1 & D.4.2) The other potential partners preferred the energy efficiency use case where the recent RFID frame solution should have interfaced with the MDI. The horizontal project process partners were able to manage the middleware development processes as they were in a close relationship with the manufacturing companies.

Deliverable 4.5 Public

18

Final Version

Apollon – D.4.5 Several meetings happened at our Budapest office and at the Factories in Székesfehérvár and Taksony. We have given many presentations to engage with potential partners and introduced the project objective in a very detailed way.

We also strived to find a partner with integrated ERP system capability to manage the whole process as a flow. That day KUKA was actually underway to implement other software solutions from SAP which we thought would be of benefit and others like Denso and Becker had their own ERP systems which then would have been shown the ability of MDI to integrate into non-SAP systems as well.

5.1.3 Challenges and reasons that lead to a failure of the active participation of the Hungarian project partners In order to establish Public Privat Partnerships (PPP) we met also governmental organizations such as the National Innovation Technology Office, International Trade Development Hungary, Ministry of Economy in order to get support for this CIP and/or the European Living Lab activities. After many meetings and discussions we unfortunately did not succeed to get support from there. Nonetheless we tried to stay within Apollon but without governmental support as one of various aspects we were finally not able to continue our engagement.

The most relevant impact on the final decision that the partners faced in general was delay. It was very unfortunate to keep the interest on a longer run without any progress.

Also the recession was a depressive fact and drew the attention away from such a partial importance of our project that has been expressed to them.

In our opinion the most significant impact we had to face with it was the Synergon retreat after a year wait in vain for project launch. Since the letter of Guarantee had financial consequences to Synergon, they decided to withdraw the agreement. No other entity shouldered the participation after such a long period without any decision and as a consequence of that with the Synergon retreat.

In addition we have to admit that the political changes after the governmental election in April 2010 caused a significant impact on all the projects started under the former Hungarian administration.

Given these facts none of project element has been realized although we got indication of interest of three SMEs to apply the MDI agents and in addition five IT cooperation partners for developing and implementing the MDI. Most of them were affiliates and depended on an indirect decision making flow, in which the EU project was introduced to the central decision making body. That was also a time consuming effort.

In general most of the companies have policies for applying for an EU publicly funded project. For example there are restrictions in participating of any, because of the length of a project implementation and the forthcoming evaluation and assessment period. In addition the SMEs in Hungary must calculate with central administrative risks, assessments beyond the normal and formal audits, they would better ignore.

5.1.4 Conclusions and Recommendations Even the very ambitious and persistent partners lost their faith in the project and LL approach after a long waiting period for a guarantor. Especially when it comes to the matchmaking between European / transnational co-innovation projects and the national and regional innovations of our Hungarian SMEs and other supporting offices which are profoundly interested to contribute to the co-innovations they got stuck because of impotence and disinterest of the public authorities that are in charge to comply with all formalities.

Deliverable 4.5 Public

19

Final Version

Apollon – D.4.5 Recommendations The CIP program in Hungary seems to be out of the governmental scope. Neither support nor submission was delegated to any of the CIP projects gained and executed. Only for the FP7 were contact points setup and budget allocated for local submission. The Living Lab program should have more importance and PR on the national level, and the cluster partners shall play a more important role to represent the projects and the participating SMEs. Clusters are often not corporate identities, which don’t let them participate under any supporting program or if they create an identity suffering of history and resources. However to our opinion the most promising network / platform to bring companies, R&D institutions, individual inventors and end users together is Living Lab setup as we've seen it working in so many other countries.

So we think, that different rules and supporting mechanism has to be created to reach higher innovation potential in East-European countries, to help spread out expected results, and forcing the national and regional level to pay higher attention (support, but not only monetary) on that very important European projects.

6. Summary Living Labs methodologies are a notable open innovation environment that thrives with ICTintensive tools. The collaboration platform is one of such tools, which due to its business-oriented nature, facilitates and allows for easier and faster identification of partners, products or services, enables the establishment of Business-to-Business relationships and partnerships and proves the validity of the open-access “market platform” used in a way to improve local and cross-border networking.

This case was validated through the APOLLON WP4 eManufacturing experiment that took a deep dive into the complete lifecycle of cross border activities we did based on defined use cases.

Starting with the technical evaluation of the use cases as such and the identification of required services and technologies that are needed to operationally execute a certain project we came to the business related requirements to enable players from different countries running trans-national projects.

In other words - if you know what's needed to run a projects in general but also specifically aspects like technology transfer, logistics, consultancy, legal aspects, etc. you become most likely automatically an expert in knowing of what's needed to setup a collaboration platform as we did for the domain specific network of eManufacturing in WP4.

Of course we knew from the beginning on that such a collaboration platform is key in order lower barriers especially for the SMEs we explicitly decided not to start with the build and development of it right at the beginning of Apollon as that would have been led to a "trial and error" mode of the project w.r.t the key requirements to be implemented.

So the MDI - also introduced as a platform, but with a totally different meaning as it is a straight technical platform integrating machines and devices - was "just" a means to an end (an instrument) to gain knowledge, experiences and insights about the core purpose of Apollon. That means that the first 60% of the Apollon time was used for the observation and information retrieval of how we run our use cases and then in a first wave theoretically investigated into the setup of a potential collaboration platform.

Based on these experiences we started a design thinking process how the collaboration platform should look like and finally implemented it based on the identified requirements for the different user categories.

Looking back how we setup the overall project in WP4 in comparison to what we achieved we can say that it was absolutely right to start with practical work by executing the use cases and then taking the results from them and finally turning it into a collaboration platform that is well accepted.

Deliverable 4.5 Public

20

Final Version

Apollon – D.4.5 The feedback we got so far is really amazing and we believe that this type of a collaboration platform in combination with the existing Living Lab network can trigger and support transnational businesses opportunities for SMEs in Europe.

Nonetheless our recommendation is to really stay focused w.r.t. a domain specific setup and may setup different entities for different industry segments.

With the possibility to implement the open collaboration platform by a Living Lab at local level, in order to map its own ecosystem, ENoLL eManufacturing Network will provide support to member Living Labs in implementing such platform.

Regarding the cross-border aspect of the eManufacturing Network, the implementation of a European wide platform, populated by the members of ENoLL will allow for an easier and speedier identification of technical, human and knowledge resources and the facilitation of business and RDI partnerships between Living Labs (and/or local ecosystem stakeholders, such as SMEs, Research Institutes, Universities, etc., accessing the platform through their local Living Lab).

The implementation of the platform in the context of WP4 experiment has demonstrated the B2B capabilities of the system and proven the case for the advantages of such tool in the Living Lab environment.

The collaborative platform developed under APOLLON WP4 also demonstrates the advantages of an online repository of stakeholders, following the open-data paradigm both by being an opensource platform and for providing information on Living Lab ecosystems.

The possibility of a future large scale project, where the management at European and local level is provided by a consortium, and where Living Labs take part in implementing local platforms and populate a European-wide platform and assume the role of faciliators, leaving to their ecosystems stakeholders the role of autonomously and in true market conditions, interact and strive for local and cross-border B2B opportunities would serve as a real-life environment for eManufacturing, where the successful best practices from APOLLON WP4 can be implemented, with the objective of constructing a more cohesive and networked Europe.

Deliverable 4.5 Public

21

Final Version