Gabinete de engenharia próprio vs. outsourcing — o que compensa mais na construção de máquinas?

A decisão entre desenvolver um gabinete de projeto próprio ou basear a construção de máquinas em outsourcing de engenharia deixou de ser apenas uma questão de custo de contratação ou da tarifa do fornecedor. Hoje, influencia diretamente o prazo de arranque, a capacidade de introduzir alterações de projeto, o nível de risco do lado do fabricante e o controlo efetivo sobre a conformidade. Em projetos em que mecânica, automação, software, segurança funcional e documentação técnica têm de convergir num único ponto de aceitação, um modelo organizacional inadequado normalmente não se faz sentir de imediato, mas sim no final do projeto: nas receções, nas alterações de âmbito, na validação ou na preparação da documentação para o utilizador e para a assistência técnica. Na prática, por isso, a pergunta não é o que é “mais barato”, mas sim qual o modelo que permite manter a responsabilidade, o conhecimento de projeto e o ritmo de decisão num nível adequado à complexidade da máquina.

A importância desta escolha aumenta também porque a máquina atual raramente é apenas um sistema mecânico com um controlo simples. Cada vez mais, inclui uma camada de software, comunicação com os sistemas da fábrica, registo de eventos, rastreabilidade do produto e do processo, além dos requisitos da equipa de manutenção em matéria de diagnóstico e assistência. Isto faz com que a fronteira entre “projeto de máquina” e “organização da colaboração entre várias competências” se esbata muito rapidamente. Se desde o início já se sabe que no projeto vão participar um integrador, um fornecedor de software e a equipa de manutenção do cliente, então a decisão entre in-house e fornecedor externo transforma-se naturalmente numa questão de distribuição de funções, responsabilidade pelas interfaces e definição de quem é o dono das decisões técnicas. O tema alarga-se de forma semelhante quando a máquina deve gerar dados de produção ou suportar a rastreabilidade: sem definir quem responde pela arquitetura de dados, pela validação da lógica e pela gestão das alterações, é fácil criar uma solução que funciona bem em demonstração, mas que é dispendiosa na operação.

Na prática, o critério mais útil para esta decisão não é a simples comparação do orçamento de execução, mas sim o local onde é criado — e onde deve permanecer — o conhecimento crítico para o ciclo de vida da máquina. Se a vantagem da empresa assenta num processo único, em modificações frequentes do produto, na necessidade de mudanças rápidas de formato ou no desenvolvimento de novas variantes da mesma plataforma, então a ausência de competência interna de projeto aumenta o custo de cada alteração seguinte. Pelo contrário, quando o projeto tem um âmbito claramente definido, um baixo nível de modificações repetitivas e não constitui o núcleo da vantagem competitiva da empresa, um fornecedor externo pode ser uma solução racional, desde que o cliente mantenha o controlo sobre os requisitos, as receções e a documentação. Um bom teste é responder a três perguntas: quem toma a decisão quando há alteração de âmbito, quem compreende as consequências dessa alteração para a segurança e para as funções da máquina e quem será capaz de manter a solução após o arranque sem ficar dependente de uma única pessoa ou de um único fornecedor. Estes são indicadores organizacionais que, em regra, preveem melhor a rentabilidade do que o simples preço do projeto.

Um exemplo típico repete-se em muitas fábricas. A empresa subcontrata o projeto e a construção da máquina porque quer reduzir o tempo de entrada no investimento. No início, ganha rapidez, mas ao fim de alguns meses surgem alterações resultantes de ensaios tecnológicos, necessidades de produção e requisitos de qualidade. Se não tiver do seu lado uma equipa capaz de avaliar o impacto dessas alterações na construção, no controlo, no diagnóstico e na documentação, cada correção transforma-se numa encomenda autónoma, e o calendário começa a depender da disponibilidade do fornecedor. Nessa altura, o outsourcing já não é a compra de competência, mas a deslocação do estrangulamento para fora da organização. É precisamente aqui que o tema se cruza com a organização da cooperação entre o integrador, o fornecedor de software e a manutenção, bem como com o desenho da rastreabilidade: se estas áreas não tiverem um proprietário comum dos requisitos, o projeto perde coerência operacional ainda antes da receção.

No fim, a questão da responsabilidade acaba sempre por regressar. Independentemente do modelo de execução, é o fabricante, o importador ou outra entidade que coloque a máquina no mercado ou a ponha em serviço que responde, no âmbito aplicável, pela conformidade do produto, pela completude da documentação e pela correta realização da avaliação de riscos. Por isso, a escolha entre um gabinete de projeto próprio e o outsourcing deve ser avaliada também à luz de quem consegue demonstrar os fundamentos das decisões de projeto, reconstituir o histórico de alterações e preparar o material necessário desde o projeto até à certificação e marcação CE, quando o caso o exigir. Se a organização não conseguir assegurar isso, a poupança aparente na fase de projeto transforma-se muito facilmente em custo de atraso, litígio com o fornecedor ou problema na receção técnica e na operação.

Onde o custo ou o risco mais frequentemente aumentam

No debate entre um gabinete de projeto próprio e o outsourcing de engenheiros, o custo raramente aumenta onde todos olham no início, ou seja, na tarifa do projetista ou no orçamento do pacote de trabalhos. Na maioria dos casos, o problema começa antes: na definição incompleta dos limites da máquina, das interfaces, da responsabilidade pelos pressupostos e da forma de aprovar alterações. Se estes elementos não ficarem fechados logo à partida, a equipa interna consome tempo em alinhamentos e correções, enquanto o fornecedor externo projeta com base em pressupostos próprios, que mais tarde têm de ser revertidos. Na prática, isto significa não só horas de trabalho adicionais, mas também atraso na compra de componentes, interferências na montagem e discussão sobre se o erro resulta de um projeto defeituoso ou de uma encomenda imprecisa. Por isso, o primeiro critério de decisão não deve ser a pergunta sobre quem “faz mais barato”, mas sim quem, nesse modelo, consegue manter a coerência dos requisitos técnicos, de segurança e de operação desde o conceito até à receção.

O segundo ponto em que o risco aumenta é a separação de competências sem separação de responsabilidades. Um gabinete de projeto interno pode parecer mais seguro, porque o conhecimento permanece na organização, mas, se o projeto for conduzido por pessoas que acumulam em paralelo o apoio à produção, a manutenção e as alterações correntes, o projeto passa a ser condicionado pela disponibilidade das pessoas, e não pela lógica técnica. Por outro lado, o outsourcing permite um acesso mais rápido a recursos, mas, sem uma supervisão madura do lado do cliente, conduz facilmente a uma situação em que o fornecedor entrega documentação suficiente para fechar a fase contratual, mas insuficiente para assistência técnica, modernização ou demonstração dos fundamentos das decisões de projeto. O custo desta lacuna surge mais tarde: numa avaria, na mudança de fornecedor, na ampliação da linha ou quando é necessário verificar, com base nas soluções efetivamente implementadas e no percurso de decisão, o nível real de segurança das máquinas e linhas de produção.

Os erros mais dispendiosos têm normalmente um caráter cumulativo. Um exemplo típico é um projeto em que a mecânica, o controlo e as medidas de redução de risco são desenvolvidos em diferentes áreas da organização ou por diferentes fornecedores. O projetista mecânico assume uma determinada forma de acesso à zona de trabalho, o especialista de automação define a lógica de paragem com base em dados incompletos, e as compras encomendam os componentes em função do prazo de entrega, e não dos pressupostos de segurança e de manutenção. Na fase de arranque, torna-se evidente que a proteção dificulta a mudança de formato, que o sensor não dispõe de condições de funcionamento estáveis e que o procedimento de trabalho manual nem sequer foi descrito. Nessa altura, o projeto regressa para reformulação, aumenta o número de alterações na documentação e é necessário voltar a acordar o âmbito com o fornecedor. Aqui, o critério prático de avaliação é simples: se a organização não consegue, numa única revisão, indicar o responsável pelos requisitos, o responsável pela avaliação de riscos e o responsável pela decisão de alteração, então, independentemente do modelo de execução, existem condições para o aumento do custo e da responsabilidade.

Esta questão entra na área do trabalho sobre o risco de processo mais cedo do que muitas empresas assumem. Se o projeto disser respeito a uma instalação com interações relevantes do processo, sequências operacionais e estados perigosos dependentes da organização do trabalho, a simples “adição de proteções” já chega tarde. Nesse caso, conta não só a experiência do projetista, mas também se a equipa sabe conduzir uma análise estruturada de perigos e desvios, ou seja, se possui uma competência próxima da que se desenvolve numa formação HAZOP. Não se trata de formalismo pelo formalismo, mas da capacidade de identificar os pontos em que a decisão tecnológica, operacional e de segurança se influenciam mutuamente. Se essa capacidade não existir dentro da empresa, o outsourcing de engenheiros pode ser justificado; se também não existir do lado do fornecedor, o risco é apenas deslocado para fora da organização.

Só no fim se torna visível a dimensão da conformidade. Quando o projeto chega à receção, à modernização ou à entrada em serviço, a questão deixa de ser quem executou o modelo 3D ou escreveu o programa, passando a ser se é possível demonstrar que as soluções adotadas eram justificadas, que o risco foi avaliado e que a documentação corresponde à execução real. Neste ponto, a escolha entre um gabinete interno e um externo cruza-se já diretamente com a preparação da máquina desde o projeto até à certificação e marcação CE, quando o caso assim o exige. Se o conjunto de evidências estiver incompleto, o custo deixa de ser um custo de projeto e passa a ser um custo de responsabilidade: arranque atrasado, retrabalhos adicionais, receção difícil ou limitações na operação. Por isso, uma comparação sensata entre modelos de execução deve assentar em indicadores mensuráveis: número de alterações após o congelamento dos pressupostos, tempo de aceitação das decisões entre especialidades, completude da documentação “as built” e capacidade de reconstituir por que motivo uma determinada solução foi considerada admissível.

Como abordar o tema na prática

Na prática, a questão entre ter um gabinete de projeto próprio ou recorrer ao outsourcing de engenheiros não deve ser colocada ao nível das tarifas horárias, mas sim ao nível do controlo da decisão técnica e da responsabilidade pelas suas consequências. O modelo mais vantajoso é aquele que permite tomar decisões de projeto fundamentadas com maior rapidez, manter a coerência entre mecânica, automação industrial e segurança e passar da conceção ao arranque sem perdas. Se a equipa interna conhece bem o processo, as limitações da fábrica e o histórico de implementações semelhantes, normalmente ganha em tempo e na qualidade das validações. No entanto, se não existirem recursos para conduzir o projeto, verificar os pressupostos e aceitar a documentação, manter tudo internamente pode revelar-se apenas uma poupança aparente. O custo surge mais tarde: em alterações após a montagem, em disputas sobre o âmbito da responsabilidade ou em documentação que não permite demonstrar por que motivo determinada solução foi considerada admissível.

Por isso, vale a pena basear a decisão num critério prático: onde está, dentro da organização, a capacidade de tomar e sustentar decisões-limite. Trata-se daqueles momentos em que é necessário decidir se uma determinada função deve ser implementada em hardware ou em software, se uma modificação já afeta a segurança, se é possível aceitar um desvio face aos pressupostos e também quem aprova uma alteração com impacto na operação e na manutenção. Se a empresa tiver internamente competência para conduzir este tipo de decisões, o outsourcing pode abranger a execução de parte dos trabalhos sem perda de controlo sobre o projeto. Se essa competência não existir, o prestador externo tem de assumir não só o projeto, mas também a própria estrutura de decisão, o que exige pontos de aceitação claramente definidos, um âmbito claro dos dados de entrada e regras de aprovação de alterações. Sem isso, o outsourcing não encurta o processo; apenas cria uma camada adicional de alinhamentos.

Um exemplo típico é a modernização de uma máquina em que o cliente subcontrata a mecânica e o controlo, mantendo internamente apenas a manutenção e a aceitação final. No início, isto parece razoável, porque o fornecedor declara uma execução completa. O problema começa quando, durante os trabalhos, se verifica que o novo sistema de alimentação altera a forma de acesso à zona perigosa e, ao mesmo tempo, o programa do controlador tem de compensar limitações resultantes da integração física. Se ninguém do lado do cliente conseguir avaliar as consequências dessa alteração para o conjunto da máquina, as decisões serão tomadas de forma reativa, sob pressão do prazo. Como resultado, pode obter-se um equipamento funcional do ponto de vista tecnológico, mas que exige posteriormente alterações em resguardos, interbloqueios, lógica de controlo ou documentação. É precisamente neste ponto que a questão do custo entra no domínio da avaliação prática de saber se a máquina é segura e, depois — se o âmbito do projeto assim o exigir — na preparação da base documental para demonstrar a conformidade.

Do ponto de vista do gestor, isto significa que é necessário medir não apenas a produtividade do fornecedor, mas também a qualidade da condução do projeto. Se, após o congelamento dos pressupostos, aumenta o número de alterações com impacto na segurança, se a aprovação de decisões interdisciplinares demora demasiado tempo ou se a documentação “as built” não acompanha a execução real, isso é um sinal de que o modelo de execução está mal definido. Um gabinete de projeto próprio oferece vantagem onde contam a continuidade do conhecimento sobre o produto e a rapidez de resposta à mudança. O outsourcing faz sentido quando o âmbito está bem definido, as interfaces estão fechadas e a responsabilidade pelo resultado foi distribuída sem lacunas. Quando no projeto participam ainda um integrador, o fornecedor de software e o departamento de manutenção, a simples decisão “fazer internamente ou subcontratar” deixa de ser suficiente; torna-se igualmente importante organizar a cooperação entre estas partes, porque é isso que acaba por determinar o tempo de arranque, os custos das alterações e a possibilidade de uma aceitação rigorosa.

A dimensão normativa e formal não surge no fim, mas exatamente no ponto em que a decisão de projeto afeta uma função de segurança, o modo de utilização ou o âmbito da modificação da máquina. Nem sempre isso conduzirá à mesma obrigação por parte da organização, porque contam a natureza do projeto e o papel de cada entidade. No entanto, é preciso adotar uma regra simples: se não for possível reconstituir os fundamentos das decisões técnicas, da avaliação de risco e das alterações introduzidas ao longo dos trabalhos, então a escolha entre modelo interno e outsourcing deixa de ser uma questão de eficiência e passa a ser uma questão de responsabilidade. A partir daí, a conversa passa naturalmente para duas áreas seguintes: como verificar se a máquina é segura na sua execução real e quando o projeto já exige organizar o percurso desde o projeto até à demonstração da conformidade e à marcação CE.

Naquilo a que deve prestar atenção durante a implementação

Durante a implementação, a diferença entre um gabinete de projeto próprio e o outsourcing deixa de ser uma discussão sobre a tarifa por hora de trabalho. O que determina a rentabilidade é quem controla, na prática, as alterações, quem compreende as limitações do processo e quem consegue sustentar as soluções adotadas quando surge um problema no arranque ou na aceitação. O que mais custa não são os próprios erros de projeto, mas os erros detetados demasiado tarde: conflitos entre mecânica e controlo, interfaces mal definidas, falta de dados de entrada do utilizador final, lógica de responsabilidade pela segurança desalinhada. Se a organização optar pelo outsourcing sem capacidade de supervisão técnica do seu lado, normalmente compra não só o projeto, mas também uma dependência do fornecedor em cada alteração. Por outro lado, se tudo ficar dentro de casa, mas a equipa não tiver tempo para manter a documentação das decisões e as revisões interdisciplinares, o custo regressará na fase de correções, aceitações e assistência técnica.

A armadilha mais comum está em escolher o modelo de execução com base na disponibilidade de recursos, e não no tipo de risco do projeto. A avaliação de uma máquina repetitiva, desenvolvida com base num padrão interno, é diferente da de um posto novo, com cinemática atípica, grande interferência no processo ou elevada participação de funções de segurança. O critério prático é simples: é preciso verificar se, do lado do cliente, existe competência para aprovar pressupostos técnicos, alterações de conceção e a arquitetura de controlo, e não apenas para receber o resultado final. Se essa competência não existir, o outsourcing completo pode parecer mais barato, mas aumenta o risco de litígios sobre o âmbito, prolonga as validações e dificulta a avaliação de saber se o atraso resulta de um erro do executante ou de requisitos de entrada incompletos. Por isso, vale a pena medir não só o orçamento e o prazo, mas também o número de alterações após o congelamento do conceito, o tempo de aprovação da documentação, o número de não conformidades em aberto após o arranque e o tempo necessário para as encerrar.

Na prática, isso vê-se bem na modernização de uma máquina existente ou na construção de uma linha com a participação de várias entidades. Um gabinete de projeto interno compreende muitas vezes melhor as limitações da fábrica, o acesso para assistência, os padrões de manutenção e a forma real de utilização do equipamento. Já um executante externo pode ser mais rápido na preparação do projeto e mais eficiente em questões especializadas, mas pode não ter uma visão completa do ambiente de trabalho. Se, na fase de implementação, se verificar que é necessário alterar o sistema de proteções, a sequência de funcionamento ou a forma de reset após uma paragem, a questão deixa de ser quem fará o desenho ou corrigirá o programa. A questão passa a ser quem avaliará o impacto dessa alteração na segurança, na função da máquina e na integridade da documentação. É neste ponto que a questão da rentabilidade passa naturalmente para uma avaliação prática de como verificar se a máquina é segura na execução real, e não apenas nos pressupostos de projeto.

Só neste enquadramento se percebe a dimensão formal. Nem todas as alterações no projeto conduzem às mesmas obrigações, mas qualquer intervenção relevante na função, no modo de utilização ou nas soluções relacionadas com a segurança exige uma definição clara das responsabilidades e um registo das decisões. Se não se souber quem aprovou a alteração, com que base foi avaliado o risco e se a documentação reflete o estado real, o modelo in-house ou de outsourcing deixa de ter relevância económica, porque surge um problema de responsabilidade pela conformidade. Nessa altura, o tema entra já no domínio da preparação da máquina, desde o projeto até à demonstração da conformidade e à marcação CE. Do ponto de vista da gestão de projetos, isto significa uma coisa: a implementação deve ser planeada de modo a que, juntamente com a máquina, sejam também recebidos o conjunto completo de decisões técnicas, os resultados de verificação e os documentos necessários para a operação futura, modernizações e eventual defesa em receção ou em litígio.