Find delays, choose CRM configuration, integration or BPMS, and measure a pilot. Practical decision tables and a material-purchasing case.
Choose one workflow, establish a baseline and test the change before scaling.
The event that completes the work for the customer.
Where the request waits or needs correction.
One change with an owner and acceptance criteria.
Compare lead time, rework and quality.
Choose one outcome: an approved contract, paid order or accepted delivery. Define the starting event, the person accountable for the whole process and completion criteria. Trace real requests to find waiting time, data corrections and who decides on exceptions.
A business process connects an input, actions, roles and a measurable outcome. A cross-functional process spans departments: sales accepts orders, the warehouse confirms stock and accounting records payments. Core processes deliver customer outcomes, support processes provide resources and management processes define rules. The owner is accountable for the full journey.
| Observation | Check | First change |
|---|---|---|
| The next step is unclear | Roles, readiness criteria and workflow | Ownership and handover rules |
| Repeated data entry | Existing data and its owner | System integration |
| A document waits for approval | Waiting time versus active work | Deadline and escalation rule |
| A long cross-department workflow | Rework and exceptions | A BPMS pilot for one process |
| Format | When it fits | What to preserve |
|---|---|---|
| A short procedure | A simple sequence | Input, role, result and exception |
| Responsibility matrix | Multiple departments | One outcome owner |
| BPMN or flowchart | Branches and parallel activities | Transitions, rejection and rework |
| Value-stream map | Finding waiting time | Separate work from idle time |
An approval workflow must show rejection and rework, not only success. ELMA365’s tutorial describes a contract workflow with initiator, approver and registrar roles. Define where an incomplete request goes and who checks it again.
| Task | Approach | Check before buying |
|---|---|---|
| CRM or ERP already has the function | Configure the current system | Demonstrate it with your data |
| Data transfer between systems | Integration | Data owners, retries and error logs |
| Workflow across departments and systems | BPMS | Roles, exceptions and deadlines |
| No API; entry through the interface | A bounded RPA workflow | Resilience to interface changes |
For a construction developer, KT.Team standardised material requests for five delivery scenarios, defined roles and linked approvals to documents and acceptance. The case reports purchasing becoming 4.9 times faster with prepayment and three times faster with postpayment.
Cases
Before changing the process, measure end-to-end request time, active staff effort, rework and completion rate. Separate waiting time from labour: a notification may accelerate approval without removing the cause of rejection. Afterwards, compare equivalent requests and outcome quality.
Does every process need a BPM system? No: a procedure, CRM configuration or integration may solve a simple problem.
Must you map the whole company first? Start with one bounded process, an owner and a measurable outcome.
How do you measure the effect? Lead time, staff effort, rework and quality; choose criteria before the pilot.
Prepare a sample request, delays and a system list. BPMS connects workflow stages and systems. If data transfer is the main loss, start with integration.
Checked: 15 October 2026
