Topics In Demand
Notification
New

No notification found.

Co-Creating AIoT: Conquering the Valleys of Death
Co-Creating AIoT: Conquering the Valleys of Death

November 21, 2022

228

1

AIoT: Why co-create when you can do it alone?

AIoT is a collaborative and ecosystem game – then why do organizations attempt to do it all alone? Is it a ”legacy hangover” that they carry to the AIoT products and services?

Because AIoT is a relatively new space, organisations are still finding their footing in order to realise full potential. A typical AIoT product would need multiple players to come together to conceive, develop, and launch a connected product. Because data twins are the foundation of connected products, the diversity and complexity of the technology stack necessitates collaboration among players with deep tech domains, cloud platforms, and connectivity to orchestrate the end-product or service.

What are these ‘Valleys of Death?’

Typical journey of Connected Products Life Cycle has four major phases
 

  • MVC: Minimum Viable Concept or Minimum Viable Business based on an idea. This phase focuses on assessing and validating the feasibility of the concept and business, which is normally done by hacking team who can quickly explore different options and hack a solution to prove the concept.
  • NPE: New Product Engineering to convert the MVC into a product that is reliable to deliver the conceived services and value.
  • NPI: New Product Introduction – Launch the product into the market to scale and develop the required ecosystem. Designing connected products and services are ecosystem plays.
  • Lifetime Engineering: Unlike traditional products, connected products go through lifetime engineering to continuously enhance the value creation, be it in terms of adding more intelligence (AI), extending sensing effectiveness (edge algorithms),or so on.

Transition Awareness: Most AIoT projects go through different product phases without transition awareness of shifting to different phases in terms of Product Lifecycle Management (PLM) shift and capability needs, and fall into “Valleys of Death”.

Transition from Concept to Product Engineering
PLM Shift: The concept phase is where the feasibility is ascertained, whereas a quick shift in focus is required to achieve reliability in the product engineering phase. As the AI algorithms need data to train and learn, in the AIoT space, Beta itself becomes a product. This means the measurement and tracking of product performance and quality can become tricky and pose dilemmas for the classical QG processes.

 

Capability: The concept phase is driven by tech geeks from multiple disciplines in a happy engineering mode to prove the hypothesis, whereas in the product engineering phase, the required team composition is seasoned professionals proficient in reliability engineering with equal exposure to the technology stack.

Transition from Product Engineering to Connected Product Introduction

PLM shift: Connected Product Introduction requires a shift to establish a partner ecosystem and associated contractual and legal processes for accountability and service delivery. The need is to establish a feedback loop to continuously learn and improve the connected product/service. This implies that the product is continuously evolving, hence the product engineering continues throughout the product lifecycle. Since the connected product is ‘phygital’, disruptions in digital technologies will directly impact the product landscape and the value creation. This demands the PLM strategy to be continuously adaptive to enable the continuous product evolution.
 

Capability: The Connected Product Introduction phase requires a team proficient in operations, marketing, business models, and legal to drive the product/services operations at scale. As the connected product continues to evolve, the product engineering team will continue to focus on the product evolution.

Conclusion: It is important to be transition aware through these phases in terms of PLM and capability shifts.

One needs to adopt a multi-speed model to navigate through these phases, with clear ‘Transition Awareness’ to operate in the right gears. To manage capability shifts, one needs to operate in a multi-threaded model covering classic product engineering to technology (AIoT) fusion.

Original blog was published at  BOSH website

About the author:

" "

 Srinivasulu Nasam, Regional Head, India – IoT and Digitalization, BGSW

 

That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.