Sourcing and Procurement

Ignite AIoT - Technology and Resource Acquisition perspective

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 Ignite AIoT 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, discusses make vs buy, introduces a generalized sourcing process for AIoT solutions based on the concept of the Sourcing BOM, helps defining vendor selection criteria, covers the RFP document creation and management, and finally looks at vendor selection.

AIoT Sourcing Challenges

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.

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 sometimes 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 four phases: procurement strategy and planning, 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.

Make or Buy

The Make or Buy decision is a fundamental one and will be shaping your AIoT business for the years to come. Giving up too much control for a strategic product can be as problematic as investing too much in commodity technologies and failing to build truly differentiating features on top.

First, let`s look at the options. The diagram below is showing the most common options based on the assumption that the AIoT solution will have an initial development phase, after which it is officially launched (including the SOP, or Start-of-Production, for the asset/component manufacturing), and then entering a phase of continued development/maintenance.

An option that is leaning heavily towards the buy-side is the acquisition of a turnkey solution from an external provider (1). This can either be a completely custom developed solution, or an off-the-shelf solution. This decision can make sense for auxiliary systems with little strategic relevance. In this case, operations and maintenance can also be external (2). Another reason for a turnkey solution could simply be that the company does not have the skills or resources to build it internally. In case of a more strategic solution, it is likely that the company will use the acquisition process to actually build up the required skills and resources internally and then take over the maintenance or even continued development after the launch. In case of a turnkey solution, it is likely that the customer will provide detailed functional and non-functional requirements, but will leave the solution design to the provider.

Another option is the combination of some in-house with some externally provided components. A typical combination for non-manufacturing businesses is to build the AI and custom software components internally, but use an external supplier for the hardware (e.g. IoT hardware). In case of a manufacturing company, this might be the other way around. Either way, this scenario would typically require at least a high-level design from the customer, as prerequisite for further planning and sourcing.

Finally, in case of highly strategic AIoT solutions - e.g. a smart, connected product which will become the main business for the company or a business unit - the manufacturing depth for both hardware and software might be considerably deeper than in the above examples. While this approach gives much more control over technology, functionality and potentially also cost, it also carries the risk of re-inventing commodity technology and diverting much needed resources from actually developing truly differentiating features.

In many cases, the Make or Buy question will not be answered for the entire product or solution, but will be broken down to different components (see discussion on the Sourcing BOM below). Regardless of the level of granularity the Make or Buy question is applied to, the following are typically questions which must be answered in order to come to a conclusion:

Is the solution/component a critical differentiator for the business?
Would building it internally allow to reduce costs (e.g. by utilizing own manufacturing lines)?
Could you build it fast enough?
Could you build it good enough?
Do you want to keep building it yourself after the launch/SOP?
How mature is the supplier market?
Is there an opportunity for a strategic partnership for here?
Is a well-known supplier brand a potential differentiator?

In order to answer the Make or Buy 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 following.

The AIoT Bill of Material

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 different, specialized BOM-types, including Engineering BOM, Manufacturing BOM, and Sales BOM. Given the potential complexity of an AIoT project, we are proposing the creation of a Sourcing BOM as the foundation for the sourcing process.

AIoT BOM Creation

The starting point is the creation of a basic BOM structure for the AIoT project. This BOM can be derived from the high-level solution architecture. The figure below shows an example. 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 also include software elements, as well as network infrastructure.

Sourcing BOM

Then next step is to turn the project BOM into a 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.

Schedule Alignment

AIoT Vendor Selection Criteria

Once it is decided which items from the Sourcing BOM should be externally acquired, it is important to create a set of clearly defined selection criteria. Ignite AIoT 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.