SAP, Salesforce, and the Emergence Engine
How Enterprise Platforms Are Changing the Rules — and Why Some Organisations Will Extract Ten Times the Value of Others from the Same Software
Enterprise platforms are no longer systems you manage. They are becoming systems that manage work. SAP, Salesforce, and ServiceNow have crossed a line. On one side: software that stores and displays. On the other: software that acts, decides, and adapts. The organisations that understand this difference will extract dramatically more value from the same licence fee. Those that do not will keep paying more for software they use at thirty percent of its capability.
The Platform Has Changed More Than Most Organisations Realise
For thirty years, enterprise software followed a predictable logic. SAP held your financial data. Siebel held your customer records. Oracle managed your supply chain. The software was a repository. Humans were the intelligence layer on top of it. If you wanted to know what the platform was telling you, you hired analysts, built reports, and ran dashboards. The platform stored. You interpreted. You decided.
Salesforce changed the model partly when it moved CRM to the cloud. ServiceNow changed it again when it automated ITSM workflows. SAP S/4HANA took another step when it moved transactions to real-time. But these were changes in delivery speed and accessibility, not in the fundamental logic of who was doing the thinking.
What has changed since 2023 is different in kind, not just degree.
Salesforce Agentforce deploys autonomous AI agents directly inside CRM workflows. These agents handle customer queries, qualify leads, update records, and escalate to human reps — not when a human tells them to, but when the agent determines escalation is warranted. SAP Business AI is embedded natively across S/4HANA: it flags procurement anomalies before they become problems, proposes journal entries, detects supplier risk, and summarises financial close status in natural language. ServiceNow’s AI platform rewrites its own workflows when it detects recurring failures.
This is not automation in the traditional sense. Automation follows rules someone wrote. What these platforms are now doing is taking action inside a context they read themselves. That is a qualitatively different thing. The platform has become an agent. The question is no longer whether you have these platforms. It is whether your organisation is built in a way that lets you actually use what they have become.
The core problem: Most organisations have licenced Era 3 platforms and are using them like Era 1 tools. They have Agentforce switched off. They have Business AI enabled for three peripheral features. They have ServiceNow’s AI layer sitting dormant because no one has redesigned the workflows that would let it act. The capability gap is not in the software. It is in the organisation.
Why the Same Platform Produces Different Outcomes
Two organisations can sign identical SAP S/4HANA contracts on the same day. Five years later, one has reduced its financial close from twelve days to two. The other is still on twelve days and has just renewed its licence at a higher cost. The software is identical. The outcome is not. What explains the gap?
The answer is not technical skill. Both organisations have certified SAP consultants. Both went through implementation. Both trained their staff. The difference is organisational architecture: specifically, whether the organisation built itself around what the platform can do, or merely installed the platform and preserved the organisation it already had.
In the OEF framework, we distinguish two post-transformation organisational models. The Restructured Machine has gone through digital transformation. It has moved to the cloud. It has deployed the platform. But its fundamental operating logic is unchanged: humans receive reports from the platform, deliberate, and then decide. The platform is a faster, more connected version of the same system.
The Super Organism is built differently. Its interaction clusters — the working units of humans and AI agents — are designed around the platform’s intelligence layer, not around the reports the platform generates. When Agentforce handles a tier-1 customer query, there is a human in the cluster whose job is to handle exceptions, set thresholds, and intervene when the agent’s decision needs review. That human is not waiting to be told what the platform thinks. That human and the platform are co-producing the outcome together, in real time.
The difference in platform value extraction is not marginal. Organisations in the Restructured Machine category typically use thirty to forty percent of what their enterprise platform is capable of. Super Organism organisations reach eighty to ninety-five percent. The licence cost is the same. The gap in value is enormous.
What drives the gap: Restructured Machines fear autonomous agent action because they have no trusted human-agent operating model. Super Organisms allow it because they have built the oversight layer into their cluster design. Trust is not a cultural disposition. It is an organisational structure.
What Enterprise Platforms Are Doing Inside ITES Workflows Right Now
The shift is not hypothetical. It is already running inside the large ITES firms. The question is whether the organisation is structured to benefit from it or to resist it.
Salesforce Agentforce in BPO and CX Delivery
Before Agentforce, a Salesforce-enabled customer service operation worked like this: the platform showed the agent the customer’s history, purchase records, and open cases. The human agent read the screen and decided what to say. The platform was a display.
With Agentforce, the dynamic has changed. Autonomous agents now handle the tier-1 case queue directly. They respond to customers, update case records, process returns, and route to human reps only when the case requires judgment that the agent cannot apply. In a large CX delivery operation, this means the human reps are no longer triaging or responding to basic queries. They are doing the work the agent cannot: complex negotiation, emotionally sensitive escalations, decisions that require cross-system context the agent does not have permission to access.
For Indian ITES firms running Salesforce-based CX operations for global clients, this is a structural shift. The headcount model for tier-1 CX has changed permanently. The skill requirement for the humans in the loop has changed. And the client expectation — response time, resolution rate, cost per case — has shifted to a new baseline that only an Agentforce-enabled operation can meet.
SAP Business AI in F&A and Procurement BPO
SAP Business AI is embedded across fourteen functional areas in S/4HANA. In Finance and Accounting BPO, the most significant changes are in three areas: automated journal entry proposal, exception detection in invoice processing, and financial close summarisation in natural language.
Automated journal entry proposal means the system reads transaction data and suggests the appropriate accounting entry, which a human reviewer approves or modifies. This is not replacing the accountant. It is changing what the accountant’s time is spent on. The accountant is no longer creating entries. The accountant is reviewing and overriding AI proposals — a materially different cognitive task that requires deeper understanding of accounting principles, not less.
Exception detection in invoice processing catches mismatches, anomalies, and potential duplicates before human review. This is reducing the volume of human intervention required for routine invoice processing by sixty to seventy percent in deployments that have properly configured the system. The humans remaining in the workflow are handling the exceptions the system cannot resolve.
For Indian F&A BPO firms, this is not an incremental efficiency improvement. It is a change in what the operation is. The operation is now an exception-management and AI-oversight business, not a transaction-processing business. That requires different people, different skills, and different reporting structures.
ServiceNow AI Platform in IT Services
ServiceNow’s AI layer has moved from workflow automation to what the company calls self-healing operations. Anomalies in IT infrastructure trigger automated remediation flows. Incident patterns are detected and root causes proposed before the human team has opened a ticket. Change risk is assessed by AI and flagged for human review based on risk score.
For Indian IT services firms running managed services operations on ServiceNow, this has changed the nature of the L1 and L2 support function. A significant portion of what L1 support staff did — acknowledging incidents, running standard diagnostics, applying known fixes — is now handled by the platform directly. The human team is doing L2 and L3 work by default. The cost model for the operation has changed. The skill requirement has changed. And the staffing ratio — humans per managed endpoint — has changed.
India ITES: The Implementation Layer That Must Become the Intelligence Layer
India’s ITES industry is, in a meaningful sense, the world’s enterprise platform implementation and delivery infrastructure. The large firms — TCS, Infosys, Wipro, HCL, Tech Mahindra, and Cognizant — collectively hold more SAP, Salesforce, ServiceNow, and Oracle certified professionals than most other countries combined. India runs a significant portion of the world’s SAP-based F&A operations, Salesforce-based CX operations, and ServiceNow-based IT service management.
This position is a profound advantage. India’s ITES workforce has deep platform expertise, client relationship depth, and a track record of delivery at scale. When SAP launches Business AI or Salesforce ships a new Agentforce capability, Indian firms have the volume of deployments to iterate fast, the talent to configure and customise, and the client relationships to pilot and prove.
Get Praveen Shandilya’s stories in your inbox
Join Medium for free to get updates from this writer.
But the position also carries a risk that is worth naming plainly.
The risk: India ITES has built its competitive advantage on being the implementation layer for platform capability designed elsewhere. As platforms become emergence engines, the value is no longer in implementing what the platform does. The value is in knowing what to do with what the platform has become. That is a different capability — and it lives in organisational design, not in certification.
The firms that will lead the next decade are not those that implement Agentforce for clients. They are those that build internal Super Organism capability using Agentforce and then sell that operational model to clients. The product is no longer the implementation. The product is the proven operating model.
Infosys’s Topaz Fabric is an example of an attempt to move in this direction: an AI capability layer that sits across enterprise platform implementations and adds a coordination intelligence layer on top. TCS’s Ignio, which started as an AI engine for IT operations on ServiceNow, is another. These are not just service offerings. They are attempts to move from being an implementation partner to being an emergence engine partner.
The ITES firms that succeed in the next five years will be the ones that ask a different question. Not: how do we implement this platform capability? But: how do we build an organisation that uses this platform capability better than our clients can on their own — and then help our clients build the same?
The Emergence Engine Stack: What a Super Organism Actually Does with a Platform
We can now be specific about what distinguishes a Super Organism’s relationship with an enterprise platform from a Restructured Machine’s relationship. The difference is in what gets built on top of the platform — and who builds it.
The platform vendor builds three things. First, the data and integration foundation: S/4HANA, Salesforce Data Cloud, ServiceNow’s CMDB. Second, the process fabric: the standard workflows, objects, and automation rules. Third, the intelligence layer: Agentforce, Business AI, ServiceNow AI — the autonomous agents and AI features that act inside those workflows.
What the platform vendor cannot build — because it is specific to each organisation — are layers four and five. Layer four is what the OEF calls guided emergence: the interaction clusters of humans and AI agents that decide how to use the platform’s intelligence layer, when to override it, and how to escalate. Layer five is the Constitutional Core: the mission-anchored values and non-negotiable commitments that govern every agent action and every human override decision.
The insight that matters: The Restructured Machine buys layers one through three and stops. It has the platform. It has the workflows. It may even have the AI features switched on. But it has not built the guided emergence layer (four) or the Constitutional Core (five). So the platform’s intelligence layer has no trusted operating context. Autonomous agents are disabled because no one trusts the agents to act within the organisation’s values. The platform is, in practice, an Era 1 tool wearing Era 3 software.
The Super Organism builds all five layers. Its interaction clusters are the organisational form of layer four. Its Constitutional Core — the mission statement and values that ground every cluster’s operating mandate — is layer five. When Agentforce handles a customer escalation, the agent acts within thresholds set by the cluster. When Business AI proposes a journal entry that falls outside normal parameters, a Domain-AI Specialist in the F&A cluster reviews it. The agent acts. The human oversees. The Constitutional Core defines what neither can compromise.
This is the emergence engine running as designed.
The Practical Implication for Platform Strategy
If your organisation has recently renewed an SAP, Salesforce, or ServiceNow contract, or is in the process of migrating to the current generation of these platforms, there is a decision embedded in how you structure the programme that most programme sponsors do not recognise as a decision.
The default approach to an enterprise platform programme is to treat it as a technology deployment. You hire an implementation partner, you map your current processes to the platform’s standard objects, you train your people on the new screens, and you go live. The programme is done when the technology is running. This is Era 2 thinking applied to an Era 3 platform.
The alternative is to treat the programme as an organisational redesign enabled by the platform. You start not from your current processes but from the question: if an autonomous agent handles thirty percent of what our people currently do, what does the organisation look like — and what do the people do? You redesign your interaction clusters around that answer. You define the agent-human handoff points. You build the oversight roles — the Domain-AI Specialists, the Agentic AI Engineers — before the platform goes live, not as an afterthought when people start worrying about their jobs.
This is a different programme. It takes longer to plan. It requires the CHRO to be in the room alongside the CTO. It requires the Constitutional Core — your mission and values — to be stated explicitly as a constraint on agent behaviour, which is uncomfortable for organisations whose Constitutional Core has only ever been a slide in the annual review presentation.
But it is the programme that produces layer four and five. And without layers four and five, you will spend the next five years paying for an emergence engine that you are running as a data warehouse.
What This Means for Platform Buyers, Implementation Partners, and the People in Between
Three audiences read this differently.
For enterprise platform buyers in ITES and beyond: The question to ask your implementation partner is not “how will you configure this for our current processes?” It is “how will you help us redesign our operating model around what this platform now does autonomously?” If your implementation partner cannot answer the second question, you have the wrong partner for an Era 3 programme.
For Indian ITES firms implementing platforms for clients: The competitive moat is shifting. Certification volume and delivery track record are necessary but no longer sufficient. The firms that will command higher margins are those that come to the engagement with a proven model for building layers four and five — the guided emergence and Constitutional Core layers — not just the technical implementation of layers one through three. This means investing in OEF-type organisational design capability alongside your SAP and Salesforce certifications.
For the professionals inside these organisations: The work is changing in a direction that rewards different things. The SAP consultant who can configure a workflow is being supplemented by the Domain-AI Specialist who can define where in that workflow a human must be present and why. The Salesforce admin who sets up Agentforce is less valuable than the AI Workflow Redesign Specialist who defines the agent-human handoff logic that makes Agentforce trustworthy in a regulated environment. These roles exist now. They are not abstractions.
“The platform has become an agent. The organisation that understands this will treat platform implementation as organisational redesign. The one that does not will spend five years paying for intelligence it never uses.”
The Honest Difficulty
There are reasons most organisations do not build layers four and five, and they are not irrational.
Building guided emergence requires accepting that some roles will change substantially and that this needs to be managed, not avoided. Most platform programmes are sold as efficiency plays, not as restructuring programmes — because restructuring programmes face resistance and take longer to approve. The path of least resistance is to implement the technology and leave the organisational model largely intact. The result is the thirty to forty percent value extraction that characterises the Restructured Machine.
For Indian ITES firms specifically, there is a client expectation problem. Clients commission platform implementations, not organisational transformation programmes. The ITES firm that says “we will implement your SAP S/4HANA and redesign your operating model” is proposing a more complex and expensive engagement than the one that says “we will implement your SAP S/4HANA.” Short-term procurement decisions favour the latter. Medium-term value creation strongly favours the former.
The ITES firms that crack this problem — that learn how to sell the five-layer programme to clients who think they are buying a three-layer programme — will define the next chapter of the Indian technology services industry.
Where This Sits in the OEF Journey
This article is the fourteenth in the series. We have moved through the full OEF methodology: from defining the Interaction Cluster as the fundamental unit of an AI-era organisation, through measuring cluster health and diagnosing gaps, through the four intervention types and the specific challenges of hiring for AI-era roles and designing reskilling pathways, to the Super Organism as the target organisational model.
This article asks a different question from the ones before it. Not: what should your organisation look like? But: what does the technology environment you are operating in now require of your organisation? The answer is that enterprise platforms — the backbone of every large ITES operation — have become intelligence engines. They are expecting a certain kind of organisation on the other side of the deployment. The Super Organism is that organisation. The Restructured Machine is not.
The final article in this series will examine how the OEF applies beyond ITES — to government, public sector, and sectors where the emergence dynamic is moving more slowly but is no less consequential. The framework does not change. The starting conditions do.
