Rules
Roles, stages and conditions of transition between tasks.
BPM
BPM helps describe and improve workflows across people and systems. It shows who takes the next step and what is needed to make a decision.
Roles, stages and conditions of transition between tasks.
Acceptance, completion and submission for implementation.
Waiting time and reasons for returning cases.
We describe the beginning and end of the case, roles, transition conditions and exceptional situations. The form is one of the elements: approval rules, deadlines, substitutions and the method of withdrawing the case for completion are equally important.
BPM is also a method of analysis and improvement. It may involve several applications and activities outside of ERP; is not by definition a module of it.
The employee submits an application with justification. The system checks the completeness and directs it to the person authorized to make the decision. Lack of data triggers a replenishment, and acceptance may transmit the instruction to ERP. Every step remains in history.
The process must include absences, rejections, value changes and resubmissions. Without handling these cases, automation only transfers existing blockages to the form.
Need, amount and justification.
Completeness and person authorized to make the decision.
Acceptance, rejection or addition.
Submitting the approved instruction to ERP.
The application requiring completion is returned to the author. Changes to material terms may require re-approval.
We analyze waiting times, the number of returns to be completed and the reasons for detention. This data helps you change a rule or remove an unnecessary step. The goal is to improve workflow, not add more approvals.
Workflow implements the steps of a specific workflow. BPM also includes analysis, selection of measures and improvement of work principles. Automation should come after understanding the process.
At each stage, we indicate the responsible role, deadline and completion condition. The replacement should maintain the scope of authority, and escalation should help solve the bottleneck.
Changing the rules requires a decision on how to treat cases that have already started. Without distinguishing between versions of the process, it is difficult to explain why two similar applications took different paths.
Who takes over the task, for how long and to what matters they have access.
Reason for addition, comment history and explicit re-forwarding.
Fields whose editing, after approval, triggers a new decision.
Distinguish between acceptance, implementation, cancellation and refusal.
It is worth distinguishing between the time of performing an activity and the time of waiting for it. The open case count report is more useful when it shows stage, age and responsible role.
We check the first change on a limited basis. We observe whether users complete missing data less often and whether the next step is understandable. Only then do we extend the rules to other processes.
Questions and answers
Not always. You can organize one workflow and combine existing tools. We select technology after describing roles, decisions and exceptions.
NO. It's a way of describing and improving the work that people and different applications can do. We select the tool according to the established rules.
From a repeatable course with a recognizable beginning and end, an owner and a measurable problem. Applications, approvals and ticket handling work well.
Let’s start with a conversation
Describe the data-missing decision and your current workflow. We will determine the scope of the solution and the role of existing tools.
Discuss BPM needs