Why Business Process Management Matters: Risk Control and Performance Evaluation with BPMS

A purchase request has been submitted, but nobody knows why it is still waiting for approval. The finance department says that supporting documents are missing, the requester has not been notified, and the manager can discover the current status only by making several phone calls. The problem is not simply the absence of software. The workflow, responsibilities and decision rules have not been clearly defined.

Business process management begins by turning scattered activities into a clear, repeatable and measurable workflow. When this workflow is implemented in a BPMS, the organization can determine who must perform each task, what information is required, which controls must be applied and when the work should be completed.

The main value of a BPMS is not merely the removal of paper. Its real value lies in controlling risks, identifying bottlenecks and producing reliable operational data for management decisions. However, software alone cannot correct a poorly designed process or weak management practices.

What is business process management, and how is it different from BPMS?

Process management means defining a repeatable path for achieving a specific outcome. Its starting point, inputs, outputs, responsible roles, decision rules and exceptions must be known. A purchasing process, for example, may begin with identifying a need and continue through approval, procurement, receipt and payment.

BPM, or Business Process Management, is a managerial approach used to discover, model, analyse, measure and continuously improve these workflows. A BPMS is the technology platform that supports the execution of this approach. The IBM guide to business process management also describes BPM as an end-to-end discipline covering process design, execution, monitoring and optimisation.

BPMN has a different purpose. It is a standard visual language for modelling processes. The official BPMN 2.0.2 specification published by OMG defines this notation. A BPMN diagram makes activities, events and decision paths understandable, but the diagram itself does not create executable forms, access controls or management reports.

Why is digitising forms alone insufficient?

Suppose a paper purchase request is converted into an online form, but nobody defines which purchases require financial approval, who replaces an absent manager or where an incomplete request should be returned. In that case, the same ambiguity has merely been moved into a digital environment.

Before designing a form, the organization should determine the expected output, process owner, required approvals, necessary information, escalation rules and performance data. These decisions turn form building into effective workflow management.

How does process management reduce organizational risks?

A control is effective only when it is placed at the correct point in the workflow. Approval recorded after payment cannot replace a control that should have been performed before payment. The COSO Internal Control Framework also treats internal control as a mechanism that supports organizational objectives and increases confidence in information.

1. Lost requests and unclear responsibility

Every request should have a unique identifier, a clear status and a current owner. Time-sensitive activities should include deadlines, reminders and escalation rules. A substitute role should also be defined so that the process does not stop when one employee is absent.

2. Unauthorized approval and conflicts of interest

The requester, approver and executor can be assigned separate roles. Approval routes may depend on the amount, request type, department or cost centre. The person who creates a request should not be able to approve it alone through another role.

Critical access controls must be enforced on the server and across every access route, including APIs. Hiding a button in the user interface is not a sufficient security control.

3. Incomplete or modified information

Validation of amounts, dates, item codes and required documents reduces the circulation of incomplete requests. If an approved amount or supplier is later changed, the process may require approval again. The system should also preserve the exact information seen by the approver.

4. Duplicate purchasing or payment

A unique request identifier and checks based on supplier and invoice numbers can reveal suspicious duplicates. When the BPMS communicates with a financial system, retransmitting the same message must not create a second payment. This requires appropriate integration and data controls.

5. Absence of a reliable audit trail

The system should record who changed information, when the change was made, and why a request was approved, rejected or returned. Access to audit records, retention periods and permissions to modify or delete logs must also be controlled. Shared user accounts weaken accountability because actions cannot be attributed to a specific person.

6. Dependence on individuals and informal communication

Documented rules and substitute routes keep operational knowledge inside the organization when employees change. If employees continue to obtain important approvals outside the system, however, BPMS reports will provide an incomplete picture. Usability, training and managerial support are therefore essential.

Process management reduces the likelihood of certain errors and makes them easier to detect, but it cannot eliminate every risk. Collusion, inaccurate data, excessive administrator access and infrastructure failure remain possible. Backup, recovery and periodic access reviews must accompany workflow design.

A practical example: designing a purchase request process

The following scenario is an educational example and does not represent the claimed result of a particular project:

1. Request submission: The requester enters the required item, quantity, reason, cost centre and required delivery date.
2. Inventory check: If the item is available, the request follows the internal delivery route. Otherwise, procurement continues.
3. Budget review: An authorized person confirms the available budget. If the BPMS is integrated with a financial system, the organization must also define how the budget is reserved.
4. Appropriate approval: The approval path is determined by the amount, sensitivity and organizational rules instead of using one long approval chain for every purchase.
5. Procurement and receipt: Supplier, purchase and delivery information is recorded. Partial delivery and discrepancies follow defined exception routes.
6. Pre-payment control: Required documents are matched and discrepancies are resolved before payment proceeds.

Cancellation, rejection, price changes, absent managers, integration failures and urgent purchases should also have defined routes. An emergency route should include a recorded reason, an authorized approver and a later review.

Which data should a BPMS record?

Useful reporting begins during process and data-model design. According to Microsoft documentation on process-mining data, case identifiers, activity names and timestamps are fundamental inputs for process analysis.

For a purchase process, the organization should record the request ID, activity, creation time, assignment time, start and completion timestamps, deadline, responsible unit, result and return reason. Amount, purchase type, supplier and process version support more detailed analysis.

Time spent in an employee's task list does not necessarily equal active working time. Much of it may be waiting for external information. If active handling time is not recorded reliably, managers should not calculate employee productivity or labour cost from task-list duration.

Useful performance indicators in a BPMS

Process cycle time

Cycle time is the difference between the defined start and end of a process instance. In addition to the average, managers should examine the median and the 90th percentile so that very slow cases are not hidden by an acceptable average. The APQC definition of purchase-order cycle time includes both active work and waiting time.

SLA compliance rate

One possible formula is the number of requests completed by their deadline divided by all requests that had a deadline during the reporting period, multiplied by 100. Open and overdue requests should remain in the denominator. Working days, calendar days, approved pauses and cancelled cases must be defined consistently.

Rework rate

Rework rate can be calculated by dividing the number of completed cases returned for correction at least once by the total number of completed cases in the same group. The number and reason for returns should also be reported because one case returned four times differs from four cases returned once.

Work in progress and queue age

The number of open requests alone is insufficient. Reports should include the oldest case, overdue cases and waiting-time distribution at each stage. Ten complex cases cannot automatically be compared with fifty simple cases.

Output quality and process cost

Speed should be evaluated alongside quality. Completion without correction, delivery discrepancies and reopened cases can serve as supporting indicators. Calculating cost per case requires reliable active-work time, labour rates and additional costs.

How can BPMS data support fair employee evaluation?

Ranking employees solely by the number of completed tasks may encourage them to select simple cases or close work prematurely. Evaluation should consider case complexity, incoming workload, dependency on other departments, leave and output quality.

If most of an employee's delay comes from waiting for supplier quotations, additional pressure on that employee may not solve the problem. The organization may need alternative suppliers, a redesigned quotation process or better procurement planning. Access to individual performance reports should also be restricted and their purpose clearly communicated.

How do BPMS reports support organizational strategy?

• Capacity planning: Increasing request volume and queue age can identify stages that require workload redistribution, simplification or additional capacity.
• Delegation policies: If low-value requests wait a long time for managerial approval, controlled delegation may be considered.
• Automation priorities: Frequency, handling time and error rate help determine which activity provides the greatest value from automation.
• Supplier management: Connecting order and delivery data allows delays and discrepancies to be analysed by supplier.
• Risk management: Increased use of emergency routes may indicate weak planning, unsuitable rules or attempts to bypass controls.
• Strategic objectives: Goals such as faster customer response should combine total response time, quality and demand volume.

Every management report should answer four questions: What decision does it support? How is the indicator defined? Who is responsible for acting on it? When will the result be reviewed?

Numerical example: turning a delay report into action

The following figures are hypothetical. During one month, 200 purchase requests reached their deadlines. Of these, 140 were completed on time, 40 were completed late and 20 remained open and overdue. Based on the definition used here, SLA compliance is 70 percent: 140 divided by 200.

If 45 of the 180 completed requests were returned for correction at least once, the rework rate for this group would be 25 percent. If most returns were caused by a missing item code, improving the item-selection field and its validation may be more effective than adding another approver.

The role of ProcessMaker, DynaForms and routing conditions

In ProcessMaker 3.x, DynaForms are used to design process forms. A form should collect the information required at its specific stage, while routing rules determine which activity receives the case next.

In a purchase process, the amount and cost centre may influence the approval route. Conditions must also address empty values, invalid amounts, modified information and unavailable users. Critical controls should not rely only on form-side JavaScript.

How should an organization begin?

1. Select a frequent process with a clear problem and an engaged process owner.
2. Study the actual work through observation, interviews and real cases.
3. Remove unnecessary activities and model the desired workflow and exceptions.
4. Define controls, control owners and the data required for performance indicators.
5. Build the forms and workflow, then test normal and exceptional scenarios.
6. Run a limited pilot, collect feedback and expand after stabilization.
7. Review indicators regularly and assign an owner and deadline to every improvement action.

Frequently asked questions

Does BPMS replace ERP or accounting software?

Not necessarily. A BPMS can coordinate work between people and systems while financial transactions or inventory records remain in specialized applications. The authoritative source for each data item must be clear.

Does BPMS eliminate every operational risk?

No. Appropriate controls reduce the likelihood of errors and support earlier detection, but data quality, permissions, user behaviour and infrastructure remain important.

Is process mining required at the beginning?

No. An organization can start with process modelling and a small number of meaningful indicators. Process mining becomes more useful when sufficient and reliable event history is available.

Do more approvals create better control?

No. Every approval should address a defined risk, and the approver must have the required information and authority. Repeated approvals can increase waiting time without reducing risk.

What I Have Learned from Implementing Organizational Processes

My experience in designing and implementing organizational processes has shown me that the success of a BPMS project does not depend only on the quality of its BPMN diagrams or the technical capabilities of the platform. User adoption, workflow simplicity, data quality and the ability to improve the process gradually have a direct effect on the outcome. The following observations come from working with users, forms, routing conditions and changing organizational requirements.

Initial resistance does not always mean opposition to technology

When process management or BPMS is introduced into an organization for the first time, some resistance is normal. Employees are asked to change familiar habits, enter information in a more structured way and perform activities that are now more visible and traceable.

In my experience, this resistance decreases when users understand why each stage and field exists and can see that the system solves a real daily problem. Once requests stop disappearing, case status becomes visible and repeated phone calls and manual follow-ups are reduced, users begin to experience the practical value of the new process. In many cases, people who were initially uncertain later suggest useful improvements to forms and workflow paths themselves.

This is why user participation during process discovery and pilot implementation is so valuable. Observing the actual work, speaking with the people who perform it every day and explaining the reasoning behind changes usually produces better results than delivering a completed workflow without involving its users.

A process should begin with a simple and usable first version

Another lesson I have learned is that the first version of a process should not be expected to cover every possible exception in the organization. Excessive complexity at the beginning makes forms heavier, testing more difficult and user adoption slower.

The approach that has worked better for me is to begin with a clear and manageable version covering the main workflow, responsibilities, essential controls and the most important exceptions. After implementation, real process data and user feedback reveal which stages create delays, which information is missing and which routing conditions require adjustment.

This approach follows the continuous-improvement cycle of business process management: the process is designed, implemented in a controlled scope, measured and then improved based on evidence. The initial simplification must still preserve essential controls, legal requirements and security rules.

Form reference data should be managed centrally

Repeatedly storing fixed options inside Dropdown or Suggestion fields can create maintenance problems. Consider a list of departments, cost centres, request types or suppliers entered separately into several forms. Each organizational change then requires every related form to be found and edited, increasing the likelihood of outdated or inconsistent information.

For this type of data, I prefer to retrieve reference values from a centralized source, such as controlled SQL database tables or a reliable data service. A department change or a new option is then recorded in one source, and all dependent forms receive the updated data. This approach simplifies process maintenance and reduces inconsistency between forms.

The implementation still requires careful design. End users should not have direct database access, queries should be secure and parameterized, inactive options should normally be retained rather than physically deleted, and historical cases must remain understandable after reference data changes. Controlled caching may also be used for frequently requested data so that database access does not slow down the forms.

A good form requests only the information required at its current stage

In process projects, I have seen forms that ask users for a large amount of information during the first step simply to appear complete. Some of that information may not yet be available or should be provided by a different role later in the workflow. This increases submission time and encourages users to enter estimated or inaccurate values.

Each role should see and complete the information needed for the decision or activity at that stage. Conditional fields, default values obtained from trusted sources and validation based on the request type make forms easier to use. Essential controls should also be enforced on the server and should not depend only on the form interface or JavaScript.

Reporting requirements should be defined before implementation

If reporting needs are discussed only after the process has been running, the required data may never have been recorded. During process design, I therefore ask what managers need to understand: Which stage should be timed? How should return reasons be recorded? Which unit is responsible for a delay? What makes a case successful, unsuccessful or in need of correction?

The answers determine which fields and events the BPMS must store. My experience has shown that a simple dashboard with a few precise and actionable indicators usually provides more value than a crowded report containing numerous charts with unclear definitions.

For me, a process has been designed successfully when users can complete their work with less ambiguity and fewer manual follow-ups, managers can see the actual status of operations, and the organization can use recorded data to improve the workflow over time.

A well-designed process supports execution and measurement

The value of organizational process management comes from connecting easier execution, proportionate risk controls and reliable data. A BPMS provides the environment for this connection, while effective results still depend on process analysis and responsible management.

If you are planning to redesign an organizational process or implement it in ProcessMaker, visit the About Ali Yazdian page to learn more about my work. A useful discussion can begin with one specific problem: delayed requests, unclear approvals or a management report for which reliable data is currently unavailable.