When flows are made to be automated with a BPMS, we are faced with designing work interfaces for the end user and integrations with other systems, among other things. These two elements are the focus of this article, and we will arise situations that occur frequently when automating a business process and that we must take into account to sort them out in the best possible way.
It is well known that automating many of the physical formats that are part of the process, become forms immersed in the BPMS solution, these forms often contain tables and drop-down list-type fields connected to databases to ensure the quality of the data. These two elements should be used with care and always thinking about how their operation will be once the model is in production because certain factors that will ultimately affect the perception of the solution quality by the end user may go unnoticed.
Assume a process in which a massive approval of requests is required, for example, a process of invoices payment in their stage of final approval. In the stage of payment when the person in charge of the Treasury, must approve the hundreds or thousands of invoices that have programmed for payment, usually requires great agility and basic information such as: the invoice number, the name of the supplier with its tax identification number, process that consumed the product or service and value of the invoice, this implies that the table will have at least 5 fields and if we multiply this by 1000 invoices, we will be talking about 5000 fields that must load the BPMS, just talking about the approval table and this depending on the infrastructure used can lead to delays in the form that finally impact user experience. In these cases should be thought of solutions that control this depending on the capabilities of the tool used, for example, you can think of using a result pagination, as long as this is viable in the process, use filters that guarantee a number of fields acceptable to the platform or look for ways to reduce the number of variables contained in the table.
Another factor that can generate extensive times during the execution in the user interface are the extensive associated queries, can be delayed in their execution and this can cause the user to perceive a bad experience when using the implemented solution since these queries usually translate in time that the user must wait in the application without being able to execute its process.
For example, it can become slow when you have a form that you should go to consult another application and then return a certain response. In a process of property management of a leasing agency, suppose that you have a process of building management and its interface has an option to consult estates with properties, but the information of these is in another or other information systems, depending on the complexity of integrations between systems, the query will be more or less fast, and in certain cases, may be a relevant factor to consider when implementing a solution. If these types of slow services are configured at times that are perceived by the user, the most certain is that they will have a perception of slowness and therefore a bad experience for the user.
Such bad practices in the volume of data can be presented in the use of tables as mentioned above or at the time of configuring the information of the drop-down lists. A drop-down list with hundreds or thousands values is an element that should be considered when designing a solution.
In conclusion, whenever we are designing the interfaces for end users, we must take into account that these should be as light as possible, looking for fast execution times and a pleasant experience using the solution designed and in those cases that it is essential to go to some practice that impacts the performance, this one must be measured and negotiated from the beginning with the users.