0049-(0)611-59057-0 [email protected]

Which software to choose for Open Innovation

This article discusses which software is best suited to different Open Innovation (OI) approaches. The subject is particularly interesting since, on the one hand there are more and more companies that embrace OI, and on the other, there are a lot of software solutions on the market that have proven productive.

The article first looks at the different OI approaches companies are using and which types of software support internal processes, and the interaction between the Open Innovators and the co-innovation community. It then examines in depth why a large German company has selected a not-so-obvious software solution for R&D-driven Outside-in OI.

Any company that is serious about implementing OI eventually will get to the question about which software to use in order to support the corresponding processes, and the interaction between internal and external innovators. Currently OI comes in many shades and, depending on which OI approach your company is pursuing, there are various types of software that could be appropriate.

Inside-out OI: Minimal software support

In OI Inside-out, companies try to exploit the value of Intellectual Property (IP) that is not being actively used or does not play an obvious role in deterring competitors. Statistics say that some 40-90% of a company’s IP is in this category. Within the OI paradigm exploiting the value in this kind of IP will involve external market paths such as licensing, Joint Ventures and Spin-Offs.

Internal processes are supported by databases in which IP is kept and managed. However, I cannot identify a software solution that is being used on a wide scale, for interaction between open innovators and the external community. Interaction mostly takes place person-to-person with little software support.

Consider IBM, seen by many as global benchmark for this type of OI. IBM spends more than USD 5 billion on R&D annually, holds more than 60,000 patents, and generates some USD 2 billion per year in licence revenue. How does it do this? IBM’s R&D labs include what they call Industry Solutions Labs. These labs are the drivers of Inside-out OI. Their mission is to ensure early involvement of customers and business partners in order to identify and exploit emerging business opportunities. Around 25% of IBM’s Zurich lab staff work with customers and business partners; they run more than 400 workshops per year, which generate around 100 innovation projects a year.

One notable exception regarding software for this OI approach is www.yet2.com, which is operated by a Web company originally funded by chemical giant DuPont and others.

Outside-in OI: Focus of OI software solutions

The situation is different for outside-in OI. In this approach, companies take external ideas and then treat them as if they were internal ones. In practice, companies pursue this type of OI in two ways: customer-driven ‘crowdsourcing’ (i.e. ideas from customers, co-creation with customers); and R&D-driven.

Interestingly, all of the software used by leading companies in this context is Web-based. This supports the argument recently put forward by Ehsan Ehsani in a recent article.

Customer-driven Outside-in OI: Numerous crowdsourcing software providers

A quick search on Google on the terms ‘crowdsourcing’ and ‘software’ yields some 4 million results. The software vendors in this type of OI come from six backgrounds:

  • Software companies that originally developed software for idea management;
  • Web 2.0 social software companies that migrated to crowdsourcing;
  • Online communities that leveraged their proprietary technology outside the original community;
  • Software companies that started out with what today is called crowdsourcing;
  • Applications within existing social networks (e.g. Facebook);
  • Intermediaries that focus their business model on crowdsourcing.

Selection of the most appropriate software platform depends firstly on the focus of your search for external ideas and the associated level of confidentiality. Is your company looking for optimization potential in existing products, line extensions or radical innovations? Secondly, selection of a platform depends on the type of crowd you want to attract (although this should be seen, at least partially, in conjunction with the first aspect). Is your company looking for open/semi-open ideation communities, a broad public community, or a carefully selected closed community?

R&D-driven Outside-in Open Innovation: eSourcing software might be the right choice

In R&D-driven OI, researchers and developers look for scientific or technical solutions to issues on the current R&D agenda. Looking at global benchmarks, we find that this type of OI is practised in two variants. firstly, in a rather open approach where potential co-innovators have low barriers to membership of the community (e.g. Procter&Gamble’s connect+develop), secondly as a closed community in which confidential, not-for-public information about innovation challenges is shared.

I recently concluded a project with one of Germany’s largest companies, focusing on the second variant. In this project, a ‘large’, closed and global co-innovation community had to be built up. The rationale for this approach was that one-step seeker/solver-processes in a confidential environment would provide higher potential effectiveness and efficiency than an approach where individual OI challenges were open to a global audience and in a second step the best out of a huge number of proposals had to be picked. This approach required that the individual OI challenges contained extensive background information. Consequently, in order to protect this confidential information, a closed community had to be set up.

In selecting the software platform we first established the high level requirements. These were:

  • Security: proven security and robustness
  • Communication: easy communication with participants for a specific OI challenge; easy submission of proposals; legally accepted storage of all communication (due to IP considerations)
  • Workflows: support for processes via workflows, e-mail reminders, etc.
  • Competence areas: classification of community members by competence areas (to facilitate the search for suitable participants)
  • Proposal management: easy capturing of structured and unstructured information; formalized evaluation of proposals; repository of submitted proposals (for later use)
  • Performance Management: statistics and reports; automatically generated dashboards
  • Integration into existing stage gate process, supplier database, ERP system and corporate Web site
  • Usability: easy handling for internal and external innovators.

When we analysed these requirements we made an interesting finding: with some level of abstraction, all of these requirements are provided by solutions for strategic, Internet-based procurement (eSourcing).

So, in this case, the client decided to take an existing in-house eSourcing software platform and customize it to the requirements of this particular OI approach. Measured in terms of Total Cost of Ownership (TCO) and deployment time, this was a clever decision.

Looking back at the implementation of the software I think there are two important points to keep in mind:

  • Plan for learning cycles
    No standard software – especially not one to be used in such a dynamic scenario as OI, will be perfectly fitted to the business requirements in the first shot. Moreover companies that have implemented OI have found that the underlying processes will change as the breadth and depth of implementation increases. Based on experience it is wise to plan for several versions that ultimate will yield the perfect software solution.
  • Be prepared for communication challenges
    In defining the details of the software solution, at least three different parties will be involved, each of them with a different view and a different language: R&D experts, deeply involved in the technical / scientific challenges they want to be solved; the management of the implementation project interested in having clearly defined roles and processes; and the software provider, who is deeply rooted in the standards set by his software. Based on experience you should expect some “translation efforts” in order to get these parties aligned.