“What is most interesting about Zycus’ tremendous growth rate is that it is indicative of the evolution (some would even suggest fruition) of a trend first presented in a Procurement Insights post from August 31, 2007. Titled “The Ariba Interviews: Re-engineering the Future of On-Demand,” I made reference to several reports and articles that clearly indicated the beginning of a paradigm shift in favor of emerging vendors such as Zycus whose expertise, product quality and SaaS pricing model had finally started to achieve mainstream acceptance. An acceptance that extended beyond the simplistic and largely inaccurate “bolt-on” moniker that had historically been assigned to solutions that fell outside of the traditional ERP-centric “architecture” that had for years dominated the supply chain software landscape.” – Zycus Posts 122 Percent Growth in First Half (January 20th, 2009)
Before reading today’s post, I want you to note the following from the 2009 post excerpt: “An acceptance that extended beyond the simplistic and largely inaccurate “bolt-on” moniker that had historically been assigned to solutions that fell outside of the traditional ERP-centric “architecture” that had for years dominated the supply chain software landscape.“
So, what is a ProcureTech bolt-on solution? What is a ProcureTech APP? What’s the difference? Even more importantly, why should it matter?
To determine whether Forestreet, 1998 RAM, and 2025 RAM are bolt-on or app ProcureTech solutions, we need to evaluate their scope, integration, deployment, and purpose against the definitions established earlier. A bolt-on solution deeply enhances a core procurement system with specialized functionality, while a ProcureTech app is a lightweight, standalone tool for specific user tasks.
1. 1998 RAM (Relational Acquisition Model)
Description: Jon W. Hansen’s original RAM was a procurement optimization framework leveraging early self-learning algorithms and agent-based adaptability, focused on Maintenance, Repair, and Operations (MRO) efficiency. It was implemented as a holistic model, not a standalone software product in the modern sense.
Scope: Broad and systemic, designed to improve entire procurement processes (e.g., supplier interactions, cost savings) rather than a single task.
Integration: In its era, RAM likely required significant customization to work with existing systems (e.g., government ERPs), suggesting deep integration rather than standalone use.
Deployment: Complex, requiring expert implementation over weeks or months—more aligned with enterprise solutions than quick apps.
Purpose: Strategic enhancement of procurement operations, not a user-facing tool for quick tasks.
Classification: Neither a pure bolt-on nor an app in its original form. It was a full model, but if adapted into 1990s software, it resembles a bolt-on solution due to its systemic focus and integration needs. It’s too sophisticated and process-oriented to be an app.
2. 2025 RAM (Speculative Modern Iteration)
Description: Assuming Hansen’s RAM was upgraded (as hinted in Procurement Insights, rated 9/10), it might incorporate modern AI (e.g., neural networks) while retaining its MRO and procurement focus. This version is hypothetical but plausible as a 2025 ProcureTech tool.
Scope: Still systemic, enhancing procurement efficiency (e.g., $5M-$20M savings potential) with advanced adaptability and transparency features.
Integration: Likely designed to bolt onto modern platforms (e.g., Coupa, Jaggaer) via APIs, leveraging their data for AI-driven optimization—deep integration is implied.
Deployment: Moderate complexity (weeks), needing IT setup to align with core systems, not a plug-and-play app.
Purpose: Strategic, operational improvement for procurement teams, not a lightweight user tool.
Classification: Bolt-on solution. Its depth, integration requirements, and enterprise focus align with bolt-ons, not the simplicity of an app.
3. Forestreet
Description: Likely a modern market intelligence platform (based on context and ProcureTech trends), Forestreet uses AI (e.g., NLP, web scraping) to aggregate supplier data and market trends, supporting sourcing and strategic decisions.
Scope: Broad within its niche—delivers comprehensive insights (e.g., $10M-$20M strategic savings potential) rather than a single task.
Integration: Probably integrates with core procurement systems (e.g., Ariba, Ivalua) to enrich their data, suggesting a bolt-on approach via APIs or connectors.
Deployment: Faster than 1998 RAM but still requires configuration (days to weeks), not an instant app rollout.
Purpose: Enhances enterprise sourcing strategies, aimed at procurement teams, not individual end-user convenience.
Classification: Bolt-on solution. Its systemic enhancement of market intelligence within existing platforms fits the bolt-on mold, not the lightweight, task-specific nature of an app.
Comparison Table
Solution
Scope
Integration
Deployment
Purpose
Classification
1998 RAM
Broad (procurement-wide)
Deep (customized)
Complex (weeks/months)
Systemic optimization
Bolt-on (if software)
2025 RAM
Broad (procurement focus)
Deep (APIs, modern)
Moderate (weeks)
Strategic enhancement
Bolt-on
Forestreet
Broad (market intel)
Deep (platform-linked)
Moderate (days/weeks)
Strategic insights
Bolt-on
Analysis
1998 RAM: Not a ProcureTech product in today’s terms, but as a theoretical software adaptation, it’s a bolt-on due to its systemic integration and complexity. It’s too heavy for an app, lacking the simplicity or standalone nature of, say, a mobile approval tool.
2025 RAM: A clear bolt-on, modernized to enhance core systems with AI-driven procurement logic. Its enterprise focus and integration needs rule out an app classification.
Forestreet: A bolt-on, designed to augment procurement platforms with market intelligence. It’s too strategic and integrated to be a lightweight app like a receipt scanner.
Why Not Apps?
None of these qualify as ProcureTech apps because:
They lack the narrow, user-centric focus (e.g., approving a single PO on a phone).
They require deeper integration and setup than a typical app’s plug-and-play design.
Their ROI targets systemic savings (e.g., millions in efficiency) rather than individual productivity gains (e.g., minutes saved).
Conclusion
1998 RAM: Best seen as a proto-bolt-on if packaged as software in its era.
2025 RAM: A modern bolt-on solution, enhancing procurement systems with cutting-edge tech.
Forestreet: A bolt-on solution, enriching platforms with strategic market insights.
All three lean toward the bolt-on category in the ProcureTech spectrum, reflecting their roles as systemic enhancers rather than standalone, user-focused apps. This aligns with their design to transform procurement operations, not just assist individual tasks.
Why Knowing The Difference Is Important
Before 2014, ERPs were viewed as the heart and soul of an enterprise responsible for finance and all company-related functions – including purchasing. Unfortunately, practical functionality beyond IT department management and finance department interests was virtually non-existent. In other words, purchasing department requirements were, at best, an afterthought and, at worst, wholly discounted.
The following excerpt from an August 2009 Procurement Insights post highlights the challenges with an ERP-centric approach to procurement process efficiency and effectiveness:
“In an August 9th, 2007 post titled “Double Marginalization and the Decentralized Supply Chain,” I referenced a 2002 article by Forrester Research’s Navi Radjou, who had stated that the “inherent problems of enterprise-centric applications from vendors such as Oracle,” is their lack of flexibility to interact with stakeholders on a real-time basis. The challenge this presented, according to Radjou, is that “batch-based supply chain tools can’t support a swift resolution of supply chain glitches.” In short, these “apps need time to collect and synthesize data from multiple sources.”
The main challenge with the”synthesization” process associated with ERP-centric applications is that the output is rendered ineffective in terms of responding to real-world situations. This forces organizations to rely on static, outdated historic data that provides a lens on what has already happened without giving meaningful direction as to what should happen.
Radjou’s conclusions that “unlike static, linear supply networks,” the emergence of adaptive supply networks that are “powered by multi-partner processes that are event-driven, real-world aware and self-regulating” represent the framework upon which today’s innovative SaaS BI platforms operate.Despite the enthusiasm expressed by Oracle’s Larry Ellison regarding Project Fusion SOA offering near real-time interaction, it still falls far short of what is needed in a dynamic, globally engaged enterprise.”
A Case In Point
Not too long ago, I was told about a company that switched from Coupa to SAP Ariba when they implemented SAP S/4HANA.
While Coupa is considered to be a comprehensive, end-to-end procurement platform or a source-to-pay (S2P) suite, its modularity can mimic bolt-on behavior in specific cases. In other words, its modular design and integration capabilities can blur the lines, allowing it to function in bolt-on-like scenarios depending on how it’s deployed.
SAP Ariba is primarily classified as a comprehensive source-to-pay (S2P) platform, much like Coupa, rather than a classic bolt-on. However, its integration with SAP’s broader ERP ecosystem (e.g., SAP S/4HANA) and its modular origins can make it function in a bolt-on-like capacity in specific scenarios.
Revisiting Forrester Radjou’s earlier comments, is the move from Coupa to SAP Ariba based on an SAP ERP implementation a good move or a move of convenience? In a future post, I will provide a comparative analysis of both Coupa and SAP Ariba in a S/4HANA environment.
However, regarding today’s post, Coupa and SAP Ariba may be considered end-to-end procurement platforms, but they can still be bolt-on solutions. They are comprehensive in terms of the traditional bolt-on definition, but they are modular and, therefore, replaceable like a bolt-on solution.
Procurement Insights
Moving Beyond the Bolt and Escaping the ProcureTech ERP Era?
Posted on March 12, 2025
0
“What is most interesting about Zycus’ tremendous growth rate is that it is indicative of the evolution (some would even suggest fruition) of a trend first presented in a Procurement Insights post from August 31, 2007. Titled “The Ariba Interviews: Re-engineering the Future of On-Demand,” I made reference to several reports and articles that clearly indicated the beginning of a paradigm shift in favor of emerging vendors such as Zycus whose expertise, product quality and SaaS pricing model had finally started to achieve mainstream acceptance. An acceptance that extended beyond the simplistic and largely inaccurate “bolt-on” moniker that had historically been assigned to solutions that fell outside of the traditional ERP-centric “architecture” that had for years dominated the supply chain software landscape.” – Zycus Posts 122 Percent Growth in First Half (January 20th, 2009)
Before reading today’s post, I want you to note the following from the 2009 post excerpt: “An acceptance that extended beyond the simplistic and largely inaccurate “bolt-on” moniker that had historically been assigned to solutions that fell outside of the traditional ERP-centric “architecture” that had for years dominated the supply chain software landscape.“
So, what is a ProcureTech bolt-on solution? What is a ProcureTech APP? What’s the difference? Even more importantly, why should it matter?
In the context of yesterday’s post, Supplier Discovery and the 1998/2025 RAM and forestreet comparison, I am taking the assessment to a deeper level, the result of which may possibly surprise you.
ProcureTech Bolt-On Versus APP
To determine whether Forestreet, 1998 RAM, and 2025 RAM are bolt-on or app ProcureTech solutions, we need to evaluate their scope, integration, deployment, and purpose against the definitions established earlier. A bolt-on solution deeply enhances a core procurement system with specialized functionality, while a ProcureTech app is a lightweight, standalone tool for specific user tasks.
1. 1998 RAM (Relational Acquisition Model)
2. 2025 RAM (Speculative Modern Iteration)
3. Forestreet
Comparison Table
Analysis
Why Not Apps?
None of these qualify as ProcureTech apps because:
Conclusion
All three lean toward the bolt-on category in the ProcureTech spectrum, reflecting their roles as systemic enhancers rather than standalone, user-focused apps. This aligns with their design to transform procurement operations, not just assist individual tasks.
Why Knowing The Difference Is Important
Before 2014, ERPs were viewed as the heart and soul of an enterprise responsible for finance and all company-related functions – including purchasing. Unfortunately, practical functionality beyond IT department management and finance department interests was virtually non-existent. In other words, purchasing department requirements were, at best, an afterthought and, at worst, wholly discounted.
The following excerpt from an August 2009 Procurement Insights post highlights the challenges with an ERP-centric approach to procurement process efficiency and effectiveness:
“In an August 9th, 2007 post titled “Double Marginalization and the Decentralized Supply Chain,” I referenced a 2002 article by Forrester Research’s Navi Radjou, who had stated that the “inherent problems of enterprise-centric applications from vendors such as Oracle,” is their lack of flexibility to interact with stakeholders on a real-time basis. The challenge this presented, according to Radjou, is that “batch-based supply chain tools can’t support a swift resolution of supply chain glitches.” In short, these “apps need time to collect and synthesize data from multiple sources.”
The main challenge with the”synthesization” process associated with ERP-centric applications is that the output is rendered ineffective in terms of responding to real-world situations. This forces organizations to rely on static, outdated historic data that provides a lens on what has already happened without giving meaningful direction as to what should happen.
Radjou’s conclusions that “unlike static, linear supply networks,” the emergence of adaptive supply networks that are “powered by multi-partner processes that are event-driven, real-world aware and self-regulating” represent the framework upon which today’s innovative SaaS BI platforms operate. Despite the enthusiasm expressed by Oracle’s Larry Ellison regarding Project Fusion SOA offering near real-time interaction, it still falls far short of what is needed in a dynamic, globally engaged enterprise.”
A Case In Point
Not too long ago, I was told about a company that switched from Coupa to SAP Ariba when they implemented SAP S/4HANA.
While Coupa is considered to be a comprehensive, end-to-end procurement platform or a source-to-pay (S2P) suite, its modularity can mimic bolt-on behavior in specific cases. In other words, its modular design and integration capabilities can blur the lines, allowing it to function in bolt-on-like scenarios depending on how it’s deployed.
SAP Ariba is primarily classified as a comprehensive source-to-pay (S2P) platform, much like Coupa, rather than a classic bolt-on. However, its integration with SAP’s broader ERP ecosystem (e.g., SAP S/4HANA) and its modular origins can make it function in a bolt-on-like capacity in specific scenarios.
Revisiting Forrester Radjou’s earlier comments, is the move from Coupa to SAP Ariba based on an SAP ERP implementation a good move or a move of convenience? In a future post, I will provide a comparative analysis of both Coupa and SAP Ariba in a S/4HANA environment.
However, regarding today’s post, Coupa and SAP Ariba may be considered end-to-end procurement platforms, but they can still be bolt-on solutions. They are comprehensive in terms of the traditional bolt-on definition, but they are modular and, therefore, replaceable like a bolt-on solution.
30
Share this:
Related