Automation of border control within the company
Another piece of business programming tutorial.
Border processes are better automated. It sounds trite, but this recommendation is far from being always implemented.
There are still quite common situations when the process of crossing the border is carried out without the use of automated systems. At many enterprises paper service notes, applications, orders, etc. are in progress. Of course, this applies not only to the boundaries between departments - employees of the same service are also sinners.
If one employee transfers the process to another in paper form, it is extremely difficult to track the status of this task. An elementary, widespread method of losing such a task is expressed in the phraseologism “to remove the cloth”. It’s good if the employee puts such pieces of paper in a pile on his desktop - then the volume of requests is at least visible. Theoretically, a specific piece of paper in this pile can even be found, and determine how long it has been in this queue.
A method of transmitting the process via e-mail is also common. Alas, this approach is also not suitable. In a sense, it is even worse than a stack of papers, because mail clients do not have sufficient functionality to manage emails as tasks. A person will simply have a mountain of letters, which is hardly possible to determine the status of the queue.
About the oral transfer of tasks and say no. As they say, in one ear flew, in the other - flew out.
There is another unpleasant moment associated with the knowledge of boundaries. When one person handed over another task - on paper, verbally or by e-mail - the carrier of the task now belongs to the second. From a formal, moral, and often technical point of view, the first can no longer dig into the queue of tasks of the second. With a certain structure of subordination, you can, of course, dig deeper into a pile of papers, but reading someone else's email is a bust. It’s still somehow possible to find out the status of one or several of your applications, your process copies, but it’s almost impossible to assess the general status of the queue “at the border”.
So, we need an automated border control system. To her are several important requirements.
The first requirement is that the system must clearly identify the queue and the tasks in it. Even in advanced automated systems, this is not always possible. If you ask a person to show his tasks in the program, he will be able to demonstrate something — show a list of documents, apply some filters and sorting, and you will get a certain list of tasks. If you ask a programmer, he will do the same thing, just not in the list of documents, but, most likely, by a query to the data.
The key phrase here is “if you ask.” And if you do not ask? For a business programmer, this simple question (“and if not to ask?”) Can be a clear criterion for the correct identification of the boundary. If you, being an outside observer, you can see the list of his tasks without asking the employee, then the first requirement is fulfilled - the queue is identified.
With the seeming simplicity of this criterion, you will find that most automated systems do not correspond to it. Understanding the queue as it was only in the head of the employee, even during the reign of King Pea and office memos, remained in the automated system. This situation is familiar and seems normal, because "everyone has it." But if you, as a business programmer, want to improve this process, then the identification of queues will have to do.
The second requirement is that the queue should be decomposed to tasks, i.e. to simple entities requiring clear actions. It happens that the queue, like, is identified, but it contains tasks from different processes. In this case, the controllability and controllability of the queue is a serious matter.
The criterion is simple: if you, without asking the employee, can say for each specific task what needs to be done, then the queue is properly decomposed. If the answer is "need to understand", or "need to somehow fix", or "have not yet looked," then the decomposition is done badly. The system, and the process, continues to depend on the employee.
The third requirement is that the priorities for completing tasks should be clear. The principle is the same as in the previous criteria. If you are looking at the queue from the side, you see the order of the tasks, then the priorities are clear. If you, or consumers of the process, need to ask the employee about priorities, or reinstall these priorities every day, then the queue is poorly managed.
The fourth requirement is that the time the task is in the queue must be accurately known; applied the principle of "Iceberg" . The time spent is usually interconnected with the priorities of implementation, but there are also conflicts.
For example, the priority system is based on double sorting - first importance, then - the date of the problem statement. In this case, with a large volume of important tasks, the matter will never reach unimportant. If the process is such that the eternal non-fulfillment of some tasks is considered the norm, then do not worry. But, as a rule, in streaming processes it is important to complete all tasks.
Therefore, the mutual influence of priority and time in the queue should be monitored. For example, specifying the system of priorities - add a weighting factor to the time spent in the queue, so that with a certain value of it, the task floats to the surface, despite the importance.
So, the criterion is simple: if you see the time spent in the queue for each task, then the requirement is fulfilled. A typical mistake is the opinion that it is enough to know and see the date of the problem statement, because in this case the time spent in the queue can be easily calculated. Automation tools make it really easy. But calculating in your mind is much more difficult, and no sane employee will do this. Therefore, the time spent in the queue will not be counted in the work.
The fifth requirement - no matter how trite, but the executor of the task must be known. If the choice of the performer is governed by an automated algorithm, then the moment when this algorithm is executed should be clear.
As long as the task has no performer, it will not be solved. The contractor is not required to be assigned to each specific task - it is quite enough to understand that the solution of all the tasks of the identified queue is entrusted to a specific person.
The choice of the performer often becomes the cause of idle queues in cases where the executor in the process is not a specific person, but a position or department. In this case, it is recommended that the choice of the contractor be done by a separate task that must be performed by the manager or a certain dispatcher. While the choice of the performer is not a task, but a privilege, the queue at this point will constantly get stuck.
The criterion is simple: you, looking from the outside to the queue, should know exactly who will do the task.
The sixth requirement , from the highest areas of business programming: the system should be able to view and compare queues from different processes. In general, such a requirement is never satisfied, so you can only talk about the degree of compliance.
The problem, usually, is that different queues, tasks and processes are different entities of the system, with disjoint sets of properties. There is an instance of a process in one queue, but not in another. In one task there is the date of the production, in the other it is not. Etc.
Due to such heterogeneity of entities, the task of controlling all the queues “in one window” is usually not solved by anyone - either in automated systems or in manual control. Therefore, the state of the queues - both instantaneous and metrics for the period - remains a mystery, which reduces the effectiveness of management and analysis.
Partly help process management systems that "string" a variety of primary documents of a single entity. So there are maps of processes, uniform entities of tasks and addressing.
But for a business programmer, such an approach, alas, is not very good.
First, the application of processes usually leads to more complex automation — not so much from the development period, as from subsequent changes. The process, with a map, performers, actions and conditions, is in itself, an object of automation, with all the ensuing consequences - the need for maintenance, debugging, coordination, etc.
Secondly, the real picture of the processes, as a rule, cannot be drawn due to the “one-to-many” conflict. Most process-drawing systems want a single object to run a single object, even if the object is a set.
For example, the process of execution of the application for purchase. If you draw a pass-through map of this process, it turns out that the same application runs from the beginning to the end. The same supplier, judging by the process map, should work with each application separately, as part of the process instance.
In reality, the supplier does not participate in the end-to-end process at all. He has his own map, at the entrance of which is an array of applications. Moreover, every day - a different volume (including, sometimes, empty). After the execution of a specific application from the first instance, control returns to a single process.
Such a process can be drawn only by using nested processes, which is usually possible, but the simplicity and clarity of the algorithm is lost - it turns into a technical one, understandable to programmers, but not suitable for living people and management.
Thirdly, such processes are prone to bureaucratization — they are striving to be made “reinforced concrete”, coordinated, printed out and put on the shelf. This approach is contrary to the principles of fast automation and, accordingly, is not suitable for business programming. Concreting processes, especially in the debugging period, is the same as printing a program code.
Well and, fourthly, the developers of mechanisms for drawing processes, guided only by programmer logic, do not provide tools for queue management. Accordingly, to analyze all the queues at the borders, compare them with each other, on the move will not work. You still have to reinvent your tools.
The way of drawing "reinforced concrete" processes can be used as an auxiliary, there will not be much harm. Or, it can be applied at the end of the project, as a way of preserving the configured processes. Until the next project.
However, do not forget about the third point - the tendency to bureaucracy. If it seems to you that you preserve the system for a while, then the rest of the staff and managers have the opposite opinion: do not touch what works. The system created, debugged and implemented by you will begin to resist you.
It is much better to use the principle of "autotasks" or similar, when there are entities in your system capable of "attaching" to the ongoing processes and building tasks in the queue. The principle itself will be discussed further.
A single entity for managing queues at borders gives, first of all, a single coordinate system - the metrics of all processes in the same units of measurement. Any process can be assessed - both instantly and in retrospect - on the same scale.
Instant assessment can be implemented, for example, in the overall process control panel. Not in the traditional common process map, which you can’t see on one screen without scrolling, but as a simple list, you can even without numbers - using a color display like a traffic light. Get a list of two columns: process and state.
The option is a little more interesting - not a list of processes, but a list of problem points. A point, in this case, is an auto-task, a certain node of a specific process, uniquely associated with life. For example, "the harmonization of contracts by a lawyer." It is enough to list all the points in the list, show their status, and sort it so that the most problematic ones are at the top.
Such an instant assessment of all processes, despite its apparent simplicity and obviousness, is extremely rare. Now you understand why.
Retrospective queuing analysis is even less common, because most systems do not contain the necessary data at all. Such data are available only if the Iceberg principle is fully used, when not only the instantaneous time of the state is stored, but also its history.
In general, as you can see, there is nothing difficult in automating the control of borders. It is important not to create difficulties artificially, using “reinforced concrete” processes and ignoring the principles of fast automation. The approaches and criteria to be used when automating the border states of processes are now known to you.