Why Traditional Procurement Doesn’t Work for Sourcing Innovative Solutions
How Challenge Curation is the best tool for this process
Digital Transformation is no longer just an option but a necessity for companies, especially for industrial companies & public sectors — the sectors that are ripe for transformation. Why is this important? In today’s rapidly evolving technological landscape, businesses and organizations need to adopt innovative & advanced technological solutions to remain competitive and relevant.
These organisations are aware that they have to adopt innovations, however, they do not have the capabilities to build such innovative products internally—hence has to rely on external sources to bring digital transformation to their organisations & the sectors as a whole.
In the past decade, technology startups drove digital transformation in the consumer market—introducing digital payments, e-commerce, etc. The same is the case with enterprise markets—thanks to companies like Salesforce, and now Zoho (startups back then). Going by this trend, it’s quite evident that startups will drive digital transformation in the industrial & public sectors too. So industrial companies & public sectors have to work with startups to source & adopt innovations.
Startups drove digital transformation in consumer and enterprise markets over the past decade—indicating that startups will also drive digital transformation in the industrial and public sectors.
The challenge that large organisations will find here is that their procurement processes is unfit for engaging with startups. Procurement processes are great for buying standardised solutions, however, it fails while trying to source innovative solutions. Say, for instance, a motor manufacturing company wants to introduce an advanced robotic solution (an advanced technology) for picking & placing components on the shop floor. This company would traditionally go about by putting out the “specifications” of the solution they need and solicit proposals from vendors who could supply them. Here, the product or the solution is defined and procurement managers go about buying the one who provides the solution for the lowest price.
There are serious limitations to this method. Firstly, by definition, advanced technologies are not standard products available in the market. Most of them are still in the proof of concept, prototype or early product stages.
Secondly, these technologies are evolving, which means their specifications aren’t fixed and won’t be fixed unless it matures after being adopted by a large number of users.
Lastly, when procurement managers put out the specification, they are limited by their knowledge of what is available in the market. And as mentioned earlier, these technologies are not yet in the mainstream market and the specifications aren’t fixed yet. So it’s impossible to put out the specifications.
Hence traditional procurement processes don’t leave any room to source innovation. While it’s great for buying market-ready solutions, but fails when trying to buy innovative & advanced technological solutions.
The other approach organisations adopt is to put out just the use case for which they wanna source innovations for. For instance, a city’s administration facing a waste segregation problem might put out something like “Artificial Intelligence enabled solution for automatic waste segregation” and solicit solutions from vendors. What will follow is the buyer sitting with the vendor and explaining the specific details of what they want. While this might get artificial intelligence-based solutions, it will most likely end up as a customised project. However, for companies to attain true Digital Transformation, they need products, not projects.
A few reasons for this are—projects are not scalable, so doing large-scale deployments will not be possible, and Digital Transformation is all about quickly scaling technologies across the organisation. On the other hand, products can be easily scaled. Secondly, projects don’t get better over time and are not easily upgradable when the technology evolves, while products do. This again is critical for digital transformation.
At Forge, to circumvent this limitation of the traditional procurement processes in sourcing innovative solutions, we use the Challenge Curation Approach.
Challenge Curation
In this approach, we convert narrowly defined problem statements into broad market opportunities, i.e., a problem that prevails across different companies in an industry & beyond. This way, the problem becomes an industry-wide one—opening up possibilities for products to emerge. Whereas if it’s portrayed as a problem that only one company faces, as mentioned above, only projects are likely to emerge.
Also, in this approach, only the requirements are defined without specifying the solution. It focuses on what the solution should do, rather than what it should be. While doing this, organisations don’t need to know what solutions are out there, at the same time opening up possibilities for a wide range of solutions to address the problem. In other words, this opens the door for innovations.
This approach requires the user or buyer to detail the problem or challenge, the beneficiaries impacted by the problem, the requirements of the solution, the expected outcomes/benefits, constraints, the gaps in the current solution, etc. Putting all these together we build a Challenge Brief—a document that can be used as a means to source innovations. This approach not only works well for sourcing innovations for piloting or procurement but also works for co-creating solutions from scratch with startups.
Guide to Building a Challenge Brief
Below is a template for building a Challenge Brief, with 8 sections, along with the purpose of having each section and a real-time example of a use case/challenge—Predictive Maintenance of an HVAC System in a Manufacturing Facility.
1. Challenge Summary
This is a 1 or 2-line description of the challenge to be addressed or needs to be fulfilled for the end-users. Challenge Summary gives an overview of what the challenge or use case is all about.
Eg: Lack of a digital monitoring system for the HVAC system causing frequent equipment failures leading to unplanned downtime, and also resulting in increased energy consumption.
2. Challenge Scenario
100–120 word description of the challenge or use case to help understand how the challenge manifests on the ground—how the beneficiaries are getting impacted by the problem, including relevant technical & operational requirements, constraints, and expected benefits. This paints a clear picture to startups of what the problem is.
Eg: HVAC is a critical system in a manufacturing plant as it maintains ambient working conditions for both workers & equipment. Specifically, systems like microprocessors, soft starters & other power electronic devices are highly sensitive to temperature and hence require an HVAC system to maintain the temperature in the required range. However, unplanned failure of the HVAC system can severely impact the performance of electronic systems, manpower & other equipment, bringing down the overall productivity. These unplanned failures, directly & indirectly, costs upto $50K for the factory.
Currently, the HVAC system is widely distributed across 68 substations in the factory and monitoring them manually—to predict possible breakdowns—is laborious, time-consuming & inefficient. Hence there is a need for a system that can help monitor the entire HVAC unit from a central location with predictive maintenance capabilities.
3. Profile of the end-users
The profile of the people or the team impacted by the problem and the likely end-users if there is a solution/product for the problem. This should also include the details of the current methods they employ to overcome the problem.
Eg:
1. Electrical Team — Responsible for the operation & maintenance of the HVAC system. The team currently monitors the system manually, which is inefficient, leading to unplanned downtime.
2. Maintenance Team—Responsible for looking after maintenance in case of equipment or machine breakdowns in the plant. They assist the electrical team when the HVAC system breaks down.
4. Functional requirements of the end-user
This section should detail the Jobs-to-be-done, i.e., the specific set of jobs that a solution should do to address the problem. This will include the needs to be fulfilled, gaps to be addressed, challenges to be overcome, etc. Note that these are not specifications of a solution in any way, only requirements. Read more on jobs to be done here.
Eg:
1. Monitoring the key parameters in the components across the HVAC system
2. Predict & alert the electrical & maintenance team on the likely failure of components in the HVAC system
3. Provide actionable recommendations for preventing component failure or system breakdown.
4. Facilitate a simulation to showcase the optimal running hours and energy consumed.
5. Functional & Operational Capabilities
This section should specify the desired features & functionality of the solution. However, the core of the solution shouldn’t be specified here, only the end user interface (i.e. HMI—Human Machine Interface). In other words, what should the solution have (features & functionalities) if the end-user has to effectively operate and gain value out of it?
For instance, “dashboard for easy visualisation of data” and “mobile application for users in the field to capture data” are examples of functional & operational capabilities. In contrast, “AI/ML capabilities for predictive maintenance” would be specifying the core of the solution itself, hence not a functional & operational capability.
Eg:
1. A centralised dashboard to display the energy consumed & to indicate which component is likely to fail
2. An SMS based notification to the end-users when a component is likely to fail along with the recommended action for preventing the failure
6. Deployment Constraints
Deployment constraints refer to the obstacles that must be considered when deploying, integrating and operating a solution within a specific environment—these are essentially adoption barriers that need to be overcome to successfully buy, deploy & operate the solution.
Here is a list of primary adoption barriers: Total Cost of Ownership, Maintenance/Service, Skills/Expertise, Installation/Integration, Resources/materials, Time consumption, Physical/personal risk, Product training, Changes to habits/process, Accessibility, Inability to assess the quality of the product/service (Risk Perception), Monitoring the usage/deployment, etc.
In his blog, Death, Taxes & Adoption Barriers, Vish Sahasranamam, co-founder & CEO of Forge, explains in detail what adoption barriers are and how innovators should overcome them while building products.
Eg:
1. Installation/Integration: Solution should be easily integrable to the existing systems, without any major modifications.
2. Product training: The solution should be easy to use without any special product training required and avoid any significant changes to the existing workflows.
3. Maintenance/Service: The solution should be robust with minimal need for maintenance.
7. Expected Outcomes
This section should describe the quantified & qualified outcomes for the buyer & user by addressing the problem. In other words, what is the current scenario and the scenario after implementing the solution?
This sets the expectation for the startups on what their solution should ultimately deliver.
Eg:
1. Number of unplanned HVAC breakdown/year — 25 (Current); 0 (Expected Outcome)
2. Cost of unplanned downtime due to HAVC failure—$50K (Current); $0 (Expected Outcome)
3. HVAC energy consumption—720 KWh/day (Current); 600 KWh/day (Expected Outcome)
8. Gaps in the Current Solution
This section should describe the gaps that are in the current solutions or alternative methods being applied today for addressing the problem. This gives startups a sense of what is being done or which product is being used currently. And the solution they offer should address all the gaps.
Eg: At present, the HVAC system is being maintained through manual processes, and the maintenance and electrical teams are only notified of issues after a breakdown occurs. This means that maintenance is carried out on a reactive basis.
While all the sections in the challenge brief mentioned above may not apply to your organization or industry, they can be customized to suit your needs as long as the essential requirements are captured.
Here is a downloadable challenge brief template.
Summing it up
The primary source of Industry 4.0 technologies is startups, so industrial companies & the public sector must work with them. And challenge curation is an important tool that aids organisations in this process.
Summary of all the sections in a Challenge Brief:
- Challenge Summary: A 1–2 line description of the problem
- Challenge Scenario: How does the problem unfold or manifest on the ground?
- Profile of the end-users: Who is impacted by the problem?
- Functional requirements of the end-user: What jobs should the solution do to address the problem?
- Functional & Operational Capabilities: What should the solution have for the user to effectively use & gain value out of it?
- Deployment Constraints: What are the barriers that could potentially impede the successful adoption of the solution?
- Expected Outcomes: What should the solution ultimately deliver?
- Gaps in the Current Solution: Why is the current solution not working?
At Forge Innovation & Ventures, we help industrial & public sectors implement Digital Transformation through Open Innovation with deep-tech startups as innovation partners. We run open innovation & accelerator programs for our clients through a structured 3-phased process — Discover, Accelerate, and Integrate. During the Discover phase, we help them identify challenges & use cases for Digital Transformation and curate them into Challenge Briefs for sourcing startups.
Know more about our programs & offerings here — www.forgeforward.in
