Digital Marketplaces Unleashed
Page 74
In order to reflect the fact that each of the selected business models has an impact on the setup of platform governance mechanisms, we included this dimension as well. Nevertheless, even similar business models like Airbnb and Uber, delivering services and described as shared economy, are different in terms of services like accommodations and transportations. This is also true for WeChat and Facebook. While WeChat concentrates on the digital market of mobile Social Networks, Facebook tries to cover the classical online‐ and the mobile market. In order to draw correct conclusions, we recommend comparing not only similar business models but also similar products and services like the App‐Store and the Play‐Store.
In general, all dimensions show tradeoffs if implemented differently. Especially interesting are the conclusions illustrated in Fig. 47.2. Nevertheless, it is important to stress that the figures and graphs are only a first conclusion of the multiple case study analysis. In order to reach significance, it is crucial to gather more concrete facts supporting our claims.
47.5 Conclusion
Multi‐sided platforms are continuing to disrupt long‐established markets. Therefore, it is crucial to get a deeper understanding of how they work and which factors are of importance. The centerpiece of each MSP is the platform governance, which orchestrates the interaction between the different parties. They describe for example if the overall structure is organized centrally or decentrally, which resources like APIs or SDKs are used or what restrictions are in place to control the openness and the products and services offered on the platform. While the literature offered already theoretical insights about those mechanisms [1, 6, 22, 23], the practical application and tradeoffs were not examined in closer detail. Therefore, we conducted a multiple case analysis including seven different MSPs. All results were analyzed due to theoretically known platform governance mechanisms. The resulting table highlights for example that both, centrally and decentrally organized platforms exist. There are also different degrees of openness or in‐ and output‐control. Influence factors might be the underlying business model or the current state of maturity of the MSP. Based on these results we observed different tradeoffs of implementing platform governance mechanisms differently. One hypothesis deriving from the case study is that the degree of platform control correlates in a non‐linear relationship with the platform monetization. No control provides too much power to users or third‐party developers, while too much control leads to a narrower range of products and services. Therefore, this article helps to understand how platform governance mechanisms are implemented by currently successful MSPs and which tradeoffs different implementation causes. Moreover, practitioners may learn from already established digital marketplaces and can transfer this knowledge to other industries.
References
1.
J. Manner, D. Nienaber, M. Schermann and H. Krcmar, “Governance for mobile service platforms: A literature review and research agenda,” GOVERNANCE, vol. 1, 2012.
2.
F. Weigmann, “AXOOM is developing into a sought-after business platform for the manufacturing industry,” AXOOM GmbH;, 2016. [Online]. Available: http://www.trumpf.com. [Accessed 19. 4. 2016].
3.
K. J. Boudreau and A. Hagiu, “Platform rules: Multi-sided platforms as regulators,” in SSRN 1269966, 2008.
4.
Forbes, “Alibaba Claims Title For Largest Global IPO Ever With Extra Share Sales,” [Online]. Available: http://www.forbes.com/sites/ryanmac/2014/09/22/alibaba-claims-title-for-largest-global-ipo-ever-with-extra-share-sales/. [Accessed 1. 7. 2015].
5.
D. S. Evans, “Governing bad behavior by users of multi-sided platforms,” Berkeley Technology Law Journal, vol. 2, no. 27, 2012.
6.
A. Tiwana, B. Konsynski and A. A. Bush, “Research commentary-Platform evolution: Coevolution of platform architecture, governance, and environmental dynamics,” Information Systems Research, vol. 21, no. 4, pp. 675–687, 2010.Crossref
7.
A. Hein, M. Schreieck, M. Wiesche and H. Krcmar, “Multiple-Case Analysis on Governance Mechanisms of Multi-Sided Platforms,” in Multikonferenz Wirtschaftsinformatik, 2016.
8.
v. M. Alstyne, G. Parker and P. S. Choudary, “6 Reasons Platforms Fail,” 2016. [Online]. Available: https://hbr.org/2016/03/6-reasons-platforms-fail. [Accessed 1. 8. 2016].
9.
R. K. Yin, Case study research: Design and methods, Sage publications, 2013.
10.
V. Fautrero and G. Gueguen, “The Dual Dominance of The Android Business Ecosystem,” Understanding Business Ecosystems, 2013.
11.
M. B. Goodman and S. H. Dekay, “How large companies react to negative Facebook comments,” Corporate Communications: An International Journal, vol. 17, no. 3, pp. 289–299, 2012.Crossref
12.
M. Grant, “Uber Now Integrates With United And Hyatt Apps,” 2014. [Online]. Available: http://www.forbes.com/sites/grantmartin/2014/08/22/uber-now-integrates-with-united-and-hyatt-apps/. [Accessed 1. 7. 2015].
13.
Facebook, “Facebook homepage,” [Online]. Available: https://www.facebook.com. [Accessed 1. 7. 2015].
14.
V. Champoux, J. Durgee and L. McGlynn, “Corporate Facebook pages: when ‘fans’ attack,” Journal of Business Strategy, vol. 33, no. 2, pp. 22–30, 2012.Crossref
15.
F. Stutzman, R. Gross and A. Acquisti, “Silent listeners: The evolution of privacy and disclosure on facebook,” Journal of privacy and confidentiality, vol. 4, no. 2, 2013.
16.
K. S. Staykova and J. Damsgaard, “Platform Expansion Design as Strategic Choice: The Case of Wechat and Kakaotalk”.
17.
D. Tilson, C. Sørensen and K. Lyytinen, “Change and control paradoxes in mobile infrastructure innovation: the Android and iOS mobile operating systems cases,” in 45th Hawaii International Conference on System Science (HICSS), 2012.
18.
B. Pon, T. Seppälä and M. Kenney, “Android and the demise of operating system-based power: Firm strategy and platform control in the post-PC world,” Telecommunications Policy, vol. 38, no. 11, pp. 979–991, 2014.Crossref
19.
D. Pagano and W. Maalej, “User feedback in the appstore: An empirical study,” in 21st IEEE International Requirements Engineering Conference, 2013.
20.
B. Tan, S. L. Pan, X. Lu and L. Huang, “The Role of IS Capabilities in the Development of Multi-Sided Platforms: The Digital Ecosystem Strategy of Alibaba. com,” Journal of the Association for Information Systems, vol. 16, no. 4, pp. 248–280, 2015.
21.
E. Isaac, “Disruptive Innovation: Risk-Shifting and Precarity in the Age of Uber,” 2014.
22.
M. Schreieck, M. Wiesche and H. Krcmar, “Design and Governance of Platform Ecosystems – Key Concepts and Issues for Future Research”.
23.
J. Manner, D. Nienaber, M. Schermann and H. Krcmar, “Six Principles for Governing Mobile Platforms,” in Wirtschaftsinformatik, 2013.
Further Reading
24.
A. Hagiu and J. Wright, “Multi-sided platforms,” International Journal of Industrial Organization, 2015.
Footnotes
1This chapter is based on a publication at Multikonferenz Wirtschaftsinformatik 2016: Hein, A.; Schreieck, M.; Wiesche, M.; Krcmar, H. (2016). Multiple‐Case Analysis on Governance Mechanisms of Multi‐Sided Platforms. Multikonferenz Wirtschaftsinformatik (MKWI), Ilmenau.
2We thank the German Federal Ministry for Economic Affairs and Energy for funding this research as part of the project 01MD15001D (ExCELL).
© Springer-Verlag GmbH Germany 2018
Claudia Linnhoff-Popien, Ralf Schneider and Michael Zaddach (eds.)Digital Marketplaces Unleashedhttps://doi.org/10.1007/978-3-662-49275-8
_48
48. Transformation Not Completed – Identify Additional Business Opportunities by Digital Navigation
Karsten Schweichhart1 , Uwe Weber2 and Alexander Hildenbrand1
(1)Cross-Business-Architecture Lab, Bonn, Germany
(2)Detecon International GmbH, Munich, Germany
Karsten Schweichhart (Corresponding author)
Email: schweichhart@cba-lab.de
Uwe Weber
Email: uwe.weber@detecon.com
Alexander Hildenbrand
Email: hildenbrand@cba-lab.de
48.1 Digital Navigator
When Jack Welch says, “Willingness to change is a strength, even if it means plunging part of the company into total confusion for a while” this is especially valid for the Digital Transformation. When starting planning and transforming your business into a digital one this time frame of confusion should be as short as possible, because businesses today are faced with fast changing market conditions. From our experience with companies of different size and industry over the last years the adapted approach of “concurrent planning” from engineering will help to reduce the time from understanding demands and strategy definition until the products are available on the market.
People involved in a concurrent planning process moved from hierarchical organization structure into a project organization and collaborate based on a common language to overcome misunderstanding across different expertise. Capabilities in terms of a functional decomposition of relevant tasks within a specific enterprise can provide such a common language. The description of a capability comprises three dimensions: What are the processes and information that are needed for the capability?
What are the skills and competencies people provide to work in these processes?
And what is the technology that supports or drives the work within this capability?
Here is an example how to apply this approach in a manufacturing company and why this helps to avoid confusion about what Digital Transformation means. Let us have a look at the capability “Production Management” and one level deeper at capability “Worker Guidance”. Customers expect individual products today even when they are produced at an assembly line. Guidance of workers at the assembly line about what is the next part and in which tray it can be picked up will change due to digitalization. Probably today, workers are supported with parts lists and configuration drawings for the product they have to assembly next (technology dimension). Tomorrow, workers are guided by a pick‐up‐by‐voice solution, where the workers wear headphones and the information about parts and their location will be brought to the worker by a computer voice. The information provided is the same as before, but the provisioning is now digital to support an optimized process. There will also be a change in the worker’s competencies. This example shows how powerful a capability‐based planning approach as used in concurrent planning will lead to a lean and effective digital strategy and transformation project portfolio without any confusion.
Bringing this small example on a higher level, we asked ourselves, what is the difference in terms of capabilities we need for digitalization? How much change is necessary to become sustainable successful in a digital business world? Is it possible to share experience about patterns that worked at different companies? With the strong will to find the answers, some leading companies from Telecommunication, Automotive, Process Industry and High Tech as well as a consultancy company found together at Cross‐Business‐Architecture Lab to develop the Digital Navigator.
The six digital capabilities represented in the Digital Navigator (s. Fig. 48.1) close the gap between business and technical capabilities as the central structure to align strategy demands and solution supply.
Fig. 48.1Digital Navigator. (Cross‐Business‐Architecture [1])
Here is another example. Imagine your business strategy written in natural language and available in a more detailed form over the intranet. Are you sure that everyone in your company knows exactly how to decide about transformation programs according the strategy? To make strategy explicit you can detail it using a driver tree. Map leafs of this tree expresses strategic demands onto to capability maps. More precisely, map the business demands onto the business capabilities, ask yourself what digital capabilities you need to enable the business and then think about the technical capabilities, which comprises also the real fancy staff like glasses for virtual reality. With this structured and consolidated view on demands, it is easier to find the right architecture and solutions. You can also start on the opposite site analyzing the relevance of a specific solution for a future scenario.
But what do these Digital Capabilities look like?
The top‐level view on Digital Navigator comprises three circles. The grey one describes six digital capabilities that have been developed and proven by the partners within the Cross‐Business‐Architecture. More than that, the results of an empirical study [2] underline the relevance and completeness of these digital capabilities as well as the maturity across industries within the German‐speaking countries at the time the study was conducted. The first blue circle expresses the so‐called digital dimensions. Digital Transformation should always consider the complete value chain in order to provide best possible customer experiences. But the three dimensions “Customer and Partnering”, “Products and Services” and “Enterprise” may be managed with different sub goals what means different patterns of digital capabilities. At the end, all transformation programs should lead to more revenue or less costs. That’s why the three circles can be turned against each other in order to find different patterns for different goals that lead to more revenue or a reduction of costs. To develop this is an ongoing process and Life‐Cycle‐Management is managed by Cross‐Business‐Architecture and Detecon International.
48.2 Start Transformation: Use Your Data
To explain the usage of the Digital Navigator in more detail we introduce a scenario of a producer of home appliances that has been successfully transformed in a certain area. This is one of several possible approaches to apply this framework.
The regarded company produces washing machines among other things. From time to time, a service call from a customer requires sending a technician on site to fix a problem. If the problem is caused by a broken component, the technician has to order a spare part and come on site once again. In the meantime, the washing machine cannot be used.
The optimization of this scenario was based on the following idea: how can the number of visits at the customer site be reduced to one at most times. This would increase customer convenience and reduce costs. In context to the Digital Navigator, this use case addresses the cost effects in the products and services area for improvement.
To get closer to a solution, they focused on the information that they have from the customer and information they already have from calls of other customers up to now. To describe the transformation let’s have a look at the process so far (s. Fig. 48.2 – left side).
Fig. 48.2Service process transformation
A customer talks or sends a message to the service center and describes the failure of his washing machine. In general, the customer does not know the root cause of this failure. So he has to describe what happened and what can be seen from outside. At the service desk, the information is collected and described in a structured incident request by a service agent. This information will be sent to a technician who will be scheduled for a customer visit. The technician examines the failure on site and fixes the failure if possible. If a component is broken and no spare part is available by accident, he has to order it and arranges a new appointment. So the described process could cause multiple visits and increases service cost.
The approach that the company already implemented to improve this process is based on the information they have from other service calls or incidents. If it is po
ssible to match a new incident with an existing and already fixed one, some activities can be done before the technician will be sent out to the customer.
For that purpose, they implemented a data mining system for analyzing the details of the current incident and comparing with similar requests of the past. If there is a match, the corresponding spare parts are send back to the Service Management System. If there are no corresponding spare parts, this could be an indication that there is no broken component. A rule framework in the Service Management System then determines based on specific rules whether a spare part should be ordered and when a visit could be scheduled.
Because of the probability that a certain component is required, the ordering can be done automatically. It is also possible that the time schedule of the technician can be updated and the van be loaded automatically.
Based on this extended software landscape the former process has been transformed to the following (see Fig. 48.2 – right side):
The customer calls the service desk and describes the failure. The service agent collects all provided information in a structured incident. In the next step, the incident is sent to the data mining system to be analyzed and compared with older incidents. If there is a match to an existing incident, the information about how the failure was fixed will be sent back including a description of the spare parts that were needed. Based on the specific rules in the Service Management, the system decides if spare parts are needed and then automatically orders them. According to the availability of the spare part and the service technician, a time schedule for the next visit to the customer is planned. The van of the assigned technician will also be loaded automatically. Most of these steps now can be done automatically.