Published on 02/21/2017 | Strategy
Usually, after an idea has passed the first quality gate, a small team is assembled to further refine and validate the idea, with the goal of creating a concrete business case document that can attract funding. Typically, a small team works on an IoT business model for a couple of weeks or even months, before it is presented to the investment committee to decide on. If all IoT initiatives follow a similar IoT business model approach, it makes it easier to compare and prioritize the different proposals.
At Bosch, the project teams developing IoT business models include employees with multiple competencies, such as domain experts, business model coaches, and marketing consultants. Having both this organizational embedding, and a leader that is passionate about the idea from the start, is crucial. Another success factor is the structure of “podular” organizations. Silke Vogel explains what this means: “Highly motivated and energized team members join autonomous units. They have more decisive powers, can act in an “intrapreneurial” way, close to the customer, while also benefiting from the established structures and competencies of a large company. This makes them faster and more efficient.”
As established business model canvases don`t really address the specifics of IoT business models, a team at Bosch has worked on developing an IoT-specific approach to business model development. Veronika Brandt, manager of this team at Bosch Software Innovations: “Addressing IoT-specific aspects, like the intricacy of a partner ecosystem with complex value chains, is extremely important in the IoT. This means that the business model needs a clearly articulated partner value proposition. Another IoT-specific aspect is the use of data derived from connected things, and the services built on top of this information. Because of this, we have developed the IoT Business Model Builder – an extension of the Osterwalder canvas. In the Opportunity Management phase, it serves as a guide through the process of defining the components of the business model. Usually, the input is the formulated idea and the output is a business case.”
The main components of the IoT Business Model Builder are defined in the next sections. Just like when building a house, we start at the bottom:
• Strategic Embedding: This phase sets the foundation of the business model and ensures alignment with the IoT strategy, or the IoT vision of the enterprise. It defines the purpose of the business model in the mission statement and outlines its mid- and short-term goals. Performing “future proofing” should indicate how the business model intends to deal with future challenges. This includes thoughts on how to foster the development of differentiators, such as core competencies (making it harder for the business model to be imitated) and responsiveness to future change. The strategic embedding also contains a brief description of the offering.
• Value Proposition: To enhance the attractiveness of the offer for customers, the tried-and-trusted approach of segmenting target groups, formulating a value proposition, and defining customer channels (interfaces to the customer at all touch points in the customer journey, from awareness to after sales) can be employed. Because IoT solutions often depend on a strong partner ecosystem, the value proposition has to respect partners in the same way as customers. Firstly, unless partners are not already named (by existing strategic partnerships or relations, for example), their roles have to be defined (information provider, broker, operator, for example). Then, we need to define “what’s in it for them,” outlining the partner value proposition for each partner role (or candidate). Finally, the partner channels can be defined, as “other partners,” for example (it’s even possible for the customer to be defined as a channel).
• Customer Journey: Describing the end-to-end solution from the customer’s point of view helps to emphasize the features of the offering that the customer finds relevant. Here, it is relevant to focus on the actual user/consumer of the offering, irrespective if this is your customer or the customer´s customer (in B2B2C solutions). Defining the customer journey has another positive side-effect: It makes sure all relevant channels to the customer have been identified, and these serve as customer touch points at every stage of the journey, from awareness to after-sales.
• Value Added: Once the solution has been defined, the value added can be illustrated. Core element of the value added is the stakeholder network, usually illustrated in a flow chart that visualizes relevant parties (own enterprise, partners, customers) as nodes, and value and service streams between these nodes. Constituting elements of the network are the capabilities of the parties: They are a mix of technology, resources and know-how they can bring in to support the solution. The capability assessment helps defining which nodes are best suited to deliver certain services. Once the network has been defined, it should be captured for each node what connected things this node is managing, which value adding information it delivers (or derives from connected things), and which services it delivers.
• Business Case: Once the value added has been defined, it is easy to calculate the business case: The most cost-relevant aspects are indicated in the value-added phase and the estimated revenue should be taken from the customer and partner value proposition. A relevant and fair approach is to calculate the total costs of ownership (TCO) for the solution across all parties involved in the network, and to then define the return model by allocating the returns among the stakeholders in a fair manner. This requires cost transparency across all parties involved, once again underlining the importance of trust and strategic partnerships in the IoT ecosystem. There are several techniques and templates that can be used for the business case calculation, however, we recommend harmonizing one across all IoT initiatives, as this makes the business models easier to compare.
• Strategic Impact & Subsequent Business Models: The chimneys of the house in our diagram indicate two non-monetary effects of a business model that should be looked at in conjunction with the business case. For example, if the business case does not look promising, but the company needs to implement the business model in order to enter a new market, or to access a new technology, these strategic aspects have to be documented. The second chimney, “subsequent business models,” is very specific to the IoT: When defining the business model and capturing all the data associated with connected devices, it is very common that the teams come up with interesting new ideas on how to leverage the data (by combining them to new value-adding information, for example) and create new services. Some ideas are not leveraged within the same business model, but rather developed in separate business models. However, they need to refer to the business model that they are built upon.
The following advice on IoT partner ecosystem development comes from Anuj Jain, Director Partner Management by Bosch Software Innovations:
The IoT value chain is long and wide, encompassing physical assets, operational services, and digital services. Key considerations for IoT initiatives are:
• What are the elements of value chain that one can realistically deliver given the current capabilities?
• How much of the control one requires on the IoT Value Chain EcoSystem?
Practically, it is neither possible, nor reasonable, for any single player to specialize in all the aspects of the IoT value chain. For IoT initiatives, the right strategy is a partner ecosystem with a shared vision, passion, and objective. This allows ready access to specialist know-how and expertise at reasonable costs – an essential factor in the success of IoT projects. A well-crafted partner ecosystem accelerates the time to market, improves return on investment (ROI) for each stakeholder, and enhances the customer experience. It also assures customers that their investment will have continued support and innovation across the entire value chain.
Historically, only large, established behemoths like Daimler, Airbus, Microsoft, IBM worked on building a partner ecosystem. In those cases, the “behemoth” was at the center of the EcoSystem typically wielding enormous influence and often defining the character of the EcoSystem. IoT is popularizing an EcoSystem of value-adding network of partners and collaborative organizations that leads to competitive advantage. Both Large companies and smaller players are successfully working on more diffused, less centralized ecosystem that arise organically and that leads to more equal and collaborative partners.
Let’s look at some popular examples of successful ecosystems:
• Top of mind is the example of Apple and the music industry. Music Industry owned assets (music rights). Steve Jobs spotted the opportunity to provide a legal, affordable, and easy way to provide music to fans. Apple created a platform, and operated it well (operations services and digital services). Apple succeeded and controlled the EcoSystem.
• An exciting example is DriveNow. BMW manufactures great cars (Physical Assets). Sixt has extensive experience and competency in Fleet Operations and Customer Management (Operational Services). A concept to offer the cars on a more flexible basis was generated. Both organizations joined hands to develop a platform – DriveNow (digital services) to offer an innovative carsharing service. Both the partners working at an eye level and significantly contributing to the partnership.
• Another interesting ecosystem battle being played out at the moment concerns car infotainment. This is high-cost, high-margin equipment, traditionally controlled by OEMs. It allows a direct link to the customers that OEMs don’t want to lose. It’s about challenge and opportunity. Google and Apple enter with their connected services, disturbing the balance. Alignments are shaping up and the final stable ecosystem is yet to be established.
Customers are now looking for end-to-end solutions, not a collection of building blocks that they have to stick together. Customers expect open standards and inter-operability. Customers require products and solutions that evolve with their operational needs. Currently we are just scratching the surface when it comes to possible uses of IoT technologies. It is expected that IoT solutions will continue to expand both horizontally and vertically to deliver even more value to the end customer. A partner ecosystem provides customers with access to a deep well of industry-specific knowledge and industry applications to address increasingly complex problems.
We encountered this situation recently, while working on a project to enhance ‘Digital and Operational Services’ for hand-held industrial power tools (physical assets). Options were to keep this closed/confined or to make it open standard and allow integration of any hand-held power tools from any manufacturers. We opted the latter and opened the platform further by successfully proposing to the Industrial Internet Consortium to make this a testbed for hand-held industrial power tools. Bosch established an ecosystem together with Tech Mahindra, Cisco, Mongo DB, and Dassault Systems to bring the best of competencies to the overall solution.
The critical part of the ecosystem development journey is to identify the right partners. Such an ecosystem may work best if it’s based on revenue share vis-à-vis sub-contractors. This is easier said than done as each stakeholder carries a different perception of his or her contribution to the ecosystem. Mutual trust in ecosystem partners is very important. The ability to collaborate at the customer level (the most sacred thing in the business world) is a sign of a most valued partnership. The trust required for a joint go-to-market is significant as it not only demonstrates belief in each other’s products and expertise, but also that both parties trust the other to work toward a mutually beneficial outcome.
To return to our “Clash of two world” discussion in the overture, it’s important to identify what camp you belong to – Manufacturing camp or Internet camp. How does this translate realistically into delivery capabilities and market access. Should we focus on core capabilities and allow organic development of an ecosystem? Or aim to play a significant (may be controlling) role in shaping the ecosystem? Where should we start here? Should we:
• Define precise roles?
• Establish a legal basis or a strategic partnership agreement?
• Jointly develop new products?
• Initiate joint marketing activities – Press releases, thought leadership events, webinars, etc?
The IoT is still in its initial phase, it requires upfront investment, and cannot deliver immediate returns (in next quarters or so) but instead lays the foundation for good long-term returns. For the most part, Middle management (with short-term number orientation) find it difficult to manage this mismatch in expectations. Further, IoT project spans multiple verticals and horizontals. There is still lack of clarity about the group best suited to lead such initiatives, and many teams and individuals start politicking. Such partnerships require a significant involvement and commitment from C level (and sometimes the board) in order to manage these complexities and provide direction.
Organizations don’t have enough time or money to waste on signing a bunch of agreements that just say “I love you; You love me”. Successful ecosystems involve high levels of trust, matching communication styles, and complementary skills. Extreme prudence is required for establishing such ecosystems.
While it is important to understand all of the strategic aspects of the business model, many senior executives pay particular attention to the quantitative perspective, i.e. the concrete business case.
Since business cases are always forward-looking, some managers take a cynical view of employees performing Excel-based exercises. However, most managers agree that these exercises are a good way to force the team to really think every aspect of the business model through in detail. Many budget discussions have been decided based not on the quality of the detailed business case calculation, but simply on the single number presented by the team as the result of this calculation. In this context, it is particularly important to understand the scope of the business case that is developed. Recall our differentiation between the asset and IoT solution from the introduction: It is absolutely critical to understand and communicate whether or not the business case relates to the overall asset or to the IoT solution only. Take the eCall example that we have used numerous times already: It is important to understand whether you are calculating a business case that says how much money you can make on the eCall service alone, or whether you are calculating how many more (or less) cars you will sell by being able to offer (or not offer) an eCall service. Keep in mind that the ROI of the “local“ IoT solution will not always be positive. In many cases, the additional funding will be the “cost to compete“ from the asset‘s perspective.
Let’s start by taking a more detailed at the local ROI of an IoT solution. The following figure provides an overview of a generic IoT business case model. This model is based on the simple assumption that every IoT solution consists of a combination of asset enhancements (the on-asset hardware, for example) and services that are implemented by leveraging the new connectivity to the asset. This service can be a fully automated IT service, or a human-operated service like a call center service – or both. So naturally, asset enhancement and service show up both on the cost and on the revenue side. On the cost side, we usually have to differentiate between capital expenditure (CAPEX) and operating expenditure (OPEX), while on the revenue side we differentiate between up-front revenues (through hardware sales or a service sign-up fee, for example) and recurring revenues (service subscriptions, for example). Taking all of this together helps to calculate the “local” IoT solution ROI. It is really not rocket science, but in our experience it can be quite helpful when selling an IoT business case to visualize its key elements in a way similar to the following.
The next perspective is the overall business case, as shown in the figure below. Again, this has to look at both, asset enhancements and services. However, in this perspective we can also look at cost savings and operational efficiency on the one side, and differentiation and strategic benefits on the other. In some cases, it will be possible to quantify this, in other cases, the case will have to be argued qualitatively. In either case, it is usually very useful to present these different aspects of the overall business case in a structured manner.
Of course there are many challenges in the development of an IoT business case that are not obvious at first glance. Based on his experience, Felix Wortmann from the University of St. Gallen points out two major IoT business case challenges:
“First of all, fixed costs for IoT hardware development should not be underestimated. While this is certainly not new to the traditional hardware community, people with a software background often think that new development methodologies and the latest advances in the context of Arduino and Raspberry Pi have fundamentally changed the laws and economics of hardware development. And yes, today first prototypes can often be realized on low budget hardware, for example, Arduino sets are available for less than $50. However, creating reliable hardware that can actually be deployed in the field still has very high associated costs. It is not only a question of initial design and prototyping. The investments required for testing and certification, and the cost for actually integrating IoT capabilities into existing hardware have to be taken into account as well. This means that from the very beginning, significant fixed costs that occur even before first revenue can be generated have to be considered. For this reason, there are significant risks involved. In addition, business models often rely on economies of scale to cope with fix costs and facilitate acceptable unit costs. To illustrate these thoughts, let’s take the example of a business case for a security solution for electronic bicycles. The initial assumption was that a sensor could simply be attached externally to the bicycle. However, digging deeper into the overall business case, it turned out that in order to provide a compelling use case, and also to achieve acceptable unit costs, this sensor has to be designed directly into the power train of the bike. This dramatically increases the initial investment and fundamentally affects the overall business case.
Secondly, IoT-enabled connected products require a backend infrastructure that generates operating costs on an ongoing basis. This is a fundamental difference compared to non-connected products that do not generate costs after they have been sold. Thus, the operating costs of connected products have to be tackled. Either, they are calculated into the one-time sales price, or ongoing payments are introduced. However, pay-per-use or subscription-based models usually face severe customer acceptance challenges, specifically if hardware comes into play. Especially in the consumer context, people are often not willing to pay money for a physical object, connected or not, on an ongoing basis. This means that operating costs have to be calculated into the sales price. As a kind of risk insurance, companies use a variety of tactics, planned obsolescence, for example. Also, companies try to ensure that IoT-based products can still operate even if the provider shuts down its central infrastructure. Take, for example, the Philips Hue: This connected light bulb is designed to also work on the basis of a controlling local gateway, without the Phillips-backend. This effectively gives Philips the opportunity for a “graceful” exit strategy: If it would should down its own backend services, the customer has less functionality but the product still works.”
These are just some examples for the complexity of IoT business cases, yet they illustrate why a structured process for their development can be helpful, and why they also take time to reach a certain level of maturity.
For the steering committee that will be presented with the business plans for the various IoT investment opportunities, the key question is: How should these different opportunities be evaluated and prioritized? In a corporate environment, there will always be a certain amount of political behind-the-scenes influencing, but it can be really helpful to map out the different opportunities and make them comparable, ideally on a single chart. It is important that the evaluation criteria be aligned with the overall IoT strategy, as defined at the beginning of this section.
In the light of our previous discussion on the “local” business case versus the contribution of the new IoT solution to the overall competitiveness of the related asset, it would seem natural to pick these two perspectives as the key dimensions for an IoT portfolio evaluation chart (example in the following figure). Assuming that one would want to strike a good balance between these two dimensions, the chart should also define an “IoT investment corridor” that defines the area within which the investments should ideally be located. While the “ROI over a defined time period” (or some other economic measure, like economic value added, EVA) is usually easily quantifiable, the overall strategic contribution is usually harder to quantify. Also, this needs to incorporate the overall value of the particular asset class to the company. A small strategic increase in value for the main asset that contributes 50% of the company`s revenues easily outweighs a huge strategic increase in value for a niche asset with low overall revenue contribution. Another important factor that is not included in this approach is market pressure, i.e. how critical is the timing of this investment.
You can view the full report here.
