Process mining or process monitoring: which do you need?

What process mining is

Process mining reconstructs a process from the event logs your systems already write. Celonis describes it as extracting event data from systems, building a digital twin of the process and using it to find and simulate improvements, with order-to-cash and purchase-to-pay as typical examples. It also offers object-centric process mining, which follows several connected objects such as orders, deliveries and invoices.

SAP Signavio Process Intelligence works with SAP and non-SAP systems, promises first insights within 24 hours of connecting an SAP system and updates data daily. It offers root-cause analysis, benchmarks, simulation and conformance checks, and can trigger notifications, workflows and bots, with alerts by email or Microsoft Teams.

UiPath Process Mining turns IT data into dashboards that show bottlenecks and root causes, and describes a cycle of data transformation, analysis and continuous monitoring. Its event log needs at least a case ID, an activity and an end time per event, and UiPath recommends keeping a process to roughly 10 to 20 activities. Microsoft offers process mining as part of Power Automate, formerly called Process Advisor, with Power BI for custom reports.

What process monitoring is

Process monitoring does not discover the process. You describe it: the steps a case goes through and the time limit for each step. tiqline then reads events from Shopify webhooks or the track API, links them to a case by the anchor object, such as an order, and checks each open case against its deadline.

When a step runs past its limit, tiqline marks the case as stuck and groups all stuck cases of that step into one incident. One alert goes to Slack or email with a link to the process and the cases. The dashboard shows how many finished cases kept every time limit, how many cases are stuck right now and how long a case usually takes.

The key differences

• Direction: process mining answers how the process ran. Process monitoring answers which case is late right now.
• Model: mining derives the process from the data. Monitoring starts from a process you describe.
• Data: mining tools usually load event logs from ERP, CRM and other systems in batches. tiqline receives each event as it happens.
• Output: mining gives dashboards, root causes, conformance and simulation for analysts. tiqline gives an alert to the person who can fix the case today.
• Effort: a mining project needs data preparation and someone to read the results. tiqline needs events and a process description.

Side by side

When process mining fits

Choose process mining when you want to understand and redesign a process across large systems. It shines when you have years of ERP data, many process variants and a team that turns findings into changes. Questions like why invoices from one country take twice as long, or which approval step causes most rework, are mining questions.

When process monitoring fits

Choose process monitoring when you already know the steps and need to react while a case is still open. A Shopify order that was paid four hours ago and not yet picked is not a statistic. It is a parcel that will miss today's truck. tiqline is built for that moment, and it works for a small team without a data project.

Using both together

Mining and monitoring answer different halves of the same question. Use process mining, if you have it, to find which steps matter and what a realistic time limit is. Put those limits into tiqline so every open case is checked against them. The share of cases that kept every time limit in tiqline then shows whether the change worked.

If you do not run a mining tool, tiqline's dashboard still gives you a basic view from your real cases: how long a case usually takes, and how often each limit was kept. It does not replace variant analysis or simulation.

Example: from analysis to a daily alarm

All numbers in this example are made up for illustration. A company sells through Shopify and fulfils through a 3PL. An analysis of last quarter shows that 80% of late deliveries were already late at picking, and that orders paid after 2 p.m. are picked the next morning.

The team sets up a tiqline process: paid, picked within 6 hours, fulfilled within 24 hours of picking, with a branch for cancelled orders. Two weeks later, the pick step overruns on a Thursday afternoon. One alert says 23 cases are waiting and links to them. The warehouse adds a late shift on Thursdays. A month later, the share of cases that kept every time limit is visible on the dashboard.

How to turn a mining insight into a time limit

A mining result is often a distribution: most orders are picked within four hours, a long tail takes two days. A good time limit sits where a case stops being normal and starts needing a person, not at the average. Start with one or two steps that the analysis showed as the main source of delay.

In tiqline you describe those steps in the process editor, preview the draft on your real cases and see which cases would be stuck today with that limit. If the list is too long, the limit is too tight; if it is empty for weeks, it is too loose. After publishing, a change to a time limit applies at once, also to running cases, and is recorded in the audit log.

Limits of tiqline

tiqline does not discover processes from logs, does not compare variants, does not simulate changes and does not explain why a case is stuck. It does not detect deviations from the process you described; a case simply follows the path its events choose. There are no prebuilt connectors to ERP systems. If your goal is analysis across SAP data, a process mining platform is the right tool.