Business process management software helps execute and observe a process: tasks move between people and systems, rules select routes, and records show what happened. A useful evaluation asks each candidate to perform the same representative work, including the awkward cases that a polished demonstration may skip.
Describe the process before preparing the scorecard
Choose a bounded process with a clear trigger and outcome, a business owner, sample inputs, and known exceptions. State which decisions people make, which systems must participate, and what evidence must remain available afterward. If the process itself is unclear, start with Business Process Management.
Separate mandatory requirements from preferences. An essential permission boundary or required integration should pass before a tool earns points for convenience. Define operating volume, service hours, data sensitivity, retention needs, and the people who will maintain the workflow.
OMG's BPMN specification provides a common process notation. Verify which elements, execution behavior, and import/export capabilities a product supports. A diagram that imports successfully still needs a functioning implementation and a test.
Use a demonstration script you control
For a fictional purchase-request process, the requester supplies an item, quantity, cost, and business reason. A budget owner approves or rejects it, procurement creates an order in a test system, and the requester receives the result. Use synthetic data and approved test accounts.
On a small screen, scroll the table sideways to read all columns.
| Case | Expected behavior | Evidence to retain |
|---|---|---|
| Ordinary approval | Authorized owner approves; one order is created | Task history and matching order ID. |
| Missing information | Requester receives a clear correction task | Required fields and resubmission history. |
| Approver unavailable | Work can be reassigned through an authorized route | Who reassigned it, why, and when. |
| Integration times out after an order is created | Recovery avoids a second order | Destination lookup and idempotent retry evidence. |
| Ordinary user tries to approve their own restricted request | Permission rule is enforced | Observed denial and audit record. |
| Process changes while a request is waiting | The open request follows an explicit version policy | State and history before and after the change. |
Score what you can demonstrate
For optional capabilities, a simple evidence scale is useful: 0 means absent or unverified; 1 means described by the supplier; 2 means observed in a demonstration; 3 means reproduced by your team in the trial. This is an illustrative evidence scale, not a market ranking.
Keep capability and implementation effort alongside the score. A feature may be possible only with custom code, an additional product, or a different license. Ask who maintains that dependency, what happens after an upgrade, and what support is included. Record the product version and configuration used for every test.
Use the workflow evaluation scorecard to record mandatory gates, observations, unresolved questions, and operating effort. Have the future process owner and maintainer run some cases themselves.
Inspect what happens to work already in progress
A new process version can affect new requests differently from those already waiting. Establish whether open cases finish on their original definition, migrate under a supported plan, or need another controlled route. Test notifications, deadlines, variables, and permissions after the change.
As a specific example, Camunda's process-instance migration documentation requires mappings for active elements and describes restrictions. It also explains that existing jobs and their properties are not recreated by migration. This illustrates why moving a case to a new diagram needs more verification than checking the visible task name.
Keep a waiting case, a failed integration, and a parallel path in the trial where those states exist in your real process. Ask the supplier to explain unsupported scenarios and demonstrate a suitable recovery path.
Evaluate operation, costs, and exit together
Estimate licensing, environments, integration work, support, training, monitoring, upgrades, and ongoing process changes. Use your expected user roles and transaction volumes. Request an explanation of what counts as a billable unit and test the effect of growth or a busy period.
Ask how administrators find stuck work, restore service, and reconcile external actions after an interruption. Test exports of process definitions, business records, attachments, and audit history using their actual supported formats. An export is useful when your team can open it, identify records, and understand what information is missing.
Close the evaluation with passed mandatory requirements, reproducible evidence, remaining gaps, owners, and a costed implementation plan. The guides to Business Automation and Outsourcing Risks cover dependable workflows and provider dependence in more detail.