Sourcing and Procurement

AIoT 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 - don`t have a lot of experience in this space, which is why this part of the AIoT Playbook is aiming 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 defining 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 often is 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 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 at 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 avoid vendor lock-in due to 'accidential' 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 are missing their deadlines. Carefully aligning the required RFP projects with your development plans will be a key success criteria for your project.

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.

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

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 3 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 exemplary. Other options like co-innovation or Build-Operate-Transfer can also be interesting. However, these tree examples should provide a good starting point for the discussion in the following.

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 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 to reduce costs (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.

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

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.

Creating the AIoT BOM

A BOM typically is a hierarchic 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.

Make vs Buy Breakdown

For most AIoT systems, the make vs. buy (vs. partner) decision can not be applied to the entire system. Instead, it must be applied to different entries in the AIoT BOM. The figure below shows 4 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.

ACME Smart Shuttle: Oursourcing AI?

The ACME Smart Shuttle 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.

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 own experience in hiring and managing a team with the required AI skills; furthermore, the required AI experts are not easily available on 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 asset to be supported. This again will depend on the business plan. This means most likely that the right 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 notice that in a complex AIoT project, not all required solution elements might 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.

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
• 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.
• Telecommuniations 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. Sourcing/supplier decisions are often required for:

• Achieving architectural stability: For example, the selection of a specific cloud or middleware platform can have a significant impact on the solution architecture
• Tool & development environment availability: 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.

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:

AIoT BOM Item	Example SLAs
AI (Asset or Swarm Intelligence)	Compliance with intended business functionality, e.g. matching accuracy in %
Edge Platform	Event processing, e.g. #events / second
IoT Business Logic (Edge or Cloud)	Compliance with design specifications
IoT LAN	Coverage of required regions, network latency, throughput

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.

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.

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 hole / 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.

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.

IIC RFP online tool

RFP Document Distribution and Q&A Process

After completion and internal review / 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 fail 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 increasing 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 often 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 any AIoT initiative is often closely related to the co-creation and sourcing activities, because many legal aspects are directly related to the customer/supplier or partner relationships. The following interview with Philipp Haas (head of the Expert Group for Digital and New Businesses at Bosch`s legal department) is building on the ACME Smart Shuttle example we have been discussion thus far.

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

Philipp: I'm a legal consultant in the legal department here since 10 years and responsible for the central department within the legal department for digital and new businesses. So I'm responsible for consulting various smaller legal entities and central departments within Bosch. And I'm also heading the expert team for IT law. So also supporting the other colleagues within CLS in questions of digital businesses.

Dirk: And thank you for supporting us with the IOT playbook. When we started our discussions, we learned that the different legal aspects around AIoT are rather vast. And that's why we said the best way to get the 360 degree on the legal aspects of it would be to use a case study. So luckily we have our Shuttle Bus case study. So from, from a legal point of view in this case study, what are the key roles that we need to consider?

Philipp: Okay. I think the most important role is that of the platform operator, because he sits in the middle of everything and offer’s the product the, the IOT product also including making use of artificial intelligence within the product that he offers. And yeah, he has contractor relationships to many parties. I think we’ll talk about that later.

Dirk: So, as you mentioned, we have the other parties, the OEM, the supplier, the customer, and the driver, maybe let's get started with the relationship to the OEM. What does the platform operator have to look out for?

Philipp: Yeah, I mean, in our use case the platform operator is providing vehicles as well. So he he's having the vehicles in his repository and for that, obviously he has to purchase them by the OEM and maybe he can also lease them. And 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 car because otherwise he cannot offer data-based services which is necessary in our case study. And this is why we said there needs to be an additional agreement for the data of the car which we named data sharing contract that can be either an individual contract maybe only applicable for large platform providers. Otherwise the platform provider has to make use of the standard offerings of the OEM, which some OEM already have out there. For example BMW is offering connected drive services, which includes access to two car data as well.

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

Philipp: Well, the, the typical supplier for nearly all IOT use cases are the cloud providers. So cloud providers, typically Microsoft, AWS, in China, the big Chinese providers, that's essential because he needs someone who maintains and operates the services. And there are, you release standard supply contracts. Sometimes we be categorize it into categories like platform as a service infrastructure, as a service software, as a service that depends on the use case. You typically need here a platform as a service for hosting the platform, maybe also infrastructure as a service, if you have your own environment. And the services that you book at the supplier may also vary from more or less just hosting your software to making use of software as a service offerings that are available by the platform provider. For example, development tools as well because especially the large provider named all have tools and services out there that can be used by such a platform operator. And yeah, it depends what he needs in his use case.

Dirk: And what about the counterpart of itself, mainly the edge. So in the Shuttle Bus example, we're assuming that there would be some custom telematics unit embedded into the car as well and specific 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. So such devices typically have a SIM card either in industrial SIM or just, just a built in SIM card. And it depends who is responsible for the activation of this card. So if the supplier is activating the card, it might be necessary that the supplier registers as a telecommunication provider otherwise the platform provider might have to conclude an additional contract with a responsible telecommunication provider directly. So that might be also the case, so supplier is just delivering the hardware with a SIM card. And the platform operator is responsible for activating the hardware. And if the platform provider is responsible for activating the hardware, we have to have a look at his role. So if he then might become a telecommunication provider but in our use case I don't think so because you typically don't become a telecommunication provider if the transport of the data is just a minor part of your services. So only if you are responsible for the transport of the data that is typically telecommunication, you are bringing the data from A to B. And if that is a major part of your service, then you are becoming a telecommunication provider. So I don't think this will be the case for the platform provider, but especially in an international environment you have to have a look at that.

Dirk: Thanks. So 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 based funk sheets, U2 shortest shortage of skills on his end. And so if the platform operator is making all its data available to third-party IT Development Firm, are there any specific that he has to look out for in particular with respect to ownership of this data, for example?

Philipp: Yes. First of all, this is a very typical scenario for this kind of AIoT use cases. Second, you use the wording, his data, so first question would be what are his data? Do the data we are talking about really belong to him? legally there is no data ownership that is clear so far. Otherwise many things are not really clear. If you, if you're talking about data there are two key aspects. First key aspect is, are we talking about personal related data or not? Because personal related data are within Europe and under the GDPR, but also internationally protected under data protection laws. So that we have to take into account, and it typically means that you are only allowed to process the data, which means also handing it over to a third party for development, if you have a legal basis for that, and you have to look at that legal basis. Second topic, a key aspect for processing or transferring data or the contracts. If you have received the data under a contract, for example, I mentioned the contract with the OEM for receiving the data. you have to stick to the contracts and such contracts might restrict the delivery of such data, for example, for development purposes. So you're only allowed to transfer the data within that boundaries. If that is possible, usually there is no other legal protection for the data. In very, very limited cases, data might be protected by IP rights, so patterns, but this is, this are really special cases.

Dirk: So in our scenario, our I T supplier should get from the platform operator itself, for example, the [inaudible 12:05] the teacher and student related schedules to understand when we have peak times for picking up and delivering students. And you might also make match data with traffic information available to the IT supplier. So let's say the IT supplier is now taking this and creating an AI, which is basically deriving additional information from it, such as the optimal routes for the school buses, and also maybe predictive maintenance information about the school buses. Does this information to right from the AI by the IT supplier automatically belong to the platform operator because he's paying for it?

Philipp: No. The same applies as I said before. So maybe now not the aspect of personal related data becomes so relevant because let's say we have found a solution for set and rightfully transfer the data to the, to the third party that's developing, then the second topic comes into focus and that is the contract with him. So it is very, very highly recommended, and I would say absolutely necessary to have a clear regulation with a third party on the, the rights regarding the work results that have been created with such data. Because that is one of the topics that I mentioned before, where it's legally not easy to find out who really contributed to the work results and who is the, ownership means in that right, in that case, usually the copyright with respect to the work results. And that's why it's essential to have an explicit agreement on that. And I saw that also in recent agreements for joint development projects, you always have clauses regarding the work results. Since a few years, you also have clauses regarding software, so that, that is quite standard. In the newer development contracts, you see clauses that explicitly refer data, the right to data, maybe distinguishing between tests data, productive data, something like that. And also with respect to work results that have been created using such data

Dirk: Interesting. So the delivery from our IT supplier would not be a trained AI model that has been trained on data as described regarding scheduled some traffic information and so on. And this trained model will then be used to do forecasts and predictions. The train model from a legal point of view is not data or software.

Philipp: Maybe, maybe you tell me. Well the, I think it falls in the category of software. Actually software is defined in the copyright law and it's a program for computers that's showing computer what are the next steps. So I think a trained model usually runs within a software environment. At least maybe it's not a software on its own, it's just part of in software, but also parts of software are considered a software and under the copyright act. So I think it will be protected by such copywriting, which means that it is possible to have an agreement on the, not on the authorship itself, so the author is obviously the author, but you can agree 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. So there might be an agreement who is allowed to do what with the work results. And that might be an individual agreement on that.

Dirk: Thanks. So let's assume we got all this sorted 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 standardized. You offer your services most of the time via an app and for that app you need terms of use. And like I said, pretty standardized, this is not a real big issue. At Bosch, we have standards for that, that we are using for all different kinds of apps. And you have to of course comply with the relevant consumer protection laws that describe a lot, and that are renewed very often for example, in this year in Europe, we have some new consumer protection laws but otherwise, it's not a big hurdle from a legal perspective. You can also talk about EULA, EULA stands for End User License Agreement. You can use that in addition to the terms of use. So the terms of use covets, the usage of the service itself, the EULA is for the software itself. We don't think that it's necessary to use both. We make it more simple and say for the software, just the standard terms from Apple apply or the legal regulations apply, which is also sufficient in this kind of model, but terms of use unnecessary.

Dirk: And another important stakeholder group class, obviously the drivers.

Philipp: Yeah, 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, re regarding Texas, so employment contract itself, I would say also quite standardized. we have this special case here that we need to have an agreement regarding the usage of the data, because that is again a requirement because such data that we get out of the car can be contributed to the driver, which means they are personnel related. And this is why we need to have an agreement on the usage which is legally not, it's not so easy because if you are employed and you have to give a free and voluntary consent, this is sometimes conflicting because some data protection lawyers say that you are never free and independent as an employer, you always have the pressure. So if I don't agree what happens then? But, we think it's necessary, you have to get the consent voluntary. And I think in our use case here, there's a good justification for the platform provider because of the usage of the data is an absolute requirement for his whole business use case. So he cannot operate the platform without that. So the, the justification is absolutely reasonable, and that's why I think that it's possible here to ask for that consent.

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

Philipp: Yeah, we looked at the contractual relationships and what I mentioned regarding consumer protection laws, that they are many new legal developments out there. Same applies for digital use cases in general. There are many laws that either recently come into force or are still in development. So, I mentioned the telecommunications act that is currently revised on a European level. There are various legal drafts regarding platform regulation already existing, Platform regulations, for example, the platform to business regulation that is already in place. The Data Governance Act that is necessary if you want to share data via a platform. So if you want to sell the data, for example, then you need to comply with such requirements. We have a Digital Content Directive, which has already been transformed into German law. And that has been transformed into German law and will enter into force 1st of January next year. It makes certain requirements for digital offers, which include also software as a service or apps. For example, there is an obligation to make regular updates, security updates, during the lifetime of the service. So quite strict regulations. And on the horizon, we also have a regulation for AI products. There's already a first draft out there from the European Union, very, very interesting regulation from a legal perspective. From the operator’s perspective, could give some new obligations to test your products to have a special eye on the data that you're using for the training because there are certain requirements for that. You have to check that the data are free of errors. That's really part of the, of the eye regulation. You have to document the data usage. You have to document the results of the AI system so that you can track it back, why a decision has been taken. So very, very strict yet regulation for some kind of AI products, so-called high risk AI products. Maybe you could come to the result that the product of the platform operator is not a high-risk AI product, but that depends a little bit, this is something that has to be checked. But anyway, for all AIoT products, this AI Regulation will play a very big role in the future.

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

Philipp: Well, 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 more of the different approach and are looking with a skeptical view 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 into place. I think it was 1st of July, and they heavily also restrict the usage of the data not so much like the AI Regulation for protecting the individual. It's more protection of interests of the government and the country itself. But I think it will have impact, or it would have impact for the platform operator here as well, especially if he wants to transfer the data from China to abroad or the other way round. This will definitely be more difficult in the future. They will also be some categories for data that fall under this 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 will only be possible within China. So from China, within China.

Dirk: Interesting. So last question. Looking at this from the perspective of the project manager or product manager who speeding up the bus operator platform, when in the lifetime of his project should he involve legal expertise? And what's the best way to actually embed in this legal expertise in his project?

Philipp: Okay, this question is very simple to answer as early as possible. Yeah, that's just from the beginning because there are many legal considerations and I also would say many traps. So I don't see points where you come to the result that it's not possible, but there are just many aspects you have to think of. And this is why I think it's impossible to involve legal counsel as early as possible just to, to have a plan what has to be considered just from the beginning.

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 expert part of his team or how does he get access to this expertise?

Philipp: Yeah, I mean, again, this is a case by case decision in large companies. Typically, 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. As a startup 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 counselor and have like a work plan at the beginning so that, you know, what has to be considered. And then you can go ahead and yeah, have regular meetings, discussions with the legal counsel, but not directly implement him into every development. I think that's also feasible.

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

Authors and Contributors

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