More...More...More...More...More...More...More...More...Sourcing

The acquisition of the required technologies and resources is probably one of the most critical parts for most AIoT projects. Many project leaders -- and many procurement departments -- do not have much experience in this space, which is why this part of the book aims to provide a structured approach to the problem (in combination with a set of useful templates).

The approach described here covers typical sourcing challenges, introduces a generalized sourcing process for AIoT products/solutions, discusses make vs. buy vs. partner, introduces the concept of an AIoT Sourcing BOM, helps define vendor selection criteria, covers the RFP document creation and management, and finally looks at vendor selection.

Challenges

Before looking at the details of the sourcing strategy and process, we must first understand the challenges associated with AIoT sourcing and procurement. An AIoT project is often a complex undertaking. On the business side, many different stakeholders must be aligned, often contradicting requirements must be managed, and existing business processes will have to be re-engineered. On the technology side, a multitude of new technologies and methodologies must be made to work together. In case of a line-fit solution, exiting or new manufacturing capabilities must be aligned with the needs of the AIoT solution. And finally, the solution roll-out and service operations must be prepared and managed.

So what can go wrong? A lot, especially if the project management is not paying close attention to the digital supply chain. Selecting the wrong vendor or the wrong technology for all or parts of an AIoT solution can have ripple effects that put the entire project in danger. The same applies to over-specifying or under-specifying what is needed. Poor implementation services or badly defined SLAs (Service Level Agreements) can lead to bad user experience and stability problems. If these problems are only found out after the roll-out, this can put the entire business at danger. The list of sourcing-related challenges also includes issues with adapting to change, allowing poor quality for lower costs, ignoring the costs of time, ill defined sourcing and procurement processes with unclear responsibilities, project management issues, complex organizational dependencies, and loopholes in contracts.

Especially for industrial companies, dealing with AIoT-related topics from a sourcing point of view can be challenging:

  • How to support agile development with matching pricing model and contracts?
  • How to deal with new paradigms such as AI, and the required SLAs?
  • Can AI-based solutions be treated like software-based solutions from a sourcing point of view, or do they need a different approach?
  • How to manage dependencies between different suppliers, e.g. for hardware and software?
  • How to avoid vendor lock-in due to 'accidental' technical dependencies?

RFPs (Request for Proposals) play an important role in many sourcing projects. Depending on the chosen sourcing strategy, a number of different RPFs will be required, especially if different technologies and resources will be acquired from different suppliers. One should not underestimate how unpredictable and difficult to manage RFP projects can be, and how often they miss their deadlines. Carefully aligning the required RFP projects with your development plans will be a key success criteria for your project. One aspect here simply are the timelines for running the RFP and securing suitable vendors. Especially in larger enterprises, another aspect are the complexities of sourcing decisions in complex political environments.

AIoT Sourcing Process

The first important step towards successful technology and resource acquisition is to define a high-level process, which needs to be aligned with all key stakeholders: AIoT project team, procurement, legal, and often senior management. The process proposed here is based on the assumption that it will be centered around a Request for Proposal (RFP), and has five main elements: sourcing strategy and planning, RFI (optional), RFP creation, RFP distribution, and AIoT vendor selection.

AIoT Sourcing Process

Procurement strategy and planning needs to look at the most important aspects of the AIoT solution (including stakeholders, scope, and requirements), as well as the implementation project (timeline, key milestones, and budget). As part of the sourcing strategy, the make vs. buy question must be addressed. Depending on the outcome of this decision, the creation of a specialized Sourcing BOM (a breakdown of all required elements of the solution) should be considered. Furthermore, vendor profiles, sourcing criteria, and the actual sourcing process (including timelines) should be defined.

During the RFP creation phase, a concise RFP document must be created, reviewed with all internal stakeholders, and often formally approved.

After completion of the RFP document, it will be distributed to the target vendors. In some cases, it will also be made publicly available. Managing the RFP process will usually involve a structured Q&A process with all interested suppliers.

Finally, the vendor responses must be evaluated. Often, vendors are invited for individual vendor presentations. Based on this information, a first set of vendors can be pre-selected. In some cases, smaller Proof-of-Concept projects are done with these vendors. Based on the outcomes of the PoCs, a short-list can be created. Often, the last few vendors are then asked to do a more extensive pilot project. Based on the technical and functional evaluation, as well as extensive price negotiations, the final selection is then done.

AIoT Sourcing Strategy

Defining the sourcing strategy is an important first step. This section will cover strategic sourcing options (make vs. buy. vs partner), the AIoT Bill of Materials, the AIoT Soucing BOM, and finally the alignment with the development schedule.

Strategic Options: Make vs. Buy vs. Partner

The decision for a specific sourcing strategy is a fundamental one and will be shaping your AIoT-enabled business for the years to come. Giving up too much control over the production process for a strategic product can be as problematic as investing too many own resources in the development of commodity technologies and failing to build truly differentiating features on top.

So what are the options? For the purpose of our discussion, we have identified three strategic sourcing options:

  • Internal Development: This option basically assumes that only commodity technology like middleware or standard hardware components will be externally sourced, but all custom development (including software and hardware) will be done internally.
  • Acquire & Integrate: This option assumes that only the high-level design and component integration will be done internally, while all sub-components (hardware, software) will be acquired from external sources.
  • Turnkey Solution: This option assumes that an external provider will be selected to provide a complete solution or product, based on the requirements defined by the ordering organization. This can either be a complete custom development, or the customization of a standard solution / Commercial-Off-the-Shelf product. Typically, in this case the supplier is not only responsible for the implementation, but also for the design.

These three options are only examples. Other options such as co-innovation or Build-Operate-Transfer can also be interesting. However, these three examples should provide a good starting point for the discussion in the following.


AIoT Sourcing Options

So how to decide for the right sourcing option? One key factor is the strategic relevance of the AIoT-based product or solution. An auxiliary system with little direct impact on the business could probably best be acquired as a turnkey solution. A strategic product that will be responsible for a large part of future revenue will most likely require much more control over the product`s design and value chain, and thus lend itself to the custom development option. The same could hold true for an AIoT solution which is controlling parts of an enterprise`s core processes.

Other factors which have to be taken into consideration include:

  • Organizational capabilities: Does your organization have a proven track record in hardware and/or software development? And how about AI and Data Science?
  • Resource availability: Do you have the required resources available for the required time period? And is it the best use of these resources?
  • Could you build it fast enough?
  • Could you build it good enough?
  • Need for control: How much control does your organization need over the design and value chain?
  • Would building it internally allow cost reduction (e.g. by utilizing own manufacturing lines)?
  • Do you want to keep building/maintaining it yourself after the launch/SOP?
  • How mature is the supplier market?
  • Is there an opportunity for a strategic partnership here?
  • Is a well-known supplier brand a potential differentiator?

In many cases, the Make/Buy/Partner question can not be answered for the entire product or solution, but needs to be broken down to different components (see discussion on the Sourcing BOM below). In order to answer the Make/Buy/Partner question for a complex AIoT solution, it is often important to first understand the complete breakdown of the solution. This is looked at in the discussion of the AIoT Sourcing BOM below.

Sourcing strategy decision

The AIoT Bill of Materials

In manufacturing, the bill of materials (BOM) is used for planning the purchasing of materials, cost estimation, and inventory management. A BOM is a list of every item required to build a product, including raw materials, sub-assemblies, intermediate assemblies, sub-components, and parts. It usually also includes information about the required quantities of every item.

There are usually different, specialized BOM-types, including:

  • Engineering BOM: developed during the product design phase, often based on Computer-Aided Design (CAD) data. Lists the parts and assemblies in the product as designed by the engineering team
  • Manufacturing BOM: includes all the parts and assemblies required to build the finished product. Used as input for the business systems involved in ordering parts and building the product, e.g. ERP (Enterprise Resource Planning), MRP (Materials Resource Planning), MES (Manufacturing Execution System)
  • Sales BOM: used during the sales phase, provides details of a finished product prior to its assembly

Given the potential complexity of an AIoT project, we are proposing the creation of a Sourcing BOM as the foundation for the sourcing process. In the following, we start with a discussion of a generic AIoT BOM, followed by the introduction of the Sourcing BOM.

Example: ACME Smart Shuttle

To have a meaningful discussion of the BOM concept for an AIoT product, we are using the ACME Smart Shuttle example. ACME Smart Shuttle Inc. is a fictitious company offering a platform to manage shuttle services for schools. Instead of using a fixed bus network and fixed bus schedule, ACME Shuttle is utilizing AIoT to offer a much more on-demand service to students. Instead of using fixed bus stops, virtual bus stops are introduced which can change during the day, depending on demand. Students are using a smart phone app to request a ride to and from the school. These requests are then matched against the virtual bus stop system, potentially resulting in the ad-hoc creation of new, virtual bus stops. Shuttle buses are equipped with an on-board unit to provide bus tracking and AI-based in-vehicle monitoring. The platform in the back-end is utilizing AI to optimize the pick-up order and routing of the shuttle buses. The figure below is showing the key elements and stakeholders of the ACME Smart Shuttle system.

Example: Supply Chain of our Shuttle Bus system

To come back to the BOM discussion: The starting point for the creation of a basic BOM structure for an AIoT product or solution is usually an analysis of the architecture design. The figure below shows an example for the high-level architecture design of the ACME Smart Shuttle solution. Also listed are examples for resources required for implementing key elements of the system.

Solution Architecture as starting point for BOM breakdown

Creating the AIoT BOM

A BOM typically is a hierarchical structure; in our case, the 3-5 high level areas of the solution architecture should form the first hierarchy level of the BOM. Note that this BOM will not only include hardware, but also software elements, as well as network infrastructure. In reality, the BOM for such a project might be comprised of multiple, specialized BOMs. The example below indicates how a high-level architecture design -- such as the one for the ACME Smart Shuttle example from before -- can be mapped to the initial BOM.

Thinking about required resources in terms of a BOM will be unusual for people from the software world. However, the benefit of including not only hardware and physical elements in the BOM structure but also software and virtual elements is that the BOM then really provides a holistic view of the entire system. This can be used not only for the Sourcing BOM, but also from the point of view of dependency management, tracing of BOM elements from a security point of view, etc.

AIoT Sourcing BOM: Creation

Make vs. Buy Breakdown

For most AIoT systems, the make vs. buy (vs. partner) decision cannot be applied to the entire system. Instead, it must be applied to different entries in the AIoT BOM. The figure below shows four different scenarios:

  • Scenario A is a manufacturer working on a strategic new core AIoT product. In this case, most BOM item will be custom made internally. Only some items like Edge Platform, WAN, cloud infrastructure and EAI middleware will be sourced externally.
  • Scenario B is a manufacturer working on a time-to-market driven project. In this case, only hardware-centric BOM items will be sourced internally.
  • Scenario C is a software company, which takes nearly the inverse position to scenario B.
  • Finally, scenario D assumes an auxiliary AIoT system, which will be sourced as a turnkey solution. Only the preparation of existing applications for integration with the new system will be done internally.
Sourcing BOM with different sourcing scenarios

ACME Smart Shuttle: Outsourcing AI?

ACME Smart Shuttle, Inc. sees AI as a key enabler to build highly differentiated product features with a strong customer appeal. Consequently, the team has performed an assessment of the best uses of AI in the system design. The most promising AI use cases have been discussed with the procurement team as part of the BOM creation. A summary of the make vs. buy vs. partner decisions that have been made is summarized in the table below.

Outsourcing AI?

Three AI-enabled components have been identified as particularly important to the system: Shuttle routing, shuttle ETA forecast and driver shift planning. Ideally, these three components should be developed in-house to retain full control and ensure constant optimization. However, the analysis has shown that the engineering management team has no experience in hiring and managing a team with the required AI skills; furthermore, the required AI experts are not easily available in the market. Consequently, the decision was made to opt for an build-operate-transfer model: the development and operations support for these components will initially be outsourced. Medium to long-term, ACME Smart Shuttle will then take over the team from the external supplier to become part of the in-house organization.

For AI-enabled in-vehicle surveillance and vehicle maintenance, the decision was made to buy these components, because they are not strong product differentiators and commodity solutions should be available with potentially one exception: the automatic detection of violence between students or even vandalism. For this particular feature, a co-creation model could be envisioned, assuming that there would be a market for such a feature beyond the business scope of ACME Smart Shuttle.

AIoT Sourcing BOM

The next step is to turn the generic AIoT BOM into an AIoT Sourcing BOM. The first thing that needs to be looked at in more detail are the required quantities:

  • For hardware components deployed on the assets, the required quantities will depend on the number of assets to be supported. This again will depend on the business plan. This means most likely the correct strategy here will have to foresee different options, like a minimum and a maximum amount required. This will have to be mapped to different contractual options with the suppliers.
  • Also for software licenses, the number of clients often plays an important role. In the case of AIoT, clients can either be human users or assets. Again, this will be depend on the business plan and require some flexibility to be built into the sourcing contracts.
  • Finally, for custom developed software, the Sourcing BOM will sometimes have to include an estimation of the required development resources (number of developers, availability). Alternatively, this is an estimation that can come from the suppliers, based on the requirements.

Next, for each item in the Sourcing BOM a sourcing decision will have to be made. Sourcing options typically include internal development, management consultancies (e.g. for project management), System Integrators, Commercial Off-the-Shelf Software Vendors, Cloud infrastructure providers, engineering companies, manufacturers, and telecommunication companies.

A key decision for each element in the Sourcing BOM is the make vs. buy (or partner) decision. This decision will depend on a number of different factors:

  • Strategic importance of AIoT Solution as a whole, and contribution of each BOM item individually
  • Internal capabilities: is this something your company can realistically do itself?
  • Availability of internal resources
  • Timing: who can deliver within the required time frame?
  • Brand considerations: will having a certain brand for a specific sub-component improve the overall value of the product?
  • Overall partner strategy: does it make sense to utilize some companies not only as suppliers, but also as potential additional sales channels?

Once quantity and sourcing strategy information has been added to the Sourcing BOM, the schedule perspective needs to be added as well. This needs to be carefully aligned with the development schedule, to avoid roadblocks on the development side.

Finally, it is important to note that in a complex AIoT project, not all required solution elements may be known from the beginning (or they might be subject to change). Agile development methodologies are designed to deal with volatile requirements and solution designs. However, from a sourcing point of view this is obviously very problematic. Frequent changes to the Sourcing BOM will result in loss of time and potentially even spending money on the wrong things.

AIoT Sourcing BOM: Refinement

The following provides some examples for typical elements of an AIoT Sourcing BOM specifically from the point of view of AI- and IoT-related components.

AI-specific Sourcing BOM elements

The following are some examples for typical, AI-specific elements of an AIoT BOM:

  • AI platform, including AI-specific hardware and middleware - for use in the cloud/on-premise backend, or the EDGE layer
  • Functional components requiring resources with AI-specific skills, including AI engineer, data scientist and AI DevOps engineer
  • Outsourced data labeling services, e.g. for manual image classification; beware that transferring images with personalized data to other countries for such processing services can be prohibited by local regulations.
  • AI-specific QA, testing and validation services

IoT-specific Sourcing BOM elements

The following are some examples for typical, IoT-specific BOM elements:

  • IoT-related cloud infrastructure
  • EDGE infrastructure (hardware, software)
  • Resources with IoT-specific skills, e.g. embedded hardware or software development, AIoT project management, etc.
  • Telecommunications services, e.g. a global IoT network from a telco carrier or an MVNO
  • Security-related infrastructure, testing services, operations services and skilled resources
  • Operations services and support

Schedule Alignment

Aligning the agile development schedule with the sourcing schedule will probably be one of the key challenges in any project. This is critical to the success. Final sourcing and supplier decisions are often a prerequisite for:

  • Achieving architectural stability: For example, the selection of a specific cloud or middleware platform can have a significant impact on the solution architecture
  • Availability of development tools and environments: Similarly, the setup of development tools and environments will usually be supplier-specific, and will require an early decision in the project
  • Developer availability: The availability of both hardware and software developers typically also depends on the chosen technology
  • Infrastructure setup: Additional infrastructure like an AI-environment or a security framework will again depend on the final sourcing decision
  • Hardware development: Finally, any hardware-specific development will also require sourcing decisions, e.g. for processors, boards, or communication modules

The figure below highlights the potential dependencies between the agile development schedule and the sourcing schedule.

Schedule Alignment

General Considerations

Before starting the RFP process, a number of other general considerations must be made, including the required SLAs and Warranties, pricing models, and vendor selection criteria.

SLAs and Warranties

A critical decision in the procurement process is the type of contract that is aimed for, especially for any kind of custom development:

  • Service contract: Typically time and material
  • Contract work: Typically includes SLAs, maintenance commitments, warranties, etc.

In many situations, the latter will be particularly important for an AIoT solution. Warranties typically ensure that a service will perform in accordance with its functional, technical and business specifications. Service Level Agreements (SLAs) offer performance metrics and details on the specific consequences of a provider who is failing to meet those standards.

Typical SLAs in IT projects include:

  • Service availability: Specifies the amount of time a service is available, e.g. 99,99% (which would imply ~88 hours of average annual downtime)
  • Defect rates: Quantification of allowed error rates in a service
  • Defect resolution: Addresses the speed by which problems are addressed
  • Security: Addresses the security of the service
  • Business results: Addresses the business perspective, e.g. as business process metrics

Applied to an AIoT Solution, some examples include:

Sourcing BOM SLAs

ACME Smart Shuttle: SLAs for AI?

The ACME Smart Shuttle had earlier on identified 3 key components for the system, which utilize AI. The decision was made to apply a build-operate-transfer model as the sourcing strategy for these 3 components. This means the component development will initially be sourced externally, with the goal to then in-source the team over time. In order to ensure that the external team meets the requirements, a set of SLAs have been defined. These SLAs are differentiating between functional and non-functional aspects. The functional SLAs are specific to the individual components, while the non-functional SLAs in this case apply to all three components. The figure below provides an overview.

ACME Smart Shuttle SLAs for AI Components

A key issue with SLAs for AI-based components is that AI models usually decay over time, due to changes in the input data. Take, for example, the ETA prediction function for the shuttle buses: this function will heavily depend on map and traffic data. If the actual layout of the street grid is changing (e.g. due to construction sites), this will probably require the ETA models to be re-trained with the updated map data. This will have to be reflected in the contract as well: The SLA definitions can only apply to models which are regularly retrained.

Pricing Models

Another important factor in the sourcing process is the pricing model. In many situations, the customer will define the required pricing model as part of the RFP. However, in some cases the pricing model can also be defined by the supplier.

In IT development projects, the most common pricing models are Fixed Price and Time and Material. A key prerequisite for a Fixed Price project is a stable, complete and sufficiently detailed requirements specification and Service Level Agreements. If this can not be provided, then Time and Material might be the only real alternative. Variations of the Time and Material approach are the Dedicated Team approach, as well as Agile Pricing. In Agile Pricing, often a base price is agreed, combined with incentives related to the achievement of individual sprint goals. Another pricing option is a model where the supplier participates in the business success of the customer, e.g. revenue sharing ('Outcome-based pricing'). However, getting both sides to agree to a fair sharing of risks and rewards can be a difficult undertaking.

Other elements of the AIoT Sourcing BOM will again require completely different pricing models. For example, the pricing for telecommunications services will often depend on data volumes and other factors. The pricing for custom hardware is likely to depend on individual component prices, as well as volume commitments.

AIoT Vendor Selection Criteria

Once it is decided which items from the AIoT Sourcing BOM should be externally acquired, it is important to create a set of clearly defined selection criteria. The AIoT Playbook proposes a speadsheet which includes the AIoT solution in general, non-functional requirements, functional requirements, and finally the operations and maintenance requirements. Each of these criteria should be individually weighted, so that later an overall score can derived for each offer.

In this context, a number of key questions will have to be answered, including:

  • How important is cost relative to the other areas?
  • How important is the ratio between functional and non-functional requirements?
  • How important is the vendor evaluation, including strategic fit, financial stability, long-term maintenance capabilities, etc.

The figure below shows an example for a speadsheet containing key selection criteria.

AIoT Sourcing Criteria

RFP Management

Finally, once the internal alignment is completed, the RFP process starts. This includes RFP document creation, RFP document distribution and Q&A process, and eventually AIoT vendor selection.

RFP Document Creation

The creation of the actual RFP document(s) is a critical part of the sourcing process. It is key that an RFP document is as concise as possible, with sufficient detail for any contractual agreement based on it. Any gap or inconsistency in the RFP can be use further down the path by a supplier for re-negotiation or costly change requests. Consequently, the RFP should be written specifically for the situation at hand, and not a re-purposed, generic document. Typical elements in an RFP include:

  • Company name, project name, proposal due date
  • Project overview
  • Scope of work
    • Functional requirements
    • Non-functional requirements
  • Quality criteria
  • Submission requirements and process

In many cases, it can also make sense to be transparent about the following:

  • Evaluation metrics and criteria
  • Budget

For the Scope of Work part, it makes sense to re-use many of the Solution Architecture design artifacts, e.g. the solution sketch, data domain model, component design, etc. However, two key questions must be looked at here:

How many details from the business plan to reveal in the RFP? It can be advantageous to share some details of the business plan with potential suppliers, in order to allow them to get a better understanding for the business potential, and thus to make better offers. However, many companies would feel reluctant to share too many details in a document shared with many external stakeholders.

How detailed should the solution design be? Providing a solution design to potential suppliers can be a good way to ensure consistent offers from different contenders, which closely match the requirements. However, it can also be limiting in terms of getting different solution proposals with different strengths and weaknesses.

RFP Document Creation

The Industrial Internet Consortium (IIC) has developed an online tool for creating an RFP for Industrial Internet solutions. While currently lacking the AI perspective, this can still be an interesting tool for anybody creating an AIoT RFP document, at least for the IoT parts.

RFP Document Distribution and Q&A Process

After completion as well as internal review and approval, the RFP document is distributed to relevant supplier candidates. In some cases, the RFP might also be publicly made available, if this is an internal requirement.

If the process permits this, the receivers of the RFP are likely to come back with questions. First, because almost any RFP will leave some room for interpretation. Second, because most suppliers are likely to seek a close, personal contact to the acquiring company and the sourcing team. It is important that in order to run a transparent and fair selection process, the questions from all potential suppliers are collected and the answers shared as an update to the RFP with all contestants. This will also help increase the quality and comparability of the offers.

AIoT Vendor Selection

As part of the selection process, vendors are invited for individual vendor presentations. Based on this information, a first set of vendors can be pre-selected. Reference calls can provide valuable insights from other customers of the different vendors. In some cases, smaller Proof-of-Concept projects are done with these vendors. Based on the outcomes of the PoCs, a short-list can be created. Often, the last 2-3 vendors are then asked to do a more extensive pilot project. Based on the technical and functional evaluation, as well as extensive price negotiations, the final selection is then done.

The selection process is often overseen by an evaluation committee, which evaluates the recommendation by the operational sourcing team. The evaluation committee usually includes stakeholders from senior management, business and technology experts, as well as representatives from procurement and legal. Members of the evaluation committee ideally review the final proposals independently, using an evaluation spreadsheet as described above. Depending on the complexity and criticality of the project, they might also be asked to provide written statements.

Finally, the results will have to be communicated to the contenders. Depending on the internal processes of the buyer, different policies might apply here. For example, it can make sense to not only communicate the result, but also some decisions like the evaluation criteria matrix. This will help suppliers to improve their offers in the future. However, it can also lead to unwanted discussions. Developing a good (but of course also compliance-rules obeying) relationship to high-quality suppliers can be a strategic advantage and might warrant the additional effort in the communication of the selection results.

Legal Perspective

The legal perspective of an AIoT initiative is often closely related to the sourcing activities, because customer/supplier relationships need a solid legal foundation. The following interview with Philipp Haas (head of the Expert Group for Digital and New Businesses at Bosch`s legal department) provides some insights on the level perspective, building on the ACME Smart Shuttle example we have introduced earlier.

Legal Perspective - Shuttle Bus Example

Dirk: Thanks for joining us today. Tell us a little bit about what you do at Bosch. What's your role?

Philipp: I have been a consultant in the legal department of Bosch for 10 years now, and I am currently responsible for the central department for digital and new businesses. This includes consulting various smaller legal entities and central departments within Bosch. And I'm also heading the expert team for IT law. We are also supporting the other colleagues in the legal department with respect to digital businesses.

Dirk: And thank you for supporting us with the AIoT playbook. When we started our discussions, we learned that the different legal aspects around AIoT are quite complex. That's why we said the best way to get a 360 degree view of the legal aspects would be to discuss this based on a realistic use case. So from a legal point of view, what are the key issues that we need to consider in our ACME Smart Shuttle example?

Philipp: I think the most important role is that of the platform operator, because he sits in the middle of everything and offers the AIoT-enabled product. And he has contractual relationships to many parties.

Dirk: Good point. Let's get started with the relationship between the platform operator and the OEM. What does the platform operator have to look out for from a legal perspective?

Philipp: In our scenario, ACME Smart Shuttle is operating a fleet of shuttle buses, which need to be purchased or leased from the OEM. What is very important for our platform provider is that he's not only getting access to the vehicles, but that he is also having access to the data in the vehicles. Otherwise it will be more difficult to offer data-based services, which is a key assumption in this example. So there needs to be an additional agreement for the data generated by the vehicles. This means we need a data sharing contract. If the fleet is large enough, this could be an individually negotiated contract - alternatively, the platform provider has to agree to the standard offerings, which some OEM already have out there. For example BMW is offering connected drive services, which includes access to car data as well.

Dirk: Thanks. So that's our main supplier. What about the other suppliers, anything specific to look out for?

Philipp: Almost all IoT use cases today require a cloud provider, typically from the US or China. Cloud services are essential for the platform provider because they provide the infrastructure for running the software and the AI algorithms. Depending on the setting, you chose between software-as-a-service or infrastructure-as-a-service, if you need more control. A lot of these cloud services are highly standardized today, and there will be little room for negotiating individual contracts. So selection of a cloud infrastructure player will not only be a technical choice but also requires you to look at costs and standard legal terms and conditions.

Dirk: And what about the counterpart to the cloud, the edge side of things. For example, in our Shuttle Bus example, we are assuming that there will be custom edge nodes embedded into the buses. What are the relevant aspects from a legal point of view with respect to the edge component provider?

Philipp: If the platform operator purchases devices that are responsible for the connectivity - for example, to his back-end - it might be necessary to have an agreement regarding the transport of the data. Such devices typically have a SIM card, either as regular SIM or a built in SIM card. It makes a difference who is responsible for the activation of this card. So if the device supplier is activating the card, it might be necessary that the supplier registers as a telecommunication provider. The alternative would be, that the platform provider might have to conclude an additional contract with a responsible telecommunication provider directly. That might be also the case, if the supplier is just delivering the hardware with a SIM card and the platform operator is responsible for activating the hardware (and the SIM). If the platform operator is responsible for activating the hardware, we have to have a look at his role. He then might become a telecommunication provider if he is responsible for the transport of data to his contract partners, but in our use case I don't think this will be the case for the platform provider.

Dirk: Talking about data in our Shuttle Bus scenario, one option that we've been discussing is for the bus operator to out-source the development and training of the AI algorithms. This would require the platform operator to make all the required data available to a third-party IT development firm. Are there any specifics that he has to look out for, in particular with respect to the ownership of his data?

Philipp: Yes, this is a very typical scenario. You are using the wording “his data”, so the first question would be what exactly is "his data"? Does the data we are talking about really belong to him? Legally there is no data ownership. If you're talking about data, there are two key aspects. The first key aspect is, are we talking about personal data? Because personal data within Europe is subject to the GDPR (General Data Protection Regulation), in addition to the other international data protection laws. It typically means that you are only allowed to process the data - including handing it over to a third party for development - if you have a legal basis for that. The second key aspect for processing or transferring data are the relevant contracts. For example, the contracts which apply when receiving data might limit your ability to make this data available to a third party for further processing. So you're only allowed to transfer the data within these boundaries. If that is possible, usually there is no other legal protection for the data. In some very limited cases, data might also be protected by IP rights.

Dirk: In our scenario, the IT supplier of ACME Smart Shuttle is using data from different sources, including data from ACME Smart Shuttle, data from the schools (e.g. the school time tables), as well as data from third parties (e.g. traffic data). From this data, he derives new data via the AI, e.g. the bus schedules and routes. Does the AI and the new data created by the AI automatically belong to ACME Smart Shuttle, because they are paying for it?

Philipp: No. It is highly recommended - I would say even absolutely necessary - to have a clear agreement with the IT supplier regarding the results that are created with the data. That is one of the topics I mentioned before, where it's legally not easy to find out who contributed to the results and who is the owner with respect to the results. That's why it's essential to have an explicit agreement on that. In joint development projects, you always have clauses regarding the rights to the development results. You also have clauses regarding software, so that, that is quite standard. In the newer contracts, we see clauses that explicitly refer to data, the right to data, maybe distinguishing between test data and productive data, and also with respect to work results that have been created using such data.

Dirk: I do understand the differentiation between software and data. But what about the trained AI models - are they data or software, from a legal point of view?

Philipp: An AI model will usually fall in the category of software. Software is defined in the copyright law and it's a program for computers that's showing the computer what are the next steps. A trained AI model usually runs within a software environment. Maybe it's not a software on its own, it's just part of an software, but also parts of software are considered as software under the copyright act. So I think it will be protected by copyright law, which means that it is possible to have an agreement on the usage rights and you can transfer that to the platform provider. And the platform provider will, of course try to do that because as you mentioned, he paid for it. But this is not always possible because sometimes, if you have very large suppliers who argue that they are also using pre-existing works for their work results, it might be not easy to get all exclusive usage rights. There might be an individual agreement on who is allowed to do what with the work results.

Dirk: OK, let's assume we got all this sorted out, and we now have our platform up and running. What about our relationship to the end customer, the students of the school?

Philipp: I would say that that is pretty straight forward. You offer your services most of the time via an app and for that app you need terms of use. We have standards that we are using for all different kinds of apps. And that platform provider has to comply with the relevant consumer protection laws that give very detailed requirements and that are renewed very often. In this year in Europe, we have some new consumer protection laws. You can also think about EULA´s (End User License Agreements). You can use that in addition to the terms of use. So the terms of use cover the usage of the service itself, the EULA is for the software. I don't think that it's necessary to use both.

Dirk: Another important group of stakeholders in our example are the drivers...

Philipp: In our example, the drivers are employed at the platform operators. There might be also a service contract with them if they're independent, but then you have to make sure that they are really independent and not by accident employees, because this could cause major risks for the platform operator for example regarding tax law. The employment contract itself, I would say that is also quite standardized but we have this special case here that we need to have an agreement regarding the usage of the data from the shuttle buses. Because data that we get out of the vehicles could be contributed by the driver, it means that they are personnel related and that is why we need to have an agreement on the usage. This is legally not trivial because the platform operator has to get a free and voluntary consent from his employee. I think in our use case, there's also a good justification for the platform provider because the usage of the data is an essential requirement for his business use case. He cannot operate the platform without that. So the request is absolutely reasonable.

Dirk: Thanks. Anything else that we have to look out for from the perspective of the Shuttle Bus platform operator regarding legal aspects?

Philipp: We looked at the contractual relationships and I mentioned new legal developments regarding consumer protection laws. The same applies for digital business in general. There are many laws that either recently came into force or are still in development. I mentioned the telecommunications act that is currently revised on the European level. There are various legal drafts regarding platform regulation, and already existing platform regulations. The Data Governance Act that will contain requirements if you want to share data via a platform. The Digital Content Directive has already been transformed into German law and such new regulations will enter into force 1st of January 2022. It makes various requirements for digital offers, which includes also software as a service or apps. For example, it contains an obligation to make regular security updates during the lifetime of the service. And on the horizon, we also see a regulation for AI. There's a first draft from the European Union. This is a very interesting regulation from a legal perspective. From the operator’s perspective, it could lead to some new obligations, like checking the data that he is using for the training of the AI models. According to the draft, the data has to be free of errors. There is an obligation to document the data usage. You have to document the results of the AI system so that you can track back exactly why a certain decision has been made by the AI. For nearly all AIoT products that are considered as “high risk”, this AI Regulation will play a very big role in the future.

Dirk: And do you see something similar coming up in USA and China as well?

Philipp: In the US, I recently read a statement from the US Department of Commerce regarding the AI Regulation, and it didn't sound like they want to follow us. They seem to have a different approach and are looking with a skeptical eye on our regulation and don't think that it's helpful. So no, I don't expect a similar regulation from the US at the moment. In China, the situation is different. There are new security laws put into place and they also regulate the usage of the data. Not like the AI regulation for protecting the individual but more for protection of interests of the government and the country. There will be a definition of categories for data that fall under these new security laws, but I read that vehicle data will be considered as one of the critical data category. So I think in the future operating such a platform for China might be only be possible within China.

Dirk: Last question. Looking at this from the perspective of the project manager, when in the lifetime of his project should he involve legal expertise? And what's the best way to actually embed this legal expertise in his project?

Philipp: Okay, this question is very simple to answer: As early as possible. Because there are many legal considerations and I also would say many traps.

Dirk: So depending on whether the operator operates from within a large organization or actually as a startup, how does he go about this? Does he really make legal experts part of his team or how does he get access to this expertise?

Philipp: This is a case by case decision. The legal counsel can become part of the project team which has the advantage that he has deep knowledge also about the technical and business considerations of such an offering. For a startup it might be too costly to involve external counsel as part of your project team and let them participate in every discussion. You might take a leaner approach and discuss it with the counsel and work out a plan at the beginning so that it is clear what has to be considered. And then you can go ahead and have regular meetings, discussions with the legal counsel, but not directly include him into every discussion.

Dirk: Great. That was super interesting, thank you very much.

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.


Christian Weiss.jpg
CHRISTIAN WEISS, HOLISTICON AG
CONTRIBUTOR
As a consultant, coach and trainer, Christian deals with the topics of business process management and agile project management. In particular, it is important to him to support large companies in the introduction of nimble, automated business processes and agile practices. Social concerns often play a major role in the implementation of ideas, for which he have developed a sensitive sense and sensitivity over the years.


Haas Philipp.jpg
HAAS PHILIPP, ROBERT BOSCH GMBH
CONTRIBUTOR
Dr. Philipp Haas is a lawyer at Robert Bosch GmbH in the legal department. He heads the Expert Group for Digital and New Businesses. His field of activity for many years has included the drafting and negotiation of software license agreements.


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.