AIoT Business Viewpoint: Difference between revisions

No edit summary
 
(39 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
 
<imagemap>
<imagemap>
Image:2.2-v-BusinessViewpoint.png|800px|frameless|center|AIoT Business Viewpoint
Image:2.2-v-BusinessViewpoint.png|800px|frameless|center|AIoT Business Viewpoint
Line 8: Line 8:
rect 706 1337 2440 1715 [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]
rect 706 1337 2440 1715 [[AIoT_Implementation_Viewpoint|Implementation Viewpoint]]
rect 2468 55 3122 1711 [[AIoT_Product_Viewpoint|Product Viewpoint]]
rect 2468 55 3122 1711 [[AIoT_Product_Viewpoint|Product Viewpoint]]
rect 4 1581 296 1743 [[Product_Architecture|Product Architecture]]
rect 1 1041 146 1191 [[Product_Architecture|Product Architecture]]


desc none
desc none
</imagemap>
</imagemap>
__NOTOC__
<s data-category="AIoTFramework"></s>
The Business Viewpoint of the AIoT Product/Solution Design builds on the different artifacts created for the [[Business_Model_Design|Business Model]]. As part of the design process, the business model can be refined, e.g., through additional market research. In particular, the detailed design should include KPIs, quantitative planning, and a milestone-based timeline.
__TOC__
= Business Model =
The business model is usually the starting point of the product/solution design. The business model should describe the rationale of how the organization creates, delivers, and captures value by utilizing AIoT. The [[Business_Model_Design|business model design]] section provides a good description of how to identify, document and validate AIoT-enabled business models. A number of different templates are provided, of which the business model canvas is the most important. The business model canvas should include a summary of the AIoT-enabled value proposition, the key customer segments to be addressed, how customer relationships are built, and the channels through which customers are serviced. Furthermore, it should provide a summary of the key activities, resources and partners required to deliver on the value proposition. Finally, a high-level summary of the business case should be provided, including cost and revenue structure.
[[File:2.2.-bv-VacuumCanvas.png|900px|frameless|center|link=|ACME:Vac Business Model Canvas]]
The fictitious ACME:Vac business model assumes that AI and IoT are used to enable a high-end vacuum cleaning robot, which will be offered as a premium product (not an easy decision - some argue that the mid-range position in this market is more attractive). AI will be used not only for robot control and automation but also for product performance analysis, as well as analysis of customer behaviour. This intelligence will be used to optimize the customer experience, create customer loyalty, and identify up-selling opportunities.
= Key Performance Indicators =
Many organizations use Key Performance Indicators (KPIs) to measure how effectively a company is achieving its key business objectives. KPIs are often used on multiple levels, from high-level business objectives to lower-level process or product-related KPIs. In our context, the KPIs would either be related to an AIoT-enabled product or solution.


== <span id="BusinessModel"></span>Business Viewpoint ==
A Digital OEM that takes a smart, connected product to market usually has KPIs that cover business performance, user experience and customer satisfaction, product quality, and the effectiveness and efficiency of the product development process.
The Business Viewpoint of the AIoT Product Architecture is building on the different artifacts created for the [[Business_Model_Design|Business Model]]. In order to refine and validate this information, site surveys and stakeholder interviews should be performed. The definition of personas helps ensuring all key stakeholder perspectives are taken into consideration. The high-level vision and requirements are then captured as epics. From there, a story map is created to capture all high-level requirements. This is the main interface between the Business Viewpoint and the Product Viewpoint.


[[File:2.2.-bv-General.png|700px|frameless|center|Business Model]]
A Digital Equipment Operator who is launching a smart, connected solution to manage a particular process or a fleet of assets would usually have solution KPIs that cover the impact of the AIoT-enabled solution on the business process that it is supporting. Alternatively, business-related KPIs could measure the performance of the fleet of assets and the impact of the solution on that performance. Another typical operator KPI could be coverage of the solution. For example, in a large, heterogeneous fleet of assets, it could measure the number of assets that have been retrofitted successfully. UX and customer satisfaction-related KPIs would only become involved if the solution actually has a direct customer impact. Solution quality and the solution development process would certainly be another group of important KPIs.


[[File:2.2.-bv-KPIs.png|800px|frameless|center|link=|Vacuum Robot - Product KPIs]]


__TOC__
The figure with KPIs shown here provides a set of example KPIs for the ACME:Vac product. The business performance-related KPIs cover the number of robovacs sold, the direct sales revenue, recurring revenue from digital add-on features, and finally the gross margin.
 
The UX/customer satisfaction KPIs would include some general KPIs, such as Net Promoter Score (results of a survey asking respondents to rate the likelihood that they would recommend the ACME:Vac product), System Usability Scale (assessment of perceived usability), and Product Usage (e.g., users per specific feature). The Task Success Rate KPIs may include how successful and satisfied customers are with the installation and setup of the robovac. Another important KPI in this group would measure how successful customers are actually using the robovac for its main purpose, namely, cleaning. The Time on Task KPIs could measure how long the robovac is taking for different tasks in different modes.
 
Product Quality KPIs need to cover a wide range of process- and product-related topics. An important KPI is test coverage. This is a very important KPI for AIoT-enabled products, since testing physical products in combination with digital features can be quite complex and expensive but a critical success factor. Incident metrics such as MTBF (mean time before failure) and MTTR (mean time to recovery, repair, respond, or resolve) need to look at the local robovac installations, as well as the shared cloud back end. Finally, the number of support calls per day can be another important indicator of product quality. Functional product quality KPIs for ACME:Vac would include cleaning speed, cleaning efficiency, and recharging speed.
 
Finally, the Product Development KPIs must cover all of the different development and production pipelines, including hardwire development, product manufacturing, software development, and AI development.
 
= Quantitative Planning =
Quantitative planning is an important input for the rest of the design exercise. For the Digital OEM, this would usually include information related to the number of products sold, as well as product usage planning data. For example, it can be important to understand how many users are likely to use a certain key feature in which frequency to be able to design the feature and its implementation and deployment accordingly.
 
The quantitative model for the ACME:Vac product could include, for example, some overall data related to the number of units sold. Another interesting bit of information is the expected number of support calls per year because this gives an indication for how this process must be set up. Other information of relevance for the design team includes the expected average number of rooms serviced per vacuum robot, the number of active users, the number of vacuum cleaning runs per day, and the number of vacuum cleaner bags used by the average customer per year.
 
[[File:2.2-bv-quantitative plan.png|600px|frameless|center|link=|Quantitative Plan]]
 
For a Digital Equipment Operator, the planning data must at its core include information about the number of assets to be supported. However, it can also be important to understand certain usage patterns and their quantification. For example, a predictive maintenance solution used to monitor thousands of escalators and elevators for a railroad operator should be based on a quantitative planning model that includes some basic assumptions, not only about the number of assets to be monitored, but also about the current average failure rates. This information will be important for properly designing the predictive maintenance solution, e.g., from a scalability point of view.


== <span id="SiteSurvey"></span>Site Surveys and Stakeholder Interviews ==
= Milestones / Timeline =
In many traditional Internet or enterprise IT projects, it does not matter where the software is used, especially if the main point of access is a browser. With AIoT, this differs greatly, since the physical products / assets can potentially behave differently, depending on the type of environment they are deployed in. Also, usage pattern might vastly differ, depending on the environment. Consequently, it is highly recommended for the team responsible for the product design to spend time on-site and investigate different usage scenarios in different environments.
Another key element of the business viewpoint is the milestone-based timeline. For the Digital OEM, this will be a high-level plan for designing, implementing and manufacturing, launching, supporting, and continuously enhancing the product.  


While most AIoT solutions will be deployed at a dedicated site, this might not be true for AIoT-enabled products. Take, for example, a smart kitchen appliance, which will be sold to private households. In this particular case it can make sense to actually build a real kitchen as a test lab, to test usage of the product in a realistic environment.
The timeline for the ACME:Vac product differentiates between the physical product and the AIoT part (including embedded hardware and software, AI, and cloud). If custom embedded hardware is to be designed and manufactured, this could also be subsumed under the physical product workstream, depending on the organizational setup. The physical product workstream includes a product design and manufacturing engineering phase until the Start of Production (SOP). After the SOP, this workstream focuses on manufacturing. A new workstream for the next physical product generation starting after the SOP is omitted in this example. The AIoT workstream generally assumes that an AIoT DevOps model is applied consistently through all phases.  


== <span id="Personas"></span>Personas==
Key milestones for both the physical product and the AIoT part include the initial product design and architecture (result of sprint 0), the setup of the test lab for testing the physical product, the first end-to-end prototype combining the physical product with the AIoT-enabled digital features, the final prototype/Minimum Viable Product, and finally the SOP.
Personas are archetypical users of the product or solution. Often, personas represent fictitious people which are based on your knowledge of real users.


The Business Viewpoint should define a comprehensive set of personas which help with modeling the product features in way that takes the perspective of different product users into consideration. By personifying personas, the product team will ideally even develop an emotional bond to key personas, since they will accompany them through an intense development process. A persona does not necessarily need a sophisticated fictitious background story, but at least it should have a real-world first name and individual icon, as shown in the example below.
The following figure also highlights the V-Sprints, which in this example applies to both physical product development and the AIoT development. While physical product development is unlikely to deliver potentially shippable product increments at the end of each V-Sprint, it still assumes the same sprint cadence.


[[File:2.2.-bv-Personas.png|700px|frameless|center|AIoT Personas]]
Because sourcing is typically such a decisive factor, the timeline includes milestones for the key sourcing contracts that must be secured. Details regarding the procurement process are omitted on this level.


== <span id="Epics"></span>Epics ==
[[File:2.2-bv-Milestones.png|1000px|frameless|center|link=|Example Milestone Plan]]
The agile approach to managing work items is to break them down in a hierarchical way. Depending on the agile method chosen, these hierarchies will includes Themes, Epics, Features, Stories, and so on. The AIoT Framework is by default assuming that Epics and Stories are used to structure work. Depending on the complexity of the project and the agile method chosen, this might have to be adapted.


Nevertheless, it is important that the business model and the agile work schedule get closely aligned. This is why the AIoT Framework proposes that the business model team defines a high-level set up work packages as Epics, which can then be broken down into smaller backlog entries (e.g. user stories) by the agile teams.
For a Digital Equipment Operator, this plan would focus less on the development and manufacturing of the physical product. Instead, it would most likely include a dedicated workstream for managing the retrofit of the solution to the existing physical assets.


== Story Map ==
= Authors and Contributors =
[[File:2.1-Example-Story-Map.png|800px|frameless|center|Example: Initial Story Map]]
{|{{Borderstyle-author}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
<br>
{{Designstyle-author|Image=[[File:Michael Hohmann.jpg|left|100px]]|author={{Michael Hohmann|Title=CONTRIBUTOR}}}}
|}

Latest revision as of 15:57, 29 March 2022

Business ViewpointUsage ViewpointData/Functional ViewpointImplementation ViewpointProduct ViewpointProduct ArchitectureAIoT Business Viewpoint


The Business Viewpoint of the AIoT Product/Solution Design builds on the different artifacts created for the Business Model. As part of the design process, the business model can be refined, e.g., through additional market research. In particular, the detailed design should include KPIs, quantitative planning, and a milestone-based timeline.

Business Model

The business model is usually the starting point of the product/solution design. The business model should describe the rationale of how the organization creates, delivers, and captures value by utilizing AIoT. The business model design section provides a good description of how to identify, document and validate AIoT-enabled business models. A number of different templates are provided, of which the business model canvas is the most important. The business model canvas should include a summary of the AIoT-enabled value proposition, the key customer segments to be addressed, how customer relationships are built, and the channels through which customers are serviced. Furthermore, it should provide a summary of the key activities, resources and partners required to deliver on the value proposition. Finally, a high-level summary of the business case should be provided, including cost and revenue structure.

ACME:Vac Business Model Canvas

The fictitious ACME:Vac business model assumes that AI and IoT are used to enable a high-end vacuum cleaning robot, which will be offered as a premium product (not an easy decision - some argue that the mid-range position in this market is more attractive). AI will be used not only for robot control and automation but also for product performance analysis, as well as analysis of customer behaviour. This intelligence will be used to optimize the customer experience, create customer loyalty, and identify up-selling opportunities.

Key Performance Indicators

Many organizations use Key Performance Indicators (KPIs) to measure how effectively a company is achieving its key business objectives. KPIs are often used on multiple levels, from high-level business objectives to lower-level process or product-related KPIs. In our context, the KPIs would either be related to an AIoT-enabled product or solution.

A Digital OEM that takes a smart, connected product to market usually has KPIs that cover business performance, user experience and customer satisfaction, product quality, and the effectiveness and efficiency of the product development process.

A Digital Equipment Operator who is launching a smart, connected solution to manage a particular process or a fleet of assets would usually have solution KPIs that cover the impact of the AIoT-enabled solution on the business process that it is supporting. Alternatively, business-related KPIs could measure the performance of the fleet of assets and the impact of the solution on that performance. Another typical operator KPI could be coverage of the solution. For example, in a large, heterogeneous fleet of assets, it could measure the number of assets that have been retrofitted successfully. UX and customer satisfaction-related KPIs would only become involved if the solution actually has a direct customer impact. Solution quality and the solution development process would certainly be another group of important KPIs.

Vacuum Robot - Product KPIs

The figure with KPIs shown here provides a set of example KPIs for the ACME:Vac product. The business performance-related KPIs cover the number of robovacs sold, the direct sales revenue, recurring revenue from digital add-on features, and finally the gross margin.

The UX/customer satisfaction KPIs would include some general KPIs, such as Net Promoter Score (results of a survey asking respondents to rate the likelihood that they would recommend the ACME:Vac product), System Usability Scale (assessment of perceived usability), and Product Usage (e.g., users per specific feature). The Task Success Rate KPIs may include how successful and satisfied customers are with the installation and setup of the robovac. Another important KPI in this group would measure how successful customers are actually using the robovac for its main purpose, namely, cleaning. The Time on Task KPIs could measure how long the robovac is taking for different tasks in different modes.

Product Quality KPIs need to cover a wide range of process- and product-related topics. An important KPI is test coverage. This is a very important KPI for AIoT-enabled products, since testing physical products in combination with digital features can be quite complex and expensive but a critical success factor. Incident metrics such as MTBF (mean time before failure) and MTTR (mean time to recovery, repair, respond, or resolve) need to look at the local robovac installations, as well as the shared cloud back end. Finally, the number of support calls per day can be another important indicator of product quality. Functional product quality KPIs for ACME:Vac would include cleaning speed, cleaning efficiency, and recharging speed.

Finally, the Product Development KPIs must cover all of the different development and production pipelines, including hardwire development, product manufacturing, software development, and AI development.

Quantitative Planning

Quantitative planning is an important input for the rest of the design exercise. For the Digital OEM, this would usually include information related to the number of products sold, as well as product usage planning data. For example, it can be important to understand how many users are likely to use a certain key feature in which frequency to be able to design the feature and its implementation and deployment accordingly.

The quantitative model for the ACME:Vac product could include, for example, some overall data related to the number of units sold. Another interesting bit of information is the expected number of support calls per year because this gives an indication for how this process must be set up. Other information of relevance for the design team includes the expected average number of rooms serviced per vacuum robot, the number of active users, the number of vacuum cleaning runs per day, and the number of vacuum cleaner bags used by the average customer per year.

Quantitative Plan

For a Digital Equipment Operator, the planning data must at its core include information about the number of assets to be supported. However, it can also be important to understand certain usage patterns and their quantification. For example, a predictive maintenance solution used to monitor thousands of escalators and elevators for a railroad operator should be based on a quantitative planning model that includes some basic assumptions, not only about the number of assets to be monitored, but also about the current average failure rates. This information will be important for properly designing the predictive maintenance solution, e.g., from a scalability point of view.

Milestones / Timeline

Another key element of the business viewpoint is the milestone-based timeline. For the Digital OEM, this will be a high-level plan for designing, implementing and manufacturing, launching, supporting, and continuously enhancing the product.

The timeline for the ACME:Vac product differentiates between the physical product and the AIoT part (including embedded hardware and software, AI, and cloud). If custom embedded hardware is to be designed and manufactured, this could also be subsumed under the physical product workstream, depending on the organizational setup. The physical product workstream includes a product design and manufacturing engineering phase until the Start of Production (SOP). After the SOP, this workstream focuses on manufacturing. A new workstream for the next physical product generation starting after the SOP is omitted in this example. The AIoT workstream generally assumes that an AIoT DevOps model is applied consistently through all phases.

Key milestones for both the physical product and the AIoT part include the initial product design and architecture (result of sprint 0), the setup of the test lab for testing the physical product, the first end-to-end prototype combining the physical product with the AIoT-enabled digital features, the final prototype/Minimum Viable Product, and finally the SOP.

The following figure also highlights the V-Sprints, which in this example applies to both physical product development and the AIoT development. While physical product development is unlikely to deliver potentially shippable product increments at the end of each V-Sprint, it still assumes the same sprint cadence.

Because sourcing is typically such a decisive factor, the timeline includes milestones for the key sourcing contracts that must be secured. Details regarding the procurement process are omitted on this level.

Example Milestone Plan

For a Digital Equipment Operator, this plan would focus less on the development and manufacturing of the physical product. Instead, it would most likely include a dedicated workstream for managing the retrofit of the solution to the existing physical assets.

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.


Michael Hohmann.jpg
MICHAEL HOHMANN, BSH HAUSGERÄTE GMBH
CONTRIBUTOR
Dr. Michael Hohmann works as a Systems Engineer in the field of autonomous cleaning robots at BSH. After studies in Mechanical Engineering and Measurement Science at TU Ilmenau he joined the Bosch Roxxter development team at BSH robotics department.