Related Expertise: デジタル/テクノロジー/データ, Internet of Things
In the modern industrial age, the principal model for organizing economic activity has been linear value chains running from component supplier to OEM to end customer. The Internet of Things (IoT) presents a new opportunity for value creation—and a risk for those who ignore it.
The opportunity: industry incumbents that aggregate data from their own products or their customers’ business processes can establish an IoT platform or ecosystem business that serves a single- or multi-industry user base. (See the sidebar, “Defining Platforms and Ecosystems.”) Other companies can contribute data, products, and services to make the platform more valuable. Platforms and ecosystems have the potential to dramatically alter linear value chains by breaching industry barriers and establishing new value pools.
The risk: incumbents that do not participate in the new IoT models could become mere suppliers of commodity hardware and see their customer relationships erode.
Here’s how we think a major transformation in the B2B industrial economy will play out.
Two primary drivers for IoT ecosystem formation, both powerful forces, are taking shape. Customers seeking to lower implementation costs and scale up solutions in their own businesses are creating demand-side pull. Meanwhile (and partly in response), supply-side industry incumbents are partnering with technology companies to deliver industry-specific platforms, push standards, and aggregate use cases into broader solutions. Both forces are fueled by network effects, which strengthen the size and quality of ecosystems; data aggregation, which enables companies to turn data into competitive advantage; and data models, which ease the replication of IoT solutions across multiple customers.
Demand-Side Pull. For enterprise customers struggling to implement IoT solutions, it’s a heavy lift. They need to build their own customized solutions or integrate solutions from multiple suppliers. Both paths involve a host of tasks and plenty of participants. For example, a company must implement an IoT platform to aggregate machine data and provide the IoT application development environment. The same company has to work with a telecommunications or network equipment provider to connect its equipment and transmit data to the cloud. A systems integrator is required to integrate the IoT platform with other enterprise applications. And cybersecurity providers are needed to secure the entire IoT architecture, from the deployed sensors and equipment to the network and cloud environment.
It becomes very clear very quickly that implementing IoT solutions at scale can be more efficiently addressed by an ecosystem approach that makes the requisite solutions readily available, lowers integration costs, enables data aggregation, and delivers a secure infrastructure.
Supply-Side Partnering. To meet this demand, technology firms and leading industrial companies have been partnering to build ecosystems that take advantage of each other’s core capabilities. These partnerships address multiple objectives: establishing common data and technology standards, developing IoT solutions based on industry templates, enabling independent software vendors to develop additional solutions, mounting joint go-to-market programs, and driving IoT adoption within a specific industry. (See Exhibit 1.)
Take the example of Microsoft, which is working with OEMs in multiple industrial segments, including elevators (Schindler, ThyssenKrupp) and industrial automation (Honeywell, Schneider Electric, and ABB), to establish IoT platforms specific to industry verticals. In each instance, the industry incumbent brands its own platform (for example, Honeywell Forge, Schneider Electric EcoStruxure). The industrial OEM then draws on Microsoft’s technological capabilities and codevelops solutions using the tech giant’s investment in cloud infrastructure and tools.
In another example, Airbus has partnered with Palantir to build Skywise, an IoT platform that aims to improve the operations of airlines. As more such partnerships are formed, the suppliers to the large OEMs face increasing pressure to join the OEMs’ platforms. For example, Volkswagen plans to encourage its supplier base to join the Volkswagen Industrial Cloud, an IoT platform formed with Amazon Web Services (AWS) for the automaker’s more than 120 factories. The ecosystems that set data standards (one of the goals of the Volkswagen Cloud) will be able to aggregate data and apply analytics at scale to address a variety of use cases and unlock the value of machine data.
In the early days of enterprise software, companies developed custom code to automate business processes. Over time, third-party software companies offered less expensive and more capable enterprise applications, such as ERP (enterprise resource planning), MRP (manufacturing resource planning), SCM (supply chain management), and CRM (customer relationship management). We expect a similar pattern of development with the emergence of IoT applications that target the use cases unlocked by machine data. Several structural factors will shape the value pools and ecosystems of IoT application providers. (See Exhibit 2 and the appendix, which examines the IoT value pools forming in five industry sectors with different dynamics.)
Use Cases Benefiting from Network Effects. A substantial number of high-value use cases, in a single industry or spanning a group of industries, that benefit from network effects can constitute the basis for a platform marketplace connecting buyers and sellers. For example, Zira, an industrial IoT startup, has created a marketplace of customers and equipment suppliers with a platform that triggers automatic work orders for maintenance and repair in response to equipment data indicating machine failure. As more customers connect a wider variety of equipment to the marketplace, Zira and its suppliers can offer new services such as asset sharing and benchmarking of equipment reliability. Once a robust market of suppliers and buyers is established, third parties can offer innovative services and solutions and Zira can make it easier for these participants to develop new services by providing data and other development services.
Use Cases Requiring Data Aggregation. There are entire categories of use cases that require aggregation of data from multiple parties. For example, operational benchmarking (such as when a company benchmarks its maintenance strategy against those of its peers) will be most valuable if the data set is large, comparable, and as comprehensive as possible with respect to the operational dimensions it includes. Companies that aggregate data from multiple sources benefit from both network effects and economies of scale as they amortize the fixed costs of defining data standards and application programming interfaces (APIs). Third-party data-as-a-service providers can help overcome such challenges as collection cost, data that is perishable or time-sensitive, data that is controlled by multiple companies, and the need for anonymization.
In many refineries and factories, multiple components and assets work together to improve throughput; the dependencies along the production process require aggregation of data from devices and sensors belonging to multiple suppliers. Honeywell’s INspire program has recruited multiple oil and gas component suppliers to share data with the Honeywell Forge platform to deliver software solutions, data, and algorithms that optimize entire processes in an oil refinery.
The Need for Standards. Data and communication standards lower integration and aggregation costs and enable solutions to scale across customers and suppliers. For example, the Society of Automotive Engineers established the J1939 data standard for transmitting vehicle data from all commercial trucks in the US, regardless of manufacturer. This enabled fleet management companies to offer plug-and-play telematics hardware and software that tracks location, fault codes, fuel levels, and other truck data. Without this common standard, each fleet management company would have had to develop software to translate proprietary data from different truck models. Standards also exhibit direct network effects: once adoption of the standard reaches a tipping point, it becomes uneconomical for companies to develop solutions incompatible with the standard or to promote alternative standards.
Fragmented Customer Base. A highly fragmented customer base will benefit from data aggregation, network effects, and reuse of solutions. Customers are unlikely to have the resources needed to build their own IoT-based solutions and will seek to join third-party platforms. The aggregating demand and data from customers helps solutions providers lower their customer acquisition and integration costs.
The combination of these factors drives platform competition toward three potential outcomes. In each, the value pools are divided up differently:
In all cases, however, the ecosystems will comprise companies that play three distinct roles. (See Exhibit 3.) Orchestrators will own the platform and establish the ecosystem. These companies will typically be incumbents with a strong right to win. Contributors will develop and sell specific solutions on the platform. Enablers will provide infrastructure or common platform services but will not be unique to a given vertical.
Our colleagues at the BCG Henderson Institute studied a broad set of ecosystems and discovered that only a minority (about 15%) of orchestrators achieve the critical mass necessary to succeed. To be a successful orchestrator requires investment, commitment, and continual renewal of the value proposition. The majority of companies will therefore be contributors, a role that can have a very attractive risk-reward profile of its own because solutions can be developed and sold across multiple ecosystems to maximize reach and revenue growth. Here’s our analysis of the specific moves required to build winning positions in each of the three roles.
Orchestrators and Contributors. Orchestrators orchestrate. They have the resources and capability to invest and operate a platform. They recruit contributors and enablers (by partnering with technology companies, for example). They define the governance model and value sharing rules, establish the legal framework surrounding data and intellectual property, set the standards (for data, communication, APIs, and the like), and provide common tools to make it easy to develop new solutions.
Contributors increase the value of the ecosystem by bringing unique data sets or intellectual property, engaging in codevelopment with the orchestrator, or building solutions on the orchestrator’s platform. Contributors can sell their solutions via the orchestrator’s platform, generating network effects for the ecosystem by increasing its value to customers. For example, SkyFoundry, a connected-building startup, offers a set of white-label building-specific data and analytics solutions to its building automation OEM partners, each of which has its own platform. SkyFoundry’s solution is offered on multiple, competing ecosystems. SkyFoundry is better off joining the ecosystems orchestrated by major building automation OEMs because the OEMs have oligopolistic market share (and thus access to building data), deep relationships with building owners and operators, and, in some cases, the ability to “close the loop” by automating control of building equipment. By joining these ecosystems, SkyFoundry can access a bigger customer base and differentiate the value proposition of its OEM partners’ connected-building platform and software suites.
Enablers. Enablers are companies that provide the generic underlying technology capabilities (such as cybersecurity, connectivity, and billing functionality) for an IoT ecosystem. While enablers can differentiate themselves from one another on the basis of features and functionality, they offer common solutions because the same underlying technology needs apply across industry verticals.
For business leaders with the ambition to become orchestrators, there are three potential paths, each with a different starting point, for attracting customers and contributors and building critical mass. (See Exhibit 4.)
Innovation Platforms. Some orchestrators begin by launching an innovation platform. If companies are incumbents with a strong right to win, they will have large equipment data sets (from their installed base of customers) and can create APIs and software development kits to enable third parties to build complementary solutions that widen the scope of addressable use cases.
Given the inherent complexity and heterogeneity of equipment and data, creating the necessary data standards can be challenging. Almost every industrial customer—a trucking company, a manufacturer, a farmer, or a building owner—operates a set of assets supplied by multiple OEMs. A successful orchestrator must cooperate with multiple equipment OEMs to create data standards and interfaces that enable integration and interoperability to drive innovation.
Transaction Platforms. If there is a preponderance of IoT use cases that exhibit network effects, orchestrators can start with a transaction platform to establish a marketplace that connects buyers and sellers of data, software, or equipment and spare parts. Most OEM incumbents already offer parts and equipment through online marketplaces or their dealer network. IoT data unlocks insights into the customer’s operations and equipment health to enable better inventory planning and potentially more customized marketing offers. With a deeper understanding of the customer’s operations, based on a customer’s transaction data, OEMs can recruit third parties to sell complementary goods and services. Farmers Business Network (FBN), for instance, expanded its e-commerce marketplace from seeds to chemicals and spare parts. Alternatively, OEMs can create asset sharing marketplaces, leveraging equipment data (such as location and usage) to enable customers to monetize higher equipment utilization by renting their asset to others.
As a transaction platform scales up, it may evolve into an innovation platform as it aggregates data, making it possible for independent software vendors to build and market new solutions. For example, Avnet, a distributor of electronic components for equipment manufacturers, has partnered with Microsoft Azure to launch a platform that offers advisory services, APIs and software development kits, prebuilt IoT applications, embedded software, and a program to accelerate the adoption of IoT solutions by customers. Avnet has moved from a strictly transactional platform to enabling innovation and the reuse of solutions in an innovation platform.
Over time, orchestrators’ platforms tend to evolve toward providing both innovation and transaction functionality, which enables third parties to build and monetize IoT solutions. Orchestrators can leverage the transaction data generated by the platform’s marketplace to gain a deeper understanding of which products and services are gaining traction and use that insight to inform future decisions. A key question for orchestrators to ask: Which solutions do we develop ourselves and which do we look to contributors to develop? Over time, orchestrators building innovation platforms can adopt an “embrace, extend, extinguish” strategy in which they initially support a third-party solution but then build a competing application and integrate the solution into their own proprietary offering. This approach, however, carries the inherent risk of alienating contributors and sending them to competing platforms.
Data Aggregation. Another starting place is aggregating data, which creates the option of building either a transaction platform or an innovation platform. Otonomo began as a startup, aggregating connected-car data from a variety of OEMs in order to address data-driven use cases for insurance companies, municipalities, and other customers. Then it created a set of APIs, developer documentation, and such value-added services as data anonymization to enable customers to build apps using Otonomo’s aggregated data set. In precision agriculture, Farmers Business Network has pursued a similar approach, initially aggregating data from farmers and offering benchmarking services. It then created a transaction platform that aggregates demand from its members and suppliers. FBN has been able to apply machine learning techniques at scale across its aggregated data set to recommend which seeds to plant to optimize yield. Farmers can buy the necessary seeds and other materials through the FBN marketplace.
Not all companies have the ability or requisite investment appetite to be an ecosystem orchestrator. But they may still have valuable IoT-enabled solutions to offer. For these companies, becoming a contributor is a viable path to capturing a piece of the IoT value pool. Moreover, contributors can participate in multiple IoT ecosystems, but they need to consider how to de-risk their relationships with orchestrators to avoid two potential pitfalls: product commoditization and orchestrator lock-in. Several strategies can help.
The first is to specialize in truly differentiated capabilities (such as IP and data) that cannot easily be replicated by the orchestrator. Senseye, a startup providing predictive maintenance analytics for rotating equipment, leaves the data integration and device management to its orchestrator’s platform and instead focuses on developing better-quality predictive algorithms that use proprietary machine learning approaches.
Second, contributors should pay close attention to an orchestrator’s announced product roadmap and be wary of investing in use cases that are close to those that the orchestrator is itself targeting. For example, numerous industrial IoT platforms have released application suites and services that target asset and process optimization in manufacturing. While the platform vendors are addressing only a limited set of use cases today, we can expect that they will expand their offers over time. Contributors with similar solutions could find that the orchestrators absorb their offers in future platform functionality.
Third, contributors need to sustain investment in innovation. SkyFoundry focuses its efforts on product development and leverages orchestrators’ platforms for distribution. In industries with fragmented customer bases, long sales cycles, and complex value chains, using a platform as a distribution channel can reduce contributors’ go-to-market costs.
Contributors within the same industry can also collaborate to build their own innovation platform and then resell the solutions through multiple orchestrator transaction platforms. For example, several European machine tool manufacturers (such as Karl Mayer, Engel, and Dürr) formed a joint venture, Adamos, with technology provider Software AG. The machine tool manufacturers used the platform to develop a set of IoT applications that they sell through multiple other platforms, including their own application marketplace.
Platform and ecosystem co-opetition will ultimately become the norm in industrial IoT, with new value pools emerging from clusters of use cases and new categories of software that addresses these cases. The question for top management is this: Does your company have a clear strategy to win, either as an orchestrator or a contributor?
To better understand the likely development of platforms and ecosystems in B2B industrial sectors with different dynamics, we took an in-depth look at five sectors: precision agriculture, commercial buildings, automotive (with a focus on autonomous vehicles), trucking, and manufacturing automation. We explored the range of potential use cases in each and the degree to which they benefit from network effects and data aggregation. The frequency and value of use cases that benefit from both indicate the potential for platforms and ecosystems and whether there will be a consolidation trend. (See Exhibit A1.)
Conditions favor IoT platform adoption in agriculture. Farmers have a clear need to improve productivity and yield, and adoption of precision sensors, drones, advanced analytics, and autonomous equipment connected to data aggregation platforms is already on the rise. Farmers own their data and can choose multiple parties for data sharing on the basis of the solutions and services these parties provide.
Among the 50 precision agriculture use cases in our analysis, few inherently exhibit network effects, but 17 (35%) benefit from data aggregation. For example, customers of Farmers Business Network (FBN), which is backed by more than $200 million in venture capital, share anonymized data (such as seed prices, historic yields, and chemical and fertilizer treatments) with FBN in return for operational benchmarks. Using these benchmarks, farmers can compare input prices and see the yields of similar farmers, helping them negotiate with input distributors and retailers and optimize their farming practices.
FBN has generated network effects throughout its business model. As more farmers share data, the validity and scope of the benchmarks improve. Moreover, FBN has built an e-commerce marketplace (a transaction platform) where farmers can purchase seeds, chemicals, and equipment from FBN or third parties. As the number of third-party sellers increases, farmers get a wider selection of inputs from which to choose, and sellers can reach a larger number of farmers. The fragmentation of the farming customer base enhances both the value of data aggregation and the value of a transactional marketplace. (About 90 farms, each with more than 2,000 acres, work 60% of the land in the US, while about 1,900 small and midsize farms work the rest, according to USDA.)
In agriculture, there are relatively mature efforts to drive data standardization. Ag Gateway, a nonprofit consortium with more than 200 member companies, including John Deere, AGCO, and Monsanto, has developed the ADAPT framework, which acts as a common data model, API standard, and set of open-source and proprietary data plug-ins that enable precision agriculture software to integrate with data generated by many different types of farming equipment. Over time, as these standards mature, we expect new entrants providing precision agriculture point solutions to enter the market and potentially join the ecosystems forming around major precision agriculture platforms. John Deere has a suite of APIs for third-party developers and has released a precision agriculture marketplace where farmers can contact companies selling farming software that leverages data from Deere’s farming equipment.
New types of data are also becoming available—from unexpected sources. Airbus, the aircraft manufacturer, offers a set of API services that provide crop analytics based on satellite images. These services, delivered via a precision farming software portal, enable Airbus to act as an analytics supplier to precision agriculture manufacturers and software vendors. In the future, the fusion of satellite and farmer-owned data, aggregated on a platform such as FBN’s, will further enhance analytics for crop optimization. While FBN could emerge as a dominant platform and ecosystem, it faces competition from the platforms of incumbent players such as John Deere and Monsanto’s Climate Corp.
Going forward, we expect to see a few, complementary precision agriculture platforms remain, with some, such as FBN, focused on specific parts of the value chain (crop procurement and sales, for example), others focused on managing farm equipment, and yet others on crop analytics. These platforms can coexist, with farmers sharing data with multiple platforms for different uses. But farmers will share sensitive crop data only with platforms that do not violate their trust by reselling data to third parties that could use the data in ways that are not in the farmers’ best interest. For example, a recent case concerned the potential use of farm and soil productivity data to increase land lease prices. Platform providers face the strategic questions of how to engage farmers to share data, which use cases to address, and how to monetize the data without violating farmers’ trust. The answers will shape the evolution of the competitive landscape.
In the commercial building industry, there is potential for connected-building solutions to deliver compelling value propositions to developers, landlords, builders, tenants, and others. Connected HVAC and lighting systems can reduce energy costs, which can account for 40% of a building’s total operating costs. However, there are fewer use cases that benefit from network effects and data aggregation than in other verticals. Of the 65 use cases in our analysis, only seven—among them smart parking, flexible workspace allocation, identity management, and predictive signage—exhibit network effects.
The data standards in commercial buildings are less mature than those in the precision agriculture sector. Every connected building is filled with equipment and systems from multiple OEMs; one supplies the lighting, another the HVAC system, and others the elevator, access control, and security systems. Each system, if connected, transmits data in different formats. Existing building management software cannot easily integrate data across different equipment types without a significant system integration effort. Innovation platforms with open APIs are not yet available in commercial buildings because there is no common data model across the sector’s domains and equipment suppliers.
The fragmented commercial building customer base—in New York City, for example, the top five building owners own only about 2% of the commercial square footage—and the lack of standards and APIs make it difficult to implement industrywide solutions.
This may be changing as equipment and building management software OEMs identify opportunities to promote data standardization. For example, Siemens is supporting Project Haystack, a nonprofit consortium that has built a common framework for tagging building data. Johnson Controls, a provider of HVAC and fire safety equipment, is supporting the Bricks Schema, another open-source effort to build a common data model for the building industry. Haystack and Bricks are both working with established industry bodies to integrate their data models into new building specifications. As standardization efforts progress, we expect to see major building controls OEMs offer platforms with similar suites of building applications, essentially forming a competitive oligopoly with little room for new entrants.
With the advent of new mobility models enabled by rideshare platforms and vehicle autonomy, change in the automotive industry is accelerating dramatically. The rapid rise of connected vehicles and the resulting flood of data across OEMs point to a ripe opportunity for data aggregation across highly fragmented sets of consumers and car manufacturers. Of the 49 use cases we analyzed, 31 demonstrate either network or data aggregation effects. We focus specifically on autonomous vehicle (AV) development as an underlying technology trend with significant implications.
Multiple platform scenarios are possible in the AV technology stack, depending on which layer is under consideration: the AV software stack running in the car, the high-definition mapping layer, or the fleet management level. (See Exhibit A2.)
Autonomous Driving Software. The AV software companies with first-mover advantage can collect large driving data sets to develop more reliable software by covering more “edge cases.” They can then deploy autonomous vehicles at scale and pursue platform-based business models, such as licensing their software to multiple OEMs or to rideshare companies for application in robotaxis or last-mile delivery use cases. For example, if Waymo (Alphabet’s autonomous driving venture) can develop such an advantage in software performance and reliability, it has the potential to become the digital operating system for the autonomous automotive industry. (GM’s Cruise, another autonomous driving enterprise, could well have something to say about that.)
High-Definition Mapping. HD mapping may become a winner-take-most data aggregation platform because there are clear economies of scale in map creation and maintenance. In this scenario, multiple makers of autonomous vehicles would license HD maps from a sole provider, analogous to mapping software provider HERE, which is owned by a consortium of Mercedes, Audi, and BMW and competes with Google Maps. Numerous other specialized mapping providers and consortia have formed. For example, Toyota, Aisin, and Denso have put together a group that OEMs can join. They share their raw camera data and, in return, can access the HD maps created from the consortium.
Creating HD maps is complicated because there are no common data standards, and each car model produces its own mapping data based on its specific sensor configuration (which involves camera, LIDAR, or radar and different sensor locations). Fusing data from different vehicles’ sensor stacks to create an aggregate map is technically challenging, and numerous autonomous vehicle and mapping companies are redundantly mapping the same territories. Governments, such as the UK, are encouraging the formation of common mapping standards and data sets to mitigate these inefficiencies. A startup from Silicon Valley, DeepMap, has developed HD mapping software that can process data from a variety of sensor configurations. As the underlying sensor and hardware stack for self-driving vehicles continues to evolve, being able to generate HD maps from, and for, various types of autonomous vehicles will be a competitive advantage for DeepMap if the company has truly solved the data fusion challenge. If mapping data can be fused, then network effects also come into play as multiple OEMs can contribute their data, making the data sets more accurate at the same time. If technical challenges can be overcome, HD mapping could be a winner-take-all platform.
AV Fleet Management. The fleet management layer of the AV technology stack may become a transaction platform, operating much like the consumer ride hailing platforms Uber and Lyft, to connect drivers and riders. Companies such as RideOS have already developed sets of APIs that are specific to ride hailing to enable third parties, including autonomous car manufacturers and cities, to implement their own ride hailing platforms. Because drivers and riders can use and easily switch between multiple ride hailing platforms, they exhibit weaker localized network effects, and multiple autonomous vehicle fleet management platforms can coexist.
Of the 41 telematics use cases we analyzed from the trucking industry, roughly 40% exhibit network effects or benefit from data aggregation. The combination of industry data standards, such as J1939, and the fragmentation of trucking fleets has spurred rapid innovation in the industry.
Three types of platforms address different use cases in commercial trucking: load boards, digital freight brokers, and fleet management application marketplaces. Load boards provide real-time postings of available trucks and cargo shipments, enabling carriers to find loads to transport (an example of indirect network effects). Using machine learning algorithms and aggregated data, digital freight brokers (which have raised more than $600 million in venture capital funding over the past five years) seek to disintermediate the traditional broker model through automation. To do so, they will need to overcome the fragmentation and heterogeneity of carrier truck fleets and shipper needs. Carriers, for example, often operate on specific lanes in a given geography, and shippers frequently have specific requirements, such as safety ratings or equipment types (flatbed or refrigerated trucks, for example).
Fleet management applications have existed for years, but by aggregating data from trucks across fleets, management companies such as Geotab have created platforms and app marketplaces that enable innovation in the industry. For example, Geotab aggregates fuel economy data across truck types and enables carriers to compare their fuel economy performance with that of similar vehicles and industry benchmarks.
The advent of autonomous trucks combined with digital freight platforms may accelerate consolidation of platforms by altering how carriers and shippers transact. In addition to replacing the driver, autonomous trucks reduce the need for human dispatchers. Autonomous trucking companies can develop APIs that integrate with digital freight brokers. Shippers will be able to automatically book the capacity of a truck via APIs instead of human brokers. The necessary scale and investment in both autonomous trucks and digital freight platforms could drive consolidation in the carrier industry and convergence or interoperability among digital freight brokers, fleet management platforms, and autonomous trucks. As autonomous trucks lower total cost of ownership and generate more revenue (they can operate 24/7), the largest carriers will gain substantial economies of scale over smaller competitors that still rely on human drivers and could rapidly gain market share. We expect that, over time, significant consolidation of trucking platforms or interoperability across different platforms will maximize network effects.
Manufacturers have embraced IoT solutions to enhance their operations. Most companies with an industrial software and controls heritage, such as Siemens, Emerson Electric, Schneider, ABB, Honeywell, Bosch, and Rockwell Automation, have launched or taken equity stakes in IoT platforms that improve their customers’ operations and processes.
In our analysis of 51 use cases in manufacturing, however, less than 5% exhibit network effects, while 20% exhibit potential for data aggregation. For example, automated spare parts procurement and inventory management show network effects. Data aggregation use cases include operational benchmarking; customers can compare their average mean time to repair (MTTR) of equipment with peers based on anonymized customer data. Other use cases in manufacturing suggest strong potential for cross-company data sharing.
To make it easier to implement use cases and access third-party solutions, providers such as Schneider have built both transaction and innovation platforms. On Schneider’s Electric Exchange, for example, users can share information via Q&A forums, developers can access software development kits, and customers can access potential suppliers, including third-party independent software vendors. However, while these efforts support the development of new platform-accessible solutions, they do not address the fundamental challenge of scaling IoT solutions within a customer.
Multiple equipment providers offer IoT platforms. But the last thing a manufacturer wants is multiple industrial IoT platforms that all offer native connectivity and data modeling capabilities for the provider’s equipment but only limited integration with third-party equipment. Multiple costly platforms weaken the business case for IoT use. (A 2019 Microsoft-sponsored survey indicated that roughly one-fifth of IoT proofs of concept fail because there are “too many platforms to test.”)
Customers lack the in-house talent to build and integrate end-to-end IoT solutions from multiple providers. To overcome this issue, platform providers and equipment OEMs are partnering to lower integration costs and aggregate use cases into broader enterprise applications that address a larger value proposition.
Customers can follow a few paths in implementing IoT solutions. (See Exhibit A3.) One is to adopt a single IoT platform and bear the integration and complexity costs of connecting their equipment and plants and modeling their operations. In this approach, customers can leverage only their own data for analytics, limiting the potential value of the platform.
A second option is to adopt multiple point solutions, each with native connectivity and data modeling capabilities covering particular types of equipment but limited integration across platforms and equipment types. If the point solutions are provided by the equipment OEM and the OEM is aggregating data across its customers’ installed base, then the OEM should be able to access a much larger data set and provide better analytics-based solutions. In this situation, the customer benefits from OEM knowledge and data, but the solutions are not integrated to optimize end-to-end processes.
To address this tradeoff, industrial IoT platform providers can strike partnerships with equipment OEMs, which enables solutions that access all equipment data from each OEM across the customer’s manufacturing plant network and integrates data for the customer at the cloud level. Use cases requiring machine data from multiple OEMs—such as production process optimization that improves throughput, reduces scrap, and enhances quality—can be unlocked more easily. A customer can use one IoT platform to access multiple OEM equipment data streams and solutions and build end-to-end process models. This should significantly reduce the cost and complexity of implementing use cases.
In addition to reducing the integration cost involved in accessing shopfloor equipment data, platform providers can aggregate use cases into new enterprise applications. Just as we have seen enterprise software solutions evolve from customized company-specific code to enterprise applications such as ERP, MRP, SCM, and CRM, we now see six new categories of IoT applications emerging: asset optimization, process optimization, industrial worker productivity, energy management, augmented reality, and industrial cybersecurity. (See Exhibit A4.) The benefit of these new application classes is that they package individual point solutions into broader value categories that generate a more attractive return on investment, provide more mature functionality, and reduce the cost of implementation.
But the industrial incumbents launching IoT platforms do not have a monopoly on the market; they both partner and potentially compete with “hyperscalers” such as AWS and Microsoft Azure. Almost every industrial IoT platform leverages infrastructure-as-a-service (IaaS) in the public cloud. Honeywell, Schneider, ABB, and Emerson all position themselves as IoT solution providers, based on their decades of domain expertise in their core verticals, but they all embed Microsoft Azure’s platform-as-a-service (PaaS) capabilities within their industry-specific platforms. Siemens and PTC emphasize their own IoT platforms and are recruiting developers to build IoT applications for their proprietary platforms. For example, PTC offers IoT solution “building blocks” (such as domain-specific business logic and common user-interface elements) as well as a suite of connectors with enterprise systems to accelerate and simplify IoT application development for its customers and partners. Bosch has taken a different path, leveraging an open-source IoT platform, Eclipse, to build its offering—trying to follow the model of companies such as Red Hat in the technology industry by enhancing open-source software with support and maintenance services.
With substantial R&D budgets and a history of rapid innovation (Microsoft launched more than 100 new IoT services on Azure in 2019), platforms continue to evolve. The hyperscalers are investing in new IoT capabilities. For example, AWS’s IoT SiteWise service enables communication with industrial controls via the manufacturing-specific OPC-UA protocol and comes prepackaged with dashboarding capability to, among other things, monitor overall equipment effectiveness. As hyperscalers cocreate IoT solutions with customers, they may start offering their own IoT-based enterprise applications. An AWS executive observed at a recent developer conference that a “long list of product ideas” came from the joint AWS-Volkswagen Industrial Cloud partnership. Whether the hyperscalers or the vertical-specific industrial IoT platform providers ultimately prevail is an open question based on the degree to which the hyperscalers choose to compete with some of their largest industrial customers.
The authors are grateful to Patrick Su, Claire Wu, Tazia Middleton, Moira Scanlon, Natnael Kassaw, Bernhard Siegert, and Parth Tripti for research and analysis supporting this publication. They also thank David Duffy for his help in writing this report and Katherine Andrews, Kim Friedman, Abby Garland, Adam Giordano, Frank Müller-Pierstorff, Shannon Nardi, and Ron Welter for their assistance in editing, design, and production.
The BCG Henderson Institute is the Boston Consulting Group’s strategy think tank, dedicated to exploring and developing valuable new insights from business, technology, and science by embracing the powerful technology of ideas. The Institute engages leaders in provocative discussion and experimentation to expand the boundaries of business theory and practice and to translate innovative ideas from within and beyond business. For more ideas and inspiration follow us on LinkedIn and Twitter: @BCGHenderson.