3.4.5.- Análisis de Valor Agregado

Este es el último bloque de la hoja-T que presentaremos en este blog. Esto no significa que no existan o no se puedan crear otros bloques. La necesidad, por una parte, y la flexibilidad de esta herramienta, por la otra, pueden conducir a muchas otras variaciones útiles para la documentación, análisis y mejoramiento de los procesos. Queda en sus manos desarrollar y compartir estas otras variantes.

El bloque que es objeto de esta entrega está compuesto de solo dos columnas. La primera de ellas la denominamos simplemente AVA, por análisis de valor agregado. La otra la denominamos Acción AVA, para registrar lo que haremos a partir de nuestro análisis. Para poder desarrollar este bloque de la hoja-T, previamente debe haber completado la caracterización de actividades (entrega 3.4.2).

De la documentación y análisis de procesos, recordemos que los insumos y productos de un proceso, o incluso de cada una de sus tareas, pueden ser (o suelen ser) objetos documentales y materiales. Como objetos documentales se denotan las tablas de datos, reportes, documentos transaccionales, registros, comprobantes y, en definitiva, todos aquellos datos e informaciones que deben ser producidos según ciertas especificaciones para ser usados en otra tarea, permitiendo su trazabilidad a lo largo del proceso. Como objetos materiales denotamos a la materia prima, sub-productos y productos terminados, que, acompañados de objetos documentales, son trazables a lo largo del proceso.

En la figura que encabeza esta entrega, se puede ver un diagrama de flujo que se inicia con un rombo de decisión. Lo primero que debemos hacer, para cada tarea del proceso, es identificar si en ella ocurre efectivamente una transformación. Debemos comprender que por transformación queremos decir que los productos o salidas de esa tarea en particular difieren sustancialmente de los insumos de esa misma tarea. Es decir, ingresan uno o varios objetos con unas características, contenidos y usos, mientras que a partir de esos mismos insumos y esa misma tarea, egresan otros objetos con características, contenidos y usos diferentes. Para ilustrar, visualicemos a un comprador que recibe una o varias requisiciones de compra. Primero él hace las validaciones aplicables, de lo cual resultarán las mismas requisiciones, solo que ahora revisadas. Luego, para cada requisición válida él produce el panel de proveedores que corresponda. Fíjese que en la primera tarea realizada por el comprador ingresa la requisición y sale la requisición, esencialmente el mismo documento. Luego ingresa la requisición y sale el panel de proveedores, otro documento. Aunque comparten algunos datos, tienen características y usos distintos. En la primera tarea, aunque hay validación, no hay transformación. Mientras que en la segunda tarea, efectivamente ocurre una transformación. Ejemplos de transformación se pueden citar incontables. Pero prefiero en este punto citar algunos ejemplos de lo que no es transformación. El transporte o desplazamiento de documentos y mercancías, no implica la transformación de estos.
La recepción, verificación, validación, archivo o almacenamiento, así como el despacho, tampoco implica la transformación de documentos y materiales. La autorización y / o firma de documentos, tampoco implica su transformación.

La identificación de si ocurre o no transformación en una tarea es importante a efectos del tratamiento que le vamos a dar seguidamente. En una tarea que transforma los insumos, determinamos que se da agregación de valor. Es por esto que en la columna AVA escribimos para esta tarea AV, es decir, que agrega valor. Claro está, muchas veces cuando se hace este ejercicio alguien levanta la mano y manifiesta estar en desacuerdo. “Cuando yo recibo un documento y lo reviso y lo firmo, ya no es el mismo documento”, puede decir. Pero en los términos de nuestra definición de transformación, ese documento sigue teniendo las mismas características, contenidos y usos. Si bien la tarea que realiza esta persona no agrega valor en términos de transformación, debemos tranquilizarla aclarando que esta tarea puede ser útil al proceso en términos de control. Pero debemos abrir un espacio para que el análisis nos permita hacer estas verificaciones y llegar a conclusiones.

Seguidamente, para aquellas tareas que no implican transformación, debemos determinar si son necesarias. Una tarea, aunque no agregue valor puede ser necesaria para el proceso. Anteriormente mencionamos las tareas logísticas (transporte, recepción, almacenamiento, despachos, etc.) y también las tareas de control (revisión, validación, autorización, etc.). Otro tipo de tareas necesarias es aquel que se define para cumplir con requisitos o regulaciones externas a la organización.

Si una tarea no es de transformación y tampoco necesaria, entonces será clasificada como innecesaria. Cuando hacemos el análisis de valor agregado, todas las tareas innecesarias se “marcan” para ser eliminadas. Hay que poner a prueba estas tareas, así como la voluntad de la organización para cambiar. Suele ocurrir que este tipo de tareas, por “uso y costumbre”, están enraizadas y, por lo tanto, son difíciles de eliminar.

Frecuentemente las tareas necesarias dan lugar a acciones de racionalización y simplificación. Para esto es conveniente verificar que el diseño de la planta (“layout”) es armónico con el flujo del proceso. También se recurre al uso de tecnologías de la información. Recuerde que el control solo tiene sentido dentro de un contexto donde también existen la planificación y la toma de decisiones. Todas estas actividades son intensivas en el uso de información. Pero también en este caso debe prevalecer lo racional y lo simple, en conjunción con la orientación a la integración de los procesos y a la industria especifica de la organización.

Para las tareas de transformación (AV), las acciones más comunes apuntan hacia la identificación de aquello que es factor de diferenciación, competitividad y excelencia, para maximización, documentación y periódica transferencia al personal. Las tareas AV pueden ser el núcleo de su práctica, que tal vez es la mejor para usted y su organización. Debe ser muy cuidadoso cuando las compare con otras “mejores prácticas”. Lo que puede funcionar muy bien para otro, puede ser desastroso para usted.

Finalmente, recuerde que lo facilitado aquí no es una receta, es solo un método que le proporciona algo de estructura para llevar a cabo el análisis que usted requiere para lograr que su proceso sea mejor. En este sentido, le recomiendo que sea flexible y no tenga ninguna reserva para probar, adaptar y adoptar.

3.4.4.- Cálculo de Capacidad

Cuando documentamos un proceso es de suma importancia el determinar el volumen o cantidad de los recursos que serán necesarios para producir los productos y servicios que son requeridos por los clientes de dicho proceso. De otro modo, aunque los indicadores de desempeño del proceso muestren valores aceptables, no serán satisfechas las metas ni los objetivos que deben ser soportados por este proceso. A manera de ilustración, imaginemos que tenemos una bomba hidráulica diseñada para darnos un caudal de un litro por segundo; aunque trabaje siempre a máxima eficiencia y nos entregue este caudal, habrá insatisfacción en los clientes si ellos requieren obtener un caudal de diez litros por segundo. El diseño correcto del sistema hidráulico pasaría por instalar una bomba que me pueda dar todo el caudal requerido. Así mismo ocurre con el proceso. Puede tratarse del proceso correcto pero, si su capacidad es incorrecta, habrá insatisfacción. El cálculo de capacidad, también conocido como dimensionamiento, debería realizarse siempre que se diseñe o rediseñe un proceso. Debería revisarse al menos una vez al año cuando se definen los objetivos y metas del siguiente año, siempre antes de la formulación del presupuesto.

Aunque es muy común el uso de la expresión “headcount” (conteo de cabezas), el cálculo de capacidad realmente se expresa en horas hombre (H-H) requeridas para ejecutar una actividad, o un proceso, o todos los procesos de un departamento. Por supuesto, estas H-H se pueden expresar como cantidad de personas requeridas por rol cuando se establece una relación entre dichas H-H y las horas estándar año o calendario que rige la labor de estas personas. Veamos a continuación el paso-a-paso de este cálculo.

Comencemos por presentar la ecuación de capacidad. La capacidad (o simplemente C) es igual al producto del periodo de observación de repeticiones consistentes (también conocido como factor de frecuencia o FF), por el número de repeticiones consistentemente observadas en dicho período (o simplemente repeticiones o Rep), por la cantidad de personas de un rol particular que son requeridas para realizar la tarea o transacción una sola vez (o simplemente recursos o Rec), por la duración en horas de la ejecución de la tarea o transacción una sola vez (o simplemente duración o D). En términos aritméticos sería: C = (FF)*(Rep)*(Rec)*(D). La figura proporcionada con esta entrega servirá para ir ilustrando los conceptos que se desarrollan a continuación.

El factor de frecuencia (FF) o período de observación de repeticiones consistentes, es el menor lapso durante el cual podemos estimar la ocurrencia del número de veces que normalmente repetimos una tarea o transacción. Los lapsos o períodos que se consideran comúnmente son: hora, día, semana, quincena, mes, bimestre, trimestre, semestre, año, bienio y quinquenio. Consideremos un ejemplo muy trivial para ilustrar el uso y determinación de este factor. Supongamos que la tarea que estamos dimensionando es “cepillar los dientes”. El menor lapso para el cual podemos estimar un número consistente de repeticiones es un día. Diariamente podemos observar consistentemente entre 3 y 4 repeticiones. ¿Qué pasaría si seleccionamos “hora”?. Bueno tendríamos cada hora un número de repeticiones que no es consistente. A las 6AM, 7AM, 1PM y 8PM, veríamos una repetición cada vez, pero en el resto de las horas veríamos cero repeticiones. Con un lapso mayor, digamos “semana”, estimaríamos un número de repeticiones que sería consistente, digamos entre 21 y 28, pero ciertamente no se trata del menor lapso en el que somos capaces de hacer la estimación de un valor que es consistente de período en período. Para que podamos usar FF en una ecuación debemos expresarlo en términos numéricos. En nuestro ejemplo anterior debemos convertir el lapso “día” o la frecuencia “diaria” en un número que podamos insertar en nuestra ecuación para poder realizar el producto. Para hacer esto se ha estandarizado que FF se re-exprese según una base anualizada. Para realizar esto es importante conocer cuál es el calendario laboral o calendario de servicio aplicable. Explicado en otros términos, necesitamos saber si el servicio inherente a la tarea “cepillar los dientes” debe estar disponible diariamente o solo de lunes a viernes; si incluye media jornada del sábado; si contempla horarios de guardia; y cuál es el horario de disponibilidad regular cada día. Como en nuestro ejemplo el servicio está disponible todos los días sin restricción de horario, la re-expresión del FF “día” queda igual a 365 (porque hay 365 días en un año).

Seguramente ya notó que cuando vamos haciendo la determinación de FF para cada tarea, al mismo tiempo vamos determinando el número de repeticiones (Rep), que es el segundo factor de la ecuación de capacidad. Hay casos de dimensionamiento que, por su simplicidad, quedan resueltos con un solo valor de repetición para cada tarea, registrado en una única columna para tal fin. Lo más común es que tengamos que desagregar, en múltiples columnas, la expresión de esta variable para que sea más fácil hacer su estimación. De este modo, insertando varias columnas para la variable “repeticiones”, un departamento puede establecer más de un valor discriminando por clientes y/o ubicaciones geográficas. En cualquier caso, debe tenerse presente que todos estos valores deben ser expresados para una sola definición de frecuencia que afecta a toda la "fila" de esa tarea o transacción. Considere que la desagregación de la data que interesa a sus clientes mediante el uso del factor “Rep”, le puede ser útil para demostrar variación de costos y conseguir patrocinio estableciendo una clara relación entre del dimensionamiento de los procesos con sus metas y objetivos.

Los dos factores ya descritos, “FF” y “Rep”, solo podrán ser definidos o estimados en la medida que el documentador del proceso o quien calcula la capacidad, tiene conocimiento de las necesidades que se intentan satisfacer con dicho proceso. Es decir, debe tenerse idea de quienes son los clientes y del volumen de sus requerimientos que deberán ser respondidos por este proceso. De lo contrario el dimensionamiento conducirá a error grave, tanto de insatisfacción como de costo (presupuesto). A este par de variables se les llama factores de mercado. Se comportan del siguiente modo: a mayor el mercado servido veremos que se incrementa el valor de repeticiones mientras el factor de frecuencia se mueve hacia los lapsos mínimos. En contraste, los otros dos factores de la ecuación de capacidad, “Rec” y “D”, son totalmente insensibles a las variaciones del mercado. Requieren que se disponga de conocimiento y estadísticas específicas del proceso a lo interno.

Continuemos con la definición de los otros dos factores de la ecuación. El factor “recursos” (Rec), refleja como valor la cantidad de personas requeridas para hacer la tarea una sola vez. Recuerde que cada fila de la hoja-T corresponde a una tarea y a un solo rol. La cantidad de personas que refleje este valor, solo puede corresponder al rol específico de la tarea que se analiza. Lo más común es que este valor sea igual a uno (1). Normalmente una tarea solo requiere de una persona desempeñando el rol correspondiente para ejecutarla una sola vez para una sola transacción. Si la tarea es “colocar orden de compra”, realizada por el rol “comprador”, solo necesita un (1) comprador para colocar una sola orden de compra, una sola vez. Hay casos especiales, que por razones de limitación humana, seguridad o complejidad, requieren dos o más personas para realizar la tarea una sola vez para una sola transacción. Una ilustración trivial sería “bailar un tango”, en donde el rol sería “bailarín”. El valor de “Rec” en este caso sería dos (2). Debe evitar “inflar” o manipular este valor debido a que haría que todo el ejercicio careciera de sentido.

El último factor de esta ecuación es “duración” (D). Este factor refleja el valor del tiempo que toma realizar la tarea que se analiza (fila), una sola vez, para una sola transacción. De todos los factores descritos, este es el más sensible a la calidad de la información estadística disponible y/o la experiencia del estimador. Debe reflejar el tiempo NETO requerido para que la persona en el rol específico ejecute la tarea que se analiza. Esto quiere decir que si desde el inicio hasta el fin de la tarea, ejecutada una sola vez, para una sola transacción, existen intercaladamente tiempos de espera o de reposo, los mismos deben ser descontados del valor que se registrará finalmente. Otro aspecto a considerar se relaciona con evitar confundir el tiempo de cola con el tiempo de ejecución. Si una persona está una hora en la cola, pero luego el tiempo promedio de atención del cajero es de tres (3) minutos, la tarea “atender público en caja”, realizada por el “cajero”, tendrá un factor D igual a 0,05 horas. Finalmente, ya debe haber notado que este factor debe ser expresado en horas. Esto es así para mantener la consistencia dimensional que proporcionará un valor de capacidad expresado en horas-hombre (H-H).

Cada una de las filas en la tabla de la hoja-T, habiendo incorporado las 5 o 6 columnas necesarias para el cálculo de la capacidad, irá permitiéndonos conocer el valor de H-H requeridas para ejecutar esa tarea específica en un año, que corresponden a una combinación de una sola tarea y un solo rol. También podemos totalizar y ver las H-H requeridas para un proceso al año, abarcando todas sus tareas y correspondientes y diversos roles. Pero podemos aplicar, en el proceso, un “filtro” (función de hoja de cálculo) y ver las H-H totales requeridas para un rol en ese proceso. Y si tomamos ese mismo rol en todos los procesos que aparece, podremos obtener las H-H totales requeridas para un rol en un departamento. En cualquiera de estos casos podemos tomar esas H-H y obtener la razón o relación de ellas respecto de las horas estándar año (HEA). ¿Recuerda cuándo estábamos expresando FF en términos numéricos y anualizados (final del párrafo 4)?. El mismo calendario laboral que usamos en esa oportunidad, lo volvemos a usar acá. Si decimos, a manera de ejemplo, que ese calendario es de lunes a viernes, ocho horas diarias durante todas las semanas del año, entonces el valor de HEA es igual a 52 semanas, por cinco días, por ocho horas (importante, HEA debe expresarse en horas para mantener la consistencia dimensional), HEA = 2080 horas. Este sería el número de horas que una sola persona estaría disponible para el horario laboral definido. Al realizar el cociente de las H-H totales requeridas para un rol, entre HEA, obtendremos la cantidad de personas requeridas para ese rol.

Como se ve, el cálculo de capacidad no es un ejercicio complejo, pero si debe hacerse ordenadamente, después de caracterizar el proceso y los roles, contando con la participación de la gente que conoce el proceso y el mercado que será servido por dicho proceso.

Algunas consideraciones especiales deben tenerse cuando este ejercicio se realiza para una organización tipo “acordeón”, como las que desarrollan proyectos. En estos casos suele ocurrir que el dimensionamiento no se realiza para un año si no para múltiples años dependiendo de la duración total de la cartera de proyectos. Debe diferenciarse el dimensionamiento de una “carga base”, que sería mantenida a lo largo de la ejecución de todo el portafolio, versus la carga variable para atender los “picos”. También deben identificarse tempranamente los roles que serán formados en los distintos proyectos y que luego, no permaneciendo en la organización de proyectos, pasarán a formar parte de las organizaciones de operaciones y mantenimiento.

Otra consideración especial la merece el encadenamiento en “cascada” o desarrollo que puede establecerse entre los diferentes roles identificados. Los requerimientos de un rol superior pueden satisfacerse con personal en roles subordinados, dando lugar a una migración o movimiento entre los roles si se identifican los candidatos para los que puede aplicar una promoción o ascenso. Finalmente, los requerimientos no satisfechos por estos movimientos internos del departamento, serían cubiertos con otras transferencias o nuevas contrataciones.

En la próxima entrega estaremos compartiendo el bloque de la hoja-T con el que cerramos la caracterización de procesos, el análisis de valor agregado, que es de gran utilidad para el mejoramiento continuo y el rediseño.

3.4.3.- Caracterización de Roles

Un rol es el papel que nos toca desempeñar en una obra. Por extensión, el rol pasa a definir las funciones que debemos cumplir para ejecutar los procesos de nuestro trabajo. Cuando hablamos de caracterización de roles, lo que hacemos es delinear el conjunto de funciones que es lógico agrupar y asignar a un rol en particular.

Cuando caracterizábamos actividades, en la entrega anterior (3.4.2), usábamos una columna que titulamos “asignación”, para ir estableciendo en cada tarea cual es el rol que la desempeña. Cuando hacemos esto debemos tener en mente un conjunto o perfil de destrezas que pueden encontrarse en una persona para poder realizar las tareas que le son asignadas. Al mismo tiempo que definimos la tarea a partir de su verbo y predicado (acción y alcance), también la asociamos con un perfil de destrezas que es requerido para ejecutarla. Supongamos que una tarea cualquiera del proceso que caracterizamos queda definida como: “Analizar comportamiento de facturación de clientes con medición indirecta”. Observemos que la acción particular queda definida como “analizar”. Ahora, dependiendo de qué es lo que se analiza pensaremos mejor en el perfil de destrezas requeridas. Para esto nos enfocamos en el predicado de la oración que define a la tarea. Lo que se quiere analizar es el “comportamiento de facturación de clientes con medición indirecta”. No se trata de cualquier análisis. No lo podemos asignar a cualquier analista. Las destrezas requeridas incluyen el conocimiento de la gestión comercial de una empresa de servicios eléctricos, así como de segmentos específicos de su mercado y de sus patrones de consumo. De este modo la acción de “analizar” queda completamente separada de otras acciones que pudieran estar enfocadas a “decidir” o “cambiar” o “contabilizar” o “contratar”. Así pensaremos en un analista de consumo y no en un gerente, operador, contador o comprador.

Esta separación ocurre por tres razones. Una de ellas la hemos venido comentando y se refiere al perfil de destrezas. Otra tiene que ver con la separación de funciones que son vulnerables. Y la tercera tiene que ver con buscar el equilibrio económico y de eficiencia a través de la paquetización. En un extremo estaríamos estableciendo una segmentación demasiado granularizada del proceso, asignando solo una tarea por persona/rol. Sería la máxima segmentación del trabajo según los principios de Frederick Winslow Taylor. Pero todos sabemos que el taylorismo tiene grandes desventajas. Es alienante, al tiempo que sustrae al trabajador de una visión más integral del proceso, que es requerida para que pueda responder sobre el estatus del trabajo y contribuir mejor con los resultados. En el otro extremo tendríamos todas las funciones asignadas a una sola persona/rol, lo que inmediatamente entra en conflicto con la definición de perfil de destrezas. Una persona puede poseer muchas destrezas pero es prácticamente imposible que las posea todas para realizar todas las tareas. Algunas tareas las haría eficientemente, pero otras tantas serían hechas con mucha ineficiencia. Entre estos dos extremos es que tiene cabida la noción de hacer paquetes de tareas que sean asignables a personas/roles con base en sus perfiles de destrezas. El límite del tamaño de un paquete vendría impuesto por: (1) razones de economía y eficiencia, que ya hemos ilustrado; y (2) vulnerabilidad de tareas incompatibles. Cuando pueda anticiparse que dos acciones incompatibles (p.ej.: contratar y pagar), hagan más vulnerable el proceso al riesgo de fraude, es recomendable separarlas para un mayor control.

Pero para que un rol esté completo debemos ir más allá de la mera asignación de tareas (funciones). Debemos también identificar cuáles son las responsabilidades y las competencias. De este modo, según la metodología de la “hoja T” (T-sheet), el rol está completamente definido cuando: (1) tiene asignadas las tareas; (2) para cada una conocemos la responsabilidad inherente; y (3) conocemos cuáles son las competencias para ejecutar la tarea y cumplir la responsabilidad.

En este ejercicio de caracterización del rol, la responsabilidad la definimos como lo que debo lograr cuando realizo la tarea. Si la tarea es “Elaborar el plan de trabajo semanal”, la responsabilidad va más allá de elaborar el plan una vez a la semana. La responsabilidad abarcaría al menos lo siguiente: (1) ser oportuno en la elaboración y entrega del plan; (2) Incluir todas las actividades y recursos requeridos para hacer el trabajo de la semana; y (3) coordinar con los participantes y asegurar que conocen el plan y sus objetivos.

Siguiendo con este ejemplo, las competencias requeridas irían más allá que las que corresponden a elaborar un plan, a saber: ser estructurado, conocer detalladamente el proceso o trabajo que debe planificarse y dominar el uso de herramientas informáticas de apoyo a la planificación. Por ejemplo, para ser oportuno en la elaboración y entrega del plan, mis competencias deben abarcar: orden y método. También, para incluir todas las actividades y recursos requeridos para hacer el trabajo de la semana, mis competencias deben incluir: conocimiento detallado del trabajo y experiencia previa en este. Finalmente, para coordinar con los participantes y asegurar que conocen el plan y sus objetivos, mis competencias también deben contemplar: habilidades de comunicación y empatía, liderazgo y delegación. Al obviar todas estas competencias, algunas organizaciones hacen una incorrecta asignación del rol, lo que se traduce en tener un plan semanal, pero que no logra los resultados que se esperan.

Al completar la caracterización de roles de un proceso, las tres primeras columnas de la hoja T se verán complementadas por otras dos, para totalizar las siguientes: elementos del proceso, actividades, asignaciones (surge el rol), responsabilidades y competencias.

En la hoja T podremos ver un aspecto que nos ayuda a validar la definición de los roles. Si hemos ordenado las actividades según el criterio de secuencia lógica descrito en la entrega anterior (3.4.2) y, al mismo tiempo, ordenamos los roles de tal modo que hacia el extermo izquierdo estén aquellos con mayor responsabilidad de dirección y coordinación, mientras que hacia el extremo derecho estén aquellos de mayor responsabilidad por la operación y ejecución, deberá "dibujarse" lo que denominamos una "C-invertida". Es decir, todo proceso debe iniciarse desde las más altas instancias de coordinación, para luego avanzar hacia las instancias de ejecución y, finalmente, regresar a las instancias de coordinación. Esto es consistente con el Ciclo de Gestión descrito por Deming: P+R+E+O = planifico+ejecuto+evalúo+optimizo.

Es conveniente identificar en este momento cuantos roles estoy identificando para el proceso. Lo razonable es ver unos cuatro roles por proceso. En caso extremo se pueden ver hasta siete. Pero es obvio que en la medida que vea más roles, debo regresar a revisar los criterios de segmentación del trabajo que estoy usando.

En la próxima entrega hablaremos sobre el cálculo de capacidad del proceso para determinar el “conteo de cabezas” (headcount) o cantidad de personas para cubrir los roles asignados a este.

3.4.2.- Caracterización de Actividades

Se refiere a la determinación de las características o atributos peculiares de un proceso, desagregado hasta un nivel de detalle deseado, de modo que podamos entenderlo cabalmente. Un proceso es acción, es movimiento, es actividad. Para poder documentarlo y analizarlo, debemos preestablecer un nivel de detalle práctico. En un nivel de detalle muy grueso veríamos macro-procesos de la cadena de valor. En el otro extremo de la escala veríamos el paso-a-paso procedimental de la acción. Pero existe un nivel de detalle de la actividad que es particularmente práctico para la documentación y el análisis de los procesos. Me refiero al nivel de detalle que corresponde por igual a tareas y transacciones.

La tarea es el conjunto de actividades de un proceso que se asignan a una persona como parte de su rol para obtener un resultado especifico que es requerido para lograr el resultado principal o final del proceso; para hacer esto la persona no requiere ser complementada por otras con roles distintos y le son suficientes las destrezas que por sí misma posee. Un ejemplo de tarea puede ser la operación de una máquina de llenado para completar un lote, incluyendo el registro de los datos que permitan la trazabilidad de los sub-productos manipulados. Otro ejemplo de tarea puede ser la preparación y obtención de un panel de proveedores para efectuar una consulta de precios. Nótese que podemos reconocer este nivel de detalle por dos características: una, que cada tarea es asignable a una y solo una persona; otra, que la tarea comienza cuando la persona recibe algo que es requerido para hacer la tarea y finaliza cuando debe pasar a manos de otra persona para continuar el proceso.

El concepto de transacción está muy ligado al ámbito informático, aunque no le es exclusivo. Esencialmente una transacción es una tarea. Solo que para que una transacción se considere completa debe verificarse que se den dos condiciones: una de ellas es que cada transacción resulta en un documento (físico o electrónico) que corresponde con una combinación particular de variables; la otra es que cada documento suele estar asociado a un código que le proporciona una identificación única para permitir el control y seguimiento de los diferentes momentos de un proceso que responde a un requerimiento o necesidad particulares. Algunos ejemplos de transacción pueden ser: completar la planilla de declaración de impuestos, crear una solicitud de materiales, etc.

En suma, al caracterizar las actividades de un proceso debemos ajustarnos a un nivel de detalle que nos permita: (i) asignar la actividad a una y solo una persona por transacción y (ii) identificar claramente el documento generado. A este criterio de documentación le denominamos “asignabilidad” y es fundamental para considerar como aceptable cualquier documentación de procesos.

Adicionalmente, se emplean dos criterios complementarios para la caracterización de actividades. Uno es el de secuencia lógica y el otro es el de redacción.

La secuencia lógica tiene que ver con un orden tipo “cascada” en el que deben registrarse las actividades cuando las documentamos. Ese orden puede responder a diferentes enfoques. Uno de ellos puede denominarse “cronológico” (lunes, martes, miércoles, etc.). Otro está basado en frecuencias de ejecución y va de lo macro a lo micro (anual, mensual, semanal, diario, etc.). También puede estar basado en los ámbitos gerenciales (estratégico, táctico y operacional). Otro está basado en el ciclo P-R-E-O de Deming (planifico, hago, evalúo y optimizo). Y finalmente, en lo procedimental (fundación, columna, techo, etc.). Cuando desarrollamos la secuencia lógica de un proceso y nos encontramos con una actividad a partir de la cual podemos seguir con dos o más rutas o secuencias diferentes, lo que hacemos es documentarlas todas pero identificándolas como elementos o secciones distintas del proceso. Vale decir que los elementos, entre sí, también deben cumplir con el criterio de secuencia lógica.

La redacción tiene que ver con asegurar que cada actividad quede documentada de tal modo que podamos conocer cuál es la acción específica y su alcance. Para esto es necesario que toda actividad comience con un verbo en su forma infinitiva (-ar, -er, -ir) y continúe con su predicado especifico. El verbo nos indica la acción y el predicado su alcance. Una adecuada redacción nos simplifica establecer la correcta asignación de la tarea a personas y roles.

Con todo lo dicho hasta ahora solo falta decir que este primer bloque de la hoja-T está compuesto de solo tres columnas, identificadas con los siguientes encabezados: elementos, actividad y rol. La primera columna nos permite reconocer las diferentes secciones de un proceso, mientras que la tercera columna nos permite verificar que estamos cumpliendo con el criterio de asignación.

Como punto de partida de la caracterización, comunmente usamos los elementos con los que trabajamos en el ejercicio de identificación de soluciones (ver entrega 3.2). Esto nos permite trabajar con secciones del proceso que produciran componentes específicos de la solución que entregaremos a nuestros clientes.

3.4.1.- Documentación de Procesos

En 1996 me correspondió usar por primera vez una metodología para la implantación de sistemas corporativos, que había sido ampliamente documentada y probada por PW (en aquella época era simplemente Price Waterhouse), conocida como “system management methodology” (SMM). Esta metodología estaba complementada por una herramienta de documentación denominada “SMM tool-kit”, que venía en efecto a ser un paquete informático alrededor de un conjunto de técnicas que de manera integrada permitían la utilización de la metodología. Una de las técnicas allí contenidas que demostró ser muy útil fue la que aplicamos para documentar los procesos del negocio. Simplemente le llamábamos “hoja-T”. Su nombre deriva de su forma: se trata de una tabla con múltiples juegos de columnas. Desde aquella vez, con la práctica, hemos venido mejorándola de tal modo que en este momento tiene muy pocas fisuras cuando se trata de documentar y analizar procesos desde una perspectiva transaccional.

La hoja-T es un documento que se va completando por partes o bloques. Aunque no siempre se usan todos, los bloques más comunes son: (a) el de caracterización de actividades, (b) el de caracterización de roles, (c) el de dimensionamiento o cálculo de capacidad y (d) el de análisis de valor agregado.

Cada uno de estos bloques será tratado separadamente en las siguientes entregas.