Rapid modeling of internal procedures using graphical tools
A flow is a logical sequence of steps (decision states) that must be followed to complete a request.
Automated internal procedures
Such internal flows exist in any company, regardless of the level of procedural organization. At the very least, we are talking about a set of rules that must be met in order for a request to be approved. There are also rules that are required by law and cannot be circumvented.
The higher the number of approvals required for a request, the more important the automation of the processing of these requests becomes.
The flow definition incorporates the knowledge needed to apply the procedure. Once the flow is defined, it becomes transparent to employees. The procedure to follow is extremely simple: start the flow.
The employee knows that he wants to submit a request to Human Resources. The emplyee selects the HR category, chooses from the available flows and submits the request. They don't have to print anything, they don't have to go to the "x" or "y" office. They will receive a notification, via the application and by email, at the end of the flow.
Instead of running after the papers, he deals with the productive activity for which he is paid.
Applications that may include the Workflow module
The Flow module provides graphical tools for defining the controlled movement between decision states and establishing alternative branches (paths) depending on the values of the defined variables.
If you can logically define the information movement algorithm then you can model the procedure using the flow module.
Including security and notification mechanisms, the flow engine will automate internal procedures and will significantly reduce processing costs.
Save time. Secure access to information. Every request, every result, every decision taken in the steps of the flow court, can be found in the archive.
Someone is responsible for each state (flow step). They must consider the request and approve or reject it.
For workflows to be valid regardless of the applicant, then, as far as possible, step responsibles must be "relative." That is, I will have another person in charge depending on the initiator of the request. We solved this using the positions in the organization chart.
Structure si Organize
Workflows are organized into categories. Thus, access to a flow becomes much faster.
Not all workflows need to be available to any employee. For this there is the system of access rights to flows.
We believe that any procedure can be modeled using the workflow module
- Step manager missing => Stream definition allows you to add backup users.
- Workflow blocked in a step => The application administrator can access and reallocate that request.
- The request can be solved by any of the members of a department => The definition of the workflow allows the allocation of multiple responsible per step. The flow will continue in the form of "first come, first served".
- I prefer to manually assign responsibility for the next state => The user will have the option to select from a list of predefined potential responsible.