Databricks targets P2P with Services-as-Software™ playbook

Databricks is recruiting a Senior Director, Procure to Pay, who will deliver an HFS Research Services-as-Software™ -inspired blueprint for converting a people-heavy enterprise service into a software-defined operating model.

The potential to eat into service providers’ BPO and consulting margins is explicit (see exhibit 1). Enterprise leaders should take this moment to ask themselves if job descriptions in their procurement department – and beyond – are keeping pace. Job descriptions across the organisation are likely to need to be redrawn to align with the impact of AI on traditional roles. Leading AI-first firms such as Databricks show the way.

Exhibit 1: The artifact Databricks is about to build is an encoded, continuously learning P2P operating model

Source: HFS Research analysis of Databricks Sr. Director, Procure to Pay job description, 2026

HFS coined Services-as-Software to describe the $1.5 trillion collision of enterprise tech and services spend, as work traditionally delivered by people is codified into AI-native platforms. This hire is an example of the software-led servitization leg of that framework: agentified labor and native orchestration inside software platforms displacing services via productized models.

The San Francisco-based role – with salary of up to $326,700 plus bonus and equity, is, At first glance a finance operations hire. But read the job description and it becomes clear the role owns Databricks’ “global P2P engine”: procurement operations, supplier onboarding and risk, accounts payable, financial controls, and the systems that tie them together. And it comes with a mandate to transform.

They want to build AI-driven workflow orchestration; automation from intake through payment; increased throughput without adding headcount; real-time spend visibility; explicit authority over insourcing, outsourcing, and shared-services decisions; with a stated preference for candidates who have led BPO transitions.

Databricks has enabled P2P before: SAP and Salesforce data unification, AP analytics, marketplace solutions, and partner offerings such as KPI Partners’ ProcurementIQ built on Agent Bricks. But it has never operated an outcome-accountable P2P service. This role could indicate a new direction.

Databricks will now generate its own process data, exception patterns, control designs, evaluation frameworks, and operating metrics from running P2P as an AI-orchestrated function. The job spec is effectively an excercise in service codification (exhibit 1).

The artifact Databricks is about to build is an encoded, continuously learning P2P operating model running on its own platform – and that is inherently productizable, and by absorbing the analysis, coordination, exception handling, and operational decision-making wrapped around SAP it is eating right into the layer for BPO and consulting margins.

Databricks is setting out to learn how to turn an enterprise service into software, by working on itself first. That is a textbook Services-as-Software move, and the process knowledge, orchestration patterns, and proof points it generates are exactly what a software company needs to claim space currently owned by shared services, consultants, and BPO providers.

The Bottom Line: Databricks isn’t launching a P2P business (yet) but it is learning how to turn an enterprise service into software. That is a textbook Services-as-Software move, and the process knowledge, orchestration patterns, and proof points it generates are exactly what a software company needs to ear into terriroty owned by shared services, consultants, and BPO providers.