Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Introduction

Internet and the web-based technologies have facilitated the collaborative approaches for innovation enabling the emergence of large networks of potential contributors (i.e. the so-called “crowd”). A high number of new innovative enterprises promoted innovation and allowed the collaboration of individuals and companies and the so-called crowdsourcing through open innovation web-based platforms [2]. The most recent innovation model is then the collaborative crowdsourcing (also referred to as the collective innovation), which integrates the crowdsourcing approach with the open innovation paradigm [3]. The collective innovation process involves three typologies of actors: (1) the individuals or companies forming the crowd (workers, solvers and know-how providers), (2) the individuals or client companies (seekers) and (3) the open innovation intermediary platforms (OIPs) which act as brokers between the crowd and the seeker (e.g. Innocentive, NineSigma, CrowdSpring, etc.). The problem to reach an agreement on the quality and quantity of work to be performed among outsourcers and suppliers and on the value of the knowledge provided by solvers is typical to all markets and is often resolved through negotiation. But negotiation is not easily practicable in all situations. In open distributed markets, the work performed by any single worker is often vanishingly small. For this reason buyers’ take-it-or-leave-it prices tend to predominate, and negotiations are rare [4]. Moreover open innovation and crowdsourcing requires web-based platform able to protect the intellectual property, but also to support the negotiation phase and the definition of terms of agreements in the contracts in order to motivate companies and individuals in participation both as seekers and solver and prevent disputes. A solution can came from patents, but patenting is costly and, in the collective innovation, the mechanisms for collecting and enforcing patent rights and licensing royalty income, are complex and impose high transaction costs. The user agreements and contracts should be used as a deterrent to opportunistic behaviour, while patents can be employed too late, i.e. in the final stages of the innovation process [1].

The objective of our research has been to design and to implement an innovative tool able to guarantee the solvers/providers that their ideas are protected in order to create a “win–win” scenario. The chapter presents the design (Sect. 2) and the implementation (Sect. 3) of the Open Contract Mechanism (OCM), an innovative web-based tool which allows innovation seekers and solvers to dynamically and simultaneously bargain the clauses and the characteristics of distinct innovation contracts in general open innovation and crowdsourcing collaborative environments. Finally, we draws conclusions (Sect. 4).

The Design of the Open Contract Mechanism

The design of OCM starts from a general open innovation and crowdsourcing scenario where an organization (from now on referred to as seeker) does not possess specific skills and technical knowledge (hereinafter referred to as know-how items) which are crucial for an innovation or for a part of NPD project (e.g. work, solutions to problems, patents, licenses, prototypes). Using the OCM tool the seeker can acquire these missing know-how items by posting a challenge inside an open innovation platform, where selected organizations and individuals (hereinafter referred to as solvers) are requested to submit bids to provide their work or know-how according to some conditions specified by the seeker. In particular, the seeker can specify the quantity demanded, the required quality, the terms of delivery, of warranty and of payment and clauses to safeguard possible intellectual property rights. Moreover, in order to select reliable solvers both in terms of owned know-how and economic performances, the seeker can impose agreements which strictly require solvers with suitable characteristics (special certifications, constraints in term of key financial ratios, etc.). To avoid solvers’ post-contractual opportunistic behaviour, the agreements can be enforced by an appropriate set of penalties for not fulfilling the related undertakings. There exist different ways of exchanging skills and technical knowledge between the seeker and the solvers: sell of existing patents, licensing, development and patenting of the design of a crucial input described in terms of abstract and general ideas and/or a fixed amount of money to solve a specific technical problem. Furthermore the OCM allows the seeker and the solvers to bargain the features of an innovation contract (contract amendments) by applying an open contract model.

Design of the Seeker and Solvers Client Side

The seeker clicks on OCM tool which displays two sections, respectively labelled “My contracts” and “My bids”. In the first section, the tool permits the seeker to create a new challenge to acquire know-how items. The challenge will allow the seeker to acquire all the specified know-how items from exactly one solver after a competition among all solvers invited by the seeker (possibly suggested by a suitable procedure based on the semantic engine of the OIP which selects potential solvers on the basis of the keywords representing the know-how items desired).

In the second section the seeker can:

  • Monitor the current round of a challenge which the seeker himself has created. Since it is still running, the challenge is referred to as an open challenge.

  • Look through a challenge created by him and that is ended. Since there are no more rounds, the challenge is referred to as a closed challenge.

  • On the solver side the OCM displays a section where the solver:

  • Attends the current round of an open challenge which a seeker has created and which the solver is taking part in.

  • Attends the amending phase of an open challenge which the seeker has created and which the solver is taking part in.

  • Attends the boarding phase (namely, the period when the invited solvers are accepting or rejecting the invitation to take part in the challenge) of a challenge and which the solver has been invited to take part in.

  • Can investigate whether there are or not new challenges (still in the boarding phase) which the solver could be interested in. The tool allows the solver to contact the seeker in order to be invited before the boarding phase ends.

Process Description

The OCM functioning can be divided in three phases: (a) the creation, (b) the boarding and (c) the negotiation. During the creation phase the tool allows the seeker to define:

  • The name of the challenge and a description of the required know-how items.

  • A bunch of keywords related to every know-how item.

  • The maximum number of rounds of the challenge. In every round the seeker and the solvers will bargain contract features. The challenge ends after a given maximum number of rounds. However, depending on the competition level among solvers, the challenge can end in a fewer number of rounds.

  • The maximum running time of any round of the challenge. Each round automatically ends after a given maximum time.

  • The timetable of the challenge, that is, the beginning and the end of the boarding phase, of the amending phase, and the beginning of the 1st round.

At the end of the creation phase the OCM asks the seeker to design the contract scheme (see Sect. 2.3). Once the contract scheme is definitively carried out, OCM allows the seeker to invite the solvers to take part in the challenge. When the list of all solvers to be invited is ready, the seeker can write a letter of invitation. Then, the tool automatically contacts all the solvers and communicates them the seeker’s letter of invitation. Then the boarding phase starts and the OCM tool waits for the solvers answering to the seeker’s invitation. The tool displays to any invited solver the list of the names of the open challenges which he has been invited to take part in and which are in the boarding phase. Once solver has clicked on the challenge he is interested in, the tool allows him to accept or to reject the invitation. At the end of the boarding phase, the OCM contacts the seeker providing the list of the solvers who have accepted the invitation. The tools don’t provide this list to any solver so as to reduce collusion among solvers. Subsequently the amending sub-phase begins the tools waits for the solvers submitting their amendments. When the amending phase is over the seeker decides which amendments can be accepted and which ones have to be rejected. Afterwards the tool communicates the definitive formulation of the contract scheme to any solver and no information about which solvers have proposed the submitted amendments (so as to reduce collusion among solvers). Then, when it is the time for the beginning of the negotiation phase, the tool contacts the solvers and informs them for the beginning of the first round. For any current round the tool waits for the solvers submitting their contract bids. If any solver has definitely carried out his contract bids (or quit the challenge), or the maximum running time of the round is over, the tool stops the current round. Then the tool compute a score for every submitted contract bid (see Sect. 2.4). At the end of the negotiation phase the tool communicates:

  • To the seeker, the details of the winning contract bid and of the solver.

  • To the solver who has submitted the winning contract bid, the details of the winning contract bid.

  • To all other solvers, the details of the winning contract bid and no information regarding which solver has submitted the winning contract bid (so as to reduce collusion among solvers).

Contract Design

The tool allows the seeker to design the contract schemes to acquire all the desired know-how items and provide their details. In particular:

  • The seeker uploads files which can be applied (inserting links in the contract scheme) to design the clauses (i.e. “.pdf”, “.avi”) and enclosed in the contract.

  • Any contract clause, which makes up the contract scheme, is a string.

Every contract clause can also be parametric. The seeker can insert parameters, that is, unspecified quantitative data of the clauses which every invited solver will specify through values selected among those the seeker has defined as feasible. In order to highlight which parameters are more crucial than others, the seeker assigns a weight to each introduced parameter. Therefore, if \( {\text{r}} \) is the overall number of parameters which characterize the contract scheme and \( w_{i} \ge 0 \) are the weight associated by the seeker to parameter \( i \) for \( i = 1, \ldots ,r \); the weights decided by the seeker are subject to the constraint \( \sum\nolimits_{i = 1}^{r} {w_{i} } = 1 \). For any parameter, the seeker has to specify if the parameter is ascendant (descendent), in the sense that the higher (the lower) the parameter, the better the resulting contract scheme for the seeker. The seeker has also to specify which values can be taken into account for it (the feasible values for the parameter); to do this, the seeker associates to any parameter \( i \) a lower bound \( lb_{i} \), an upper bound \( ub_{i} \) and a minimum step \( ms_{i} \). Consequently, if parameter i is ascendant the tool will show in the drop-down menu of the parameter all and only these values (ordered from the lowest value to the highest):

$$ \begin{array}{*{20}c} {lb_{i} + 0 \cdot ms_{i} } \\ {lb_{i} + 1 \cdot ms_{i} } \\ {\begin{array}{*{20}c} \vdots \\ {lb_{i} + f_{i} \cdot ms_{i} } \\ \end{array} } \\ \end{array} $$

where \( f_{i} = \frac{{ub_{i} - lb_{i} }}{{ms_{i} }}. \)

If the parameter is descendant the tool will show in a drop-down menu of the parameter all these numbers (ordered from the highest value to the lowest):

$$ \begin{array}{*{20}c} {ub_{i} - 0 \cdot ms_{i} } \\ {ub_{i} - 1 \cdot ms_{i} } \\ {\begin{array}{*{20}c} \vdots \\ {ub_{i} - f_{i} \cdot ms_{i} } \\ \end{array} } \\ \end{array} $$

where \( f_{i} = \frac{{ub_{i} - lb_{i} }}{{ms_{i} }}. \)

For example, let us assume that the know-how item is the production of a specific component which has been designed by capital company Solinnovation. The component is critical, but the expected demand is highly uncertain. The seeker Solinnovation proposes a challenge to negotiate the risk sharing between the seeker and the solver who will produce the component. Solinnovation defines a contract scheme (Fig. 1), where Clause 7 contains links to some enclosed files, while clauses 12 and 13 are parametric (in the example all and only the parameters of the contract scheme are those proposed by the seeker in these two clauses).

Fig. 1
figure 1

Example of a contract scheme

Bid Score Calculation

The score of a bid is computed as follows:

  • Let \( l \) be the number of solvers who have submitted bids in the current round. Let \( d_{k} \) be the number of contract bids submitted by solver \( k \) in current round for \( k = 1, \ldots ,l \), and let \( d = d_{1} + \cdots + d_{l} \) be the overall number of contract bids submitted by all solvers in current round. Let \( k\left( j \right) \) denote the solver who has submitted bid \( j \). Every contract bid j for \( j = 1, \ldots ,d \) consists of an ordered list of values \( \left( {v_{1,j} , \ldots ,v_{r,j} } \right) \), where any \( v_{i,j} \) for \( i = 1, \ldots ,r \) is the value offered, by solver \( k\left( j \right) \), in contract bid j for parameter i. First, the OCM computes for \( i = 1, \ldots ,r \) both average \( m_{i} \) and standard deviations \( \sigma_{i} \) of the values offered for parameter \( i \) by all solvers. For \( i = 1, \ldots ,r \), the OCM computes:

$$ m_{i} = \frac{{\mathop \sum \nolimits_{j = 1, \ldots d}^{{}} v_{i,j} }}{d}\quad \;\quad \sigma_{i} = \sqrt {\frac{{\mathop \sum \nolimits_{j = 1, \ldots d}^{{}} \left( {v_{i,j} - m_{i} } \right)^{2} }}{d}} $$
  • The OCM defines the new weights of the parameters (\( \overline{\text{w}}_{\text{i}} = {\text{w}}_{\text{i}} \) if parameter i is ascendant and \( \overline{\text{w}}_{\text{i}} = - {\text{w}}_{\text{i}} \) if parameter \( {\text{i}} \) is descendant).

  • Then, the tool sets the score of contract bid \( {\text{j}} \) equal to:

$$ sc_{j} = \mathop \sum \limits_{i = 1}^{r} \overline{\text{w}}_{i} \frac{{v_{i,j} - m_{i} }}{{\sigma_{i} }} $$
  • Among all bids which have been stored so far (i.e. from the beginning of the challenge until this round), the tools select as winning the contract bid with the highest score (ties are broken randomly).

The Open Contract Mechanism (OCM) Tool

The OCM has been implemented as a standalone web-based tool which can be integrated inside an OIP. The overall architecture is depicted in Fig. 2.

Fig. 2
figure 2

The open contract mechanism overall architecture

OCM has been implemented using a web service approach where a number of HTTP verbs have been developed implementing the basic operations that are needed in order to create, manipulate and negotiate contracts. The communication between the client and the server through HTTP is performed with the exchange of appropriate JSON documents. Everything in the OCM data model is built around the concept of the contract. Inside the contract, a number of metadata are defined, e.g. information regarding the seeker, a list of solvers that the seeker decides to call to participate and a number of parameters that constitute the negotiable values of the contract. These entities are related to the contract creation and boarding phases. Finally, for the modelling of the negotiation phase, the concept of round is introduced. The final element is the scheduler. The various phases and the rounds of the negotiation are defined by a starting and ending time provided by the seeker. At the beginning of each round specific actions have to be performed, e.g. the change of the contract status from creation to boarding and from boarding to negotiation. These kinds of actions are performed by the scheduler in pre-defined time intervals based on the values provided by the seeker during the contract creation. A relational database is used to store the jobs. The current version of the OCM consists of the three distinct phases described below.

Creation Phase

During this phase the seeker defines all the defined parameters of a contract and invites the potential solvers who would participate in the negotiation of the specific contract. The contract creation phase consists of four distinct sub-phases:

  1. 1.

    Creation of a new contract with a title and a brief description (Fig. 3–left).

    Fig. 3
    figure 3

    Contract creation, definition of parameters and of the number of rounds (screenshots)

  2. 2.

    Definition of an arbitrary number of parameters that will be negotiated for the contract together with their attributes (Fig. 3–center).

  3. 3.

    Selection of the potential solvers who will participate in the negotiation.

  4. 4.

    Definition of the number of rounds the negotiation phase will have, when the boarding phase will start and end and the duration of each negotiation round.

Boarding Phase

During the boarding phase, when the user submits the newly created contract, two scheduled jobs are created: one for the initialization of the phase and one for its conclusion. Both the date and time for these two states are provided by the seeker during the creation phase. When the scheduled job is fired, a number of e-mails are sent to the candidate solvers. The status of the solver has three potential states, (a) pending, (b) accepted and (c) rejected. Initially the system assigns the state pending. By either accepting or rejecting the participation, the user alters the status either as accepted or rejected. At the end of boarding phase, another scheduled job is fired and the invited solvers are scanned. If their status is still in pending state, it is changed into rejected, while if no one accepted the invitation, then the current state of the contract is changed into closed and the whole procedure ends. If one or more potential solvers have accepted the invitation, the status of contract changes into negotiation.

Negotiation Phase

During the negotiation phase the actual process of negotiating a contract is performed. Initially the seeker is able to create a new negotiation round (Fig. 4–center). When this happens a new scheduled job is created and scheduled using the round duration provided by the seeker at the creation phase. During the creation of a new negotiation round, notifications are sent to the solvers so they can submit new offers for the current negotiation round. The solvers can create new offers using the OCM interface. After deciding about the values of each parameter, they are able to submit their offers (Fig. 4–right). At the end of the round the scheduled job is fired and a number of actions occur; initially the system parses all the offers together with any past winning offers and calculates the various scores based on the scoring algorithm (see 2.4).

Fig. 4
figure 4

Notification for participating in the negotiation of a contract, initiation of a new negotiation round and creation and submitting an offer (screenshots)

On the basis of these scores the winner is retrieved and then the system sends e-mails and notification to both the seeker and the solvers. The mail to the seeker contains all the details regarding the last negotiation round together with the information about the current winner. The solvers receive an e-mail which contains only the information of the winning contract but without the credentials of the winning solver. At this point the seeker can initiates again a new negotiation round unless all the solvers have left the negotiation phase: in this case the winner is found and the contract status changes to closed.

Conclusions

The open contract mechanism can be implemented inside open innovation web-based platforms, or directly used by the companies. OCM can become a powerful tool for evaluating offers and determining the winning one, and therefore guaranteeing valuable binding contract clauses. Moreover it can enhance confidence in decision making and flexibility in dealing with negotiation issues developing the company’s ability to confront with the complexity of the collective innovation in open innovation web-based platforms. On the basis of several simulations run up to now using the software prototype developed, we found improvements achieved in negotiation performance in terms of reduction of purchasing costs and increase of quality and quantity of know-how items acquired.