Business Model Design: Difference between revisions

No edit summary
(Editorial Changes)
 
(28 intermediate revisions by 4 users not shown)
Line 6: Line 6:
rect 2735 257 3539 390 [[Product_/_Solution_Design|More...]]
rect 2735 257 3539 390 [[Product_/_Solution_Design|More...]]
rect 2735 385 3539 518 [[Co-Creation|More...]]
rect 2735 385 3539 518 [[Co-Creation|More...]]
rect 2735 518 3539 651 [[Agile_AIoT_Grid|More...]]
rect 2735 518 3539 651 [[Rollout_GTM|More...]]
rect 2735 647 3539 788 [[Product_Operations|More...]]
rect 2735 647 3539 788 [[Product_Operations|More...]]
rect 2735 775 3539 921 [[Product_Organization|More...]]
rect 2735 775 3539 921 [[Product_Organization|More...]]
Line 13: Line 13:
</imagemap>
</imagemap>


The development and validation of a (more or less) detailed business model is usually the first step on 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.
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. This section looks at tools and best practices for developing AIoT-specific business models, with a focus on the product perspective.


__TOC__
__TOC__
Line 20: Line 20:
For a product or service-oriented organization, the business model usually describes how the organization creates, delivers, and captures value <ref name="osterwalder" />. For example, the St. Gallen Business Model Navigator <ref name="gassmann" /> 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 product or service-oriented organization, the business model usually describes how the organization creates, delivers, and captures value <ref name="osterwalder" />. For example, the St. Gallen Business Model Navigator <ref name="gassmann" /> 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|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 like value proposition and target customers.
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|Digital Equipment Operator]]: How will the investment in a new, AIoT-enabled solution 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 which 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, only looking at business models 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.
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 a 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.
 
Christian Renz, Global Head of IoT and Digitalization at Bosch, has made the following experience in this area: ''Successful manufacturers of physical products typically have a great understanding of their products’ domain: They understand usage of their product, value creation processes they are part of, the competitive landscape, purchasing behavior and so on. However, they view their domain through the lens of their products, which means they tend to not perceive value creation that their products are not part of. To successfully incubate new AIoT business models, product manufacturers need to build up competencies in service incubation and design. Coming from a hypothesis of value created for customers, dedicated teams quickly iterate through a series of “minimum viable products”, proving or disproving the value hypothesis. These cycles are much faster than typical product engineering cycles. The initial value hypothesis should be purely derived top-down from concrete customer pain points in the domain, rather than bottom-up from augmenting physical products with connectivity, allowing even for the freedom to come up with business models that could potentially disrupt an existing business.''


[[File:BM Development.png|800px|frameless|center|link=|AIoT-Business Model Development - Considerations]]
[[File:BM Development.png|800px|frameless|center|link=|AIoT-Business Model Development - Considerations]]


What is important to understand is that usually, business models 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 cloud and [[AIoT_DevOps_and_Infrastructure|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. And 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 are providing an opportunity to address this issue, at least to a certain extend - 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.
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 [[AIoT_DevOps_and_Infrastructure|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.


== <span id="AIPatterns"></span>AI Business Model Patterns ==
== <span id="AIPatterns"></span>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.
The area of business model patterns based on AI in the context of the IoT is not (yet) widely researched. The diagram below describes the most common patterns from the AIoT perspective.


[[File:2.1 Business Model.png|800px|frameless|center|link=|AI Business Models Patterns]]
[[File:2.1 Business Model.png|800px|frameless|center|link=|AI Business Models Patterns]]
Line 35: Line 37:
== <span id="IoTPatterns"></span>IoT Business Model Patterns ==
== <span id="IoTPatterns"></span>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 <ref name="gassmann" /> defines a number of patterns summarized in the table below. These patterns generally are based on the assumption that they combine physical assets with digital services.
The area of business model patterns for the Internet of Things is well researched and documented. For example, the St. Gallen Business Model Navigator <ref name="gassmann" /> 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.


<span id="iotpatterns"></span>
<span id="iotpatterns"></span>
Line 42: Line 44:
A great example of a 'Digital Add-on' is BMW's announcement to make [https://arstechnica.com/cars/2020/07/heated-seats-as-a-service-bmw-wants-to-sell-car-features-on-demand/ seat heating] available on demand. Two factors make this interesting:
A great example of a 'Digital Add-on' is BMW's announcement to make [https://arstechnica.com/cars/2020/07/heated-seats-as-a-service-bmw-wants-to-sell-car-features-on-demand/ 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
* 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 up-sell this feature to customers especially in winter could significantly increase the total number of seat heating options sold in total
* 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 =
= Ignite AIoT Business Model Templates =
The following is introducing a set of templates for AIoT business models. As far as possible, these templates are re-using existing, well established business model templates, adding the AI and IoT perspective 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.
The following introduces 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.


[[File:BM Template Overview.png|600px|frameless|center|link=|Ignite AIoT Business Model Templates]]
[[File:BM Template Overview.png|800px|frameless|center|link=|Ignite AIoT Business Model Templates]]


== The Smart Kitchen Example ==
== 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 [https://miro.com/app/board/o9J_lJmp474=/ HERE], in case you can`t read some of the details in the diagrams below.
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 [https://miro.com/app/board/o9J_lJmp474=/ HERE], in case you can't read some of the details in the following diagrams.


[[File:2.1-SmartKitch Intro.png|1000px|frameless|center|link=|Example: Smart Kitchen]]
[[File:2.1-SmartKitch Intro.png|1000px|frameless|center|link=|Example: Smart Kitchen]]


== <span id="BMCanvas"></span>AIoT Business Model Canvas ==
== <span id="BMCanvas"></span>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 [http://alexosterwalder.com/ Osterwalder] representing the classic, and the [https://blog.leanstack.com/why-lean-canvas-vs-business-model-canvas-af62c0f250f0 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 business model canvas is probably one of the most established tools in the business model community. There are a plethora of variations, with [http://alexosterwalder.com/ Osterwalder] representing the classic and the [https://blog.leanstack.com/why-lean-canvas-vs-business-model-canvas-af62c0f250f0 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 derives from Osterwalder, but adding 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, etc.
The AIoT Framework proposes an AIoT business model canvas derived from Osterwalder, but adds another area to specifically highlight the impact of AIoT on other elements, including value proposition, customer relationships, channels, key resources, key activities, cost and revenue structure.


[[File:2.1-x-Canvas.png|1000px|frameless|center|link=|AIoT Business Model Canvas]]
[[File:2.1-x-Canvas.png|1000px|frameless|center|link=|AIoT Business Model Canvas]]


== <span id="SolutionSketch"></span>AIoT Solution Sketch ==
== <span id="SolutionSketch"></span>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.
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.
[[File:2.1-x-SolutionSketch.png|800px|frameless|center|link=|AIoT Solution Sketch]]
[[File:2.1-x-SolutionSketch.png|800px|frameless|center|link=|AIoT Solution Sketch]]


== <span id="UseCaseMapping"></span>AIoT Use Case Mapping ==
== <span id="UseCaseMapping"></span>AIoT Use Case Mapping ==
The AIoT Use Case Mapping can be used to clarify in how far one of the typical AIoT Use Cases can best be supported by utilizing AI and IoT together. An example is given [[Artificial_Intelligence#Example|here]].
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 [[Artificial_Intelligence#Example|here]]. In the example of the kitchen appliance, almost all generic AIoT use cases are relevant: AIoT will be used to improve the design of the kitchen appliance, data will be used for sales support, overall product performance improvements are in scope, as well as predictive maintenance. Finally, digital services such as recipe recommendations will play an important role.


[[File:1.2-AIValuePropKitchenExample.png|800px|frameless|center|link=|AI Value Proposition - Smart Kitchen Example]]
[[File:1.2-AIValuePropKitchenExample.png|800px|frameless|center|link=|AI Value Proposition - Smart Kitchen Example]]


== <span id="Journey"></span>AIoT Customer Journey Map ==
== <span id="Journey"></span>AIoT Customer Journey Map ==
Customer (or User) Journey Maps are a common [https://en.wikipedia.org/wiki/User_experience User Experience (UX)] tool. There are many shapes, sizes, and formats available. The general idea of a journey map is to help understanding and visualizing the process that a person goes through in order to accomplish a specific goal.
Customer (or User) Journey Maps are a common [https://en.wikipedia.org/wiki/User_experience 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.


Ignite AIoT proposes a format for a customer journey map which 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.  
The Digital 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:
Below this, the template provides space for the following:
* '''Touchpoints''': What touchpoints is the customer actually using in order to interact with the solution or the asset?
* '''Touchpoints''': What touchpoints is the customer actually using to interact with the solution or the asset?
* '''Doing''': What is the customer actually doing?
* '''Doing''': What is the customer actually doing?
* '''Thinking/Feeling''': This covers the emotional side of the journey
* '''Thinking/Feeling''': This covers the emotional side of the journey
* '''Opportunities''': What opportunities from a business model point of view can be found here?
* '''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?
* '''Key AIoT Features''': What features/capabilities from an AIoT point of view are utilized here?


Note that this template is focusing more on the high-level journey, including business model aspects. A more detailed, UX-focused version of this is introduced later in the [[Solution_Architecture|Solution Architecture]].
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_Architecture|Product / Solution Design]].


[[File:2.1-x-CustomerJourney.png|800px|frameless|center|link=|AIoT Customer Journey]]
[[File:2.1-x-CustomerJourney.png|800px|frameless|center|link=|AIoT Customer Journey]]


== <span id="ValueNetwork"></span>AIoT Value Network Modelling ==
== Commercial Model ==
[https://en.wikipedia.org/wiki/Value_network Value Networks] are another tool in the business model toolbox. Again, a wide variety can be found. The basic idea of a value network is to help explore and design the relations and the value exchange between a solution / product / company and the different stakeholders (see example [https://bmtoolbox.net/tools/value-network/ here]).
The commercial model has to address the question of 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 that eventually generate revenue, e.g., upfront revenues for the physical asset, subscription revenues for digital premium services
* Pricing: all sellable features must be included in the pricing model
 
The target customer must be well understood, 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 persons
* 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


Ignite proposed a value network template which focuses on people (usually described via roles) and corporate stakeholders (e.g. partner companies). In addition, another type of node in the network should be the intelligence embedded in the AIoT solution (e.g. as asset intelligence or swarm intelligence). This is important because in an AIoT solution this will usually be an important provider of either information / intelligence or revenue / value.
[[File:BM Commercial Model.png|800px|frameless|center|Commercial Model]]


[[File:2.1-x-ValueNetworkModeling.png|800px|frameless|center|link=|AIoT Value Network Modeling]]
== 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 [[AIoT_Business_Viewpoint|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:
* Number of kitchen appliances sold
* Average subscription revenue per customer
* Monthly recurring revenue
* Customer Lifetime Value
* Customer acquisition cost
 
These KPIs are assuming an established business. In the early phase of business model validation, different KPIs should be applied - for example, KPIs related to UX.


== <span id="BusinessCase"></span>AIoT Business Case ==
== <span id="BusinessCase"></span>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 the strategic contributions.
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 ===
=== Direct ROI ===
The direct ROI for an AIoT solution must typically take into consideration the asset-related as well as the 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. Ignite AIoT proposes to combine these perspectives in the template shown below.
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 Digital Playbook proposes combining these perspectives in the template shown below.
<span id="BusinessCase-Diagram">
<span id="BusinessCase-Diagram">
[[File:2.1-x-BusinessCase.png|700px|frameless|center|link=|AIoT Business Case]]
[[File:2.1-x-BusinessCase.png|700px|frameless|center|link=|AIoT Business Case]]


=== Strategic contributions ===
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 [[AIoT_Business_Viewpoint|Product Design]] section.
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 a 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: 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.
 
=== 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.


== <span id="Validation"></span>AIoT Business Case Validation ==
== <span id="Validation"></span>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.
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.  
The business case validation should include both sides, costs and revenues.  


Validating assumptions made about revenue in the business model is of course tricky. The best way forward are typically interviews with potential customers, to validate not only their willingness to purchase the intended products and services, but also their price sensitivity.
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.
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 which is involving physical assets or products, this is different. The 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 getting price indications from potential suppliers as early as possible. The AIoT Sourcing BOM introduced in the section on [[Sourcing_and_Procurement|Sourcing and Procurement]] can be a very helpful tool.
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|Sourcing and Procurement]] can be a very helpful tool.


In addition to IoT-related costs (especially hardware and costs for telecommunication), the AI-related costs should also not be underestimated.
In addition to IoT-related costs (especially hardware and costs for telecommunication), AI-related costs should also not be underestimated.
Especially the data labeling can be a cost driver - don`t 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.
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.


[[File:3.1-CostEstimation.png|600px|frameless|center|link=|AIoT Cost Estimation]]
[[File:3.1-CostEstimation.png|600px|frameless|center|link=|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<ref name="zarnekow" />.
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<ref name="zarnekow" />.


= <span id="PoC"></span>Proof of Concept =
= <span id="PoC"></span>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 as well as private equity investors). AIoT-based solutions are not different in that perspective. Except that 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.
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:
Consequently, the following should be clearly defined for any AIoT-related PoC:
Line 129: Line 159:


= <span id="InvestmentDecision"></span>Investment Decision =
= <span id="InvestmentDecision"></span>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 following 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.
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'' toward 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.
[[File:2.1-x-InvestmentDecision.png|500px|frameless|center|link=|AIoT Investment Decision]]
[[File:2.1-x-InvestmentDecision.png|500px|frameless|center|link=|AIoT Investment Decision]]


Line 146: Line 176:
<br>
<br>
{{Designstyle-author|Image=[[File:Kim Kordel.jpg|left|100px]]|author={{Kim Kordel|Title=CONTRIBUTOR}}}}
{{Designstyle-author|Image=[[File:Kim Kordel.jpg|left|100px]]|author={{Kim Kordel|Title=CONTRIBUTOR}}}}
<br>
{{Designstyle-author|Image=[[File:Heiko Löffler.jpg|left|100px]]|author={{Heiko Löffler|Title=CONTRIBUTOR}}}}
<br>
{{Designstyle-author|Image=[[File:David Monzel.jpg|left|100px]]|author={{David Monzel|Title=CONTRIBUTOR}}}}
|}
|}

Latest revision as of 22:14, 5 July 2022

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. This section looks 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 will the investment in a new, AIoT-enabled solution 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 a 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.

Christian Renz, Global Head of IoT and Digitalization at Bosch, has made the following experience in this area: Successful manufacturers of physical products typically have a great understanding of their products’ domain: They understand usage of their product, value creation processes they are part of, the competitive landscape, purchasing behavior and so on. However, they view their domain through the lens of their products, which means they tend to not perceive value creation that their products are not part of. To successfully incubate new AIoT business models, product manufacturers need to build up competencies in service incubation and design. Coming from a hypothesis of value created for customers, dedicated teams quickly iterate through a series of “minimum viable products”, proving or disproving the value hypothesis. These cycles are much faster than typical product engineering cycles. The initial value hypothesis should be purely derived top-down from concrete customer pain points in the domain, rather than bottom-up from augmenting physical products with connectivity, allowing even for the freedom to come up with business models that could potentially disrupt an existing business.

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 the 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 introduces 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 following diagrams.

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 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. In the example of the kitchen appliance, almost all generic AIoT use cases are relevant: AIoT will be used to improve the design of the kitchen appliance, data will be used for sales support, overall product performance improvements are in scope, as well as predictive maintenance. Finally, digital services such as recipe recommendations will play an important role.

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 Digital 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 of 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 that eventually generate revenue, e.g., upfront revenues for the physical asset, subscription revenues for digital premium services
  • Pricing: all sellable features must be included in the pricing model

The target customer must be well understood, 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 persons
  • 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

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:

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

These KPIs are assuming an established business. In the early phase of business model validation, different KPIs should be applied - for example, KPIs related to UX.

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 Digital 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.

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 toward 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.


Heiko Löffler.jpg
HEIKO LÖFFLER, MM1
CONTRIBUTOR
Heiko Löffler is a consultant at mm1. During his studies of industrial engineering, he gained experience in the fields of smart connected products, industry 4.0, financial risk management and consulting through various internships at companies such as TRUMPF GmbH and SICK AG. Meanwhile, he is working as a consultant for mm1 in large IoT projects.


David Monzel.jpg
DAVID MONZEL, MM1
CONTRIBUTOR
David Monzel is a senior consultant at mm1. During his studies of industrial engineering, he gained experience in the fields of connected and AI-supported manufacturing, project management, agile development and consulting through various internships at manufacturing and consulting companies. At mm1, he actively contributes with his expertise in the fields of AIoT, digital & agile transformation and strategy in large IoT and IT projects across various industries