Skip to content

Back to the catalog

AI-Decision Checkpoints for AI-Augmented Business Process Management: Framework and Educational Instantiation
arxiv.orgpaper

AI-Decision Checkpoints for AI-Augmented Business Process Management: Framework and Educational Instantiation

This paper proposes AI-decision checkpoints, explicit moments in business process development where process developers must evaluate whether to adopt, constrain, or reject AI-candidate sub-processes built with LLMs, RAG, or AI agents, based on expected effects on time, cost, quality, flexibility, and legal or organisational constraints. The checkpoints are embedded in a six-module BPM teaching lifecycle covering process modeling, simulation, workflow execution with AI agents, and process mining, piloted via a fictitious customer-onboarding teaching case with formative observations drawn from instructor logs and student artifacts. It addresses a curriculum gap where AI is still treated as a bolt-on rather than a first-class design element in BPM education.

TL;DR A framework and BPM teaching case introducing structured AI-decision checkpoints to help process developers decide where LLM, RAG, or agent components belong in business processes.
Open original ↗
Document

What it claims

Each phase of the standard six-phase BPM lifecycle (identification, discovery, analysis, redesign, implementation, monitoring) gets one AI-decision checkpoint (CP1–CP6). Each checkpoint produces a named artifact and a recorded decision to adopt, adapt, postpone or reject an AI component. That replaces one yes/no call on AI with a chain of assessments, each grounded in that phase's own instruments, plus a decision trail that can be revisited. The checkpoints define no correct answer; they grade the quality of the reasoning. They can be weighted or merged without breaking the sequence.

How it works

CheckpointQuestionArtifact
CP1 IdentificationWhich subprocesses are plausible AI candidates (knowledge-intensive, data-heavy, repetitive, scarce expertise)? Scored on the devil's quadrangle (time, cost, quality, flexibility) plus GDPR, ethics, data availability, readinessAI opportunity register with prioritisation matrix
CP2 DiscoveryWhere would candidates attach in the as-is model, and which roles and systems do they affect? Candidates are positioned, not yet integratedAs-is model plus AI-positioning note
CP3 AnalysisWhat is the baseline? Throughput, waiting time, utilisation and workload sensitivity, from process mining or from simulating the CP2 modelBaseline report; the simulation model is reused later
CP4 RedesignDo AI variants beat the baseline when combined with classic redesign moves (task elimination, resequencing, parallelisation)?Comparative redesign-and-simulation dossier
CP5 ImplementationIs the design realisable on the chosen workflow platform and AI services?Feasibility and governance dossier per AI component
CP6 MonitoringDo AI subprocesses behave as intended and deliver net value? Discovery and conformance (e.g. bypassed AI steps) plus performance against the CP3 baseline and CP4 expectationsMining-based evaluation, fed back to CP1

In CP4, all variants are simulated under the same assumptions:

  • LLM agents for email intake and document data extraction
  • RAG agents for fraud screening that retrieve AML rule documents
  • Classical redesigns with no AI, used as the comparison

In CP5, where the platform lacks the needed control flow, the paper prescribes compensating structures:

  • schema-constrained prompts
  • extra validation tasks
  • explicit human approval steps
  • fallback paths triggered on AI failure or low confidence
  • logging, thresholds and escalation rules

The paper motivates these with documented LLM weaknesses in control-flow reasoning (Kluza et al.).

flowchart LR
  CP1[CP1 opportunity register] --> CP2[CP2 positioning]
  CP2 --> CP3[CP3 baseline]
  CP3 --> CP4{CP4 simulate variants}
  CP4 -->|LLM / RAG variant| CP5[CP5 governance]
  CP4 -->|classical, no AI| CP5
  CP5 --> CP6[CP6 mining eval]
  CP6 -->|feedback| CP1
  CP3 -.baseline.-> CP6

In the course, CP4 is split across two modules: a workflow-net simulation redesign in M3 and a BPMN exception-handling redesign in M4. The case is a fictitious banking customer-onboarding process.

Evidence

The literature scan was a single Scopus query, which returned 45 documents as of 2026-05-31. Three were judged indirectly related; none covers AI decisions across all lifecycle phases.

The course is Master's level, for final-year Business Information Systems or Computer Science students with no prior BPM or AI knowledge. The author has run it for more than 15 years. The text shows 152 enrolled students, then cuts off.

The only outcome claim is from the abstract: "exploratory observations" suggest students drew clearer distinctions between task-level automation and process-level value. It rests on instructor observations, student artifacts and LMS event logs. No metrics or comparison group appear in the fetched text.

Limits

  • The fetched text stops at Section 4. The instantiation details, the formative reflection (Section 5) and the conclusions were not visible.
  • The authors call the evaluation preliminary and formative.
  • Event logs for CP6 are pre-generated in the course setting, not taken from a real deployment.
  • The method is a pedagogical framework, not a validated industrial method.

Techniques named here

  • AI-decision checkpoints

Related in ai-policy