From BPR to BSR: Why AI Shifts Organizational Focus from Processes to Scenarios

The Core Problem: Local Speed vs. Collective Decisions

The article opens with a Monday-morning scenario: a manufacturing firm receives an urgent request to advance delivery by ten days, increase quantity by 30%, and use an unqualified substitute supplier. Five departmental AI agents (sales, supply chain, scheduling, finance, quality) each produce locally optimal answers, yet the general manager still needs a two-hour meeting to stitch them into a single enterprise commitment. The paradox: every local function got faster, but the joint decision did not.

This reflects a broader mismatch: AI has dramatically raised the productivity of understanding, judgment, and action, but most enterprises still organize work around departments, roles, processes, and isolated systems. Citing IBM's 2025 CEO survey (2,000 CEOs, 33 countries) where only 25% reported expected ROI from AI projects and 16% had scaled AI enterprise-wide, and McKinsey's 2026 survey (1,719 respondents, 97 countries) where 80% saw personal productivity gains but only 37% saw positive EBIT impact and just 6% qualified as 'AI high performers,' the author notes that high performers fundamentally redesign workflows around AI rather than inserting AI into existing workflows.

Historical Lens: What BPR and ERP Actually Achieved

The article traces the last major reorganization—Business Process Reengineering (BPR) in the 1990s (Hammer, 1990; Hammer & Champy, 1993). BPR's key contribution was shifting management's gaze from departmental activities to end-to-end customer outcomes, introducing process owners (accountable for a class of processes) and case managers (single point of contact for a specific instance). ERP then provided the scalable execution substrate, codifying industry best practices into standard transactions, master data, roles, and control rules. The 'fit-to-standard' implementation method essentially continued BPR inside software delivery.

However, BPR/ERP excels at stable, repeatable, low-risk work (payroll, routine procurement). It struggles with situations that cannot be fully defined before the process starts —precisely the high-value, high-variability, cross-system, multi-judgment scenarios that now dominate competitive differentiation.

Why the Center of Gravity Moves from Process to Scenario

Management history is a migration of the organizational center of gravity: function → process → scenario. In the IT era, data and tasks could not flow freely in real time, so 'what this class of situation promises' and 'the stable steps to deliver it' were welded together into a single process. AI agents and real-time data now decouple them: the scenario answers 'what promise are we making this time, and where are its boundaries?', while task contracts and orchestration answer 'which capabilities do we invoke and how do we deliver?'.

The article contrasts the two operating chains:

BPR world: An incoming order is classified into a standard process type; promises, rules, and responsibilities are pre-set at design time; the process owner owns the end-to-end result for the class, the case manager for the instance.

BSR world: An incoming situation triggers a scenario ; the enterprise first makes a commitment (for whom, to what extent, with what boundaries); that commitment is translated into a task covenant (result, boundary, judgment, evidence, escalation); tasks flow dynamically among people, agents, systems, and partners; results and evidence write back to authoritative systems; a retrospective with independent reuse validation then feeds stable elements back into processes.

The difference is not the presence or absence of steps, but when judgment is frozen : BPR front-loads reusable judgments; BSR keeps necessary judgments at runtime while preventing loss of control.

BSR's Operating Skeleton: One Chain, Three Layers, Six Relationships

The author defines Business Scenario Redesign (BSR) as:

"Redesigning the specific business scenario as the value context and reconstruction object for organizational commitment formation and fulfillment, re-determining value outcomes, service boundaries, authoritative facts, capability nodes, authority/responsibility, and task operating modes so that the situation can be recognized, triggered, executed, accepted, learned, and reused."

The six relationships to reconstruct:

Value outcome – whose situation changes, how much, why worth scarce resources.

Service boundary – what we promise and explicitly do not promise (quality, safety, legal, cash, existing customer commitments).

Authoritative fact – what each key judgment rests on, which system holds the fact, what remains unknown.

Capability node – which people, agents, processes, systems, partners are needed; they need not move into a new department but must be discoverable, invocable, and releasable within the scenario.

Authority & responsibility – who makes trade-offs, who guards professional red lines, who owns system capabilities/permissions, who approves irreversible risk. Tasks flow between carbon and silicon; full-result accountability stays with a named, authorized person who understands consequences.

Operation & learning – how commitments decompose into tasks, what evidence completes a task, what anomalies stop or escalate, how temporary permissions are revoked, what validation admits experience into the next action.

These form a scenario responsibility network (the 'task-driven responsibility network' in mycelium organization language). Its minimal runtime unit is the task covenant (distinct from a one-off contract), whose thickness varies with risk but whose responsibility anchor is permanent. Three disciplines keep covenants honest:

Hierarchy discipline – distinguishes the whole delivery from its sub-tasks; sub-tasks serve the parent commitment without silently expanding it.

Change discipline – modifying the top commitment is not mere rescheduling; quality gates hold, cross-customer capacity conflicts require authorized arbitration, external promise changes return to the commercial owner.

Closure discipline – temporary collaboration ends and permissions are revoked, but accountability persists; execution traces must link trigger event, fact/rule versions, key judgments, authorization changes, and acceptance evidence.

Positioning Against Neighbors: RACI, ACM, Intelligent BPM

The article fairly acknowledges adjacent practices:

RACI clarifies roles but assumes a fixed process and stable roles; it answers 'who is responsible in the given process,' not 'how responsibilities chain across a scenario with no predefined process.'

Adaptive Case Management (ACM/CMMN) handles non-repeatable cases with runtime human judgment but assumes goals and responsibilities are largely clear; it does not address commitment formation, cross carbon-silicon responsibility configuration, temporary permission revocation, or independent reuse validation.

Intelligent BPM / Agentic BPM (e.g., 2026 Information Systems manifesto) introduces constrained autonomy, delegation, responsibility gaps, and human-in-the-loop boundaries—yet these are runtime concerns. BSR adds the upfront management judgment : which scenario to reconstruct, what commitment to make, who owns the result, then decide whether to invoke a process, a case, or an agent swarm.

BSR therefore has a two-layer structure: value layer (scenario, commitment, boundary, capability combo, result owner) and runtime layer (task covenant, responsibility network). Both are indispensable.

Software Substrate: MOOS and the Mycelial Network Protocol

AI is a general-purpose productive force; ERP is a class of management software. The counterpart for the AI era is the Mycelium Organization Operating System (MOOS) . MOOS does not replace ERP, CRM, MES, finance, or quality systems—authoritative facts and transactions remain there. Instead, MOOS builds a cross-system work order above them: when a scenario appears, it locates facts, assembles people/agents/processes/systems/partners into actionable nodes, writes results back to the systems of record, and keeps responsibility traceable.

Key technical pieces:

Mycelial Network Protocol (MNP) – a common work syntax expressing identity, task, state, capability, permission, evidence, escalation (not just another API).

Common Mycorrhizal Network (CMN) – the live task-flow network formed when nodes connect via MNP. Connection ≠ network ≠ shared value. Shared value requires common facts, shared responsibility, shared gains around the same outcome.

Strong core, live edge – the core guards mission, shared facts, identity/permissions, professional standards, capability interfaces, risk floors; the edge, close to customers and field, autonomously judges, combines capabilities, and acts within clear boundaries (analogous to mission-type tactics in military doctrine).

Forward Deployed Engineers (FDE): Catalyst, Not Crutch

Palantir's FDEs temporarily supply the four missing organizational functions: translating business problems into machine semantics, finding scattered facts, coordinating cross-department resources/permissions/responsibilities, feeding field experience back to product. They effectively erect a temporary 'organizational OS' on the client site. However, the model scales linearly with scarce talent; success does not equal the client's independent operating capability; permissions, responsibilities, and experience often leave with the FDE team.

Palantir's own November 2025 'AI FDE' beta (an interactive agent inside Foundry that works in branches, respects existing permissions, requires review for ontology/code merges) confirms that part of the technical labor can be productized, but who decides what problem is worth solving, who authorizes changes to the business world, who accepts consequences remains a management question. The mature delivery goal: capability stays after the engineer leaves. Chinese policy (MIIT 2026, Shanghai 2026) now explicitly encourages cultivating internal FDE-like teams so external experts only tackle genuinely new problems.

Implementing BSR: Triage, Then Seven Steps

Mirroring ERP-era BPR (product-layer standard processes + on-site adaptation), BSR should have a product layer (MOOS with reference scenarios, task covenants, capability interfaces, risk templates) and an implementation layer. Implementation starts with a single high-impact, cross-department coordination failure—not a full org-chart redraw—and requires the business owner, not IT alone, to drive it.

Pre-work: triage . Fix skill gaps, enforce existing rules, realize nominal authority first. Only when commitments, rules, participants, and sub-tasks keep shifting at runtime and current mechanisms cannot reliably chain them does scenario reconstruction become necessary.

The seven steps:

Select scenario – real problem, high value, controllable boundary, verifiable outcome.

Define outcome – service object, business result, deadline, non-negotiable floor; commit first, discuss models later.

Establish authoritative facts – list sources, owning systems, freshness for order, capacity, inventory, quality, contract, credit. MOOS links, does not create a second set of books.

Map nodes & capabilities – identify people, agents, processes, systems, partners; state what each can and cannot do.

Assign authority & responsibility – task covenant binds result, boundary, judgment, evidence, escalation; business owner owns trade-offs, professionals hold veto/stop rights, system owners explain digital capabilities, qualified persons approve major risks.

Controlled run – let tasks flow in a real but bounded scope; record how AI suggestions are adopted or overruled, how exceptions are handled, how actions write back to business systems. Validates both tech and organizational authorization/responsibility.

Independent reuse validation – a different team, with different responsibilities, handles a similar scenario without original designers or daily FDE help. One success shows preliminary reusability; only after independent acceptance, formal adoption, and ongoing monitoring/correction/retirement does experience become organizational rule. Customer delivery closes on fulfillment; reusable learning moves to a separate learning task with its own owner.

Acceptance Metrics and Falsifiable Predictions

Metrics must shift from project outputs to business outcomes: signal-to-commitment time, cross-department wait/rework, exception escalation/permission recovery, fulfillment & margin, professional veto effectiveness, external-expert dependency decline in independent reuse. Baselines are scenario-specific, not universal.

As a hypothesis awaiting validation, BSR offers falsifiable predictions:

Scenario-reconstructed enterprises show significantly shorter signal-to-commitment times than tool-only peers.

Clearer scenario responsibility networks correlate with fewer cross-department reworks and fewer ad-hoc top-leader interventions.

Enterprises that tighten task covenants with risk exhibit lower irreversible error rates than those that either universally delegate or universally centralize.

Scenarios passing independent reuse validation show declining dependence on original teams and external engineers.

If long-term observation fails to support these, the scope should be narrowed or the hypothesis abandoned.

Five Strong Counter-Arguments and Boundaries

Over-scenarizing stable work. Routine reimbursement, accounting, replenishment should stay in processes. BSR targets high-value, high-variability, high-coupling, high-responsibility situations.

Delegating to an incapable front line. Authority must match capability, information, and accountability; strong core (training, exception takeover) must precede delegation.

Strong core mutating into algorithmic control. Task covenants must include appeal/refusal/escalation channels; humans stay in the loop for key judgments; core rules must be explainable and accountable, not black boxes.

Concentrating responsibility on named individuals without matching resources. Responsibility, authority, resources, and rewards must be configured together—an organizational design issue, not a software fix.

Old wine in new bottles. BPR, case management, agile, process redesign have voiced similar ideas. The novelty is the combination : when agents can understand, orchestrate, and execute in real time, and authoritative facts are locatable across systems, the loop of commitment formation → task covenant → carbon-silicon collaboration → responsibility anchoring → independent reuse becomes technically feasible for the first time. BSR stands or falls on whether enterprises achieve reusable, independently verifiable business results with it.

Closing: The Real End of an AI Project

Returning to the Monday-morning urgent order: a mature organization doesn't need five departments with five AI reports waiting for the GM to stitch them. The request enters the network; MOOS pulls authoritative facts from ERP, CRM, MES, quality systems; relevant people, agents, and systems convene around the scenario; sales states customer value, finance guards cash/margin floors, quality holds professional stop authority, production and supply chain combine options within delegated bounds. The enterprise commits, adjusts, or declines—with a named owner, facts, and evidence explaining why.

After closure, temporary permissions are revoked; exceptions enter retrospective. When another team faces a similar order and independently reuses the scenario template, task covenants, and capability interfaces to reach a judgment, the experience has begun to detach from the original crew. Only after independent acceptance, formal adoption, and continuous governance does the capability truly stay in the organization .

BPR helped ERP turn advanced end-to-end processes into management rules; BSR aims to help MOOS turn scenario-specific value judgments, capability combinations, and responsibility structures into organizational capability. The former makes known work reliably repeatable; the latter lets the enterprise form and keep promises amid change. The true finish line of an AI project is not agent go-live or deployment team departure—it is when the new capability remains in the organization: people know what they answer for, systems know what facts to serve, agents know what they can do and when to stop, and the network can reconnect and produce results again when the next change arrives.