Diseño de responsabilidades y autoridad de decisión para la colaboración interdepartamental en impresión 3D: método de ingeniería desde la matriz RACI, las listas de interfaces y las reglas de escalamiento

Introducción: los fallos de colaboración no suelen ser un problema de actitud, sino de autoridad de decisión sin definir

Durante la ejecución de pedidos de impresión 3D, los retrasos y retrabajos rara vez se deben a que una persona no coopere. Con mayor frecuencia, un mismo problema circula entre tres departamentos antes de que alguien tome realmente una decisión. Diseño considera que puede flexibilizarse el espesor de pared; ingeniería de procesos sostiene que debe imprimirse conforme al plano original; calidad insiste en evaluar según los planos; y ventas ya ha prometido verbalmente al cliente una fecha de entrega. Las cuatro partes están «colaborando», pero ninguna ha recibido autoridad explícita para realizar la elección final. Si el mecanismo de colaboración interdepartamental se limita a «establecer canales de comunicación, celebrar reuniones periódicas y reforzar la coordinación», no podrá responder a las tres preguntas más importantes: quién toma la decisión final, a quién se debe consultar y a qué nivel se escala una discrepancia.

I. Convertir la colaboración de un problema de comunicación en un problema de autoridad de decisión

El primer trabajo de ingeniería de un mecanismo de colaboración consiste en descomponer cada asunto interdepartamental en unidades de decisión delegables, en lugar de asignarlo genéricamente a un departamento. Un pedido típico de impresión 3D incluye al menos seis tipos de decisiones interdepartamentales: determinación de viabilidad técnica (si la geometría puede fabricarse), selección de la ruta de proceso (combinación de material y equipo), compromiso de plazo de entrega (incluidos los procesos subcontratados), aceptación de cambios (si se reprograma tras una modificación del diseño por parte del cliente), disposición de productos no conformes (reparación, concesión o rechazo) y liberación para entrega (incluyendo o no un informe de inspección). Si todos estos puntos de decisión se resuelven por defecto mediante «reuniones de discusión», decisiones que deberían completarse en minutos se convertirán en reuniones de varios días.

El enfoque de ingeniería consiste en asignar un único responsable final (Accountable) a cada punto de decisión; debe ser único, no una «responsabilidad compartida». Dos personas conjuntamente responsables equivalen, en la práctica, a que nadie sea responsable. El responsable final posee la autoridad de decisión definitiva; las demás partes se clasifican como consultadas (Consulted, deben proporcionar información antes de la decisión) e informadas (Informed, reciben el resultado después de la decisión). Este es el núcleo de la matriz RACI: Responsible (ejecuta), Accountable (asume la responsabilidad y decide), Consulted (consultado) e Informed (informado).

II. Reglas para completar la matriz RACI y errores frecuentes

Al completar una matriz RACI deben respetarse varias reglas estrictas. En primer lugar, la columna A de cada unidad de decisión debe contener una, y solo una, marca. Dos A indican un defecto de diseño y obligan a seguir descomponiendo la unidad de decisión; por ejemplo, la «disposición de productos no conformes» puede dividirse en «determinación de la clasificación del defecto» (calidad como A) y «selección del método de disposición» (procesos como A y calidad como C). En segundo lugar, puede haber varias R, pero debe identificarse al ejecutor principal, normalmente entre paréntesis. En tercer lugar, no debe haber demasiadas C: más de tres C en una unidad de decisión indica que el asunto se ha difundido en exceso y debe limitarse a las dos o tres partes que realmente influyen en la decisión. En cuarto lugar, I no significa falta de participación: en hitos como la liberación para entrega, ventas, como I, debe completar la comunicación con el cliente en la hora posterior a la generación del resultado.

El error más frecuente consiste en incluir nombres de departamentos en la matriz en lugar de roles. Los departamentos son unidades organizativas; los roles son los portadores de la responsabilidad. El papel de un mismo departamento puede ser completamente distinto según el punto de decisión: calidad es A en la «clasificación de defectos», pero solo C en la «selección de la ruta de proceso». La matriz debe organizarse por roles, como ingeniero de procesos, responsable del proyecto o ingeniero de calidad, y por puntos de decisión.

III. Lista de interfaces: convertir los entregables entre departamentos en elementos verificables

Una vez definida la autoridad de decisión, el segundo paso es definir las interfaces. Gran parte de la fricción interdepartamental se produce por «entregables de transferencia incompletos»: el modelo que diseño entrega a procesos no incluye la especificación del material; la instrucción de trabajo que procesos entrega a producción no indica cómo retirar los soportes; la muestra que producción entrega a calidad no incluye el número de lote de impresión. La lista de interfaces debe definir claramente tres campos: nombre del entregable, momento de entrega y criterio de aceptación. El criterio de aceptación debe ser verificable; por ejemplo, «el archivo del modelo incluye grado de material, requisitos de posprocesado, cotas críticas y número de versión», y no simplemente «documentación completa».

Se recomienda establecer un conjunto de campos obligatorios para cada entregable de la lista de interfaces. Por ejemplo, una instrucción de trabajo entregada por procesos a producción debe incluir, como mínimo: número de equipo, número de lote de material, orientación de colocación y estrategia de soportes, espesor de capa y rango de parámetros críticos, curva de tratamiento térmico, método de retirada de soportes y limpieza, y proporción de muestreo para inspección. Si falta cualquiera de estos campos, el área receptora tiene derecho a rechazar la recepción, y el tiempo de rechazo no se contabiliza dentro del plazo del área receptora. Esta regla elimina del proceso las «instrucciones verbales» y la «documentación completada posteriormente».

IV. Reglas de escalamiento: las discrepancias no deben resolverse mediante reuniones repetidas

Incluso con una autoridad de decisión clara, surgirán discrepancias. En ese momento se necesitan reglas de escalamiento predefinidas, en lugar de buscar a un directivo de forma improvisada. Se recomienda utilizar dos condiciones de activación: una basada en tiempo y otra basada en impacto. El disparador temporal se activa cuando un punto de decisión supera el plazo acordado sin cerrarse, por ejemplo, 24 horas para una determinación de viabilidad técnica, y escala automáticamente al nivel superior. El disparador de impacto se activa cuando la discrepancia implica un cambio de plazo por encima de un umbral, como una afectación superior a dos días en la fecha de entrega, o un cambio de coste superior a un umbral, como más del 5 % del coste unitario. En tal caso, se escala de inmediato y se notifica simultáneamente al responsable del proyecto y al interlocutor del cliente.

La decisión posterior al escalamiento debe contar con un plazo de respaldo claro y una acción predeterminada. Por ejemplo, tras escalar al responsable del proyecto, debe emitirse una conclusión por escrito en un plazo de 8 horas. Si no se resuelve dentro de ese plazo, se ejecuta por defecto la «opción conservadora», es decir, se aplica el plano y el proceso originales, y se aplaza la fecha de entrega. Esto evita que el proyecto quede suspendido a la espera de una decisión. La propia existencia de una acción predeterminada actúa como mecanismo de presión y motiva a las partes a alcanzar una conclusión dentro del plazo establecido.

V. Llevar el mecanismo de colaboración a registros verificables

No debe evaluarse por intuición si el mecanismo de colaboración funciona realmente; deben revisarse tres tipos de registros: registros de decisiones (conclusión, responsable y hora de cada punto de decisión), registros de transferencia de interfaces (entregable, receptor y resultado de aceptación) y registros de escalamiento (condición de activación, nivel de escalamiento y conclusión final). Estos tres tipos de registros pueden ser muy ligeros, incluso una sola entrada en una hoja compartida, pero deben existir. Además, deben calcularse mensualmente dos indicadores: el tiempo medio de cierre de los puntos de decisión y la tasa de aceptación a la primera de las interfaces. El primero refleja si la delegación de autoridad es clara; el segundo, si la definición de las interfaces es completa.

Se recomienda seleccionar cada mes cinco proyectos terminados para realizar una revisión de colaboración. El objetivo no es asignar culpas, sino corregir la propia matriz: qué puntos de decisión con marca A nunca se ejercen en la práctica, lo que indica una delegación excesivamente detallada; qué puntos de decisión escalan con frecuencia, lo que indica que el nivel de autoridad es demasiado bajo o que los criterios no son claros; y qué interfaces se rechazan repetidamente, lo que indica que el conjunto de campos obligatorios debe ajustarse. La matriz y las listas deben revisarse conforme evolucione el negocio, conservando el número de versión y la fecha de entrada en vigor.

Conclusión

La vía de ingeniería para la colaboración interdepartamental puede resumirse en cuatro pasos: descomponer los asuntos de colaboración en unidades de decisión delegables; asignar un único responsable final a cada unidad y completar la matriz RACI; utilizar una lista de interfaces para convertir los entregables entre departamentos en elementos verificables; y gestionar las discrepancias mediante reglas de escalamiento con doble activación por tiempo e impacto, respaldadas por acciones predeterminadas. Finalmente, se utilizan los registros de decisiones, transferencias y escalaciones para realizar mediciones mensuales y revisar la matriz. Un mecanismo de colaboración construido de este modo no depende de la disposición individual a cooperar, sino que funciona de forma sostenida mediante una delegación clara, interfaces verificables y rutas de escalamiento que se activan automáticamente.