Sourcing and Procurement: Difference between revisions

No edit summary
Line 228: Line 228:
{|{{Borderstyle-author}}
{|{{Borderstyle-author}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
<br>
{{Designstyle-author|Image=[[File:Heiner Duffing.jpg|left|100px]]|author={{Heiner Duffing|Title=CONTRIBUTOR}}}}
<br>
<br>
{{Designstyle-author|Image=[[File:Christian Weiss.jpg|left|100px]]|author={{Christian Weiss|Title=CONTRIBUTOR}}}}
{{Designstyle-author|Image=[[File:Christian Weiss.jpg|left|100px]]|author={{Christian Weiss|Title=CONTRIBUTOR}}}}
|}
|}

Revision as of 15:08, 9 February 2021

AIoTArtificial IntelligenceInternet of ThingsAIoT Data StrategyProduct ArchitectureAIoT DevOps & InfrastructureTrust & SecurityReliability & ResilienceVerification & ValidationProduct OrganizationSourcing and ProcurementService OperationsIgnite AIoT - Technology and Resource Acquisition

AIoT Framework: Sourcing and Procurement

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 vs partner, 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 and Procurement Challenges

Before looking at solutions, 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.

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 Strategy: 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, and do not take co-innovation and other alternatives into close consideration. However, they should be a good starting point for the following discussion.


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 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 Sourcing BOM below.

Sourcing strategy decision

AIoT Sourcing BOM

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.

The AIoT Bill of Material

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.

AIoT Sourcing BOM: Creation
AI-specific BOM elements

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

  • AI platform, including AI-specific hardware and middleware - for use in the cloud/on-premise backend, or the EDGE layer
  • 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 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

AIoT Sourcing BOM

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

AIoT Sourcing BOM: Refinement

The Sourcing BOM is also a good format to compare different sourcing scenarios. For example, 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. Notice that in all scenarios the preparation of internal applications will be done in-house, because this usually requires a lot of internal know-how.

Sourcing BOM with different sourcing scenarios

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.

Schedule Alignment

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

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

SLAs and Warranties

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

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.

AIoT Sourcing Criteria

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.

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

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.


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.


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.