Responsabilidades e direitos de decisão na colaboração interdepartamental em impressão 3D: método de engenharia do RACI às regras de escalonamento

Introdução: as falhas de colaboração raramente são uma questão de atitude, mas de direitos de decisão não definidos

Na execução de encomendas de impressão 3D, os atrasos e retrabalhos raramente resultam da falta de cooperação de uma pessoa. Mais frequentemente, a mesma questão circula duas vezes entre três departamentos antes de ser efetivamente decidida. A equipa de design considera que a espessura de parede pode ser flexibilizada, a engenharia de processo entende que a peça deve ser impressa conforme o desenho original, a qualidade insiste na avaliação segundo o desenho, e as vendas já prometeram verbalmente um prazo ao cliente — as quatro partes estão a "colaborar", mas nenhuma foi claramente autorizada a fazer a escolha final. Se o mecanismo de colaboração interdepartamental se limitar a "criar canais de comunicação, realizar reuniões regulares e reforçar a cooperação", não conseguirá responder às três perguntas mais importantes: quem decide, quem tem de ser consultado e para que nível se escala uma divergência.

I. Reconduzir a colaboração, de um problema de comunicação, a um problema de direitos de decisão

O primeiro trabalho de engenharia na criação de um mecanismo de colaboração consiste em dividir cada tema interdepartamental em unidades de decisão delegáveis, em vez de o atribuir genericamente a um departamento. Uma encomenda típica de impressão 3D inclui, pelo menos, seis tipos de decisões interdepartamentais: avaliação da viabilidade técnica (se a geometria pode ser fabricada), seleção da rota de processo (combinação de material e equipamento), compromisso de prazo de entrega (incluindo operações subcontratadas), aceitação de alterações (se o planeamento será refeito após uma alteração do desenho pelo cliente), tratamento de produtos não conformes (reparação, aceitação por concessão ou rejeição) e autorização de entrega (incluindo ou não relatório de inspeção). Se todos estes pontos forem tratados por defeito como "discussão em reunião", uma decisão que deveria demorar minutos transforma-se numa reunião de vários dias.

A abordagem de engenharia consiste em atribuir um único responsável final (Accountable) a cada ponto de decisão — único, e não "responsabilidade conjunta". Na prática, duas pessoas conjuntamente responsáveis equivalem a ninguém responsável no registo. O responsável final tem poder de decisão definitivo; as restantes partes relevantes são classificadas como consultadas (Consulted, devem fornecer contributos antes da decisão) ou informadas (Informed, recebem o resultado após a decisão). Este é o núcleo da matriz RACI: Responsible (execução), Accountable (responsabilidade final/decisão), Consulted (consultado) e Informed (informado).

II. Regras de preenchimento e erros comuns numa matriz RACI

Existem várias regras rigorosas para preencher uma matriz RACI. Primeiro, a coluna A de cada unidade de decisão deve ter exatamente uma marcação. A presença de dois A é uma falha de conceção e exige uma subdivisão adicional da unidade de decisão — por exemplo, dividir o "tratamento de produto não conforme" em "classificação da gravidade do defeito" (qualidade como A) e "seleção da medida de tratamento" (engenharia de processo como A, qualidade como C). Segundo, podem existir vários R, mas deve ser indicado o executor principal, normalmente entre parênteses. Terceiro, não convém haver demasiados C: mais de três C numa unidade de decisão indica que o tema foi excessivamente alargado e deve ser restringido às duas ou três partes que realmente influenciam a decisão. Quarto, I não significa não participar: em pontos como a autorização de entrega, as vendas, enquanto I, devem comunicar o resultado ao cliente no prazo de uma hora.

O erro mais comum é colocar nomes de departamentos na matriz em vez de funções. Um departamento é uma unidade organizacional; uma função é o portador da responsabilidade. A mesma área pode ter papéis completamente diferentes em distintos pontos de decisão — a qualidade é A na "classificação de defeitos", mas apenas C na "seleção da rota de processo". A matriz deve utilizar funções, como engenheiro de processo, responsável do projeto e engenheiro da qualidade, nas linhas, e pontos de decisão nas colunas.

III. Lista de interfaces: transformar entregáveis entre departamentos em itens verificáveis

Depois de definir os direitos de decisão, o segundo passo é definir as interfaces. Grande parte dos atritos interdepartamentais ocorre devido a "entregáveis de transferência incompletos": o modelo passado pelo design ao processo não inclui a especificação do material; a instrução de trabalho transferida pelo processo para a produção não descreve a remoção de suportes; a amostra passada pela produção à qualidade não tem o número do lote de impressão. A lista de interfaces deve definir claramente três campos: nome do entregável, momento de entrega e critério de aceitação. Os critérios de aceitação têm de ser verificáveis, por exemplo, "o ficheiro do modelo inclui a designação do material, requisitos de pós-processamento, cotas críticas e número de revisão", e não apenas "documentação completa".

Recomenda-se definir um conjunto de campos obrigatórios para cada entregável na lista de interfaces. Para uma instrução de trabalho entregue pela engenharia de processo à produção, os campos obrigatórios devem incluir, no mínimo: número do equipamento, número do lote de material, orientação de colocação e plano de suportes, espessura de camada e intervalo de parâmetros críticos, curva de tratamento térmico, método de remoção de suportes e limpeza, e taxa de amostragem para inspeção. Se faltar qualquer campo, a área seguinte tem o direito de recusar a receção, e o tempo da recusa não é contabilizado no prazo da área recetora. Esta regra elimina do processo as "instruções verbais" e a "documentação completada posteriormente".

IV. Regras de escalonamento: as divergências não devem ser resolvidas através de reuniões repetidas

Mesmo com direitos de decisão claros, continuarão a existir divergências. Por isso, devem ser estabelecidas regras de escalonamento antecipadamente, em vez de procurar um superior no momento. Recomenda-se que as regras utilizem duas condições de acionamento: tempo e impacto. O acionamento por tempo ocorre quando um ponto de decisão ultrapassa o prazo acordado sem conclusão, por exemplo, 24 horas para uma avaliação de viabilidade técnica, sendo automaticamente escalonado para o nível seguinte. O acionamento por impacto ocorre quando a divergência implica uma alteração do prazo acima de um limiar, por exemplo, mais de dois dias na data de entrega, ou uma alteração de custo acima de um limiar, como mais de 5% do custo unitário; nesse caso, deve ser imediatamente escalonada, com notificação simultânea ao responsável do projeto e ao contacto do cliente.

A decisão após o escalonamento deve ter um prazo de contingência claro e uma ação predefinida. Por exemplo, após o escalonamento para o responsável do projeto, deve ser emitida uma conclusão escrita no prazo de oito horas; se não houver decisão dentro desse prazo, aplica-se por defeito a "solução conservadora" — execução segundo o desenho e processo originais, com adiamento do prazo de entrega. Isto evita que o projeto fique suspenso em estado de espera. A própria existência de uma ação predefinida cria pressão para que todas as partes cheguem a uma conclusão dentro do prazo.

V. Materializar o mecanismo de colaboração em registos verificáveis

Não se deve avaliar o funcionamento real de um mecanismo de colaboração por perceção; é necessário analisar três tipos de registos: registos de decisão (conclusão, responsável e data de cada ponto de decisão), registos de transferência de interface (entregável, recetor e resultado da aceitação) e registos de escalonamento (condição de acionamento, nível de escalonamento e conclusão final). Estes três tipos de registos podem ser simples — basta uma linha numa folha de cálculo partilhada —, mas devem existir e permitir o cálculo mensal de dois indicadores: tempo médio de fecho dos pontos de decisão e taxa de aprovação à primeira das interfaces. O primeiro reflete a clareza da delegação; o segundo, a completude da definição das interfaces.

Recomenda-se selecionar mensalmente cinco projetos concluídos para uma revisão de colaboração. O foco não é atribuir culpas, mas corrigir a própria matriz: quais os pontos de decisão em que a marcação A nunca foi efetivamente exercida, indicando uma delegação excessivamente detalhada; quais os pontos frequentemente escalonados, indicando um nível de autoridade demasiado baixo ou critérios pouco claros; e quais as interfaces repetidamente recusadas, indicando que o conjunto de campos obrigatórios precisa de ser ajustado. A matriz e as listas devem ser revistas à medida que o negócio evolui, mantendo números de versão e datas de entrada em vigor.

Conclusão

A abordagem de engenharia à colaboração interdepartamental pode ser resumida em quatro etapas: dividir os temas de colaboração em unidades de decisão delegáveis, atribuir um único responsável final a cada unidade e preencher a matriz RACI, utilizar listas de interfaces para transformar entregáveis entre departamentos em itens verificáveis e gerir divergências com regras de escalonamento de dupla condição — tempo e impacto — apoiadas por ações predefinidas. Por fim, utilizam-se registos de decisão, transferência e escalonamento para medições mensais e para rever a matriz. Um mecanismo de colaboração construído desta forma não depende da vontade individual de cooperar, mas funciona continuamente graças a delegações claras, interfaces verificáveis e percursos de escalonamento automáticos.