Um projeto de sala limpa passa por muitas mãos antes de se tornar um espaço operacional, e no momento em que duas partes assumem que a outra é responsável por um determinado limite, esse limite deixa de ser gerenciado por qualquer uma delas. A questão não é se existe uma matriz de responsabilidades no papel, mas se ela está estruturada em torno dos pontos reais em que o trabalho, as informações e as aprovações mudam de mãos.

Delimite os limites do projeto antes de atribuir nomes

Antes que quaisquer nomes ou funções na empresa sejam inseridos na matriz, a equipe do projeto precisa ter uma visão clara de onde termina o trabalho de uma parte e começa o de outra. Esses limites não são os mesmos que as funções organizacionais. Uma única empresa pode atuar em ambos os lados de uma interface — produzindo um layout e, posteriormente, realizando a instalação com base nele — e a matriz ainda precisa separar essas duas posições, pois elas acarretam riscos diferentes se não forem claramente definidas.

Dois tipos de limites se repetem em um projeto de sala limpa. Uma interface física é o ponto onde o fornecimento, a obra no local, a instalação e os testes se encontram: onde um equipamento deixa de ser um item adquirido e se torna algo fixo, conectado e pronto para teste. Uma interface de informação é o ponto onde um documento ou conjunto de dados muda de mãos ou altera seu status: onde um desenho passa da fase de produção para a coordenação com as equipes adjacentes e, em seguida, para a aprovação para construção. Tratar esses dois tipos de limites como se fossem o mesmo gera ambiguidade, pois a parte que elabora algo não é necessariamente a mesma que o coordena com outros serviços, nem é necessariamente a mesma que o aprova.

A condição que determina como um limite deve ser mapeado é se o trabalho ou a informação nesse ponto depende do resultado de outra parte antes de poder prosseguir. Quando um limite é autônomo — uma parte fornece, instala e testa sem precisar de uma contribuição prévia de outra pessoa —, pode ser suficiente indicar simplesmente o nome do responsável. Quando um limite depende de uma sequência de etapas, como uma passagem na parede que deve corresponder às dimensões de montagem de uma unidade, ou um desenho que deve ser coordenado com os projetos mecânicos e elétricos antes de ser aprovado, a matriz precisa capturar essa dependência explicitamente, em vez de presumir que ela será resolvida informalmente no canteiro de obras.

Essa etapa de mapeamento é o que determina quantas linhas a matriz precisará, no final das contas. Uma matriz criada a partir de uma lista genérica de funções da empresa tenderá a subestimar o número de interfaces, pois agrupa as atividades de acordo com quem as executa, em vez de onde as transferências de responsabilidade realmente ocorrem. Uma matriz criada a partir de interfaces físicas e de informação revelará limites que uma lista baseada em funções iria fundir em uma única linha, e é aí que tende a surgir o escopo não atribuído.

Separar a função de projeto das funções de fornecimento e execução

Uma vez definidas as fronteiras, a próxima decisão é determinar quem detém a autoridade em cada uma delas — e a autoridade não é algo único. Produzir um projeto, coordená-lo com outras disciplinas, aprová-lo para uso, instalar o que ele apresenta e testar o resultado instalado são cinco funções distintas, e uma matriz de responsabilidades que as agrupe em uma única coluna de “parte responsável” subestimará os pontos em que podem ocorrer divergências.

A autoridade de projeto diz respeito especificamente a quem tem o direito de determinar como deve ser uma solução — o layout, as especificações e as dimensões da interface. Isso difere da autoridade de fornecimento, que diz respeito a quem fornece o equipamento físico ou o material, e difere ainda mais da autoridade de execução, que diz respeito a quem instala, conecta e coloca em operação o equipamento. Uma parte pode deter a autoridade de projeto sem deter a autoridade de fornecimento ou de execução, e uma parte pode fornecer equipamentos sem ter tido qualquer influência sobre como eles foram especificados. Quando essas funções não estão separadas na matriz, um erro comum é que a parte que executa o trabalho presuma que a intenção do projeto já tenha sido definida, enquanto a parte com autoridade de projeto presuma que a execução levantará questões caso algo não esteja claro.

A condição que determina o grau de separação necessária entre essas funções é o nível de interdependência entre o resultado do projeto e as restrições físicas identificadas posteriormente. Quando um projeto pode ser finalizado independentemente das condições do local, a separação tem menos importância na prática, pois há poucas chances de conflito. Quando um projeto precisa responder a condições confirmadas apenas durante a instalação — distâncias de segurança, interfaces estruturais, traçado de instalações —, torna-se necessário manter a autoridade de projeto distinta da função de execução, pois alguém precisa ter competência para decidir se uma condição no local exige uma alteração no projeto ou apenas um ajuste no local, dentro da intenção original.

A autoridade de aprovação merece, mais uma vez, um tratamento à parte. Aprovar um desenho ou uma interface concluída não é o mesmo que produzi-la, coordená-la, instalá-la ou testá-la, mesmo que, às vezes, uma única parte desempenhe mais de uma dessas funções em um determinado projeto. Quando a aprovação cabe à mesma parte que produziu o trabalho a ser aprovado, a matriz ainda deve registrar isso explicitamente, em vez de deixar a coluna de aprovação em branco, partindo do pressuposto de que a produção implica aprovação.

Registrar entradas, saídas, aprovações e comprovantes de aceitação em cada interface

Com as interfaces mapeadas e as competências separadas por função, cada interface precisa de um conjunto consistente de campos registrados a ela associados, pois uma interface com um responsável designado, mas sem entradas ou saídas definidas, ainda está incompleta. O responsável indica quem é o responsável; os campos restantes indicam o que essa responsabilidade realmente abrange.

Os dados de entrada obrigatórios são importantes porque uma interface não pode ser executada corretamente se a parte responsável por ela não souber de quais informações ou materiais ela depende. A localização de uma caixa de passagem, por exemplo, depende de dados de entrada tanto do layout da sala quanto do projeto do corredor adjacente ou da área de apoio; registrar essa dependência como um dado de entrada explícito evita a suposição de que a parte responsável pela instalação terá tudo o que é necessário sem que isso seja informado. Os resultados são importantes pela mesma razão, mas na perspectiva inversa — a matriz deve indicar o que se espera que a interface produza, seja uma instalação física pronta para teste, um desenho pronto para coordenação ou um conjunto de dados pronto para o trabalho de projeto de outra parte.

A aprovação é o ponto em que muitas matrizes se tornam pouco claras, pois muitas vezes se presume que ela exista, em vez de ser explicitamente atribuída. O critério que determina se a aprovação precisa de uma linha própria é se mais de uma parte poderia, de forma plausível, reivindicar ou negar a responsabilidade pela aprovação. Quando apenas uma parte poderia estar em posição de aprovar um determinado resultado, o risco de ambiguidade é menor. Quando a aprovação poderia, razoavelmente, caber a um projetista, a um empreiteiro ou a um representante do proprietário, deixar esse campo sem atribuição significa que o projeto não possui um mecanismo para resolver divergências quando elas surgirem.

A evidência de aceitação é um campo distinto da propriedade e não deve ser inferida a partir dela. Ser proprietário de uma interface não constitui, por si só, prova de que a interface foi concluída corretamente; a matriz precisa registrar quais evidências serão utilizadas para aceitar o resultado — seja um resultado de teste, um registro de aprovação ou outro produto definido vinculado àquela interface específica, e não ao projeto como um todo. Essa separação reflete a estrutura do ciclo de vida descrita em ISO 14644-4, que aborda o projeto, a construção e a entrada em operação como uma sequência com seu próprio processo de verificação, sem determinar qual das partes contratantes executa cada etapa; a norma descreve as fases do ciclo de vida, e é a matriz do próprio projeto que atribui as pessoas e as evidências a cada uma delas.

Um comprador que esteja preparando essas informações para uma análise de cotação se beneficia do fato de esses campos já estarem definidos, pois os detalhes de configuração de que um fornecedor precisa — quais entradas ele receberá, quais saídas se espera que ele forneça e quais evidências serão utilizadas para aceitar seu escopo — são os mesmos campos que a matriz exige em cada interface relacionada a isso equipamento do fornecedor.

Resolver questões relacionadas a múltiplas partes e escopo não atribuído por meio de esclarecimentos sobre as propostas

O mapeamento de interfaces e o registro de campos revelarão lacunas, e essas lacunas, por si só, já são informativas. Um proprietário em branco, uma lista de colaboradores sem um único responsável, uma entrada ou saída ausente ou uma entrada de comprovação de aceitação ausente — cada um desses casos aponta para um tipo diferente de escopo não resolvido, e cada um deve ser transformado em uma pergunta específica de esclarecimento antes que o projeto avance para a fase de aquisição ou construção.

Uma interface sem um responsável designado é a lacuna mais evidente, e o esclarecimento é igualmente direto: identificar quem será o responsável por essa interface antes de prosseguir com o trabalho. Uma interface que liste várias partes sem um único responsável claro é um problema diferente — os colaboradores podem estar todos corretamente identificados, mas a matriz ainda precisa de uma parte responsável, distinta das demais, pois contribuição e responsabilidade não são conceitos intercambiáveis.

Quando um campo de entrada ou saída estiver em branco, o esclarecimento necessário não se refere necessariamente à responsabilidade, mas à definição: o que, especificamente, essa interface exige para prosseguir ou o que ela produzirá quando estiver concluída. Deixar esse campo em branco não significa que a informação seja desnecessária; significa que a matriz ainda não obrigou a equipe do projeto a especificá-la.

Quando a aprovação estiver ausente ou tiver sido incorporada à mesma parte responsável pela produção, coordenação, instalação ou teste do mesmo produto, o esclarecimento consiste em separar explicitamente essa função de aprovação, mesmo que a mesma empresa, em última instância, desempenhe ambas as funções em âmbitos distintos. E quando a evidência de aceitação estiver em branco, o esclarecimento consiste em indicar qual evidência será efetivamente utilizada — pois uma interface sem evidência de aceitação definida não tem como confirmar se foi concluída de acordo com o padrão exigido pelo projeto, independentemente da clareza com que a responsabilidade tenha sido atribuída.

O fator que determina a urgência com que essas lacunas precisam ser resolvidas é o momento em que a fase de licitação ou proposta ocorre em relação ao congelamento do projeto. Quando surgem esclarecimentos enquanto o projeto ainda está na fase de licitação, uma interface não atribuída pode ser resolvida por meio de um processo de perguntas e respostas antes que qualquer parte tenha feito uma cotação ou se comprometido com o escopo. Quando a mesma lacuna só é descoberta após a assinatura dos contratos, essa mesma interface não atribuída tende a surgir, em vez disso, como uma solicitação de alteração tardia ou uma disputa sobre qual das partes deveria ter incluído essa lacuna no escopo. Levar todas as células não resolvidas da matriz para a registro de esclarecimentos sobre propostas, em vez de deixar que a questão seja resolvida informalmente durante a execução, é o que mantém essa resolução dentro do processo comercial, onde ela deve estar.

Incorporar a matriz de responsabilidades ao contrato e ao processo de alterações

Uma matriz de responsabilidades que seja finalizada, mas nunca incorporada ao contrato, não tem mais validade do que uma nota de planejamento, pois nada obriga nenhuma das partes a segui-la assim que o trabalho tiver início. A matriz precisa se tornar um documento de referência do contrato, e não um documento que exista informalmente ao lado do contrato.

Uma vez definida, a matriz também precisa de uma relação clara com o processo de mudança, pois os projetos mudam — o escopo se altera, as interfaces se deslocam, e uma parte originalmente designada para um resultado pode não estar mais em condições de entregá-lo. O que distingue uma matriz bem gerenciada de uma frágil não é se ocorrem mudanças, mas se a matriz possui um procedimento definido para ser revisada quando elas ocorrem. Na ausência desse procedimento, a primeira mudança no projeto tende a invalidar a matriz informalmente, pois nenhuma parte é obrigada a atualizá-la ou a confirmar que a atualização foi acordada pelas outras partes afetadas.

Uma matriz estabelecida no contrato deve especificar quem pode propor uma alteração na atribuição de uma interface, quem deve aprovar essa alteração e como a versão atualizada é distribuída e reconfirmada a todas as partes que dependem dela. Isso difere da aprovação no nível da interface discutida anteriormente, pois diz respeito a alterações na própria matriz, e não à aprovação de um determinado resultado dentro de uma matriz inalterada. Quando um projeto trata esses dois aspectos como o mesmo mecanismo, uma alteração na matriz pode ser feita pela mesma parte cuja autoridade a matriz deveria definir, o que enfraquece a função da matriz como documento de controle.

Os detalhes sobre os equipamentos e a interface registrados anteriormente na matriz também influenciam a forma como a execução e a coordenação são gerenciadas à medida que o projeto avança — um sistema de sala limpa A montagem de um sistema composto por várias famílias de equipamentos depende da mesma clareza de interface que a matriz foi criada para estabelecer, já que os limites físicos e de informação de cada família em relação ao ambiente circundante e aos serviços foram a razão pela qual a matriz foi criada, em primeiro lugar. Congelar a matriz não elimina a necessidade de julgamento à medida que o projeto avança; ela determina quem tem autoridade para exercer esse julgamento e quais evidências serão verificadas antes que uma alteração em qualquer interface seja aceita como definitiva.

Perguntas frequentes

Q: Qual deve ser o nível de detalhamento de uma matriz de responsabilidades de sala limpa?
A: Elabore-o com base em cada interface física ou de informação relevante em que a responsabilidade ou a aceitação possam não estar claras, em vez de se basear em uma lista genérica de empresas. Cada interface deve identificar um responsável, eventuais colaboradores, as entradas e saídas necessárias, a responsabilidade pela aprovação e a comprovação da aceitação.

Q: O fato de se indicar o fornecedor da sala limpa o torna responsável por todas as tarefas relacionadas à sala limpa?
A: Não. O escopo do fornecedor deve ser separado da autoridade de projeto, das obras no local, da instalação, dos testes e da aprovação em cada interface. Defina os limites exatos da sala limpa modular ou do pacote do sistema de sala limpa e, em seguida, atribua explicitamente cada responsabilidade relacionada.

Q: É possível que uma única parte elabore, coordene e aprove o mesmo desenho?
A: O projeto pode atribuir várias funções a uma mesma parte, mas a matriz deve, mesmo assim, registrar a produção, a coordenação e a aprovação separadamente. Isso torna visíveis as verificações previstas e evita que uma atribuição abrangente oculte uma função sem responsável.

Q: Como um comprador deve comparar propostas que atribuem a mesma interface de maneiras diferentes?
A: Compare as propostas com base na mesma linha da interface e, em seguida, esclareça as informações relativas ao proprietário proposto, aos colaboradores, às entradas, às saídas, à aprovação e às evidências de aceitação. Resolva as diferenças relevantes no registro de esclarecimentos das propostas antes que a matriz seja incorporada ao contrato.

Q: Uma matriz de responsabilidades preenchida comprova a conformidade com a norma ISO 14644-4?
A: Não. A matriz atribui responsabilidades do projeto e evidências de aceitação; por si só, ela não comprova que os requisitos ou a verificação da sala limpa tenham sido atendidos. A norma ISO 14644-4 fornece o contexto do ciclo de vida para o projeto, a construção, a entrada em operação e a verificação, enquanto o projeto ainda deve definir seus procedimentos de entrega, aprovação e aceitação.