{"id":26954,"date":"2026-09-30T10:58:36","date_gmt":"2026-09-30T08:58:36","guid":{"rendered":"https:\/\/scheer-pas.com\/en\/?post_type=post_type_article&p=26954"},"modified":"2026-10-02T11:02:22","modified_gmt":"2026-10-02T09:02:22","slug":"model-to-execution-why-the-old-phased-model-suddenly-works-again","status":"publish","type":"post_type_article","link":"https:\/\/scheer-pas.com\/en\/blog\/article\/model-to-execution-why-the-old-phased-model-suddenly-works-again\/","title":{"rendered":"Model to Execution: Why the Old Phased Model Suddenly Works Again"},"content":{"rendered":"
<\/div>\n\n<\/div><\/div>BLOG<\/p>\n<\/div><\/div><\/div><\/div>
September 30 | Sharam Dadashnia<\/p>\n<\/div><\/div><\/div><\/div><\/div>
Three terms that many still recognise from their training, studies, or first major implementation projects. And three terms that were long considered a symbol of IT that moved too slowly.<\/p>\n
<\/p>\n
Much of the criticism was justified. Thick documents piled up between the business unit and the development team. By the time the IT concept was finalised, the business had long since moved on. Implementation began with a model that was already incomplete by the time of the first release. Later, no one knew anymore whether the BPMN diagram, the wiki, or the running code actually described the process.<\/p>\n
<\/p>\n
The problem, however, was not the separation of business logic and technology.<\/p>\n
<\/p>\n
The problem was that the middle ground remained on paper.<\/p>\n
<\/p>\n
With agent-based processes, this intermediate level takes on a new role. It doesn\u2019t just describe what<\/em> a process is supposed to do. It defines which steps run deterministically, which tasks an AI agent handles, which systems it is allowed to access, when a human makes a decision, and how a process remains controllable over the course of weeks.<\/p>\n <\/p>\n This transforms an IT concept back into what it should have been: an executable link between business requirements and operations.<\/p>\n<\/div><\/div><\/div><\/div> The classic model promised a clear division of labour:<\/p>\n <\/p>\n <\/p>\n In practice, the connection usually broke down at the second stage.<\/p>\n <\/p>\n The business department worked with process diagrams, tables, and free-form text. Development wrote code, database scripts, and interface logic. Between these two worlds lay handoffs, clarifications, version conflicts, and often multiple tools. After the first process change, there wasn\u2019t enough time to update all the documents.<\/p>\n <\/p>\n This led to a familiar pattern: The business concept was understandable but not executable. The code was executable but virtually unreadable to business departments. And the IT concept lay somewhere in between, usually as a document with an outdated revision status.<\/p>\n <\/p>\n Agile development has solved part of this problem. Teams deliver in smaller increments, coordinate more frequently, and test earlier. What it doesn\u2019t automatically solve is the lasting connection between business process logic, integrations, authorisations, agents, and operations.<\/p>\n <\/p>\n This connection is becoming more important again. After all, an AI agent can be built quickly. A productive business process involving AI agents is something else entirely.<\/p>\n<\/div><\/div><\/div><\/div> A technical process concept used to describe primarily data models, interfaces, user interfaces, rules, and error handling. These topics remain. But for Agentic Process Orchestration, additional questions arise.<\/p>\n <\/p>\n A modern concept must, at a minimum, answer the following:<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n This is not an add-on for AI projects. It is the technical description of the process itself.<\/p>\n <\/p>\n A process model can remain the guiding structure here. At Scheer PAS, the process logic is modeled using BPMN, connected to applications and data sources via integration logic, and executed by the process engine. Agents are embedded within this workflow rather than running as isolated automations alongside it.<\/p>\n<\/div><\/div><\/div><\/div> Getting started today can be much more straightforward than in the past.<\/p>\n <\/p>\n A business unit doesn\u2019t have to start with a 60-page requirements specification. It can simply describe what should happen:<\/p>\n <\/p>\n When a customer inquiry is received via email, the attachments and email content should be checked. Missing technical details must be identified. Complete inquiries are forwarded to production planning. If information is incomplete, the sales department should receive a draft response for approval. After three business days without a response, the process is escalated.<\/p>\n <\/p>\n Even this short text already contains a great deal of process logic:<\/p>\n <\/p>\n <\/p>\n Language models can help generate an initial draft based on such a description: process steps, open questions, possible data objects, or a proposal for a BPMN model. The benefit does not lie in the fact that the AI \u201cknows\u201d the process. Rather, it forces requirements into a verifiable form early on.<\/p>\n <\/p>\n However, the first draft is never a green light for implementation.<\/p>\n <\/p>\n It is the beginning of the business dialogue: What exactly does \u201ccomplete\u201d mean? Which details are required? Can an agent assess technical relevance, or can it only identify missing information? Is it allowed to send a follow-up query, or only to create a draft? Which cases go directly to a human?<\/p>\n <\/p>\n This clarification was also necessary in the past. It just often took place too late…after the business department and IT had already settled on different interpretations.<\/p>\n<\/div><\/div><\/div><\/div> Here lies an important difference between a serious implementation and a nice demo.<\/p>\n <\/p>\n Uploading a BPMN diagram as an image in a chat and asking whether the process can be improved can be useful for a workshop. For productive processes, it is not enough. An image carries no robust technical semantics: no version, no binding data structures, no permissions, no linked interfaces, and no runtime status.<\/p>\n <\/p>\n The bidirectional mapping between the model and the implementation is crucial. This means:<\/p>\n <\/p>\n <\/p>\n An example: In the quotation process, an agent is added that evaluates technical attachments. In the model, it is not just an anonymous box labeled \u201cAI.\u201d It has a clear place in the workflow.<\/p>\n <\/p>\n It is defined:<\/p>\n <\/p>\n <\/p>\n This makes the agent\u2019s logic part of the process system. It can be tested, monitored, versioned, and verified in the context of the entire process.<\/p>\n <\/p>\n Current approaches to agent-based process execution follow the same line of thinking: a predefined workflow specifies the structure and control points, while agents handle the variable or unstructured tasks. The \u201cPlan-then-Execute\u201d pattern, for example, separates planning and execution to make behavior more controllable and verifiable. SAP describes this pattern for responsible agent-based AI<\/a>. Research on agentic business process management also focuses on the combination of process rules, agents, and context-dependent execution. One example is the approach with separate roles for process frameworks and operational processing in a scientific study on LLM agents in business processes<\/a>.<\/p>\n<\/div><\/div><\/div><\/div> In many companies, agent development begins differently: A team identifies an interesting task, connects a model with a few tools, and demonstrates its value. This can be a sensible starting point.<\/p>\n <\/p>\n Problems arise when this prototype subsequently becomes “unnoticed” part of a critical end-to-end process.<\/p>\n <\/p>\n In such cases, the very information that a process model makes visible is usually missing:<\/p>\n <\/p>\n <\/p>\n Agents should therefore be derived from the process model, not built around it.<\/p>\n <\/p>\n A well-modeled process makes it clear where an agent actually adds value. Not every step needs one. A credit limit, an approval threshold, or an escalation after a deadline has passed are best implemented as fixed rules. They are predictable, testable, and cost-effective.<\/p>\n <\/p>\n The agent belongs where language, documents, context, or domain-specific classification are required:<\/p>\n<\/div><\/div><\/div> Invoice total exceeds a defined amount<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td> Rule or decision table<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td>\t\t\t\t\t<\/tr>\n\t\t\t\t\t\t\t\t\t Recognise and categorise unstructured inquiries<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td> AI agent<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td>\t\t\t\t\t<\/tr>\n\t\t\t\t\t\t\t\t\t Identify missing information from emails and attachments<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td> AI agent with structured output<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td>\t\t\t\t\t<\/tr>\n\t\t\t\t\t\t\t\t\t Send a reminder for customer approval after ten days<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td> Process rule and timer<\/p><\/div>\n <\/div>\n\n<\/div><\/div><\/div><\/td>\t\t\t\t\t<\/tr>\n\t\t\t\t\t\t\t\t\t
<\/div>\n\n<\/div><\/div><\/div>Why the phase model has fallen into disrepute<\/h2>\t<\/div>\n\n<\/div><\/div>
\n
<\/div>\n\n<\/div><\/div><\/div>The IT concept has more substance today than it did three years ago<\/h2>\t<\/div>\n\n<\/div><\/div>
\n
\nFor example, a required-field check, an approval threshold, or an escalation after five business days.<\/li>\n<\/ul>\n\n
\nSuch as reviewing a complaint, classifying a technical inquiry, or verifying whether a document appears to be complete.<\/li>\n<\/ul>\n\n
\nAn agent responsible for document analysis has a different mandate, different data, and different permissions than an agent who prepares customer communications.<\/li>\n<\/ul>\n\n
\nNot every process step requires access to all customer data, contracts, or internal knowledge sources.<\/li>\n<\/ul>\n\n
\nThese include ERP, CRM, document management, line-of-business applications, APIs, and event sources.<\/li>\n<\/ul>\n\n
\nEspecially for legally relevant, financial, or technically contentious decisions, a review point must be part of the workflow\u2014with a designated role, deadline, and escalation process.<\/li>\n<\/ul>\n\n
\nA subsequent audit trail must be able to show which process went through which step and when, what data was used, and who granted approval.<\/li>\n<\/ul>\n
<\/div>\n\n<\/div><\/div><\/div>The standard approach: Describing requirements in natural language<\/h2>\t<\/div>\n\n<\/div><\/div>
\n
<\/div>\n\n<\/div><\/div><\/div>A BPMN model is not merely a screenshot for a language model<\/h2>\t<\/div>\n\n<\/div><\/div>
\n
\n
<\/div>\n\n<\/div><\/div><\/div>Agents do not emerge separately from the process model<\/h2>\t<\/div>\n\n<\/div><\/div>
\n
\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t Process situation <\/h4>\t<\/div>\n\n<\/div><\/div><\/div><\/td>
Appropriate tool<\/h4>\t<\/div>\n\n<\/div><\/div><\/div><\/td>\t\t\t\t\t<\/tr>\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t \n\t\t\t\t\t\t \n\t\t\t\t\t\t \n\t\t\t\t\t\t \n\t\t\t\t\t\t