Como organizar a colaboração entre o integrador, a software house e o departamento de manutenção numa mesma iniciativa de projeto?

Porque é que este tema é importante hoje

A colaboração entre o integrador, o software house e a equipa de manutenção deixou de ser uma mera questão de conveniência organizacional. Na prática, é hoje isso que determina se o projeto pode entrar em funcionamento sem conflitos quanto ao âmbito, se uma alteração no software não vai bloquear a aceitação técnica e se a fábrica conseguirá manter a solução em segurança após a implementação. Quanto mais lógica do processo passa para a camada de software, e menos permanece nas funções standard dos controladores e equipamentos, maior se torna a importância dos limites de responsabilidade. Se esses limites não forem definidos logo no início, o custo do projeto normalmente não aumenta de forma linear, mas sim por meio de correções feitas no sítio errado: o integrador corrige interfaces, o software house reconstrói a lógica de negócio e a manutenção só no fim revela requisitos operacionais que ninguém tinha registado antes.

Este é também um tema orçamental, e não apenas técnico. Em muitos projetos, a questão da colaboração entre as partes transforma-se muito rapidamente na pergunta sobre o que é, afinal, o software dedicado para a indústria no orçamento de investimento: um elemento do investimento, um custo de manutenção ou uma combinação de ambos. Se a arquitetura da solução pressupõe que funções-chave do processo, reporting, receitas, rastreabilidade de lotes ou integração com os sistemas da fábrica serão desenvolvidas fora do âmbito standard da automação, isso tem de ser identificado antes da encomenda, e não depois do primeiro protótipo. O critério prático é simples: se a ausência de um único responsável pela decisão na fronteira entre automação, aplicação e operação faz com que não seja possível atribuir de forma inequívoca os requisitos, os testes e os custos das alterações, então o projeto já entrou numa zona de risco acrescido e exige uma correção do modelo de colaboração. Neste contexto, a fronteira entre automação industrial e software dedicado para a indústria pode ser melhor enquadrada.

Isso torna-se ainda mais claro no exemplo da modernização de uma linha em que o integrador é responsável pelo controlo e arranque, o software house pela camada aplicacional e pela troca de dados, e a manutenção terá depois de assumir o sistema para operação contínua. Se a equipa de manutenção só for envolvida na fase de aceitação, normalmente surgem problemas que não são “avarias”, mas lacunas de decisão: ausência de procedimento de recuperação após falha, falta de requisitos para contas de serviço, janelas de atualização não definidas, dependência não prevista de um fornecedor externo ou observabilidade insuficiente dos erros. Nessa altura, o conflito já não diz respeito à qualidade do código ou à conformidade do quadro elétrico, mas sim a quem deve suportar o custo de adaptar o sistema à realidade da fábrica. É aqui que o tema se cruza naturalmente com os custos ocultos do projeto e da conformidade, porque o atraso na aceitação ou uma alteração tardia das funções de segurança, da documentação técnica ou da validação resulta muitas vezes precisamente de uma colaboração mal organizada, e não de um erro isolado de execução. Quando estas questões afetam a segurança funcional, a documentação e a validação, faz sentido analisá-las também na perspetiva de uma auditoria de segurança de máquinas e linhas de produção.

O aspeto da conformidade surge quando a divisão de trabalhos influencia as características do produto, as funções relacionadas com a segurança, a documentação ou a forma como a solução é colocada em utilização. Nem toda a integração de uma aplicação com uma máquina desencadeia as mesmas obrigações, mas a simples falta de clareza sobre quem é responsável pela descrição das funções, pela gestão da alteração e pela completude da documentação já é um sinal de alerta. Isto aplica-se em especial a projetos realizados internamente na própria fábrica, a modernizações executadas por fases e a soluções desenvolvidas para uso próprio, em que a fronteira entre “trabalho de manutenção” e fabrico ou modificação substancial pode ter relevância jurídica. Por isso, a decisão sobre o modelo de colaboração não deve ser tomada quando surge o primeiro conflito, mas sim quando o âmbito está a ser definido: quem descreve os requisitos operacionais, quem aprova a arquitetura, quem responde pelos testes entre camadas e quem assume o sistema após o arranque com capacidade real para o manter. Quando a divisão de responsabilidades afeta as características da máquina, a documentação e a entrada em serviço, o enquadramento adequado passa também pela certificação CE de máquinas.

Onde o custo ou o risco mais frequentemente aumentam

Em projetos conduzidos em conjunto pelo integrador, pelo software house e pela equipa de manutenção, o custo raramente aumenta por causa de um único erro grave. Normalmente, acumula-se na fronteira entre responsabilidades, ou seja, onde ninguém tem a obrigação plena de levar o assunto até ao fim. O mais caro não são os erros técnicos em si, mas as decisões adiadas ou tomadas sem responsável definido: ausência de uma arquitetura de comunicação acordada, fronteiras não descritas entre a lógica de controlo e a camada aplicacional, método de teste após alterações não definido e transferência do sistema para operação sem capacidade real de manutenção. Na prática, isto significa correções já depois do arranque, conflitos sobre o âmbito contratual e deslocação da responsabilidade pelas paragens para a fase em que qualquer alteração é mais cara. Um critério simples para avaliar a situação é perguntar se, para cada função crítica, é possível identificar uma parte responsável pelo requisito, uma pela execução e uma pela aceitação. Se a resposta for “depende”, o projeto já está exposto a risco organizacional. Nesses casos, a organização das dependências, dos prazos de decisão e da responsabilidade pela escalada deve ser tratada como tema de gestão de projetos.

A segunda área de perdas surge quando as decisões de projeto são tomadas sem a participação da manutenção ou, pelo contrário, quando a manutenção impõe soluções convenientes do ponto de vista do serviço, mas incoerentes com a arquitetura do sistema. O integrador tende a olhar sobretudo para o arranque e para a cooperação com os equipamentos, o software house pela ótica da lógica de negócio e das interfaces, e a manutenção pela ótica da disponibilidade, do diagnóstico e do tempo de reposição do funcionamento. Se estas perspetivas não se cruzarem na fase de definição dos requisitos, regressam mais tarde sob a forma de custos de alteração: sinais adicionais, reconfiguração de permissões, ausência de registo de eventos necessários ao diagnóstico, impossibilidade de realizar atualizações em segurança ou falta de um procedimento de contingência para falhas. É neste ponto que o tema passa naturalmente para o papel da gestão de projetos, porque o problema deixa de ser uma decisão técnica isolada e passa a ser a gestão de dependências, dos prazos de alinhamento e da responsabilidade pela escalada.

Um exemplo prático típico é uma implementação em que a aplicação de supervisão deve gerir ordens, receitas e reporting, enquanto o integrador é responsável pelo controlador, pelos acionamentos e pela sequência da máquina. Se a fronteira de responsabilidades for descrita apenas de forma funcional, sem indicar estados intermédios, condições de erro e o comportamento em caso de perda de comunicação, cada uma das partes irá construir à sua maneira pressupostos “seguros”. O software house assumirá que a falta de confirmação significa repetir o comando, o integrador partirá do princípio de que o comando é único, e a manutenção receberá um sistema que não pode ser diagnosticado durante uma paragem. O resultado é previsível: arranque demorado, erros ambíguos, correções de interfaces e tensão em torno da questão de saber quem responde por uma paragem não planeada. Na avaliação de uma situação destas, vale a pena medir não só o prazo de entrega, mas também o número de alterações de interface após a aprovação do projeto, o número de falhas detetadas apenas em campo e o tempo necessário para reconstruir a causa da avaria. Se estes indicadores aumentam apesar do avanço dos trabalhos, o problema está normalmente na organização da colaboração, e não no desempenho de um fornecedor isolado.

Uma fonte de risco distinta é tratar os testes e a documentação como um subproduto do arranque. Sempre que o sistema afeta o funcionamento da máquina, o acesso do operador, o diagnóstico, os parâmetros do processo ou funções relacionadas com a segurança, uma alteração tardia não é uma simples correção de software. Pode exigir uma nova avaliação dos pressupostos de projeto, a atualização da documentação técnica, a repetição de parte dos ensaios e, em determinados contextos factuais, também uma nova análise das obrigações do utilizador ou da entidade que introduz a alteração. Isto não pode ser decidido de forma abstrata e igual para todos os projetos, mas a regra prática é simples: quanto mais a alteração afeta o comportamento do sistema em estados normais e anormais, menos admissível é conduzi-la com base em “acordos de trabalho”. É também aqui que começa a área dos erros típicos encontrados na construção e modernização de máquinas: ausência de bloqueios contra configuração incorreta, falta de imposição da sequência de ações e ausência de mecanismos que previnam erros do operador ou da assistência técnica. Se estas salvaguardas não forem incluídas no âmbito desde o início, regressam mais tarde sob a forma de custo, paragem ou litígio quanto à responsabilidade.

Como abordar o tema na prática

Na prática, a colaboração entre o integrador, o software house e o departamento de manutenção não deve ser organizada em torno das empresas, mas sim em torno dos limites de responsabilidade por decisões técnicas concretas. É isso que determina quem responde pela lógica de controlo, quem responde pela camada aplicacional e pela comunicação, e quem responde pelas condições de assistência, cópias de segurança, recuperação após falha e implementação segura de alterações no terreno. Se estes limites permanecerem descritos de forma genérica, o projeto começa a funcionar com base em pressupostos: o integrador assume que os requisitos de exploração serão fornecidos pela fábrica, o software house parte do princípio de que a lógica do processo já está fechada, e a manutenção recebe um sistema que não pode ser mantido de forma eficaz sem o autor do código. A consequência não é apenas organizacional. Aumenta o custo do arranque, prolonga-se a eliminação de falhas e, em caso de litígio, torna-se mais difícil determinar se o problema resulta de um erro de implementação, de pressupostos incompletos ou de uma alteração não controlada após a receção.

Por isso, a primeira decisão não deve ser a escolha da ferramenta nem o calendário dos workshops, mas a adoção de um modelo comum de responsabilidade para todo o ciclo de vida da solução. Para um manager, o critério prático é simples: cada função com impacto no funcionamento da máquina ou da linha deve ter um responsável identificado em quatro estados do projeto — conceção, arranque, receção e manutenção. Se, para uma determinada função, não for possível responder de forma inequívoca quem aprova o requisito, quem executa a alteração, quem testa os seus efeitos e quem assume a responsabilidade por repor o funcionamento após uma avaria, então o âmbito não está pronto para execução. É aqui que surge naturalmente o papel do gestor de projeto de engenharia: não como a pessoa “dos prazos”, mas como o responsável pela ordem de decisão entre disciplinas e fornecedores.

A maior parte dos problemas surge na interface entre o controlo e o software dedicado. Um exemplo típico é uma aplicação que altera a forma de seleção de receitas, parametriza a sequência de trabalho ou interfere nas permissões do operador. Para um software house, isto pode parecer uma simples alteração funcional, mas para o integrador e para a manutenção trata-se de uma intervenção no comportamento do sistema, no diagnóstico e nos procedimentos de mudança de formato. Se, antes da implementação, não tiver ficado definido onde termina a responsabilidade pela interface e onde começa a responsabilidade pela lógica do processo, uma correção feita “em produção” pode exigir novos testes, atualização das instruções e, por vezes, a reformulação dos procedimentos de assistência. É precisamente aqui que a questão entra também no domínio do orçamento: o custo do software dedicado para a indústria não resulta apenas da escrita do código, mas também do grau de responsabilidade que o projeto transfere para a fase de validação, documentação e manutenção posterior.

Para evitar isso, vale a pena avaliar o estado do projeto não pelas declarações dos fornecedores, mas pelos artefactos que podem ser verificados. O conjunto mínimo inclui uma lista de interfaces acordada, a descrição do versionamento, o procedimento de reporte e autorização de alterações, os cenários de testes de aceitação e o plano de manutenção após a entrada em funcionamento. Aqui, funciona bem um filtro de decisão simples:

• se a alteração afeta a lógica do processo, os parâmetros de funcionamento ou o comportamento do operador,
• se é possível reproduzi-la, testá-la e revertê-la sem a participação do autor da solução,
• se a documentação após a implementação permite à fábrica manter o sistema sem depender de conhecimento oculto na caixa de correio eletrónico do executante.

Se a resposta a alguma destas perguntas for “não”, então o projeto precisa de um âmbito mais bem definido, e não de acelerar os trabalhos. Só nesta fase faz sentido remeter para requisitos formais: não para acrescentar reservas genéricas ao contrato, mas para verificar se a natureza das alterações já não afeta as obrigações de documentação, de aceitação ou a avaliação de responsabilidades do lado do utilizador. Isto é particularmente importante quando a própria fábrica co-desenvolve a solução, a desenvolve com meios próprios ou constrói elementos do sistema para uso interno. Nesses casos, a cooperação entre as três partes deixa de ser apenas uma questão de organização do projeto e passa também para o domínio das obrigações legais da empresa, incluindo o contexto da certificação CE de máquinas.

O que ter em atenção na implementação

A maioria dos problemas não surge quando a equipa não tem competências, mas quando as partes do projeto trabalham corretamente dentro dos seus próprios limites e, ainda assim, ninguém gere a zona de contacto entre elas. Num projeto em que o integrador é responsável pela camada de execução e pelas ligações à automação industrial, o software house pela lógica aplicacional e a manutenção pela continuidade de funcionamento da fábrica, uma organização deficiente da implementação acaba quase sempre por transferir o risco para a fase de arranque. É precisamente aí que se torna claro se as decisões de projeto foram tomadas a pensar em todo o ciclo de vida da solução ou apenas no fecho do âmbito por cada um dos executantes. Para o projeto, isso significa normalmente uma de três coisas: correções dispendiosas após a entrada em funcionamento, disputa sobre a responsabilidade por falhas ou atraso na aceitação, porque o sistema funciona apenas em condições de laboratório e não no processo real.

A armadilha principal está no facto de a implementação ser muitas vezes tratada como uma fase técnica, quando, na prática, é o momento em que se verificam decisões organizacionais. Se o integrador pode introduzir alterações no controlo sem conhecer plenamente os efeitos do lado da aplicação, se o software house desenvolve funções sem confirmação das limitações dos equipamentos e da rede industrial, e se a manutenção só é envolvida na fase de aceitação, então o problema não está na comunicação, mas numa divisão defeituosa de responsabilidades. O critério prático de avaliação é simples: antes de entrar em obra, cada parte deve ser capaz de indicar que alterações pode executar de forma autónoma, quais exigem autorização conjunta e quem toma a decisão de interromper os trabalhos se surgir risco para o processo, para a segurança ou para a reprodutibilidade da configuração. Se a resposta depender de “acordos feitos no momento”, a implementação ainda não está preparada, mesmo que o cronograma esteja formalmente correto. Nestas situações, a gestão de projetos torna-se decisiva.

Um exemplo típico diz respeito a uma modificação aparentemente pequena: a alteração da sequência de trabalho de um posto que, do ponto de vista do software house, é uma correção de lógica, para o integrador significa tempos de resposta diferentes dos equipamentos e, para a manutenção, afeta o diagnóstico e os procedimentos após avaria. Se uma alteração deste tipo chega ao local sem uma revisão conjunta dos seus efeitos, depois da entrada em funcionamento torna-se difícil determinar se a origem do problema está no código, na configuração do controlador, nos parâmetros do acionamento ou na forma de operação pelo operador. Nessa altura, o custo aumenta não apenas por causa da própria correção, mas também devido ao tempo de paragem, aos testes adicionais e ao envolvimento de pessoas que antes não precisavam de participar na análise. Por isso, vale a pena medir não só o prazo de arranque, mas também o número de alterações de implementação sem circuito completo de aprovação, o tempo necessário para repor a versão anterior e a proporção de falhas detetadas apenas depois da entrega do sistema para exploração. Isso dá uma imagem real de saber se a cooperação entre as três partes é efetivamente gerida ou apenas mantida de forma pontual.

Nesta fase, surge naturalmente também a fronteira entre uma implementação convencional e uma situação em que a fábrica passa a co-desenvolver a solução de forma a influenciar as suas obrigações formais. Se a equipa de manutenção não se limita a dar pareceres, mas modifica ela própria a lógica, seleciona componentes do sistema ou assume parte das decisões de conceção, então o tema deixa de dizer respeito apenas à organização da cooperação e passa também para o domínio das máquinas fabricadas para uso próprio. Isto não pode ser decidido com uma única regra aplicável a todos os projetos; o que conta é o âmbito da intervenção, o grau de autonomia da fábrica e quem, na prática, define as características da solução. O mesmo se aplica à análise de risco: se a alteração afeta a função do processo, o comportamento do operador, as condições de intervenção de assistência técnica ou a sequência dos estados de emergência, então já não se trata apenas de “implementar ou não”, mas também de “reavaliar o risco e atualizar os pressupostos de aceitação”. Na prática, é precisamente aqui que mais se evidencia o papel de quem conduz o projeto: não como mero intermediário de estados, mas como responsável pela decisão sobre o momento em que termina a simplificação conveniente e começa a responsabilidade técnica e jurídica.