Buenas tardes
Quiero ofrecer una pequeña excursión a la aplicación práctica de la teoría de restricciones para TI. A saber, en el asunto de calcular el "rendimiento" del departamento para desarrollar software corporativo interno.
Sobre la TCC (Teoría de las restricciones) y el mega libro "Goal" de Elia Goldratt, se ha escrito mucho, incluso sobre Habré, así que iré directo al grano.
El departamento del que estoy a cargo está apoyando y desarrollando varios llamados sistemas de información "internos", los principales de los cuales son WMS y TMS - sistemas de gestión de almacenes y transporte. Además, me centraré solo en estos sistemas y solo en una parte del negocio: los servicios de un operador logístico.
Todos los días, una docena de nuevas tareas se vierten en nuestro buzón, muchas de ellas marcadas como "¡Urgente!", "¡Importante!" etc.
Por el momento, la cartera de pedidos ha crecido hasta cerca de setecientas tareas de diferentes categorías de complejidad.
Para gestionar de alguna manera este volumen, hemos introducido un sistema de prioridades, de acuerdo con el grado de influencia en el negocio:
A - fallas del sistema o problemas que no permiten cumplir plenamente las obligaciones contractuales (para el negocio principal).
B: tareas relacionadas con el crecimiento de los ingresos de la empresa, es decir, la llegada de nuevos clientes.
C: tareas relacionadas con la mejora de la rentabilidad, es decir, tareas para optimizar la productividad (total: sistemas, procesos de trabajo, personas, crecimiento de la producción, etc.).
D - mejoras a petición de nuestros clientes (informes, integración con empresas de transporte, etc.).
Dentro de estas categorías hay otro nivel de división (A1, A2, ...), pero para los fines del artículo de hoy, esto no es esencial.
Lógicamente, la ejecución de tareas debe organizarse en orden: ABCD.
En la práctica, un plan de desarrollo es el resultado de una gran cantidad de compromisos. Como ejemplo, las tareas de categoría D a menudo llegan a la cima de la cartera (enfoque en el cliente, sí).
Es decir, de hecho, el sistema de prioridad da solo una dirección general para la planificación, pero no permite que todos den una respuesta objetiva a la pregunta: "¿Por qué mi tarea no se demora tanto?"
También tenemos el problema de los clientes pequeños y grandes, que gastan aproximadamente el mismo recurso de TI. Teóricamente, los clientes más gordos deberían ser una prioridad, pero tampoco debe dejar a los pequeños, además, uno pequeño a menudo requiere atención especial, como si no enviara dos gacelas por semana, sino al menos un tren de contenedores.
Entendiendo esto y entendiendo que la compañía es una organización comercial, no una organización benéfica, y en primer lugar debe ser rentable, decidimos impulsar el sistema de planificación utilizando la teoría de las restricciones.
La limitación en nuestro caso es el recurso de desarrollo.
CBT presenta un nuevo concepto para el rendimiento del negocio, una "tasa de generación de ingresos" condicional, que debe incrementarse continuamente. A diferencia de los costos, el crecimiento del pasaje no está teóricamente limitado por nada y puede (puede) tender al infinito.
En el caso de los desarrolladores, usaremos el retorno de horas hombre, en rublos, como medida de paso.
El algoritmo es algo como esto:
- Para cada tarea, es necesario evaluar el efecto económico de la implementación. Esto puede ser un ahorro de horas de trabajo de cuello azul, o ahorrar otro recurso (por ejemplo, escasos metros cuadrados en el área de expedición, o lugares de paleta en el área de almacenamiento u horas de carga). Deseable, en miles de rublos / año. El cliente debe realizar dicha evaluación. Si no puede hacer esto solo, se pondrá en contacto con su supervisor.
- Una vez que la tarea ha sido evaluada en términos de efecto, pasa al estudio de Timlid o a uno de los signorees. Como resultado, obtenemos una cierta estimación preliminar de los costos.
- Al dividir el primero en el segundo, obtenemos el mismo pasaje: la velocidad de lograr el efecto.
- Clasificamos las tareas en la cartera de pedidos en orden descendente de paso.
- Corte un trozo de trabajo acumulado en la parte superior del siguiente plan / sprint.
Por ejemplo, hay un problema, cuyo efecto el cliente estimó en 100 mil rublos. por mes, o 1.2 millones de rublos. por año
Por nuestra parte, la implementación requerirá 40 horas de desarrollo.
El pase, como resultado, será 1200/40 = 30 unidades convencionales.
Para otra tarea, el efecto esperado de 50 mil rublos. por mes, pero su implementación tomará 100 horas. Total, 600 mil rublos / 100 = 6 c.u.
Al final, haremos ambas tareas. Pero primero el primero, y luego el segundo.
Volviendo a las categorías de prioridad, formamos una secuencia de corrección separada (categoría A), luego lanzamos nuevos clientes (las tareas se planifican de acuerdo con los plazos existentes), y el resto del tiempo se bombardeará con el desarrollo de un nuevo sistema de evaluación de aprobación.
La ventaja de esta tecnología es que es objetiva. Incluso con todos los supuestos, cómo el cliente estimó el efecto, las imprecisiones en la evaluación de la complejidad, el nivel del desarrollador que lo implementará, ofrece una imagen real de las tareas importantes y sin importancia desde el punto de vista comercial.
¿Y qué hay de la categoría D, preguntas? ¿Cómo es el deseo del cliente, especialmente los pequeños? ¿Cómo encajaron en el nuevo esquema?
Esta pregunta aún está abierta.
Para construir una imagen objetiva, también es necesario evaluar su efecto económico, pero, condicionalmente, indirecto. Es decir, la reputación de la empresa, el enfoque al cliente, el potencial crecimiento empresarial de estos clientes, atrayendo buenas referencias. Hay asuntos más sutiles, nosotros, junto con ventas y servicio al cliente, discutimos cómo digitalizar estos indicadores.
El objetivo final es obtener un sistema objetivo transparente de creación de tareas que le permita maximizar el uso del recurso de desarrollo. Quizás, como armonía, uno solo puede esforzarse por alcanzarla, sin embargo, la teoría de las restricciones afirma inequívocamente que el "Objetivo" es alcanzable.
Algo asi.
Por la preparación de la siguiente parte del acertijo, compartiré el resultado.
PD: Por el momento, los problemas de refactorización y diversas tareas de infraestructura quedan fuera, volveremos a ellos más adelante.