Analyzing structural, operational, and performance impact of process-aware information system updates

Practical problem

Companies continuously tweak the enterprise systems (ERP, CRM) that run their business processes, for example by raising the minimum order quantity in a purchasing function or changing when a loan application is cancelled. Each small rule change ripples through the process: upstream and downstream functions change behavior, orders already in flight are caught by the new rule, and waiting and throughput times shift. IT and process owners today have little support for seeing these effects, because existing change-management approaches reason only about the model (which functions are connected) and ignore what the recorded execution data says about running instances and performance. Without a data-driven view, updates are rolled out blind and their side effects are discovered only when operations slow down or staff and documentation fall out of step.

Research questions

1. Given a process-aware information system and an update to the business rules of one of its functions, how can the structural, operational, and performance impacts of that update be systematically identified and quantified from recorded execution data?
2. How can a digital twin of an organization, built on object-centric Petri nets, be used to model both the system and its updates so that such impacts become computable?
3. Is the resulting method feasible to implement and useful on realistic enterprise data, both simulated and real?

Contributions

• A meta-model of process-aware information systems that relates business processes, functions, objects, constraint and operation rules, updates, and three impact types (structural, operational, performance).
• Formalizes the Digital Twin Interface Model (DT-IM): an object-centric Petri net with linear rule expressions, configurations, operational states, interface bindings, and actions that model system updates as configuration changes.
• A four-step impact analysis method: change detection, prior and posterior structural impact analysis, replay-based prior and posterior operational impact analysis, and function-wise and object-wise performance impact analysis.
• A web-based prototype, ProAct: Impact Analysis, with open source code and a user manual, implementing the four analyses with interactive visualizations.
• Two scenario-based case studies: a simulated procure-to-pay system mirroring SAP ERP rules, and a real-life loan application process (BPI Challenge 2017).

Key findings

• In the simulated procure-to-pay case, raising the minimum material quantity for create purchase order from 5 to 10 for five days affects 37 in-flight purchase requisitions and 95 materials upstream, and up to 32 purchase orders, 24 goods receipts, and 10 invoices before clear invoice.
• The same action reduces the average sojourn time of create purchase order by 9 minutes, cuts the number of purchase orders by 13 during the change window, and shortens average purchase order throughput time by 4 minutes.
• On the real loan application log, five consecutive two-week rule changes to cancel application affect 547, 534, 529, 489, and 410 open applications respectively; 517 of the 547 in the first window sit after create offer, pinpointing where to allocate resources.
• Operational impact counts expose process structure: applications affected after create versus submit differ by only 2 (547 vs 545), and for the call after offers action the offers waiting for return offer equal those waiting for cancel application (321).
• Limitations: the structural analysis treats all connected transitions as equally impacted, operational counts are only as reliable as the alignment between model and log, and performance impacts can be measured only after the change is applied, so the method offers limited foresight.