Otra pieza de un libro de texto sobre programación empresarial.
Los procesos fronterizos se automatizan mejor. Suena cursi, pero esa recomendación está lejos de ser siempre implementada.
Las situaciones aún son comunes cuando el proceso cruza la frontera sin usar sistemas automatizados. En muchas empresas se utilizan notas de papel, solicitudes, pedidos, etc. Por supuesto, esto se aplica no solo a los límites entre departamentos: los empleados del mismo servicio también pecan en papel.
Si un empleado entrega el proceso a otro en forma impresa, el seguimiento del estado de esta tarea es extremadamente difícil. El método elemental y generalizado de perder tal tarea se expresa en la fraseología "limpiar debajo de la tela". Es bueno si el empleado apila esos papeles en una pila en su escritorio, entonces el volumen de aplicaciones es al menos visible. Teóricamente, incluso se puede encontrar un trozo de papel específico en esta pila y determinar cuánto tiempo ha estado en esta cola.
También es común un método para transferir un proceso por correo electrónico. Por desgracia, este enfoque tampoco es bueno. En cierto sentido, es incluso peor que una pila de papeles, porque Los clientes de correo electrónico no tienen la funcionalidad suficiente para administrar cartas como tareas. Una persona solo tendrá una montaña de letras, lo que es casi imposible determinar el estado de la cola.
Sobre la transferencia oral de tareas y no vale la pena hablar. Como dicen, voló en una oreja, voló en la otra.
Hay otro momento desagradable asociado con el conocimiento de las fronteras. Cuando una persona ha entregado la tarea a otra, en papel, verbalmente o por correo electrónico, el soporte de la tarea ahora pertenece a la segunda. Desde un punto de vista formal, moral y a menudo técnico, el primero ya no puede profundizar en las tareas del segundo. Con una cierta estructura de subordinación, puede, por supuesto, profundizar en una pila de papeles, pero leer el correo electrónico de otra persona ya es demasiado. Todavía es de alguna manera posible averiguar el estado de una o más de sus aplicaciones, sus instancias de proceso, pero es casi imposible evaluar el estado general de la cola "en la frontera".
Por lo tanto, necesitamos un sistema automatizado de control de fronteras. Tiene varios requisitos importantes.
El primer requisito es que el sistema debe identificar claramente la cola y las tareas que contiene. Incluso en sistemas automatizados desarrollados, esto no siempre es posible. Si le pide a una persona que muestre el turno de sus tareas en el programa, podrá demostrar algo: le mostrará una lista de documentos, aplicará algunos filtros y clasificará, y obtendrá una lista de tareas. Si le pregunta al programador, él hará lo mismo, solo que no en la lista de documentos, sino, muy probablemente, consultando los datos.
La frase clave aquí es "si preguntas". ¿Y si no preguntas? Para un programador de negocios, esta simple pregunta (“¿qué pasa si no pregunta?”) Puede ser un criterio claro para la identificación correcta de la frontera. Si usted, como observador externo, puede, sin preguntarle a un empleado, ver una lista de sus tareas, entonces se cumple el primer requisito: se identifica la cola.
Con la aparente simplicidad de este criterio, encontrará que la mayoría de los sistemas automatizados no lo cumplen. Entender la cola, ya que solo estaba en la cabeza de un empleado, incluso bajo el Tsar Gorokh y los memorandos de oficina, permaneció en el sistema automatizado. Esta situación es familiar y parece normal, porque "todos la tienen". Pero si usted, como programador de negocios, desea mejorar este proceso, tendrá que hacer la identificación de la cola.
El segundo requisito es que la cola debe descomponerse antes de las tareas, es decir a entidades simples que requieren acciones comprensibles. Sucede que la cola parece estar identificada, pero las tareas de diferentes procesos se mezclan en ella. En este caso, la capacidad de control y la capacidad de control de la cola es una pregunta seria.
El criterio es simple: si usted, sin preguntarle a un empleado, puede decirle para cada tarea específica qué debe hacerse, entonces la cola se descompone correctamente. Si la respuesta es "es necesario entender", o "es necesario arreglarlo de alguna manera", o "aún no ha mirado", entonces la descomposición es mala. El sistema y el proceso continúan dependiendo del empleado.
El tercer requisito es que las prioridades para completar las tareas deben ser claras. El principio es el mismo que en los criterios anteriores. Si, mirando la cola desde un lado, ve el orden de las tareas, entonces las prioridades son claras. Si usted, o los consumidores del proceso, necesitan preguntarle al empleado sobre las prioridades o restablecer estas prioridades todos los días, entonces la cola está mal administrada.
El cuarto requisito es que el tiempo empleado por la tarea en la cola, es decir Se aplica el principio "Iceberg" . El tiempo empleado suele estar relacionado con las prioridades de ejecución, pero también hay conflictos.
Por ejemplo, el sistema de prioridad se basa en una clasificación doble: primero la importancia, luego la fecha de la tarea. En este caso, con un gran volumen de tareas importantes, nunca alcanzará lo que no es importante. Si el proceso es tal que el incumplimiento eterno de algunas tareas se considera la norma, entonces está bien. Pero, como regla, en los procesos de transmisión, es importante completar todas las tareas.
Por lo tanto, se debe monitorear la influencia mutua de la prioridad y el tiempo invertido en la cola. Por ejemplo, después de haber especificado el sistema de prioridad, agregue un coeficiente de peso al tiempo que pasa en la cola, de modo que a un cierto valor, la tarea flote a la superficie, independientemente de su importancia.
Entonces, el criterio es simple: si ve que cada tarea tiene tiempo en la cola, entonces se cumple el requisito. Un error típico es la opinión de que es suficiente saber y ver la fecha del enunciado del problema, porque en este caso el tiempo pasado en la cola se puede calcular fácilmente. La automatización es realmente fácil de hacer. Pero calcular en la mente es mucho más difícil, y ni un solo empleado en su sano juicio lo hará. Por lo tanto, el tiempo pasado en la cola no se tendrá en cuenta en el trabajo.
El quinto requisito no importa cuán trivial sea, pero el ejecutor de la tarea debe ser conocido. Si la elección del contratista está regulada por un algoritmo automatizado, entonces debe entenderse el momento en que se ejecuta este algoritmo.
Mientras la tarea no tenga ejecutor, no se resolverá. El contratista no tiene que ser asignado a cada tarea específica; es suficiente entender que la solución a todas las tareas de la cola identificada se asigna a una persona específica.
La elección del contratista a menudo hace que una cola esté inactiva en los casos en que el contratista en el proceso no designa a una persona específica, sino a un puesto o departamento. En este caso, se recomienda que la elección del ejecutor se realice como una tarea separada, que debe realizar el gerente o un despachador determinado. Si bien la elección del contratista no es una tarea, sino un privilegio, la cola estará constantemente estancada en este punto.
El criterio es simple: mirando desde el lado de la línea, debe saber exactamente quién hará la tarea.
El sexto requisito , desde las áreas más altas de la programación empresarial: el sistema debe poder ver y comparar colas de diferentes procesos. En el caso general, tal requisito nunca se cumple, por lo que solo podemos hablar sobre el grado de cumplimiento.
El problema, por lo general, es que las diferentes colas, tareas y procesos son entidades del sistema diferentes, con conjuntos de propiedades disjuntos. Hay una instancia de proceso en una cola, pero no en otra. Una tarea tiene una fecha de producción, mientras que la otra no. Etc.
En vista de tal diversidad de entidades, generalmente nadie resuelve la tarea de controlar todas las colas "en una ventana", ni en sistemas automatizados ni en control manual. Por lo tanto, el estado de las colas, tanto instantáneas como métricas por período, sigue siendo un misterio, lo que reduce la efectividad de la gestión y el análisis.
Parcialmente útiles son los sistemas de control de procesos que "encadenan" una variedad de documentos primarios en entidades únicas. Así es como aparecen las tarjetas de proceso, la tarea común y las entidades de direccionamiento.
Pero para un programador de negocios, por desgracia, este enfoque no es muy adecuado.
En primer lugar, la aplicación de procesos generalmente conduce a una complicación de la automatización, no tanto del período de desarrollo como de los cambios posteriores. El proceso, con la tarjeta, los ejecutores, las acciones y las condiciones, en sí mismo, es un objeto de automatización, con todas las consecuencias resultantes: la necesidad de mantenimiento, depuración, coordinación, etc.
En segundo lugar, la imagen real de los procesos, como regla, no se puede dibujar debido al conflicto de "uno-muchos". La mayoría de los sistemas de dibujo de procesos quieren que se ejecute un objeto a la vez, incluso si el objeto es múltiple.
Por ejemplo, el proceso de ejecución de una solicitud de compra. Si dibuja un mapa de extremo a extremo de este proceso, resulta que la misma aplicación se ejecuta desde el principio hasta el final. El mismo proveedor, a juzgar por el mapa del proceso, debe trabajar con cada aplicación por separado, como parte de la instancia del proceso.
En realidad, el proveedor no participa en absoluto en el proceso de extremo a extremo. Él tiene su propia tarjeta, en la entrada de la cual hay una gran variedad de aplicaciones. Además, todos los días, de un volumen diferente (incluido, a veces, vacío). Después de ejecutar una aplicación específica desde esa primera instancia, la administración vuelve a un solo proceso.
Tal proceso solo se puede dibujar utilizando procesos anidados, que generalmente tienen éxito, pero la simplicidad y claridad del algoritmo se pierde: se vuelve técnico, comprensible para los programadores, pero no adecuado para personas vivas y gerenciales.
En tercer lugar, tales procesos son propensos a la burocratización: se esfuerzan por hacerlos "hormigón armado", coordinarlos, imprimirlos y ponerlos en el estante. Este enfoque contradice los principios de la automatización rápida y, por lo tanto, no es adecuado para la programación empresarial. Los procesos de hormigonado, especialmente durante el período de depuración, es lo mismo que imprimir el código del programa.
Y, en cuarto lugar, los desarrolladores de mecanismos para dibujar procesos, guiados solo por la lógica del programador, no proporcionan herramientas de gestión de colas. En consecuencia, para analizar todas las líneas en los bordes, para compararlas entre sí, en movimiento no funcionará. Todavía tienes que inventar tus propias herramientas.
El método de dibujar procesos de "hormigón armado" se puede utilizar como auxiliar, no habrá mucho daño. O bien, puede usarse al final del proyecto, como una forma de preservar los procesos configurados. Hasta el próximo proyecto.
Sin embargo, no se olvide del tercer punto: la tendencia a la burocratización. Si le parece que puede preservar el sistema por un tiempo, entonces el resto de los empleados y gerentes tienen la opinión opuesta: no toque lo que funciona. El sistema creado, depurado e implementado por usted comenzará a resistirse.
Es mucho mejor usar el principio de "Tarea automática" o similar cuando su sistema tiene entidades que pueden "adjuntarse" a procesos en curso y crear tareas en una cola. El principio en sí será considerado más adelante.
Una entidad única para gestionar colas en los bordes proporciona, en primer lugar, un único sistema de coordenadas: las métricas de todos los procesos en las mismas unidades. Cualquier proceso puede evaluarse, tanto instantáneamente como en retrospectiva, en la misma escala.
La evaluación instantánea se puede implementar, por ejemplo, en un panel de control de proceso común. No en el mapa de proceso general tradicional, que no se puede ver en una pantalla sin desplazarse, sino en forma de una lista simple, incluso sin números, usando una pantalla a color, como un semáforo. Esto dará como resultado una lista de dos columnas: proceso y estado.
La opción es un poco más interesante, no una lista de procesos, sino una lista de puntos problemáticos. El punto, en este caso, es una autotask, un cierto nodo de un proceso específico, inequívocamente comparable con la vida. Por ejemplo, "acuerdo de contratos por un abogado". Es suficiente enumerar todos los puntos, mostrar su estado y ordenarlos para que aparezcan los más problemáticos en la parte superior.
Tal evaluación instantánea de todos los procesos, a pesar de su aparente simplicidad y evidencia, es extremadamente rara. Ahora entiendes por qué.
El análisis de cola retrospectivo es una ocurrencia aún menos común porque la mayoría de los sistemas no contienen los datos necesarios en absoluto. Dichos datos están disponibles solo si el principio Iceberg se usa por completo, cuando no solo se almacena el tiempo de estado instantáneo, sino también su historial.
En general, como puede ver, no hay nada complicado en la automatización del control de fronteras. Es importante no crear dificultades artificialmente utilizando procesos de "hormigón armado" e ignorando los principios de la automatización rápida. Ahora conoce los enfoques y criterios que debe utilizar al automatizar los estados límite de los procesos.