Un proyecto de sala limpia pasa por muchas manos antes de convertirse en un espacio operativo, y en el momento en que ambas partes dan por sentado que la otra es la responsable de un ámbito concreto, ese ámbito deja de estar gestionado por nadie. La cuestión no es si existe una matriz de responsabilidades sobre el papel, sino si se ha diseñado en torno a los puntos concretos en los que el trabajo, la información y las aprobaciones cambian de manos.

Delimita los límites del proyecto antes de asignar nombres

Antes de que se incluyan nombres o funciones empresariales en la matriz, el equipo del proyecto debe tener una idea clara de dónde termina el trabajo de una parte y dónde empieza el de otra. Estos límites no coinciden con las funciones organizativas. Una misma empresa puede estar presente a ambos lados de una interfaz —elaborando un diseño y, posteriormente, realizando la instalación según dicho diseño— y, aun así, la matriz debe separar esas dos funciones, ya que conllevan riesgos distintos si no se definen con claridad.

En un proyecto de sala limpia se repiten dos tipos de límites. Una interfaz física es el punto en el que confluyen el suministro, los trabajos in situ, la instalación y las pruebas: el lugar donde un equipo deja de ser un artículo adquirido y se convierte en algo fijo, conectado y listo para ser probado. Una interfaz de información es el punto en el que un documento o un conjunto de datos cambia de manos o de estado: el lugar donde un plano pasa de ser elaborado a ser coordinado con los oficios adyacentes y, posteriormente, a ser aprobado para su construcción. Tratar estos dos tipos de límites como si fueran lo mismo genera ambigüedad, ya que la parte que elabora un plano no es necesariamente la que lo coordina con otros servicios, ni tampoco es necesariamente la que lo aprueba.

La condición que determina cómo debe definirse un límite es si el trabajo o la información en ese punto depende del resultado de otra parte para poder continuar. Cuando un límite es autónomo —una parte suministra, instala y prueba sin necesidad de una aportación previa de otra persona—, puede bastar con indicar simplemente el nombre del responsable. Cuando un límite depende de una secuencia, como una penetración en la pared que debe ajustarse a las dimensiones de montaje de una unidad, o un plano que debe coordinarse con los esquemas mecánicos y eléctricos antes de poder ser aprobado, la matriz debe reflejar esa dependencia de forma explícita, en lugar de dar por sentado que se resolverá de manera informal en la obra.

Esta fase de mapeo es la que determina cuántas filas necesitará finalmente la matriz. Una matriz elaborada a partir de una lista genérica de funciones de la empresa tenderá a subestimar el número de interfaces, ya que agrupa las actividades en función de quién las realiza, en lugar de según dónde se producen realmente los traspasos. Una matriz elaborada a partir de interfaces físicas y de información pondrá de manifiesto los límites que una lista basada en funciones fusionaría en una sola línea, que es precisamente donde suele originarse el ámbito sin asignar.

Separar las funciones de diseño de las de aprovisionamiento y ejecución

Una vez definidos los límites, el siguiente paso es determinar quién tiene la autoridad en cada uno de ellos —y la autoridad no es algo único—. Elaborar un diseño, coordinarlo con otras disciplinas, aprobar su uso, instalar lo que en él se muestra y probar el resultado instalado son cinco funciones distintas, y una matriz de responsabilidades que las agrupe en una sola columna de “parte responsable” subestimará los puntos en los que pueden surgir desacuerdos.

La autoridad de diseño se refiere específicamente a quién tiene el derecho de determinar cuál debe ser la solución: el diseño, las especificaciones y las dimensiones de la interfaz. Esto difiere de la autoridad de suministro, que se refiere a quién proporciona el equipo o el material físico, y también difiere de la autoridad de ejecución, que se refiere a quién lo instala, lo conecta y lo pone en servicio. Una parte puede ostentar la autoridad de diseño sin tener la autoridad de suministro ni la de ejecución, y otra parte puede suministrar equipos sin haber tenido voz ni voto en cómo se especificaron. Cuando estas funciones no están separadas en la matriz, un error habitual es que la parte que ejecuta el trabajo dé por hecho que la intención del diseño ya está definida, mientras que la parte con autoridad de diseño da por hecho que la ejecución planteará dudas si algo no está claro.

El factor que determina el grado de separación que deben tener estas funciones es el nivel de interdependencia entre el resultado del diseño y las limitaciones físicas que se detectan posteriormente. Cuando un diseño puede ultimarse independientemente de las condiciones del emplazamiento, la separación tiene menos importancia en la práctica, ya que hay pocas posibilidades de que surjan conflictos. Cuando un diseño debe adaptarse a condiciones que solo se confirman durante la instalación —espacios libres, interfaces estructurales, trazado de las instalaciones—, resulta necesario mantener separadas la autoridad sobre el diseño y la tarea de ejecución, ya que alguien debe tener la competencia para decidir si una condición sobre el terreno requiere un cambio en el diseño o simplemente un ajuste in situ dentro de la intención original.

La autoridad de aprobación merece, una vez más, un tratamiento aparte. Aprobar un plano o una interfaz terminada no es lo mismo que producirla, coordinarla, instalarla o probarla, aunque a veces una misma parte desempeñe más de una de estas funciones en un proyecto concreto. Cuando la aprobación recae en la misma parte que ha producido el trabajo que se aprueba, la matriz debe reflejarlo explícitamente, en lugar de dejar en blanco la columna de aprobación partiendo del supuesto de que la producción implica la aprobación.

Registrar las entradas, las salidas, las aprobaciones y las pruebas de aceptación en cada interfaz

Una vez asignadas las interfaces y separadas las competencias según las funciones, cada interfaz debe contar con un conjunto coherente de campos asociados a ella, ya que una interfaz con un responsable designado pero sin entradas ni salidas definidas sigue estando incompleta. El responsable indica quién es el encargado; los campos restantes indican qué abarca realmente esa responsabilidad.

Los datos de entrada necesarios son importantes porque una interfaz no puede ejecutarse correctamente si la parte responsable de la misma no sabe de qué información o material depende. La ubicación de una caja de paso, por ejemplo, depende de datos de entrada tanto de la distribución de la sala como del diseño del pasillo adyacente o de la zona de apoyo; registrar esa dependencia como un dato de entrada explícito evita dar por sentado que la parte encargada de su instalación dispondrá de todo lo necesario sin que se le indique. Los resultados son importantes por la misma razón, pero a la inversa: la matriz debe indicar qué se espera que produzca la interfaz, ya sea una instalación física lista para la prueba, un plano listo para la coordinación o un conjunto de datos listo para el trabajo de diseño de otra parte.

La aprobación es el punto en el que muchas matrices pierden claridad, ya que a menudo se da por sentada en lugar de asignarse. La condición que determina si la aprobación necesita su propia fila es si más de una parte podría, de forma plausible, reclamar o negar la responsabilidad de dar el visto bueno. Cuando solo una parte podría estar en condiciones de aprobar un resultado determinado, el riesgo de ambigüedad es menor. Cuando la aprobación podría recaer razonablemente en un diseñador, un contratista o un representante del propietario, dejar ese campo sin asignar significa que el proyecto carece de un mecanismo para resolver los desacuerdos cuando surjan.

Las pruebas de aceptación constituyen un ámbito distinto de la propiedad y no deben deducirse de esta. El hecho de ser propietario de una interfaz no constituye por sí mismo una prueba de que dicha interfaz se haya completado correctamente; la matriz debe registrar qué pruebas se utilizarán para aceptar el resultado —ya sea un resultado de prueba, un registro de aprobación u otro entregable definido vinculado a esa interfaz específica, en lugar de al proyecto en su conjunto—. Esta separación refleja la estructura del ciclo de vida descrita en ISO 14644-4, que aborda el diseño, la construcción y la puesta en marcha como una secuencia con su propio proceso de verificación, sin especificar qué parte contratante lleva a cabo cada paso; la norma describe las fases del ciclo de vida, y es la propia matriz del proyecto la que asigna al personal y la documentación correspondientes a cada una de ellas.

Un comprador que prepare esta información para la revisión de un presupuesto se beneficia de que estos campos ya estén definidos, ya que los detalles de configuración que necesita un proveedor —qué datos recibirá, qué resultados se espera que entregue y qué pruebas se utilizarán para aceptar su alcance— son los mismos campos que requiere la matriz en cada interfaz relacionada con ese equipamiento del proveedor.

Resolver los casos de alcance con múltiples partes y sin asignar mediante aclaraciones sobre las ofertas

La correspondencia entre interfaces y la documentación de los campos pondrán de manifiesto las lagunas, y estas lagunas en sí mismas son reveladoras. Un titular en blanco, una lista de colaboradores sin una única persona responsable, la falta de una entrada o salida, o la ausencia de una entrada que acredite la aceptación: cada uno de estos casos apunta a un tipo diferente de alcance sin resolver, y cada uno de ellos debería traducirse en una pregunta de aclaración concreta antes de que el proyecto avance hacia las fases de contratación o construcción.

Una interfaz sin un responsable designado es la laguna más evidente, y la solución es igualmente clara: hay que identificar quién se hará cargo de esa interfaz antes de continuar con el trabajo. Una interfaz en la que figuran varias partes sin un único responsable claro plantea un problema distinto: aunque todos los colaboradores estén correctamente identificados, la matriz sigue necesitando una parte responsable que se distinga del resto, ya que la contribución y la responsabilidad no son conceptos intercambiables.

Cuando un campo de entrada o salida está en blanco, la aclaración necesaria no se refiere necesariamente a la responsabilidad, sino a la definición: qué es, concretamente, lo que esta interfaz requiere para continuar o lo que generará una vez completada. Dejar este campo en blanco no significa que la información sea innecesaria; significa que la matriz aún no ha obligado al equipo del proyecto a indicarla.

Cuando falte la aprobación o esta se haya integrado en la misma entidad responsable de producir, coordinar, instalar o probar el mismo resultado, la aclaración consiste en separar explícitamente esa función de aprobación, incluso si, en última instancia, la misma empresa desempeña ambas funciones bajo roles distintos. Y cuando la prueba de aceptación esté en blanco, la aclaración consiste en indicar qué prueba se utilizará realmente, ya que una interfaz sin una prueba de aceptación definida no tiene forma de confirmar que se haya completado según el estándar exigido por el proyecto, independientemente de la claridad con la que se haya asignado la responsabilidad.

El factor que determina la urgencia con la que deben resolverse estas lagunas es el momento en que se sitúa la fase de licitación o oferta con respecto a la congelación del diseño. Cuando surgen aclaraciones mientras el proyecto aún se encuentra en la fase de licitación, una interfaz sin asignar puede resolverse mediante un proceso de preguntas y respuestas antes de que ninguna de las partes haya fijado un precio o se haya comprometido con el alcance. Cuando la misma laguna no se descubre hasta después de la firma de los contratos, esa misma interfaz sin asignar tiende a surgir, en cambio, como una solicitud de modificación tardía o como una disputa sobre qué parte debería haberla incluido en su alcance. Trasladar cada celda sin resolver de la matriz a la Registro de aclaraciones sobre las ofertas, en lugar de dejar que se resuelva de manera informal durante la ejecución, es lo que mantiene esa resolución dentro del proceso comercial, que es donde debe estar.

Incorporar la matriz de responsabilidades en el contrato y en el proceso de cambios

Una matriz de responsabilidades que se haya ultimado pero que nunca se haya incorporado al contrato no tiene más validez que una nota de planificación, ya que nada obliga a ninguna de las partes a cumplirla una vez que comienzan los trabajos. La matriz debe convertirse en un documento contractual al que se haga referencia, y no en un documento que coexista de manera informal con el contrato.

Una vez fijada, la matriz también necesita una relación definida con el proceso de cambio, ya que los proyectos cambian: el alcance varía, las interfaces se modifican, una parte a la que inicialmente se le asignó un resultado puede que ya no esté en condiciones de entregarlo. Lo que distingue a una matriz bien gestionada de una frágil no es si se producen cambios, sino si la matriz cuenta con un procedimiento definido para revisarse cuando estos se producen. Cuando no existe dicho procedimiento, el primer cambio en el proyecto tiende a invalidar la matriz de manera informal, ya que ninguna de las partes está obligada a actualizarla ni a confirmar que la actualización ha sido acordada por las demás partes afectadas.

Una matriz incorporada al contrato debe especificar quién puede proponer un cambio en la asignación de una interfaz, quién debe aprobar dicho cambio y cómo se distribuye y se vuelve a confirmar la versión actualizada a todas las partes que dependen de ella. Esto difiere de la aprobación a nivel de interfaz mencionada anteriormente, ya que se refiere a cambios en la propia matriz, en lugar de a la aprobación de un resultado concreto dentro de una matriz que no ha sufrido modificaciones. Cuando un proyecto trata ambos aspectos como si fueran el mismo mecanismo, un cambio en la matriz puede ser realizado por la misma parte cuya autoridad se pretendía definir mediante la matriz, lo que debilita la función de esta como documento de control.

Los detalles sobre el equipamiento y la interfaz que se han registrado anteriormente en la matriz también se tienen en cuenta a la hora de gestionar la ejecución y la coordinación una vez que el proyecto se pone en marcha — un sistema de sala blanca La integración de múltiples familias de equipos depende de la misma claridad en las interfaces que la matriz se diseñó para establecer, ya que los límites físicos y de información de cada familia con respecto a la sala circundante y a los servicios fueron la razón por la que se creó la matriz en primer lugar. La congelación de la matriz no elimina la necesidad de tomar decisiones a medida que avanza el proyecto; lo que determina es quién está facultado para ejercer ese criterio y qué pruebas se comprobarán antes de que se acepte como definitiva cualquier modificación en una interfaz.

Preguntas frecuentes

Q: ¿Qué nivel de detalle debe tener una matriz de responsabilidades de una sala limpia?
A: Diseñalo en torno a cada interfaz física o de información relevante en la que la titularidad o la aceptación puedan resultar poco claras, en lugar de basarte en una lista genérica de empresas. Cada interfaz debe identificar a un responsable, a los posibles colaboradores, las entradas y salidas necesarias, la responsabilidad de aprobación y las pruebas de aceptación.

Q: ¿El hecho de nombrar al proveedor de la sala limpia implica que este sea responsable de todas las tareas relacionadas con la misma?
A: No. El alcance del proveedor debe separarse de la autoridad de diseño, los trabajos in situ, la instalación, las pruebas y la homologación en cada punto de interfaz. Defina los límites exactos de la sala limpia modular o del paquete del sistema de sala limpia y, a continuación, asigne de forma explícita cada tarea relacionada.

Q: ¿Puede una misma parte elaborar, coordinar y aprobar el mismo plano?
A: Aunque el proyecto pueda asignar varias funciones a una misma parte, la matriz debe registrar por separado la producción, la coordinación y la aprobación. De este modo, se hacen visibles los controles previstos y se evita que una asignación genérica oculte una función sin responsable.

Q: ¿Cómo debería comparar un comprador las ofertas que asignan la misma interfaz de forma diferente?
A: Compara las ofertas con respecto a la misma fila de la interfaz y, a continuación, aclara quién es el titular propuesto, quiénes son los colaboradores, cuáles son las entradas y salidas, así como las pruebas de aprobación y aceptación. Resuelve las diferencias sustanciales en el registro de aclaraciones de las ofertas antes de que la matriz se incorpore al contrato.

Q: ¿Demuestra una matriz de responsabilidades cumplimentada el cumplimiento de la norma ISO 14644-4?
A: No. La matriz asigna las responsabilidades del proyecto y las pruebas de aceptación; por sí sola, no demuestra que se hayan cumplido los requisitos de sala limpia ni que se haya llevado a cabo la verificación. La norma ISO 14644-4 proporciona el contexto del ciclo de vida para el diseño, la construcción, la puesta en marcha y la verificación, mientras que el proyecto debe definir por su parte las modalidades de entrega, aprobación y aceptación.