More...More...More...More...More...More...More...BMI

The development and validation of a (more or less) detailed business model is usually the first step in the journey towards developing a new smart, connected product or solution. The business model will usually play a central role in product development, while in solution development, it will be most likely more basic. The following will look at tools and best practices for developing AIoT-specific business models, with a focus on the product perspective.

AIoT-enabled Business Models

For a product or service-oriented organization, the business model usually describes how the organization creates, delivers, and captures value [1]. For example, the St. Gallen Business Model Navigator [2] defines four dimensions for a business model ("What, how, who and value"): What do you offer to the customer? How is the value proposition created? Who is your target customer (segment)? How is revenue created?

For a more operations-oriented organization looking to introduce AIoT-enabled solutions, the business model will often be developed around the OEE formula introduced in the discussion about the Digital Equipment Operator: How does the investment in a new, AIoT-enabled solution will benefit asset availability, performance rate or quality rate. The focus here will usually be more on the business case (ROI, OEE), and less on the other aspects of the business model such as value proposition and target customers.

When developing a more holistic business model that combines physical products with digital services, a key question is where to start. Many OEMs and manufacturers have been starting by looking at their existing portfolios of physical products and then trying to extend them with connectivity-based features, adding intelligence in a second step. If the target business model supported by these new, digital features is not clear, this can be problematic: Are the new features only seen as additional differentiators of the original product, or are they new sources of revenue? Not understanding this from the beginning can be very risky, leading to disappointing results. On the other hand, looking at business models only from the purely strategic perspective without taking existing products, capabilities, market access and brand reputation into consideration can also be difficult. So the truth probably lies somewhere in the middle.

AIoT-Business Model Development - Considerations

What is important to understand is that business models usually evolve over time. In the agile and lean world, the assumption is that business model innovation is an iterative process. Many Internet-based business models are constantly re-evaluating and adapting their business models, utilizing the flexibility of the cloud and DevOps to do so. However, for business models based on physical assets, this is typically not as easy: Design and manufacturing of physical assets has much longer lead times. Once the assets are manufactured, sold and deployed in the field, any alteration of their physical configuration becomes very difficult if not impossible. Smart, connected products provide an opportunity to address this issue, at least to a certain extent, for example through dynamic configuration of digital features or, in some cases, even the enabling of physical features on demand. The following will discuss typical business model patterns enabled by AI and IoT in more detail.

AI Business Model Patterns

The area of business model patterns based on AI in the context of IoT is not (yet) widely researched. The diagram below describes the most common patterns from the AIoT perspective.

AI Business Models Patterns

IoT Business Model Patterns

The area of business model patterns for the Internet of Things is well researched and documented. For example, the St. Gallen Business Model Navigator [2] defines a number of patterns summarized in the table below. These patterns are generally based on the assumption that they combine physical assets with digital services.

IoT Business Model Patterns

A great example of a 'Digital Add-on' is BMW's announcement to make seat heating available on demand. Two factors make this interesting:

  • Physically producing many different, custom configured variants of a car could be nearly as expensive as producing a single, mass-manufactured variant
  • Being able to upsell this feature to customers especially in winter could significantly increase the total number of seat heating options sold in total

Ignite AIoT Business Model Templates

The following is introducing a set of templates for AIoT business models. As far as possible, these templates reuse existing, well established business model templates, adding AI and IoT perspectives to them. These templates should be seen as guidance, and can be adapted in a flexible way to best fit the needs of your individual AIoT business model.

Ignite AIoT Business Model Templates

The Smart Kitchen Example

The following discussion will be based on the smart kitchen example, which is shown below. The complete Smart Kitchen Business Model has been documented in Miro. It can be accessed HERE, in case you can`t read some of the details in the diagrams below.

Example: Smart Kitchen

AIoT Business Model Canvas

The business model canvas is probably one of the most established tools in the business model community. There are a plethora of variations, with Osterwalder representing the classic and the Lean Canvas the one probably most established in the agile development community. The basic idea of the business canvas is that - instead of writing a detailed and lengthy business plan - the key information typically found here is summarized in a canvas on a single page. Sometimes, the canvas also serves as the executive summary.

The AIoT Framework proposes an AIoT business model canvas derived from Osterwalder, but adds another area to specifically highlight the impact of AIoT on the other elements, including value proposition, customer relationships, channels, key resources, key activities, cost and revenue structure.

AIoT Business Model Canvas

AIoT Solution Sketch

The first template is the so-called AIoT Solution Sketch. The idea is to provide a very simple canvas which helps visualize the key functional elements of your solution, mapped to either the field (including EDGE functionality) or the backend (e.g., in the cloud). This simple yet expressive format is especially useful for reviewing and discussing the intended functional scope with management stakeholders.

AIoT Solution Sketch

AIoT Use Case Mapping

AIoT Use Case Mapping can be used to clarify how far one of the typical AIoT Use Cases can best be supported by utilizing AI and IoT together. An example is given here.

AI Value Proposition - Smart Kitchen Example

AIoT Customer Journey Map

Customer (or User) Journey Maps are a common User Experience (UX) tool. There are many shapes, sizes, and formats available. The general idea of a journey map is to help understand and visualize the process that a person goes through to accomplish a specific goal.

The AIoT Playbook proposes a format for a customer journey map that has the key user interactions with the asset at the top, e.g., asset purchasing, asset activation, asset usage and service incidents. Depending on the complexity, each of these steps could be detailed in a map on its own. Below this, the template provides space for the following:

  • Touchpoints: What touchpoints is the customer actually using to interact with the solution or the asset?
  • Doing: What is the customer actually doing?
  • Thinking/Feeling: This covers the emotional side of the journey
  • Opportunities: What opportunities from a business model point of view can be found here?
  • Key AIoT Features: What features/capabilities from an AIoT point of view are utilized here?

Note that this template focuses more on the high-level journey, including business model aspects. A more detailed, UX-focused version of this is introduced later in Product / Solution Design.

AIoT Customer Journey

Commercial Model

The commercial model has to address the question how the product or solution is generating revenues, at the end of the day. The model must bring together the offering and the target customer.

The offerings must be broken down as follows:

  • Unique value proposition: potentially for different customer segments
  • Sellable features: identify all elements of the offering which eventually generate revenue, e.g. upfront revenues for the physical asset, subscription revenues for digital premium services
  • Princing: all sellable features must be included in the princing model

The target customer must be understood well, including:

  • Industry / domain: this will look different for B2C vs B2B offerings, but should be addressed, e.g. via a market segment analysis
  • Profile: again, must be looked at individually, e.g. B2B buying-center vs B2C persoas
  • Buying process: how is the customer - as a private person or an enterprise - buying this? What formal conditions have to be met?

Finally, the question is how to get to the customer:

  • Sales approach: traditional Solution Sales and Key Account Management, web-based sales, in-app sales, etc.
  • Monetization: how to turn non-revenue-generating items into revenue, e.g. by getting customers to upgrade from digital fremium to premium services
Commercial Model

AIoT Business Case

Another key element of the business model is the business case, including the financial perspective on costs and revenues, as well as strategic contributions.

Direct ROI

The direct ROI for an AIoT solution must typically take into consideration asset-related and service-related costs and revenues. On the cost side, the differentiation between capital expenditures and operational expenditures (including unit and operations costs). On the revenue side, the business case must differentiate between upfront revenues and recurring/subscription revenues. The AIoT Playbook proposes combining these perspectives in the template shown below.

AIoT Business Case

Please note that business case development and ROI calculation usually also require some kind of quantitative planning, including projections for numbers of units sold, customer adoption of digital features, and so on. A detailed example is given in the Product Design section.

Strategic Contributions

In addition to the direct ROI of the investment, many AIoT solutions also provide strategic contributions to a higher-level business case. Take, for example, the eCall feature of a car. This potentially AIoT-enabled device in vehicles will automatically call a local emergency service in the event of a serious road accident. Airbag deployment and impact sensor information, as well as GPS coordinates, will be sent along as well. The question is as follows: Does this feature require a dedicated ROI calculation, or is this simply the fulfillment of a regulatory requirement? Since eCall is now a requirement in the EU, for example, it is unlikely that this can be sold as an add-on with extra revenue. So it must be seen as a strategic contribution to the car.

KPIs

It is usually advisable to include a set of Key Performance Indicators (KPIs) in the Business Model. KPIs are measurable values used by organizations to keep track of and determine progress on specific business objectives. A good method for defining KPIs is the SMART method. SMART means that KPIs should be specific, measurable, attainable, relevant, and time-sensitive. Example KPIs for an AIoT product are described in more detail in the Product Design section.

KPIs are a good way of guiding the execution team and evaluating their progress against a previously defined set of goals in the business model. Closely related to this are Objectives and Key Results (OKRs). While KPIs are business metrics that reflect performance, OKR is a goal-setting method which can be used as a project steering mechanism. However, this would usually not be part of the business model.

KPIs for the kitchen appliance example could include:

  • Customer acquisition cost
  • Number of kitchen appliances sold
  • Average subscription revenue per customer
  • Monthly recurring revenue
  • Customer Lifetime Value

AIoT Business Case Validation

Validating the AIoT Business Case in the early stages as much as possible will save you from costly surprises further down your AIoT journey. The business case validation should include both sides, costs and revenues.

Validating assumptions made about revenue in the business model is of course tricky. Usually, a good way forward is interviews with potential customers to validate not only their willingness to purchase the intended products and services but also their price sensitivity.

Furthermore, one should also not underestimate the importance of validating the cost side of the business model. This is especially important for an AIoT-enabled business: While virtual, cloud-based business can scale very well on the cost side, with any business that is involving physical assets or products, this is different. Physical products will have to be manufactured, distributed and supported. A thorough investigation of unit costs/marginal costs should be performed as early as possible, and ideally validated by obtaining price indications from potential suppliers as early as possible. The AIoT Sourcing BOM introduced in the section on Sourcing and Procurement can be a very helpful tool.

In addition to IoT-related costs (especially hardware and costs for telecommunication), AI-related costs should also not be underestimated. In particular, the data labeling can be a cost driver - do not forget that this will not only cause costs for the initial data labeling but most likely require continued labeling services throughout the entire product life cycle.

AIoT Cost Estimation

In general, IT-centric business cases have a tendency to focus more on the initial costs, and not the Total Cost of Ownership (TCO). Over a five-year lifespan, initial development costs will most likely be only 20% of the TCO[3].

Proof of Concept

Most investors require some kind of proof along the way, which provides evidence for the feasibility of the investment proposal (this applies both to corporate investors and private equity investors). AIoT-based solutions are not different from that perspective. However, it can sometimes be much more difficult and expensive to run a Proof-of-Concept (PoC) for an AIoT solution: Today it is usually very easy to create a lightweight and affordable PoC for a pure software project (e.g., using simulation or mock-ups). However, as soon as hardware development and/or asset customization is involved, this can become much harder, depending on the hardware and asset categories.

Consequently, the following should be clearly defined for any AIoT-related PoC:

  • Duration & effort
  • Scope
  • Resources
  • Success criteria

Investment Decision

In today's agile and digital world, most investment decisions are staged, meaning that partial investment commitments are made based on the achievement of certain milestones. However, there is usually a point in time for any innovation project where it transitions from the exploratory phase towards the scaling phase with much higher budgets. Each organisation is typically follows its own, established investment criteria. For the project manager, it is often important to keep in mind that these criteria are usually a mixture of hard, ROI-based criteria, as well as the strategic perspective. This is why the business model should address both perspectives, as stated above.

AIoT Investment Decision

References

  1. Business Model Generation, Alexander Osterwalder, Yves Pigneur, Alan Smith, and 470 practitioners from 45 countries, self-published, 2010
  2. 2.0 2.1 The Business Model Navigator: 55 Models That Will Revolutionise Your Business, Oliver Gassmann, Karolin Frankenberger, Michaela Csik, 2014
  3. Distribution of Cost over the Application Lifecycle - a Multi-case Study, Ruediger Zarnekow, Walter Brenner, 2005

Authors and Contributors

Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

AUTHOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.


Heiner Duffing.jpg
HEINER DUFFING, ROBERT BOSCH GMBH
CONTRIBUTOR
Heiner has more than 25 years experience in purchasing and partially business development in various business areas (Steel, Automotive, Consumer, Renewables) and countries.Strong focus has been to find market innovations and develop start-up suppliers/products to reliable serial partners, including the negotiation of fitting contracts.Currently he leads the Purchasing of Software and Engineering Services for Bosch products. He holds a degree as Diplom-Wirtschaftsingenieur from TU Darmstadt.


Kim Kordel.jpg
KIM KORDEL, BOSCH.IO
CONTRIBUTOR
Kim Kordel is a senior business development manager for new IoT business at Bosch.IO. In her former position as an IoT business consultant and trainer for IoT business models at Bosch.IO she developed and taught methodology for building IoT business models. With this methodology she developed new digital business for internal and external customers. Kim also co-initiated and set-up the Bosch Startup Harbour, the incubation program for external startups for Bosch. Now Kim is responsible to establish new IoT business for the energy domain.