Final Report Summary - EBEST (Empowering Business Ecosystems of Small Service Enterprises to Face the Economic Crisis)
Executive summary:
This publishable summary recalls the EBEST project context and objectives, presents the work performed up to the project conclusion, shows the main Science and Technology (S&T) results achieved, describes their potential impact and use plans, and provides a schematic presentation of the EBEST consortium composition along with relevant contacts.
The EBEST project started on January 1st, 2010, with a work plan of 24 months, a budget of 2.701.347,40 Euros and a requested EC contribution of 1.650.000,00 Euros. The project was formally suspended for five months, May to September 2011, to overcome a bureaucratic question emerged at run-time, and its duration was extended accordingly. Then it ended regularly on May 30th, 2012.
The ultimate objective of the SME-AGs and the other partners promoting the EBEST project was the introduction of new collaboration practices in ecosystems of SMEs belonging to different industrial sectors, through the provision of easily accessible ICT services to enable community building, SME network constitution, and SME network operation for the network lead and its members.
This publishable summary is organised into the following main chapters:
-Chapter 2 recalls the context with respect to which the project was conceived as well as the strategic and operational objectives pursued during project execution.
-Chapter 3 presents the work performed and its organisation into work packages and tasks, as well as the S&T results (foreground knowledge and software) generated.
-Chapter 4 describes the pilot experiments that have been performed to validate the EBEST model and software platform versus real-life cases.
-Chapter 5 estimates the impact expected from the adoption of the EBEST solution and the procedure for SME-AGs to deploy it towards the associated SMEs.
-Chapters 6, 7 and 8 finally provide a schematic description of the EBEST consortium composition with the address of the project public web site and relevant contacts.
This document is addressed to a composite audience:
-In the first place, SME-AGs willing to promote the constitution of SME networks out of their members and support their efficient operation.
-Also, enterprises leading already constituted supply chains that are interested to increase their efficiency in communication and collaboration.
-Then, research institutions and third parties of the ICT and business sectors for the possibility they have to add functions and services.
-Finally, political institutions, especially those acting at the regional level, which can use the EBEST solution to promote SME networking.
Project Context and Objectives:
1.2 Project context and objectives
At the EBEST proposal presentation time the economic crisis was showing its first dramatic effects in terms of recession and unemployment. SME-AGs were in the forefront trying to understand how to help the associated SMEs in slowing down or even reversing the negative trend. The identified perspective was taking the crisis as an opportunity to push small and medium-sized entreprises (SME) towards organisational and ICT innovation to reach higher efficiency.
1.2.1 Vision
Observatories of European SME-AGs are expecting a dramatic future for their smaller associates acting in different industrial sector. The negative trend of the last years is continuing and possibly worsening, and could determine the closure of up to 40% of present SMEs in the EU or decrease substantially their activities, personnel and turnover. What can an association do to prevent or mitigate this risk?
1.2.2 Context
At the EBEST project start time the participant SME-AGs were very concerned about the future of their associated SMEs because of the worrying market situation generated by the global economic crisis. The project was in fact intended to promote the adoption of efficient collaboration practices within and between business ecosystems by taking advantage of a specifically conceived suite of ICT tools to support them.
To this purpose the EBEST project addressed small and micro companies (less than 50 employees) providing services to other businesses, typically by subcontracting, in a number of industrial sectors. These target companies are used to perform added-value activities (jobbing, working, etc.) in the intermediate phases of the value chain and/or in the repair and maintenance phases.
Examples of SMEs relevant to the project are:
-Textile sector: prototyping (of textile or knitted goods), weaving, finishing, ironing.
-Construction sector: heating, hydraulic and electrical plants, painting, maintenance.
-Mechanical sector: surface treatment, machining, assembling, repair, maintenance.
-ICT and media sector: setting-up and maintenance of voice and data networks.
The target companies typically operate by offering to the market their qualified resources, especially skilled personnel and specialised equipment. Their main strength points are high quality of service and intrinsic flexibility and adaptation to market conditions. Their main weakness points are limited investment capability and low efficiency due to their poor ICT adoption especially in communication and coordination.
The economic crisis is still there and its effects are involving an increasing number of SMEs in different countries. The context remains worrying and the objectives of EBEST are even more valid. Its outcomes help the target SMEs to survive by:
(i) meeting customer requests at best,
(ii) joining efforts in well-configured networks,
(iii) coordinating optimally the network members, and
(iv) optimising the use of individual member resources.
1.2.3 Objectives
The EBEST strategic objective is setting-up, experimenting and promoting the adoption of new collaboration practices within SME networks supported by innovative ICT tools making the network behave as an efficient single organisation. The EBEST tools are conceived to define and improve the network configuration, and to support its daily operation in executing customer requests and orders.
The EBEST strategic objective is split into a number of operational objectives:
-Enabling SME-AGs to support the associated SMEs in shaping potential networks out of the existing business ecosystems.
-Enabling SME-AGs and autonomous SME networks to constitute operational networks for grasping business opportunities.
-Enabling the network lead to efficiently coordinate the network by optimising task assignment to the network members.
-Enabling each network members to optimally allocate the internal resources to perform at best the assigned tasks.
-Enabling the network partners to collaborate in damping down perturbations caused by exceptions occurred during order execution.
-Facilitating the network partners in exchanging business documents and moving them from/to their legacy systems (if any).
Further general yet fundamental objectives are:
-Promoting codes of practice and trust-building mechanisms, including performance evaluation criteria, to guide the fair competition of the target companies.
-Using successful cases taken from real-life experiences as living examples of the benefits that the EBEST solution can bring to companies.
-Adopting a pay-per-use model for minimising the cost and effort required by the single SME to start using the EBEST solution and, in case, to leave it.
-Deploying the project results to the largest audience so as to reach a critical mass of user companies in the shortest possible time after project completion.
Because of the economic situation it was established that the above challenging objectives had to be met in no more than two years. This was considered feasible by involving RTD performers that could bring to the EBEST project a rich amount of background knowledge, in both organisational and technological terms, acquired by their participation in a number of successful European RTD projects.
Project Results:
1.3 Main Science and Technology (S&T) results / foregrounds
In order to pursue the above-recalled objectives the EBEST project had to innovate in two main fields, namely collaboration models and collaboration tools:
-Concerning collaboration models there were three the main aspects to consider: analysis of collaboration habits and needs, definition of trusted operational scenarios, and introduction of new organisation and business models.
-In turn, concerning the collaboration tools there were three suites of functions to develop and test through pilot experiments, respectively supporting the community building, network constitution and network operation phases.
1.3.1 Innovation in models
Collaboration habits and needs
Although generically perceived, the collaboration potential of small companies belonging to a business ecosystem is not known in the required detail. It certainly depends on variable factors such as industrial sector, company nature and size, local economic fabric, norms and regulations. Of course, the reference SME-AGs are in the best position to understand habits and needs of the associated companies.
However, further investigations are required to assess in depth specific situations. This knowledge, a first measurable result of the EBEST project, consists of business and technical specifications to be taken as basis, on the one side, for the definition of the devised collaboration models and, on the other side, for the expression of requirements on the ICT applications and functions to develop.
Trusted operational scenarios
The ways for the intended companies to interact and collaborate within and across the boundaries of their business ecosystems - on a full trust and confidence basis, including regulatory and contractual issues - are formalised and represented as main operational scenarios. These scenarios constitute the EBEST project detailed vision and perspective, and represent another of its measurable results.
The scenarios are defined starting from habits and needs and taking into account the documents the companies are used to exchange. They are not limited to express what presently happens (or is considered a possible improvement), but are intended to imagine the EBEST environment where the new practices are finally adopted to provide the target companies with other business opportunities.
New organisation and business models
The third component of the EBEST collaboration framework deals with understanding which medium-term changes could (should) be introduced by a full deployment and use of the EBEST solution. This means, in the first place, studying the impact of the collaboration practices and ICT support tools on the work organisation of the target companies, and on the associations themselves.
This leads to define business models suited to benefit from the dynamic collaboration opportunities offered by the innovative environment, representing another measurable result of the EBEST project. They provide the basis for a wide deployment of the proposed methodology and ICT support tools at each of the involved business ecosystems and towards other candidate ecosystems.
1.3.2 Innovation in technology
Community building
This technological component is intended to support the initial phase of collaboration, that is, the discovery, analysis and conception of business ecosystems. This implies investigating the role of the 'ecosystem architect' as specific actor in the ecosystem guiding processes, acting in particular at SME-AGs and offering strategic innovation support to clusters of small and medium companies.
Business ecosystem modelling is not a new concept. The term itself, borrowed from biology, represents the action of capturing and describing the interactions of economic entities such as companies. Tools and techniques exist to support the modelling of these interchanges, from supply chain modelling to the recently popular business model canvas, but most of them focus on the point of view from a single actor in the value network.
The community building tool behaves as a workbench. It must provide a combination of three basic elements: knowledge representation about candidate SMEs and their features, exploration mechanisms for querying and browsing the knowledge graph including implicit (and imperfect) enrichment of interconnections, and social networking to assist in the discovery of collaborations around potential new SME ecosystems.
Network constitution
This technological component is intended to facilitate the identification of new business opportunities and involve ecosystem actors. SME-AGs can promote business opportunities at selected companies and discuss with them their implications, while the involved companies are put in the condition to evaluate those opportunities, define the relative processes and, if possible, establish relations and constitute new networks.
The network constitution tool must provide a process workflow interface for managing regular processes of the ecosystem. There is a set of predefined processes but it provides the opportunity to add specific workflow processes tailored to new needs. The predefined processes include tender management, marketing campaign management, business or innovation award workflow, and joint event organization.
The network constitution tool should interpret the prepared workflow model and automatically generate the working software instance for workflow support. Its basic functions are: company representation, search for collaborative partners, collaborative contents and document management, task and ToDo management, workflow process management, and communication services, news, notifications, and so on.
Network operation
This technological component is intended to support and facilitate the daily activities carried out within an SME network. While community building and network constitution occur at design-time to configure the network and organise its processes, the network operation tool provides the suite of necessary functions to be used at run-time for network coordination, node optimisation and document exchange.
Network coordination is in charge to the lead company that transforms incoming requests for quotation or orders into plans involving selected network members. It relies on a distributed planning function that assigns tasks according to agreed parameters and criteria. Very important, the same planning function is used to revise the distributed plan whenever exceptions occur that need to be damped down.
Node optimisation is in charge of every network member receiving an assigned task from the lead company, and implies scheduling at best the use of its resources (manpower, equipment) for task accomplishment according to their actual state and a number of customised conditions and criteria. Even the scheduling function is reused to reduce possible perturbations affecting the network and the involved nodes.
Document exchange is the third important service to provide to lead company and network members for increasing the overall network efficiency. It includes business document import/export from/to the legacy systems (if any) of the partners, automatic document structure conversion to adapt to imposed formats, and automatic document contents translation in multi-lingual cases.
Note that in many cases an SME is at the same time member of one or more networks and lead of its own supply chain. With the network operation tool it is put in the condition to carry out both roles seamlessly having allocated the relative workspaces and assured the links between data and business documents exchanged with customers and those exchanged with suppliers.
Finally, in order to facilitate SMEs in entering the EBEST solution and possibly leaving it if not satisfied, the network operation tool should be published by every SME-AG and made accessible to its user companies in SaaS (Software-as-a-Service) mode. Hence the cost of its functions can be customised on regional/sectoral basis and this should accelerate the achievement of a critical mass of user companies.
1.3.3 Work performed
The general strategy of the EBEST project for achieving the defined objectives, and the consequent implementation methodology and work plan, were intended to maximise the probability of its full success. In fact it was decided to move along four main stages each corresponding to a measurable progress and assuring the condition for possible corrections of the work in progress.
The four project development stages are here briefly recalled:
-The initial idea of the EBEST promoters, as reported in the proposal, underwent a sound validation work by studying and discussing in the mentioned innovation fields with the ultimate aim of reaching in the shortest possible time a real common understanding of problems and solutions within the consortium.
-On the basis of the knowledge, requirements and specifications resulting from the previous stage the organisational and technological components of the EBEST solution were designed and developed in parallel tasks so as to minimise the time needed for the construction of the whole system.
-The third stage was devoted to integrate the developed components into the foreseen organisational model and EBEST software platform, and to further adapt them to a variety of operational conditions so as to meet at best the requirements of the participating associations and the identified test cases.
-Finally, the EBEST solution was submitted to a comprehensive real-life validation activity for its final improvement and tuning, and to an intense demonstration phase as the best way identified to facilitate its adoption by the associated companies and deployment to other business ecosystems.
This stepwise strategy was applied to the numerous themes representing the challenges of the EBEST project. The work plan was organised into thematic work packages since this is the most efficient structure for the constitution of qualified work teams, the full coverage of all the aspects that must be faced and resolved, and the attribution of the responsibility to obtain the devised results with the available resources and time.
Work packages
Taking into account the project objectives, methodology and implementation strategy, the adopted work plan was split into three RTD work packages (namely WP1 to WP3), one demonstration work package (WP4), one work package (WP5) devoted to training, dissemination and deployment of the EBEST solution, and one work package for project management and coordination (WP6).
The picture the work plan structure and the main dependences between work packages. In detail:
-WP1 - Collaboration Framework. This WP analysed the collaboration habits and needs in the business ecosystems represented by the SME-AGs of the EBEST consortium, proposed a set of trusted operational scenarios according to the EBEST perspective, and defined new organisation and business models suited for companies and associations to exploit the EBEST project achievements. The early results from this WP were fundamental to orient the RTD work in WP2 and WP3 and the demonstration work in WP4, while its final contribution favoured the deployment of the EBEST solution.
-WP2 - Knowledge and Languages. This WP worked simultaneously on standard taxonomies and the business documents exchanged within the ecosystems and with the external world. The aim was constituting the knowledge base of concepts and the multilingual terms needed to support the communication of the network members with the other actors. Then, the WP produced, by adaptation of the SEAMLESS prototype, the ICT tools mapping proprietary data models and the ICT services for the automatic transformation of the exchanged documents.
-WP3 -Collaboration ICT Platform. This WP designed and developed the EBEST ICT platform to support the proposed organisational model. The platform offers the devised design-time and run-time services and applications discussed above, providing community building, network composition, planning, scheduling and translation services (hence including the ICT functions coming from WP2). The platform was developed in open-source technology and was interfaced with the legacy systems of user companies to realise the required level of interoperability with existing software applications.
-WP4 -On-field Demonstrations. This WP performed pilot experiments and public demonstrations in order to validate and tune the EBEST outcomes. In particular this WP was fed by the results coming from WP1 (collaboration model) and WP3 (supporting ICT platform) and produced important indications for EBEST solution take up. The demonstrations were carried out by regional pilots involving different industrial sectors: fashion, global service and telecom in Italy, ICT in Spain, manufacturing in Greece, construction in Hungary, logistics in Slovakia, mechanics in Belgium.
-WP5 - Training, Dissemination and Deployment. The ultimate aim of this WP was deploying the EBEST solution to the largest communities of user companies and to further business ecosystems. Training actions were performed on SME-AGs (trainers) and then on companies, dissemination initiatives were undertaken with the objective to spread the EBEST concept and results, and an effective deployment model was defined for EBEST adoption after project completion. According to the above picture, this WP used results from the other WPs and specifically the ICT platform from WP3.
-WP6 - Project Management. This WP included the activities assuring full and timely achievement of the foreseen project results, effective collaboration of partners, identification and correction of possible deviations from plans, adaptation to emerging needs, relations with the European Commission. It also performed specific actions to assess the quality of project results and their correspondence to the expectations by SMEs and SME-AGs.
The EBEST consortium confirms that the adopted work plan structure was particularly effective in pursuing and reaching the project objectives in the given time, and every partner was committed to allocate the needed resource to this purpose. As a matter of fact, neither deviations nor delays with respect to the work plan were detected in spite of the five-months suspension due to mere bureaucratic reasons.
1.3.4 EBEST platform architecture
The outcomes resulting from the EBEST project are a software platform and the knowledge to use it at best in different operational conditions. The platform is published by each SME-AG (or its reference ICT provider) and its functions are made available to the associated SMEs in SaaS (Software-as-a-Service) mode. The following figure sketches the EBEST platform architecture with its main components and relations between them.
The design-time components are called Ecosystem Shaping and Collaboration Portal and are intended to support the community building and the network constitution phases, respectively. In turn, the run-time component is called Operational Platform and is intended to support the daily communication, distributed planning and resource scheduling work carried out by the network lead and the other networks members.
Before examining in more detail the three software components it is useful to recall the types of involved actors:
-SME-AG. Public or private institution whose ultimate goal is improving the competitiveness of the associated companies by providing them with advice and services aimed at augmenting their efficiency in satisfying the customer needs. The association is the only that can promote new networks, stimulate their members, push to the adoption of innovative methods and tools.
-Lead company. Companies populate the ecosystem, establish relations by constituting networks, constantly look for new customers, and are interested to increase efficiency and competitiveness. Lead company is the company assuming, steadily or dynamically, the role of network coordination, that is, the operational interface between customers and the other network members.
-Supplier companies. These are the network companies performing coordinated tasks to execute customer requests for quotation and orders. They share the collaboration model although differing by nature, size and offered services. A company can behave at the same time as lead and supplier in the network. Moreover, a supplier can be in turn the lead of its own supply chain.
Of course, customers are the engine of the entire system. They spend money for receiving back products and services, and their satisfaction is the basic condition for the network to survive. In terms of information exchange, they communicate requests for quotation, orders and possible exceptions, and the network answers with quotations, order confirmations, order progresses and new deadlines.
1.3.5 The Ecosystem Shaping component
The Ecosystem Shaping component groups the functionalities that are needed to promote and characterise the ecosystem and to improve it time by time. SME-AGs can use it for exploring the potentials if the associated companies with the purpose to promote the organisation of new networks and to characterise them in terms of sectoral or regional orientation, sharing of methods and models, and the like.
Overview
While some networks are created with no external intervention, it is assumed that in most cases an active role shall be played by a key profile, an Ecosystem Architect (EA), in discovering, exploring and shaping interesting potential ecosystems. During the early shaping phase, the involved companies could be not aware that they have been introduced into the system and that a potential role in a future collaboration is being considered.
The Ecosystem Shaping knowledge base contains non-public information that is shared bilaterally between a company and the SME-AG. The Ecosystem Architect has a privileged, cross company view on the totality of this information space. Since the information may contain competitive data on the different actors, any interactions a company can have with the knowledge store are limited and protected.
We will refer to the model whereby companies directly engage the EBEST platform out of their own initiative as the pull model, as it describes existing company collaborations being pulled directly onto the platform. The Shaping module further extends this with a push model where the SME-AG, after extensive exploration, initiates and proposes new collaboration engagements between companies.
The focus in this part of the system is not primarily on supporting the SME actors themselves, but rather on supporting the work of a group of Ecosystem Architects, experts typically operating within the SME-AG, working together on creating potential networks. The system can support early, pre-operational, incubation of networks, while networks ready to start an operational collaboration can be incepted onto the full EBEST support infrastructure.
Functional support to the Ecosystem Architect
An Ecosystem Architect actively explores, discovers, shapes, launches, observes and evaluates potential business ecosystems out of companies in diverse contexts. In theory the EA continuously synthesises a rich information into a knowledge model, uses this model to explore potential win/win scenarios for multi-company collaborations, and facilitates further exploration by the target partners in the perspective on network constitution.
While many tools such as CRM systems support efficient uniform data collection, an exploration and discovery component targeted directly at the specific EA needs has to include knowledge representation and knowledge exploration. The representation function is flexible enough to support design and change of the modelled entities such as companies, technologies, people, business contexts, and the relative relations.
In turn, the exploration component is able to support multiple forms of discovery, amongst which:
-Discovery through search/query: The Ecosystem Architect can express partially some required attributes needed and gets back the resulting set of entities that correspond to those attributes.
-Latent discovery: Searches can be immediate and single use, but it should also be possible to submit a search request and be notified whenever additions to the knowledge base produce new results in this context.
-Discovery through browsing: The EA can select a potentially interesting starting position in the knowledge model (possibly seeded through search), and explore further across the relationships present in the model.
-Discovery through serendipity, aka accidental discovery. While this can be implicitly present in both discovery though search and discovery through browsing, it can be further enhanced though active support and user interaction choices.
Apart from the technical implementation, there are strict features on the representation of the knowledge model:
-The knowledge representation is light-weight, flexible, extendible and supportive.
-The system allows for input and maintenance relevant types of local data.
-Imports and alignments with data residing and being maintained in external systems, both from EBEST as well as other sources, are possible.
-All the discovery modes (search / latent / browse / serendipity) are supported.
To this end the Ecosystem Shaping knowledge solution functionally resembles the discovery over an associative graph structure. Underlying technological alternatives have been explored during the implementation phase. Where possible they have been aligned with evolving toolsets and conventions in the semantic web domain, keeping into account the need for maintainability and simplicity.
1.3.6 The Collaboration Portal component
The Collaboration Portal offers the functionalities that are needed to work on business opportunities, possibly identified by the SME-AGs, and build new networks and distributed processes around them. By means of collaboration tools like discussion board, wiki, content management and project management one or more companies negotiate the conditions of their future collaboration.
Overview
As it can be seen in figure, the intended EBEST Collaboration Portal (also called Collaborative Ecosystem Platform) consists of three different parts:
-The back-end, which is responsible for the communication between the core eWork functions and the main collaborative services.
-The middleware, which supports the collaboration business logic. This layer is responsible for handling requests from the user domain on the upstream, and then processing the data that are fetched from the backend, compose them to objects that correspond to steps in user-configured workflow and send them as events to the various GUIs on the downstream
-The GUI, which is responsible for sending and receiving events. Such GUIs can be built in principle for desktop and mobile interfaces.
eWork functions
The modular design allows for the eWork functions to be either internal to the ecosystem platform or external to it, i.e. part of the existing infrastructure at the corporate or ecosystem level. It also allows for different ecosystem participants to work on different eWork environments although the formulation of cross-enterprise teams should be based on some commonality in particular when common/shared eWork functions are concerned.
Below we list some of the most common eWork functions:
-Content Management. Content management is a set of processes and technologies that support the evolutionary life cycle of digital information. This digital information is often referred to as content or, to be precise, digital content. Digital content may take the form of text, such as documents, multimedia files, such as audio or video files, or any other file type which follows a content lifecycle which requires management. In EBEST we are mostly concerned with simple documents and contents in wiki-like format, which is easy to edit and share. The eWork environment at the back-end is able to provide pubic APIs that expose the above functionality.
-Discussion boards. In our days, much of the digital communication is being done with email. In fact, people tend to have more than one email addresses that correspond to different types of expected messages: work emails, personal emails, and so on. It can also be used as a good notification system, which notifies the user in case of an event of a different modality. Rather than being an email provider, the EBEST Collaboration Portal provides functionalities for filtering and scheduling user accessibility by email. It also offers structured and organised messaging support in the form of threaded discussions, where the back-end eWork environment supports it.
-Task list / calendar. One of the essential things that a flexi-worker must do is to manage its time on a day-to-day basis. The eWork environment provides tools for creating and maintaining the user task lists for everyday activities, like: appointments, everyday tasks (shopping etc), payments (when they are due).
-Project management (workflow, scheduling). Project management is the discipline of planning, organising and managing resources to bring about the successful completion of specific project goals and objectives. Usually a flexi-worker has more than one project to manage, and the eWork environment provides the following functions:
--Defining workflow actions and transitions in project tasks (scheduling).
--Triggering events when specific workflow actions occur (i.e. e-mail team, when a new release of a document is online).
--Team management, to help the worker monitor the actions and logs of colleagues and provide default actions, such as reply, add to calendar, etc.
User functionality
The user functionality constitutes the scope of tools and services which are made available to the end user through the EBEST Collaboration Portal interface:
-GUI configuration and customisation. The user is enabled to configure what the EBEST collaborative workplace should be retrieved on demand (notifications), what should be automatically pushed (alerts) from a list of available options and entities and create filters for different profiles, for a certain day and so on. To this purpose a workflow constructor is made available in order to define and bind work functions and steps together in workflow processes that combine events and actions. Pre-defined and automatic user-specific and system-level workflows might include, for example, to send an email when a certain kind of event occurs (e.g. a new document in the content management system is received).
-Events. Through the collaborative GUI the user is enabled to create events and then bind them with alerts and notifications. An event may be a combination of eWork functions with certain criteria. For example an event "new task" could be defined that checks when a new task is added to the task list from a certain user or is connected with specific content like a new document. Likewise the user will be receiving events from the eWork functions and may handle them as required by defining workflows, as described above.
-Notifications / alerts. The collaboration framework provides notifications of selected events, like the one above. The users are enabled to filter the notifications and alerts in their profiles through the GUI customisation. For example notifications about new tasks should not be showed in weekends or when driving. Notifications and alerts may be bound with messages, for example an e-mail notification can be bound with the email message body. If there is an alert, message retrieval should be automatic (push), otherwise it should be on-demand.
Business logic
The logical design of the middleware in the Collaboration Portal includes the following main functions:
-Entity dispatcher. The entity dispatcher is the main component of the collaboration framework middleware. It is responsible for handling all the communications between the GUI and the eWork environment. The entity dispatcher contains the following modules:
--Request handler. The request handler is the external interface of the middleware. The UI clients connect to the middleware through the request handler. It is responsible for keeping a mapping between user authenticated sessions and access GUIs and for keeping the transfers secure. The request handler then passes the validated requests to the event controller. When the event controller has new events that need to be passed to the correct user, it sends the request handler the event with the session id, and it then validates the session id and through the mapping it knows where to send the event.
--Event controller. The event controller is the main component of the event dispatcher. It is responsible of satisfying the requests from the UI clients by taking objects from the downstream object pool and transforms them into workflow entities that the user has defined in the workflow configurator. These entities are then dispatched back to the UI component though the request handler. The event controller polls frequently the downstream object pool for new objects and if there is a workflow defined for them, it then creates it with the new objects and sends it to the correct UI client through the request handler.
--Object pools. There are two object pools available in the entity dispatcher, namely the upstream object pool and the downstream object pool. The downstream object pool is responsible for objects that come from the eWork functions through the back-end connectors. The upstream object pool is responsible for objects that come from the UI clients and contains data that either needs to be merged to the eWork environment or commands that concern the backend connectors (i.e. when a client demands a full and not an incremental synchronization because some of the data at the client side are corrupted or missing).
--Filter. The filter is a programmable component that is created from the UI components according to the user preferences. It filters all events that the user does not want to get in certain UI components at certain times. For example when the user is reachable at a mobile device he may not want to receive any events that are not critical. The filtered (i.e. not communicated) objects are stored in the cache and are fetched again on a subsequent update request from a UI component.
-Workflow engine. This is the middleware component that creates the workflow objects, and consists of two components: the configurator and the constructor:
--Workflow configurator. The configurator role is to provide the user with the tools he needs to create, modify and delete workflows and store them for use with workflow constructor. The configurator has an easy and intuitive user interface for comfortable and productive usage.
--Workflow constructor. The constructor creates workflow objects on request by the event controller. The controller requests workflows for a specific user from the constructor with specific criteria that the newly fetched objects provide. The constructor returns a workflow object, if one exists, and the controller fills it with the received data.
-Back-end. The back-end layer is responsible for the two-way communication between the middleware and the eWork functions environment. It consists of several backend connectors. Each connector connects to a single eWork service, i.e. there is one connector for the email service, one connector for the project management, etc. This approach enables different eWork providers to be used by different enterprises and be connected to the Collaboration Portal as either internal or external entities.
-Workplace ontology. When there is an agreement on a semantic-level representation of collaborative work-related tasks, actions and information exchanges among the main actors, then an ontological framework is adopted by the ecosystem. This ontology is used as a reference for modelling workflow items and constructing workflow processes. The ontology is referenced from the workflow engine of the collaboration framework, that is, the workflow configurator module presents options that are compliant with the common ontology, thus the workflow process flows are compliant with the ontological framework adopted.
1.3.7 The Operational Platform component
The EBEST operational model applies to every small and medium-sized entreprises (SME) network whose members are aggregated by business opportunities. Within the network companies establish steady collaborations involving complementary, and sometimes even competing, nodes while maintaining their full individual autonomy. Their ultimate aim is showing a unique, efficient image to potential customers to safeguard and possibly increase their position in the market.
Overview
The Operational Platform component provides SME networks and their lead and member companies with a suite of operational functions enabling them to easily and efficiently communicate, plan distributed processes (if network leads), and schedule the internal resources (if supplier). A company that is at the same time lead and supplier can take benefit of the entire EBEST Operational Platform functionality.
The main Operational Platform functions that have been identified as strictly necessary to the relevant network profiles:
-Lead company viewpoint. Its role includes interaction with customers, network coordination and supervision, task assignment to network members, business document exchange, exception handling at the network level.
-Member company (supplier) viewpoint. Its role includes interaction with the lead, optimal management of internal (own) resources, business document exchange, exception handling at the shop-floor level.
Distributed planning
The functionality of a company node depends on the role of that company in the collaborative network. In case it behaves as a lead it has access to the functions that are needed to interact with customers, plan the execution process, assign tasks to selected suppliers and keep the execution progress monitored. To this purpose the EBEST project has developed a distributed planning function which is particularly reactive and suited to handle the frequent exceptions occurring in the network.
At design time the lead company defines the distributed processes it is asked to coordinate. As usual every process is split into activities, precedences are established between activities, and every activity is properly modelled and associated to the supplier(s) in the cluster that can execute it. Core activities are normally interleaved by auxiliary activities such as on-site requirement collection or final installation and, notably, transports of materials mirroring the condition of a geographically distributed virtual enterprise.
At run time the lead company activates the distributed planning function whenever it receives a request for quotation or an order coming from a customer. The lead company must in fact activate its network and therefore it performs a distributed planning session to decide which tasks should be conveniently carried out by itself, if also supplier, which tasks should be better assigned to the other suppliers in the network, and which are the preferred partners to whom those tasks should be assigned.
Then, the lead company submits to each selected supplier the proposed tasks and the supplier replies with its estimation of execution time and cost. Those suppliers leading in turn a supply chain will carry out a similar planning activity with the involvement of further companies to fulfil the proposed tasks.
According to the received answers and applying its own planning policy rules the lead company selects the best configuration of the working supply chain for that customer order, and confirms the assigned task to each of the involved partners. The configuration is static if partners are predefined for the tasks to assign, it is dynamic if partners are selected from constellations of competing companies. The distributed planning session is concluded with the final response (e.g. quotation, order confirmation) to the customer.
This distributed planning process and its propagation across the ecosystem mirrors the present time-wasting human interactions but replaces them with a much more efficient way of finding out the desired solution. Moreover it can take into account unusual variables, such as transport times between manufacturing steps, and compare alternative solutions to measure their actual profitability. Of course its best performances come from networks where all the members are provided with the same, or equivalent, technology.
Later, during order execution, the distributed plan is put into action and the tasks are progressively carried out by the selected companies. Should a task be affected by problems (e.g. on delivery date) it will be re-planned to damp down the exception: the assignee company will be asked to revise its involvement (e.g. by choosing alternative routings) and if this will not be enough the lead company will transfer the residual perturbation on the next supplier until the problem will be (possibly) completely overcome.
Resource scheduling
On the other hand, in case the cluster member plays the mere role of supplier it has access to the functions that are needed to receive task proposals from the lead, simulate their execution to estimate times and costs, book the involved resources after the task has been formally assigned, revise the resource allocation for exception handling. This calls for an easy and efficient scheduler of internal resource that, normally, are just skilled persons and few machines or technologies.
Communication
The network behaviour is accompanied by an intense exchange of data and documents between the involved actors and with the customers. Then its efficiency can increase in relation to how communication becomes easy, seldom manual, and overcoming practical barriers such as those due to different formats and languages when a company belongs simultaneously to two or more networks.
The communication channels made available by the EBEST Operational Platform are basically two:
-Communication with partners. Whenever a lead and a member company must exchange a business document, e.g. a task assignment, the document is composed at the sender doc manager and transferred to the receiver doc manager.
-Import/export from/to the legacy system. If the document must be saved onto or, vice versa, shall be extracted from the legacy system (if any) of that company, the import/export service is activated.
Autonomic behaviour
Companies constituting SME networks are provided with limited resources that they cannot divert from the core business, then it is fundamental for them to adopt strongly automated planning, scheduling and exception handling solutions under the condition to maintain wide margins for policy customization. This can effectively be done with the adoption and adaptation of the autonomic model to the management of most network activities.
In an autonomic system every company renounces to control the system directly and assigns this role to a self-management process to which it imposes its own policies and decision rules. Under this condition the system presents the following four qualities:
-Self-configuration. This means automatic configuration of a subset of nodes in a certain zone of the network, and includes the addition of nodes and the creation and cancellation of relations between nodes in order to meet the defined requirements.
-Self-optimisation. This means automatic best allocation of resources in the single node to ensure its optimal behaviour. The algorithm is driven by performance objectives set during the self-configuration phase and by policies set by the node responsible.
-Self-healing. This means automatic discovery and correction of faults, triggered by events occurring in a single node or by changing requirements. As a rule self-healing propagates through the network and impacts on configuration and optimization.
-Self-protection. This means proactive protection from defaulting conditions. In SME networks the main cause of faults is the negative behaviour of certain nodes, then self-protection is mostly based on evaluation of past performances.
1.4 Pilot experiments
The performance of pilot experiments was foreseen to validate the EBEST approach and the relative software services with the twofold objective to demonstrate their effectiveness and collect hints for their best deployment to a wide population of SME-AGs and the associated companies. The following table summarises the demo scenarios that were subject to experimentation, grouped according to the EBEST components that each of them was committed to test.
1.4.1 Demos of Ecosystem Shaping
This section summarises the information about the pilot experiments carried out to test the Ecosystem Shaping component of the EBEST platform.
SIRRIS, Belgium
Two demos were identified in the framework of ITEA2 research projects. According to the ITEA2 NDA all participants and the research proposals in this description are anonymous. The ITEA2 brokerage days were held in Madrid, Spain, on February 1st and 2nd, 2012.
IDM -GAIA, Spain
This pilot experiment was organised by GAIA with respect to its relevant ecosystems so as to test in real life conditions and with real actors the EBEST collaboration framework and ICT platform, and specifically the Ecosystem Shaping software component.
1.4.2 Demos of Collaboration Portal
The list below shows the identified and planned actions, per SME-AG, to involve a critical mass of EBEST users, taking advantage of this part of the EBEST platform.
CCI KILKIS, Greece
The pilot experiment tested a case carried out following the 'Tendering process workflow' schema. The case was about assembling a proposal under the framework of NSRF - National Strategic Reference Framework, and specifically under the framework of ICT4GROWTH Initiative that aims to the support of SMEs to implement their development plans towards the provision of innovative products and added-value services.
OKISZ, Hungary
The title of this demonstration could be 'Adult Training for Unemployed People', meaning preparation of a proposal under the Hungarian National Development Plan Human Resource Development Program. Purpose of the pilot was testing and demonstrating the use of the Collaboration Portal, and although there are several opportunities to use this software environment, the demonstration used a tendering process as an example which entirely covered the proposal preparation process.
International
This demonstration could be entitled 'Process Oriented Knowledge Extraction' for the preparation of an EUREKA proposal. EUREKA is more than an organisation, it is an ambition: to become the leading platform for Research and Development (R&D)-performing entrepreneurs in Europe and beyond. EUREKA R&D is industry-led, applied, close-to-market with tangible results and visible benefits.
1.4.3 Demos of Operational Platform
The list below shows the actions identified and performed to involve a critical mass of users for this particular part of the EBEST ICT platform.
TEL&CO, Italy
The title of this demonstration could be 'Maintenance of ICT infrastructures', including both planned maintenance and on-demand interventions, by optimal scheduling (and re-scheduling) of weekly activities. TEL&CO is a company of 30 employees established in Modena, providing installation and maintenance of ICT infrastructures. TEL&CO is partner in the EBEST project, then it was the main driver of the Operational Platform requirement specification, design and validation.
Fashion Contract, Italy
The title of this demonstration could be 'Prototyping a clothing sample', which is the main service the Fashion Contract consortium offers to international buyers and large fashion industry, thanks to the sound skills and quality level that the members of this network all together can offer. Fashion Contract is a consortium of nine small-medium and micro companies, all working in the fashion sector and established in the Modena province. It was promoted and is continuously supported by CNA Modena as a living example of successful networking of independent entities joining forces to increase their market share.
CEDEM, Italy
The title of this demonstration could be 'Fuel station global service', which is the main service the CEDEM consortium providers to its customers (ENI in the first place). CEDEM was established in 1997 by 10 companies to survive in a market ever more populated by large global players, by offering a multi-disciplinary high quality service at reasonable price. The consortium is mainly involved in building and maintaining fuel stations, with timely and effective mechanical, electrical and hydraulic interventions.
SCCI, Slovakia
The Slovakian case presents rare but not least important operations that must be performed by a logistic company in case of a truck accident. This scenario is characterised by a fact that all the activities must be performed almost immediately after the accident, in order to minimize damages on the goods that are transported.
The main actor in this scenario is a primary logistic company, Alfaball, that must search for partners after its truck crashed, while dispatching an order to Apis company.
Potential Impact:
1.5 Potential impact and exploitation
The EBEST project had the ambition to introduce and deploy a new collaboration framework addressed to business ecosystems of small service companies in different EU countries, supported by a specific advanced software platform. It was expected that this could dramatically change the position of the target companies with respect to each other and improve their role in the local and global markets.
The results from the pilot experiments are showing the following although initial benefits:
-SME-AGs have the possibility to use a neutral and innovative support tool for shaping communities of potential partners as preliminary condition for their constitution as steady collaborative networks. This will impact on the competitiveness of networked companies and then on the survival and possible economic growth of entire ecosystems in the involved regions.
-Network leads have the possibility to achieve higher efficiency levels in coordinating the respective networks. The natural consequence is a stronger presence on the market and an increased trust in customers preferring direct and fast partnership with the lead SME on behalf of the entire network rather than managing dispersed relations with a number of individual suppliers.
-Network members have the possibility to collaborate with one or more networks or supply chains assuring fast responses to each of them without being affected by the need of adapting their legacy systems to the different leads. In other words they are finally in the condition to gain positions in the market according to their skills along with their reliability and collaboration efficiency.
1.5.1 Qualitative and quantitative benefits
The EBEST project impact will results in terms of facilitated daily work and improved company competitiveness in different aspects:
-Better image. The image that the single company proposes to its customers and partners is improved thanks to transparency of offer, timely service scheduling, as well as consistent cost and lead time estimation.
-Increased productivity. The adoption of simple but functionally rich software tools makes companies save time and cost related to non-core activities, misunderstandings and mistakes. Another positive impact comes from increased project management ability especially with respect to resource planning.
-Reduced conflicts. The adoption of clear and explicit coopetition protocols, and the possibility to easily communicate (and keep track of occurred events), reduces the risk of conflicts. Hence, the companies can focus better on their business and save effort presently wasted to recover problems.
-Access to wider markets. The new working conditions allow companies to extend their traditional niche markets and, possibly, address new markets. Disciplined collaboration methods favour the start-up of joint ventures that can lead to the constitution of larger (stronger) companies.
-New business opportunities. Although remaining basically linked to the local market, the access to the electronic market can extend dramatically the business opportunities of the target companies, especially when presenting their service capacity as a network on an entire business ecosystem.
A further beneficial element is the important extension of the knowledge base from which the target companies derive their decisions and strategies. To this purpose we expect the following main changes:
-Internal knowledge. In adopting the proposed solution each company will analyse its present practice and formalise procedures and documents. A by-product of this work is an increased awareness of what the company is, how it actually behaves and which habits should be discussed and revised.
-External knowledge. Another change comes from a broader view of similar or complementary companies acting in the same market. The possibility to examine their offers and practices produces, for the most dynamic companies, a clearer understanding of collaboration opportunities.
-Market trends. The third important aspect is the possibility, for associations, to derive indicators on the performances of the member companies and on market trends and drifts. If made available to the member companies, this knowledge can orient their investments and organisational improvements.
1.5.2 Social objectives addressed
The social objectives explicitly addressed by the EBEST project are summarised in the following points:
-Modernising the organisation of work. The project pursues the objective to offer small service suppliers a model for work organisation that allows them to face changing markets with an effective use of new technologies, a model that at present is only available to larger enterprises. This favours the introduction of a new entrepreneurial culture that facilitates the undertaking of joint initiatives and, eventually, the access to the electronic market.
-Promoting employment. A stronger position of small service suppliers on the market makes them identify new business opportunities and widen their offer. The first expected effect is therefore creation of new jobs that, very important, involve with no discrimination both genders thanks to the intrinsic variety of the intended services.
-Qualifying jobs. Moving the organisation of work of small companies from the present unstructured habit to a formalised, although simple, information flow management qualifies the existing jobs and adds new qualified jobs. In particular, improvements are envisaged in process management and introduction of advanced ICT tools.
-Emerging from the informal economy. Behind the high rate of unemployment and tax evasion recorded in Europe there is an informal economy hidden to all statistics. The project achievements will offer these companies the opportunity to dynamically collaborate and associate in smart networks provided they operate in a transparent and legal way.
-Increasing social cohesion. Even though not facing the wide problem of social inclusion, the project aims however at improving the relations between service suppliers and their customers in terms of clear regulations, explicit codes of practice, transparent times and costs. The consequent reduction of conflict is socially relevant.
-Improving inter-generation relations. The intended companies are often managed by the same persons that, years ago, started the business. In many cases, the present times are those when the old founder wishes to transfer the business to the new generation, and this raises enormous problems in terms of knowledge and relations with the market. The proposed solution captures part of this knowledge and formalises it into processes and disciplined transactions, thus providing a (partial) support to overcome the problem.
1.5.3 The EBEST system in action
The introduction of the EBEST solution at a large number of SMEs has a cost for the user companies that their reference associations can strongly contribute to limit. This critical role of SME-AGs is better understood by analysing the four main steps that they have to undertake to adapt the EBEST platform to the specific ecosystem conditions and to promote its adoption by the member companies.
Platform acquisition
Every SME-AG first customises the EBEST methodology by relating it to the respective ecosystem characteristics. It implies promoting the constitution of the community and involving the candidate user companies to choose the most suited organisational model and define in detail the rules of play. This is a task that absolutely needs to be carried out on the field by taking into account real life conditions.
Platform initialisation
Note that the EBEST platform resulting from the project is 'neutral' with respect to the single ecosystem knowledge. It is already localised on the regional language and provided with a general service sector ontology, but not characterised yet in terms of specific processes, rules and vocabulary of the single user network. What is made available to user companies must be preventively initialised to minimise the network member start-up effort.
Platform customisation
Should the initialisation work not be sufficient to cope with special needs of a certain network, the SME-AG is put in the condition to ask its reference ICT company or another third party to develop additional functions. Typical enhancements are customised user interfaces for order acquisition, graphical and reporting functions, integrations with other software packages or portals.
Platform instance configuration
When a user company can finally access its own workspace and use the functions of the (initialised and customised) EBEST platform, it must undertake in turn a parameterisation task aimed at configuring the preferred policies. They include e.g. criteria to choose the best plan to execute, the scheduling algorithm and the resulting best schedule, as well as criteria to recover idle times of internal resources and introduce margins on estimated times and costs.
List of Websites:
http://www.ebest.eu
This publishable summary recalls the EBEST project context and objectives, presents the work performed up to the project conclusion, shows the main Science and Technology (S&T) results achieved, describes their potential impact and use plans, and provides a schematic presentation of the EBEST consortium composition along with relevant contacts.
The EBEST project started on January 1st, 2010, with a work plan of 24 months, a budget of 2.701.347,40 Euros and a requested EC contribution of 1.650.000,00 Euros. The project was formally suspended for five months, May to September 2011, to overcome a bureaucratic question emerged at run-time, and its duration was extended accordingly. Then it ended regularly on May 30th, 2012.
The ultimate objective of the SME-AGs and the other partners promoting the EBEST project was the introduction of new collaboration practices in ecosystems of SMEs belonging to different industrial sectors, through the provision of easily accessible ICT services to enable community building, SME network constitution, and SME network operation for the network lead and its members.
This publishable summary is organised into the following main chapters:
-Chapter 2 recalls the context with respect to which the project was conceived as well as the strategic and operational objectives pursued during project execution.
-Chapter 3 presents the work performed and its organisation into work packages and tasks, as well as the S&T results (foreground knowledge and software) generated.
-Chapter 4 describes the pilot experiments that have been performed to validate the EBEST model and software platform versus real-life cases.
-Chapter 5 estimates the impact expected from the adoption of the EBEST solution and the procedure for SME-AGs to deploy it towards the associated SMEs.
-Chapters 6, 7 and 8 finally provide a schematic description of the EBEST consortium composition with the address of the project public web site and relevant contacts.
This document is addressed to a composite audience:
-In the first place, SME-AGs willing to promote the constitution of SME networks out of their members and support their efficient operation.
-Also, enterprises leading already constituted supply chains that are interested to increase their efficiency in communication and collaboration.
-Then, research institutions and third parties of the ICT and business sectors for the possibility they have to add functions and services.
-Finally, political institutions, especially those acting at the regional level, which can use the EBEST solution to promote SME networking.
Project Context and Objectives:
1.2 Project context and objectives
At the EBEST proposal presentation time the economic crisis was showing its first dramatic effects in terms of recession and unemployment. SME-AGs were in the forefront trying to understand how to help the associated SMEs in slowing down or even reversing the negative trend. The identified perspective was taking the crisis as an opportunity to push small and medium-sized entreprises (SME) towards organisational and ICT innovation to reach higher efficiency.
1.2.1 Vision
Observatories of European SME-AGs are expecting a dramatic future for their smaller associates acting in different industrial sector. The negative trend of the last years is continuing and possibly worsening, and could determine the closure of up to 40% of present SMEs in the EU or decrease substantially their activities, personnel and turnover. What can an association do to prevent or mitigate this risk?
1.2.2 Context
At the EBEST project start time the participant SME-AGs were very concerned about the future of their associated SMEs because of the worrying market situation generated by the global economic crisis. The project was in fact intended to promote the adoption of efficient collaboration practices within and between business ecosystems by taking advantage of a specifically conceived suite of ICT tools to support them.
To this purpose the EBEST project addressed small and micro companies (less than 50 employees) providing services to other businesses, typically by subcontracting, in a number of industrial sectors. These target companies are used to perform added-value activities (jobbing, working, etc.) in the intermediate phases of the value chain and/or in the repair and maintenance phases.
Examples of SMEs relevant to the project are:
-Textile sector: prototyping (of textile or knitted goods), weaving, finishing, ironing.
-Construction sector: heating, hydraulic and electrical plants, painting, maintenance.
-Mechanical sector: surface treatment, machining, assembling, repair, maintenance.
-ICT and media sector: setting-up and maintenance of voice and data networks.
The target companies typically operate by offering to the market their qualified resources, especially skilled personnel and specialised equipment. Their main strength points are high quality of service and intrinsic flexibility and adaptation to market conditions. Their main weakness points are limited investment capability and low efficiency due to their poor ICT adoption especially in communication and coordination.
The economic crisis is still there and its effects are involving an increasing number of SMEs in different countries. The context remains worrying and the objectives of EBEST are even more valid. Its outcomes help the target SMEs to survive by:
(i) meeting customer requests at best,
(ii) joining efforts in well-configured networks,
(iii) coordinating optimally the network members, and
(iv) optimising the use of individual member resources.
1.2.3 Objectives
The EBEST strategic objective is setting-up, experimenting and promoting the adoption of new collaboration practices within SME networks supported by innovative ICT tools making the network behave as an efficient single organisation. The EBEST tools are conceived to define and improve the network configuration, and to support its daily operation in executing customer requests and orders.
The EBEST strategic objective is split into a number of operational objectives:
-Enabling SME-AGs to support the associated SMEs in shaping potential networks out of the existing business ecosystems.
-Enabling SME-AGs and autonomous SME networks to constitute operational networks for grasping business opportunities.
-Enabling the network lead to efficiently coordinate the network by optimising task assignment to the network members.
-Enabling each network members to optimally allocate the internal resources to perform at best the assigned tasks.
-Enabling the network partners to collaborate in damping down perturbations caused by exceptions occurred during order execution.
-Facilitating the network partners in exchanging business documents and moving them from/to their legacy systems (if any).
Further general yet fundamental objectives are:
-Promoting codes of practice and trust-building mechanisms, including performance evaluation criteria, to guide the fair competition of the target companies.
-Using successful cases taken from real-life experiences as living examples of the benefits that the EBEST solution can bring to companies.
-Adopting a pay-per-use model for minimising the cost and effort required by the single SME to start using the EBEST solution and, in case, to leave it.
-Deploying the project results to the largest audience so as to reach a critical mass of user companies in the shortest possible time after project completion.
Because of the economic situation it was established that the above challenging objectives had to be met in no more than two years. This was considered feasible by involving RTD performers that could bring to the EBEST project a rich amount of background knowledge, in both organisational and technological terms, acquired by their participation in a number of successful European RTD projects.
Project Results:
1.3 Main Science and Technology (S&T) results / foregrounds
In order to pursue the above-recalled objectives the EBEST project had to innovate in two main fields, namely collaboration models and collaboration tools:
-Concerning collaboration models there were three the main aspects to consider: analysis of collaboration habits and needs, definition of trusted operational scenarios, and introduction of new organisation and business models.
-In turn, concerning the collaboration tools there were three suites of functions to develop and test through pilot experiments, respectively supporting the community building, network constitution and network operation phases.
1.3.1 Innovation in models
Collaboration habits and needs
Although generically perceived, the collaboration potential of small companies belonging to a business ecosystem is not known in the required detail. It certainly depends on variable factors such as industrial sector, company nature and size, local economic fabric, norms and regulations. Of course, the reference SME-AGs are in the best position to understand habits and needs of the associated companies.
However, further investigations are required to assess in depth specific situations. This knowledge, a first measurable result of the EBEST project, consists of business and technical specifications to be taken as basis, on the one side, for the definition of the devised collaboration models and, on the other side, for the expression of requirements on the ICT applications and functions to develop.
Trusted operational scenarios
The ways for the intended companies to interact and collaborate within and across the boundaries of their business ecosystems - on a full trust and confidence basis, including regulatory and contractual issues - are formalised and represented as main operational scenarios. These scenarios constitute the EBEST project detailed vision and perspective, and represent another of its measurable results.
The scenarios are defined starting from habits and needs and taking into account the documents the companies are used to exchange. They are not limited to express what presently happens (or is considered a possible improvement), but are intended to imagine the EBEST environment where the new practices are finally adopted to provide the target companies with other business opportunities.
New organisation and business models
The third component of the EBEST collaboration framework deals with understanding which medium-term changes could (should) be introduced by a full deployment and use of the EBEST solution. This means, in the first place, studying the impact of the collaboration practices and ICT support tools on the work organisation of the target companies, and on the associations themselves.
This leads to define business models suited to benefit from the dynamic collaboration opportunities offered by the innovative environment, representing another measurable result of the EBEST project. They provide the basis for a wide deployment of the proposed methodology and ICT support tools at each of the involved business ecosystems and towards other candidate ecosystems.
1.3.2 Innovation in technology
Community building
This technological component is intended to support the initial phase of collaboration, that is, the discovery, analysis and conception of business ecosystems. This implies investigating the role of the 'ecosystem architect' as specific actor in the ecosystem guiding processes, acting in particular at SME-AGs and offering strategic innovation support to clusters of small and medium companies.
Business ecosystem modelling is not a new concept. The term itself, borrowed from biology, represents the action of capturing and describing the interactions of economic entities such as companies. Tools and techniques exist to support the modelling of these interchanges, from supply chain modelling to the recently popular business model canvas, but most of them focus on the point of view from a single actor in the value network.
The community building tool behaves as a workbench. It must provide a combination of three basic elements: knowledge representation about candidate SMEs and their features, exploration mechanisms for querying and browsing the knowledge graph including implicit (and imperfect) enrichment of interconnections, and social networking to assist in the discovery of collaborations around potential new SME ecosystems.
Network constitution
This technological component is intended to facilitate the identification of new business opportunities and involve ecosystem actors. SME-AGs can promote business opportunities at selected companies and discuss with them their implications, while the involved companies are put in the condition to evaluate those opportunities, define the relative processes and, if possible, establish relations and constitute new networks.
The network constitution tool must provide a process workflow interface for managing regular processes of the ecosystem. There is a set of predefined processes but it provides the opportunity to add specific workflow processes tailored to new needs. The predefined processes include tender management, marketing campaign management, business or innovation award workflow, and joint event organization.
The network constitution tool should interpret the prepared workflow model and automatically generate the working software instance for workflow support. Its basic functions are: company representation, search for collaborative partners, collaborative contents and document management, task and ToDo management, workflow process management, and communication services, news, notifications, and so on.
Network operation
This technological component is intended to support and facilitate the daily activities carried out within an SME network. While community building and network constitution occur at design-time to configure the network and organise its processes, the network operation tool provides the suite of necessary functions to be used at run-time for network coordination, node optimisation and document exchange.
Network coordination is in charge to the lead company that transforms incoming requests for quotation or orders into plans involving selected network members. It relies on a distributed planning function that assigns tasks according to agreed parameters and criteria. Very important, the same planning function is used to revise the distributed plan whenever exceptions occur that need to be damped down.
Node optimisation is in charge of every network member receiving an assigned task from the lead company, and implies scheduling at best the use of its resources (manpower, equipment) for task accomplishment according to their actual state and a number of customised conditions and criteria. Even the scheduling function is reused to reduce possible perturbations affecting the network and the involved nodes.
Document exchange is the third important service to provide to lead company and network members for increasing the overall network efficiency. It includes business document import/export from/to the legacy systems (if any) of the partners, automatic document structure conversion to adapt to imposed formats, and automatic document contents translation in multi-lingual cases.
Note that in many cases an SME is at the same time member of one or more networks and lead of its own supply chain. With the network operation tool it is put in the condition to carry out both roles seamlessly having allocated the relative workspaces and assured the links between data and business documents exchanged with customers and those exchanged with suppliers.
Finally, in order to facilitate SMEs in entering the EBEST solution and possibly leaving it if not satisfied, the network operation tool should be published by every SME-AG and made accessible to its user companies in SaaS (Software-as-a-Service) mode. Hence the cost of its functions can be customised on regional/sectoral basis and this should accelerate the achievement of a critical mass of user companies.
1.3.3 Work performed
The general strategy of the EBEST project for achieving the defined objectives, and the consequent implementation methodology and work plan, were intended to maximise the probability of its full success. In fact it was decided to move along four main stages each corresponding to a measurable progress and assuring the condition for possible corrections of the work in progress.
The four project development stages are here briefly recalled:
-The initial idea of the EBEST promoters, as reported in the proposal, underwent a sound validation work by studying and discussing in the mentioned innovation fields with the ultimate aim of reaching in the shortest possible time a real common understanding of problems and solutions within the consortium.
-On the basis of the knowledge, requirements and specifications resulting from the previous stage the organisational and technological components of the EBEST solution were designed and developed in parallel tasks so as to minimise the time needed for the construction of the whole system.
-The third stage was devoted to integrate the developed components into the foreseen organisational model and EBEST software platform, and to further adapt them to a variety of operational conditions so as to meet at best the requirements of the participating associations and the identified test cases.
-Finally, the EBEST solution was submitted to a comprehensive real-life validation activity for its final improvement and tuning, and to an intense demonstration phase as the best way identified to facilitate its adoption by the associated companies and deployment to other business ecosystems.
This stepwise strategy was applied to the numerous themes representing the challenges of the EBEST project. The work plan was organised into thematic work packages since this is the most efficient structure for the constitution of qualified work teams, the full coverage of all the aspects that must be faced and resolved, and the attribution of the responsibility to obtain the devised results with the available resources and time.
Work packages
Taking into account the project objectives, methodology and implementation strategy, the adopted work plan was split into three RTD work packages (namely WP1 to WP3), one demonstration work package (WP4), one work package (WP5) devoted to training, dissemination and deployment of the EBEST solution, and one work package for project management and coordination (WP6).
The picture the work plan structure and the main dependences between work packages. In detail:
-WP1 - Collaboration Framework. This WP analysed the collaboration habits and needs in the business ecosystems represented by the SME-AGs of the EBEST consortium, proposed a set of trusted operational scenarios according to the EBEST perspective, and defined new organisation and business models suited for companies and associations to exploit the EBEST project achievements. The early results from this WP were fundamental to orient the RTD work in WP2 and WP3 and the demonstration work in WP4, while its final contribution favoured the deployment of the EBEST solution.
-WP2 - Knowledge and Languages. This WP worked simultaneously on standard taxonomies and the business documents exchanged within the ecosystems and with the external world. The aim was constituting the knowledge base of concepts and the multilingual terms needed to support the communication of the network members with the other actors. Then, the WP produced, by adaptation of the SEAMLESS prototype, the ICT tools mapping proprietary data models and the ICT services for the automatic transformation of the exchanged documents.
-WP3 -Collaboration ICT Platform. This WP designed and developed the EBEST ICT platform to support the proposed organisational model. The platform offers the devised design-time and run-time services and applications discussed above, providing community building, network composition, planning, scheduling and translation services (hence including the ICT functions coming from WP2). The platform was developed in open-source technology and was interfaced with the legacy systems of user companies to realise the required level of interoperability with existing software applications.
-WP4 -On-field Demonstrations. This WP performed pilot experiments and public demonstrations in order to validate and tune the EBEST outcomes. In particular this WP was fed by the results coming from WP1 (collaboration model) and WP3 (supporting ICT platform) and produced important indications for EBEST solution take up. The demonstrations were carried out by regional pilots involving different industrial sectors: fashion, global service and telecom in Italy, ICT in Spain, manufacturing in Greece, construction in Hungary, logistics in Slovakia, mechanics in Belgium.
-WP5 - Training, Dissemination and Deployment. The ultimate aim of this WP was deploying the EBEST solution to the largest communities of user companies and to further business ecosystems. Training actions were performed on SME-AGs (trainers) and then on companies, dissemination initiatives were undertaken with the objective to spread the EBEST concept and results, and an effective deployment model was defined for EBEST adoption after project completion. According to the above picture, this WP used results from the other WPs and specifically the ICT platform from WP3.
-WP6 - Project Management. This WP included the activities assuring full and timely achievement of the foreseen project results, effective collaboration of partners, identification and correction of possible deviations from plans, adaptation to emerging needs, relations with the European Commission. It also performed specific actions to assess the quality of project results and their correspondence to the expectations by SMEs and SME-AGs.
The EBEST consortium confirms that the adopted work plan structure was particularly effective in pursuing and reaching the project objectives in the given time, and every partner was committed to allocate the needed resource to this purpose. As a matter of fact, neither deviations nor delays with respect to the work plan were detected in spite of the five-months suspension due to mere bureaucratic reasons.
1.3.4 EBEST platform architecture
The outcomes resulting from the EBEST project are a software platform and the knowledge to use it at best in different operational conditions. The platform is published by each SME-AG (or its reference ICT provider) and its functions are made available to the associated SMEs in SaaS (Software-as-a-Service) mode. The following figure sketches the EBEST platform architecture with its main components and relations between them.
The design-time components are called Ecosystem Shaping and Collaboration Portal and are intended to support the community building and the network constitution phases, respectively. In turn, the run-time component is called Operational Platform and is intended to support the daily communication, distributed planning and resource scheduling work carried out by the network lead and the other networks members.
Before examining in more detail the three software components it is useful to recall the types of involved actors:
-SME-AG. Public or private institution whose ultimate goal is improving the competitiveness of the associated companies by providing them with advice and services aimed at augmenting their efficiency in satisfying the customer needs. The association is the only that can promote new networks, stimulate their members, push to the adoption of innovative methods and tools.
-Lead company. Companies populate the ecosystem, establish relations by constituting networks, constantly look for new customers, and are interested to increase efficiency and competitiveness. Lead company is the company assuming, steadily or dynamically, the role of network coordination, that is, the operational interface between customers and the other network members.
-Supplier companies. These are the network companies performing coordinated tasks to execute customer requests for quotation and orders. They share the collaboration model although differing by nature, size and offered services. A company can behave at the same time as lead and supplier in the network. Moreover, a supplier can be in turn the lead of its own supply chain.
Of course, customers are the engine of the entire system. They spend money for receiving back products and services, and their satisfaction is the basic condition for the network to survive. In terms of information exchange, they communicate requests for quotation, orders and possible exceptions, and the network answers with quotations, order confirmations, order progresses and new deadlines.
1.3.5 The Ecosystem Shaping component
The Ecosystem Shaping component groups the functionalities that are needed to promote and characterise the ecosystem and to improve it time by time. SME-AGs can use it for exploring the potentials if the associated companies with the purpose to promote the organisation of new networks and to characterise them in terms of sectoral or regional orientation, sharing of methods and models, and the like.
Overview
While some networks are created with no external intervention, it is assumed that in most cases an active role shall be played by a key profile, an Ecosystem Architect (EA), in discovering, exploring and shaping interesting potential ecosystems. During the early shaping phase, the involved companies could be not aware that they have been introduced into the system and that a potential role in a future collaboration is being considered.
The Ecosystem Shaping knowledge base contains non-public information that is shared bilaterally between a company and the SME-AG. The Ecosystem Architect has a privileged, cross company view on the totality of this information space. Since the information may contain competitive data on the different actors, any interactions a company can have with the knowledge store are limited and protected.
We will refer to the model whereby companies directly engage the EBEST platform out of their own initiative as the pull model, as it describes existing company collaborations being pulled directly onto the platform. The Shaping module further extends this with a push model where the SME-AG, after extensive exploration, initiates and proposes new collaboration engagements between companies.
The focus in this part of the system is not primarily on supporting the SME actors themselves, but rather on supporting the work of a group of Ecosystem Architects, experts typically operating within the SME-AG, working together on creating potential networks. The system can support early, pre-operational, incubation of networks, while networks ready to start an operational collaboration can be incepted onto the full EBEST support infrastructure.
Functional support to the Ecosystem Architect
An Ecosystem Architect actively explores, discovers, shapes, launches, observes and evaluates potential business ecosystems out of companies in diverse contexts. In theory the EA continuously synthesises a rich information into a knowledge model, uses this model to explore potential win/win scenarios for multi-company collaborations, and facilitates further exploration by the target partners in the perspective on network constitution.
While many tools such as CRM systems support efficient uniform data collection, an exploration and discovery component targeted directly at the specific EA needs has to include knowledge representation and knowledge exploration. The representation function is flexible enough to support design and change of the modelled entities such as companies, technologies, people, business contexts, and the relative relations.
In turn, the exploration component is able to support multiple forms of discovery, amongst which:
-Discovery through search/query: The Ecosystem Architect can express partially some required attributes needed and gets back the resulting set of entities that correspond to those attributes.
-Latent discovery: Searches can be immediate and single use, but it should also be possible to submit a search request and be notified whenever additions to the knowledge base produce new results in this context.
-Discovery through browsing: The EA can select a potentially interesting starting position in the knowledge model (possibly seeded through search), and explore further across the relationships present in the model.
-Discovery through serendipity, aka accidental discovery. While this can be implicitly present in both discovery though search and discovery through browsing, it can be further enhanced though active support and user interaction choices.
Apart from the technical implementation, there are strict features on the representation of the knowledge model:
-The knowledge representation is light-weight, flexible, extendible and supportive.
-The system allows for input and maintenance relevant types of local data.
-Imports and alignments with data residing and being maintained in external systems, both from EBEST as well as other sources, are possible.
-All the discovery modes (search / latent / browse / serendipity) are supported.
To this end the Ecosystem Shaping knowledge solution functionally resembles the discovery over an associative graph structure. Underlying technological alternatives have been explored during the implementation phase. Where possible they have been aligned with evolving toolsets and conventions in the semantic web domain, keeping into account the need for maintainability and simplicity.
1.3.6 The Collaboration Portal component
The Collaboration Portal offers the functionalities that are needed to work on business opportunities, possibly identified by the SME-AGs, and build new networks and distributed processes around them. By means of collaboration tools like discussion board, wiki, content management and project management one or more companies negotiate the conditions of their future collaboration.
Overview
As it can be seen in figure, the intended EBEST Collaboration Portal (also called Collaborative Ecosystem Platform) consists of three different parts:
-The back-end, which is responsible for the communication between the core eWork functions and the main collaborative services.
-The middleware, which supports the collaboration business logic. This layer is responsible for handling requests from the user domain on the upstream, and then processing the data that are fetched from the backend, compose them to objects that correspond to steps in user-configured workflow and send them as events to the various GUIs on the downstream
-The GUI, which is responsible for sending and receiving events. Such GUIs can be built in principle for desktop and mobile interfaces.
eWork functions
The modular design allows for the eWork functions to be either internal to the ecosystem platform or external to it, i.e. part of the existing infrastructure at the corporate or ecosystem level. It also allows for different ecosystem participants to work on different eWork environments although the formulation of cross-enterprise teams should be based on some commonality in particular when common/shared eWork functions are concerned.
Below we list some of the most common eWork functions:
-Content Management. Content management is a set of processes and technologies that support the evolutionary life cycle of digital information. This digital information is often referred to as content or, to be precise, digital content. Digital content may take the form of text, such as documents, multimedia files, such as audio or video files, or any other file type which follows a content lifecycle which requires management. In EBEST we are mostly concerned with simple documents and contents in wiki-like format, which is easy to edit and share. The eWork environment at the back-end is able to provide pubic APIs that expose the above functionality.
-Discussion boards. In our days, much of the digital communication is being done with email. In fact, people tend to have more than one email addresses that correspond to different types of expected messages: work emails, personal emails, and so on. It can also be used as a good notification system, which notifies the user in case of an event of a different modality. Rather than being an email provider, the EBEST Collaboration Portal provides functionalities for filtering and scheduling user accessibility by email. It also offers structured and organised messaging support in the form of threaded discussions, where the back-end eWork environment supports it.
-Task list / calendar. One of the essential things that a flexi-worker must do is to manage its time on a day-to-day basis. The eWork environment provides tools for creating and maintaining the user task lists for everyday activities, like: appointments, everyday tasks (shopping etc), payments (when they are due).
-Project management (workflow, scheduling). Project management is the discipline of planning, organising and managing resources to bring about the successful completion of specific project goals and objectives. Usually a flexi-worker has more than one project to manage, and the eWork environment provides the following functions:
--Defining workflow actions and transitions in project tasks (scheduling).
--Triggering events when specific workflow actions occur (i.e. e-mail team, when a new release of a document is online).
--Team management, to help the worker monitor the actions and logs of colleagues and provide default actions, such as reply, add to calendar, etc.
User functionality
The user functionality constitutes the scope of tools and services which are made available to the end user through the EBEST Collaboration Portal interface:
-GUI configuration and customisation. The user is enabled to configure what the EBEST collaborative workplace should be retrieved on demand (notifications), what should be automatically pushed (alerts) from a list of available options and entities and create filters for different profiles, for a certain day and so on. To this purpose a workflow constructor is made available in order to define and bind work functions and steps together in workflow processes that combine events and actions. Pre-defined and automatic user-specific and system-level workflows might include, for example, to send an email when a certain kind of event occurs (e.g. a new document in the content management system is received).
-Events. Through the collaborative GUI the user is enabled to create events and then bind them with alerts and notifications. An event may be a combination of eWork functions with certain criteria. For example an event "new task" could be defined that checks when a new task is added to the task list from a certain user or is connected with specific content like a new document. Likewise the user will be receiving events from the eWork functions and may handle them as required by defining workflows, as described above.
-Notifications / alerts. The collaboration framework provides notifications of selected events, like the one above. The users are enabled to filter the notifications and alerts in their profiles through the GUI customisation. For example notifications about new tasks should not be showed in weekends or when driving. Notifications and alerts may be bound with messages, for example an e-mail notification can be bound with the email message body. If there is an alert, message retrieval should be automatic (push), otherwise it should be on-demand.
Business logic
The logical design of the middleware in the Collaboration Portal includes the following main functions:
-Entity dispatcher. The entity dispatcher is the main component of the collaboration framework middleware. It is responsible for handling all the communications between the GUI and the eWork environment. The entity dispatcher contains the following modules:
--Request handler. The request handler is the external interface of the middleware. The UI clients connect to the middleware through the request handler. It is responsible for keeping a mapping between user authenticated sessions and access GUIs and for keeping the transfers secure. The request handler then passes the validated requests to the event controller. When the event controller has new events that need to be passed to the correct user, it sends the request handler the event with the session id, and it then validates the session id and through the mapping it knows where to send the event.
--Event controller. The event controller is the main component of the event dispatcher. It is responsible of satisfying the requests from the UI clients by taking objects from the downstream object pool and transforms them into workflow entities that the user has defined in the workflow configurator. These entities are then dispatched back to the UI component though the request handler. The event controller polls frequently the downstream object pool for new objects and if there is a workflow defined for them, it then creates it with the new objects and sends it to the correct UI client through the request handler.
--Object pools. There are two object pools available in the entity dispatcher, namely the upstream object pool and the downstream object pool. The downstream object pool is responsible for objects that come from the eWork functions through the back-end connectors. The upstream object pool is responsible for objects that come from the UI clients and contains data that either needs to be merged to the eWork environment or commands that concern the backend connectors (i.e. when a client demands a full and not an incremental synchronization because some of the data at the client side are corrupted or missing).
--Filter. The filter is a programmable component that is created from the UI components according to the user preferences. It filters all events that the user does not want to get in certain UI components at certain times. For example when the user is reachable at a mobile device he may not want to receive any events that are not critical. The filtered (i.e. not communicated) objects are stored in the cache and are fetched again on a subsequent update request from a UI component.
-Workflow engine. This is the middleware component that creates the workflow objects, and consists of two components: the configurator and the constructor:
--Workflow configurator. The configurator role is to provide the user with the tools he needs to create, modify and delete workflows and store them for use with workflow constructor. The configurator has an easy and intuitive user interface for comfortable and productive usage.
--Workflow constructor. The constructor creates workflow objects on request by the event controller. The controller requests workflows for a specific user from the constructor with specific criteria that the newly fetched objects provide. The constructor returns a workflow object, if one exists, and the controller fills it with the received data.
-Back-end. The back-end layer is responsible for the two-way communication between the middleware and the eWork functions environment. It consists of several backend connectors. Each connector connects to a single eWork service, i.e. there is one connector for the email service, one connector for the project management, etc. This approach enables different eWork providers to be used by different enterprises and be connected to the Collaboration Portal as either internal or external entities.
-Workplace ontology. When there is an agreement on a semantic-level representation of collaborative work-related tasks, actions and information exchanges among the main actors, then an ontological framework is adopted by the ecosystem. This ontology is used as a reference for modelling workflow items and constructing workflow processes. The ontology is referenced from the workflow engine of the collaboration framework, that is, the workflow configurator module presents options that are compliant with the common ontology, thus the workflow process flows are compliant with the ontological framework adopted.
1.3.7 The Operational Platform component
The EBEST operational model applies to every small and medium-sized entreprises (SME) network whose members are aggregated by business opportunities. Within the network companies establish steady collaborations involving complementary, and sometimes even competing, nodes while maintaining their full individual autonomy. Their ultimate aim is showing a unique, efficient image to potential customers to safeguard and possibly increase their position in the market.
Overview
The Operational Platform component provides SME networks and their lead and member companies with a suite of operational functions enabling them to easily and efficiently communicate, plan distributed processes (if network leads), and schedule the internal resources (if supplier). A company that is at the same time lead and supplier can take benefit of the entire EBEST Operational Platform functionality.
The main Operational Platform functions that have been identified as strictly necessary to the relevant network profiles:
-Lead company viewpoint. Its role includes interaction with customers, network coordination and supervision, task assignment to network members, business document exchange, exception handling at the network level.
-Member company (supplier) viewpoint. Its role includes interaction with the lead, optimal management of internal (own) resources, business document exchange, exception handling at the shop-floor level.
Distributed planning
The functionality of a company node depends on the role of that company in the collaborative network. In case it behaves as a lead it has access to the functions that are needed to interact with customers, plan the execution process, assign tasks to selected suppliers and keep the execution progress monitored. To this purpose the EBEST project has developed a distributed planning function which is particularly reactive and suited to handle the frequent exceptions occurring in the network.
At design time the lead company defines the distributed processes it is asked to coordinate. As usual every process is split into activities, precedences are established between activities, and every activity is properly modelled and associated to the supplier(s) in the cluster that can execute it. Core activities are normally interleaved by auxiliary activities such as on-site requirement collection or final installation and, notably, transports of materials mirroring the condition of a geographically distributed virtual enterprise.
At run time the lead company activates the distributed planning function whenever it receives a request for quotation or an order coming from a customer. The lead company must in fact activate its network and therefore it performs a distributed planning session to decide which tasks should be conveniently carried out by itself, if also supplier, which tasks should be better assigned to the other suppliers in the network, and which are the preferred partners to whom those tasks should be assigned.
Then, the lead company submits to each selected supplier the proposed tasks and the supplier replies with its estimation of execution time and cost. Those suppliers leading in turn a supply chain will carry out a similar planning activity with the involvement of further companies to fulfil the proposed tasks.
According to the received answers and applying its own planning policy rules the lead company selects the best configuration of the working supply chain for that customer order, and confirms the assigned task to each of the involved partners. The configuration is static if partners are predefined for the tasks to assign, it is dynamic if partners are selected from constellations of competing companies. The distributed planning session is concluded with the final response (e.g. quotation, order confirmation) to the customer.
This distributed planning process and its propagation across the ecosystem mirrors the present time-wasting human interactions but replaces them with a much more efficient way of finding out the desired solution. Moreover it can take into account unusual variables, such as transport times between manufacturing steps, and compare alternative solutions to measure their actual profitability. Of course its best performances come from networks where all the members are provided with the same, or equivalent, technology.
Later, during order execution, the distributed plan is put into action and the tasks are progressively carried out by the selected companies. Should a task be affected by problems (e.g. on delivery date) it will be re-planned to damp down the exception: the assignee company will be asked to revise its involvement (e.g. by choosing alternative routings) and if this will not be enough the lead company will transfer the residual perturbation on the next supplier until the problem will be (possibly) completely overcome.
Resource scheduling
On the other hand, in case the cluster member plays the mere role of supplier it has access to the functions that are needed to receive task proposals from the lead, simulate their execution to estimate times and costs, book the involved resources after the task has been formally assigned, revise the resource allocation for exception handling. This calls for an easy and efficient scheduler of internal resource that, normally, are just skilled persons and few machines or technologies.
Communication
The network behaviour is accompanied by an intense exchange of data and documents between the involved actors and with the customers. Then its efficiency can increase in relation to how communication becomes easy, seldom manual, and overcoming practical barriers such as those due to different formats and languages when a company belongs simultaneously to two or more networks.
The communication channels made available by the EBEST Operational Platform are basically two:
-Communication with partners. Whenever a lead and a member company must exchange a business document, e.g. a task assignment, the document is composed at the sender doc manager and transferred to the receiver doc manager.
-Import/export from/to the legacy system. If the document must be saved onto or, vice versa, shall be extracted from the legacy system (if any) of that company, the import/export service is activated.
Autonomic behaviour
Companies constituting SME networks are provided with limited resources that they cannot divert from the core business, then it is fundamental for them to adopt strongly automated planning, scheduling and exception handling solutions under the condition to maintain wide margins for policy customization. This can effectively be done with the adoption and adaptation of the autonomic model to the management of most network activities.
In an autonomic system every company renounces to control the system directly and assigns this role to a self-management process to which it imposes its own policies and decision rules. Under this condition the system presents the following four qualities:
-Self-configuration. This means automatic configuration of a subset of nodes in a certain zone of the network, and includes the addition of nodes and the creation and cancellation of relations between nodes in order to meet the defined requirements.
-Self-optimisation. This means automatic best allocation of resources in the single node to ensure its optimal behaviour. The algorithm is driven by performance objectives set during the self-configuration phase and by policies set by the node responsible.
-Self-healing. This means automatic discovery and correction of faults, triggered by events occurring in a single node or by changing requirements. As a rule self-healing propagates through the network and impacts on configuration and optimization.
-Self-protection. This means proactive protection from defaulting conditions. In SME networks the main cause of faults is the negative behaviour of certain nodes, then self-protection is mostly based on evaluation of past performances.
1.4 Pilot experiments
The performance of pilot experiments was foreseen to validate the EBEST approach and the relative software services with the twofold objective to demonstrate their effectiveness and collect hints for their best deployment to a wide population of SME-AGs and the associated companies. The following table summarises the demo scenarios that were subject to experimentation, grouped according to the EBEST components that each of them was committed to test.
1.4.1 Demos of Ecosystem Shaping
This section summarises the information about the pilot experiments carried out to test the Ecosystem Shaping component of the EBEST platform.
SIRRIS, Belgium
Two demos were identified in the framework of ITEA2 research projects. According to the ITEA2 NDA all participants and the research proposals in this description are anonymous. The ITEA2 brokerage days were held in Madrid, Spain, on February 1st and 2nd, 2012.
IDM -GAIA, Spain
This pilot experiment was organised by GAIA with respect to its relevant ecosystems so as to test in real life conditions and with real actors the EBEST collaboration framework and ICT platform, and specifically the Ecosystem Shaping software component.
1.4.2 Demos of Collaboration Portal
The list below shows the identified and planned actions, per SME-AG, to involve a critical mass of EBEST users, taking advantage of this part of the EBEST platform.
CCI KILKIS, Greece
The pilot experiment tested a case carried out following the 'Tendering process workflow' schema. The case was about assembling a proposal under the framework of NSRF - National Strategic Reference Framework, and specifically under the framework of ICT4GROWTH Initiative that aims to the support of SMEs to implement their development plans towards the provision of innovative products and added-value services.
OKISZ, Hungary
The title of this demonstration could be 'Adult Training for Unemployed People', meaning preparation of a proposal under the Hungarian National Development Plan Human Resource Development Program. Purpose of the pilot was testing and demonstrating the use of the Collaboration Portal, and although there are several opportunities to use this software environment, the demonstration used a tendering process as an example which entirely covered the proposal preparation process.
International
This demonstration could be entitled 'Process Oriented Knowledge Extraction' for the preparation of an EUREKA proposal. EUREKA is more than an organisation, it is an ambition: to become the leading platform for Research and Development (R&D)-performing entrepreneurs in Europe and beyond. EUREKA R&D is industry-led, applied, close-to-market with tangible results and visible benefits.
1.4.3 Demos of Operational Platform
The list below shows the actions identified and performed to involve a critical mass of users for this particular part of the EBEST ICT platform.
TEL&CO, Italy
The title of this demonstration could be 'Maintenance of ICT infrastructures', including both planned maintenance and on-demand interventions, by optimal scheduling (and re-scheduling) of weekly activities. TEL&CO is a company of 30 employees established in Modena, providing installation and maintenance of ICT infrastructures. TEL&CO is partner in the EBEST project, then it was the main driver of the Operational Platform requirement specification, design and validation.
Fashion Contract, Italy
The title of this demonstration could be 'Prototyping a clothing sample', which is the main service the Fashion Contract consortium offers to international buyers and large fashion industry, thanks to the sound skills and quality level that the members of this network all together can offer. Fashion Contract is a consortium of nine small-medium and micro companies, all working in the fashion sector and established in the Modena province. It was promoted and is continuously supported by CNA Modena as a living example of successful networking of independent entities joining forces to increase their market share.
CEDEM, Italy
The title of this demonstration could be 'Fuel station global service', which is the main service the CEDEM consortium providers to its customers (ENI in the first place). CEDEM was established in 1997 by 10 companies to survive in a market ever more populated by large global players, by offering a multi-disciplinary high quality service at reasonable price. The consortium is mainly involved in building and maintaining fuel stations, with timely and effective mechanical, electrical and hydraulic interventions.
SCCI, Slovakia
The Slovakian case presents rare but not least important operations that must be performed by a logistic company in case of a truck accident. This scenario is characterised by a fact that all the activities must be performed almost immediately after the accident, in order to minimize damages on the goods that are transported.
The main actor in this scenario is a primary logistic company, Alfaball, that must search for partners after its truck crashed, while dispatching an order to Apis company.
Potential Impact:
1.5 Potential impact and exploitation
The EBEST project had the ambition to introduce and deploy a new collaboration framework addressed to business ecosystems of small service companies in different EU countries, supported by a specific advanced software platform. It was expected that this could dramatically change the position of the target companies with respect to each other and improve their role in the local and global markets.
The results from the pilot experiments are showing the following although initial benefits:
-SME-AGs have the possibility to use a neutral and innovative support tool for shaping communities of potential partners as preliminary condition for their constitution as steady collaborative networks. This will impact on the competitiveness of networked companies and then on the survival and possible economic growth of entire ecosystems in the involved regions.
-Network leads have the possibility to achieve higher efficiency levels in coordinating the respective networks. The natural consequence is a stronger presence on the market and an increased trust in customers preferring direct and fast partnership with the lead SME on behalf of the entire network rather than managing dispersed relations with a number of individual suppliers.
-Network members have the possibility to collaborate with one or more networks or supply chains assuring fast responses to each of them without being affected by the need of adapting their legacy systems to the different leads. In other words they are finally in the condition to gain positions in the market according to their skills along with their reliability and collaboration efficiency.
1.5.1 Qualitative and quantitative benefits
The EBEST project impact will results in terms of facilitated daily work and improved company competitiveness in different aspects:
-Better image. The image that the single company proposes to its customers and partners is improved thanks to transparency of offer, timely service scheduling, as well as consistent cost and lead time estimation.
-Increased productivity. The adoption of simple but functionally rich software tools makes companies save time and cost related to non-core activities, misunderstandings and mistakes. Another positive impact comes from increased project management ability especially with respect to resource planning.
-Reduced conflicts. The adoption of clear and explicit coopetition protocols, and the possibility to easily communicate (and keep track of occurred events), reduces the risk of conflicts. Hence, the companies can focus better on their business and save effort presently wasted to recover problems.
-Access to wider markets. The new working conditions allow companies to extend their traditional niche markets and, possibly, address new markets. Disciplined collaboration methods favour the start-up of joint ventures that can lead to the constitution of larger (stronger) companies.
-New business opportunities. Although remaining basically linked to the local market, the access to the electronic market can extend dramatically the business opportunities of the target companies, especially when presenting their service capacity as a network on an entire business ecosystem.
A further beneficial element is the important extension of the knowledge base from which the target companies derive their decisions and strategies. To this purpose we expect the following main changes:
-Internal knowledge. In adopting the proposed solution each company will analyse its present practice and formalise procedures and documents. A by-product of this work is an increased awareness of what the company is, how it actually behaves and which habits should be discussed and revised.
-External knowledge. Another change comes from a broader view of similar or complementary companies acting in the same market. The possibility to examine their offers and practices produces, for the most dynamic companies, a clearer understanding of collaboration opportunities.
-Market trends. The third important aspect is the possibility, for associations, to derive indicators on the performances of the member companies and on market trends and drifts. If made available to the member companies, this knowledge can orient their investments and organisational improvements.
1.5.2 Social objectives addressed
The social objectives explicitly addressed by the EBEST project are summarised in the following points:
-Modernising the organisation of work. The project pursues the objective to offer small service suppliers a model for work organisation that allows them to face changing markets with an effective use of new technologies, a model that at present is only available to larger enterprises. This favours the introduction of a new entrepreneurial culture that facilitates the undertaking of joint initiatives and, eventually, the access to the electronic market.
-Promoting employment. A stronger position of small service suppliers on the market makes them identify new business opportunities and widen their offer. The first expected effect is therefore creation of new jobs that, very important, involve with no discrimination both genders thanks to the intrinsic variety of the intended services.
-Qualifying jobs. Moving the organisation of work of small companies from the present unstructured habit to a formalised, although simple, information flow management qualifies the existing jobs and adds new qualified jobs. In particular, improvements are envisaged in process management and introduction of advanced ICT tools.
-Emerging from the informal economy. Behind the high rate of unemployment and tax evasion recorded in Europe there is an informal economy hidden to all statistics. The project achievements will offer these companies the opportunity to dynamically collaborate and associate in smart networks provided they operate in a transparent and legal way.
-Increasing social cohesion. Even though not facing the wide problem of social inclusion, the project aims however at improving the relations between service suppliers and their customers in terms of clear regulations, explicit codes of practice, transparent times and costs. The consequent reduction of conflict is socially relevant.
-Improving inter-generation relations. The intended companies are often managed by the same persons that, years ago, started the business. In many cases, the present times are those when the old founder wishes to transfer the business to the new generation, and this raises enormous problems in terms of knowledge and relations with the market. The proposed solution captures part of this knowledge and formalises it into processes and disciplined transactions, thus providing a (partial) support to overcome the problem.
1.5.3 The EBEST system in action
The introduction of the EBEST solution at a large number of SMEs has a cost for the user companies that their reference associations can strongly contribute to limit. This critical role of SME-AGs is better understood by analysing the four main steps that they have to undertake to adapt the EBEST platform to the specific ecosystem conditions and to promote its adoption by the member companies.
Platform acquisition
Every SME-AG first customises the EBEST methodology by relating it to the respective ecosystem characteristics. It implies promoting the constitution of the community and involving the candidate user companies to choose the most suited organisational model and define in detail the rules of play. This is a task that absolutely needs to be carried out on the field by taking into account real life conditions.
Platform initialisation
Note that the EBEST platform resulting from the project is 'neutral' with respect to the single ecosystem knowledge. It is already localised on the regional language and provided with a general service sector ontology, but not characterised yet in terms of specific processes, rules and vocabulary of the single user network. What is made available to user companies must be preventively initialised to minimise the network member start-up effort.
Platform customisation
Should the initialisation work not be sufficient to cope with special needs of a certain network, the SME-AG is put in the condition to ask its reference ICT company or another third party to develop additional functions. Typical enhancements are customised user interfaces for order acquisition, graphical and reporting functions, integrations with other software packages or portals.
Platform instance configuration
When a user company can finally access its own workspace and use the functions of the (initialised and customised) EBEST platform, it must undertake in turn a parameterisation task aimed at configuring the preferred policies. They include e.g. criteria to choose the best plan to execute, the scheduling algorithm and the resulting best schedule, as well as criteria to recover idle times of internal resources and introduce margins on estimated times and costs.
List of Websites:
http://www.ebest.eu