Leila Saari & Katri Valkokari
Can joint offerings create novel business opportunities for software solution providers? Which are the roles of the actors providing a software solution together? What kind is the interaction between the actors? These questions were discovered in the SEED ecosystem project, where several large forest industry companies open their challenges to a group of software companies. In SEED context the companies with challenges are called use case owners and the software companies are solvers.
To discover the business opportunities and interaction between actors we have sketched different value network models from the anonymised industrial challenges in SEED. The two models identified are i) traditional bilateral supplier–customer relationships, and ii) multi-actor models based on system integration or open boundaries of the digital platform (Valkokari et al. 2020). Both models have strengths and weaknesses; the traditional bilateral supplier–customer relationships ensure effective co-operation, whereas multi-actor models could boost novel business models or even solve the challenges regarding so called vendor lock-ins.
Within the bilateral model, the Use case (UC) owner provides both requirements and data to the solver company. The selected solver company implements and delivers a digital solution and will receive a fee. The questions related to this model concern the sustainable earning logic of the solver and the return of investment for the use case owner. Traditionally this means a closed contract where the requirements are specified in detail from the beginning and the reward is fixed. In many cases the requirements will change and the software modifications will cause extra work to solver and extra costs to the UC owner. For the UC owner the total cost cannot be foreseen. Another invoicing model is to agree on the development phase reward (fee) and monthly service maintenance fee. These two models include reward for a separate development phase unlike a monthly or bi-annual service fee that is based on a Service Level Agreement (SLA). In addition to those the invoicing could be periodic and based on the business impact of the solution. This is often challenging as the business impact of the solution may not be transparent. Also the mutual understanding and agreeing on the impact KPIs is required.
Another option is a case with several solvers having complementary technical (software implementation) skills. Skills can vary from capability to provide raw data interfaces via analytics to user interfaces. In this model each solver has their own niche competence field and they are not competing with each other. How this could happen? Is it possible for an UC owner to pick a group of interacting solvers without any existing network or ecosystemic project where the solvers are in principle committed to solve the challenges of an UC company? How to interact with the group of selected solvers? How to share costs and profit among solvers? Shall one of the solvers become a coordinator intermediating both the requirements and rewards? In case the UC owner agrees bilateral with each solver company, who will grant the interoperability of separate sub-solutions? Usually an integrator is needed. Does the integrator act as the contact point to UC owner both delivering solution and sharing fees/ rewards? What is the basis for rewards of the sub-solution solvers as each sub-solution is necessary to deliver the total solution? Does the integrator carry total responsibility (with potential risks and profits) and purchase the sub-solutions from each solver? In this case it is just hierarchical bilateral subcontracting. Still, a total joint solution is delivered. Did it also create joint offering among the solvers? This depends mainly on the scalability and modularity of the solution as well as the agreement of ownership of the jointly created solution.
In case the sub-solvers deliver the data interfaces and intelligence (analytics etc.) the integrator does not to have access on the raw data (grey dotted line). Integrator creates the user interface to display the result or status. In case the solution includes a control loop, the feedback signal goes via the data interface included in the solution.
There are also cases where external data is needed for example from the suppliers of the UC owner. How the supplier(s) are engaged? Why would they grant access to real data? They need to foresee prospected sales, extended transparency or some other profit in the long run.
It is clear that the bilateral model does not create any joint offering between solvers /developers as there is only one. It might still bring the solver company to a new domain or even to international markets if the solution is scalable and general enough with modular interfaces. The multi-solver model delivers a total solution. Will it also became a joint offering and create new business still is open. Is the solution scalable?
Does the contracts allow to scale a solution to another company or another domain? Is a common (technical) platform the best solution to grant common interfaces, modularity and scalability for joint offerings? How to grant sustainable business in a multi-solver case? Which are the earning logics of solvers and ROI of UC owner? Further, can an ecosystem boost shaping the (international) markets for joint offerings?
Allee, V. (2002). The Future of Knowledge: Increasing Propsperity though Value Networks. Butterworth-Heinemann.
Partnering Resources. (2016). Mapping Business Ecosystems. Retrieved October 10, 2019, from Partneringresources website: http://partneringresources.com/business-ecosystems/
Valkokari, K. Valkokari, P. Kortelainen, H & Nyblom, J. (2020). Building business impacts of an Industry4.0 ecosystem through collaborative network settings between IT and forest companies. in Camarinha-Matos L. M. et al. (Eds.): PRO-VE 2020, IFIP AICT 598, pp. 1–12, 2020.
*There are i) Entities (balloons) that are either individuals, teams, groups or companies, and ii) Transactions (arrows) are exchanges between entities (in an ecosystem). For example payment, document, equipment, contract, schedule, workbook, advice, security, feedback, criticism, assurance etc. Transactions are either tangible (solid line) or intangible (dotted line),