A proposta de um fornecedor pode vir acompanhada de uma pasta com certificados, relatórios de testes e uma apresentação de projetos anteriores, mas nada disso responde à questão que realmente importa: essas evidências se aplicam ao sistema objeto da cotação? A análise das evidências não se resume ao volume de documentos apresentados, mas sim à verificação de se cada documento se relaciona com essa entidade jurídica, essa configuração e uma condição de projeto comparável à que está sendo planejada. Essa relação deve ser verificada cuidadosamente, pois um documento pode ser autêntico e, mesmo assim, não ser aplicável.
O que cada tipo de prova pode e não pode comprovar
Certificados, relatórios de teste e projetos de referência respondem a questões diferentes, e tratá-los como provas intercambiáveis de prontidão gera lacunas que vêm à tona posteriormente no projeto. Um certificado atesta que um órgão ou entidade emitiu um parecer sobre uma entidade, produto ou local específico sob condições definidas; ele não descreve o desempenho de uma unidade específica e não confirma que o escopo certificado abranja a configuração que está sendo oferecida. Um relatório de teste descreve o que ocorreu quando uma configuração específica foi testada de acordo com um método estabelecido; ele não comprova que a unidade testada seja semelhante ao que o projeto receberá, a menos que a correspondência da configuração seja confirmada. Um projeto de referência descreve o que um fornecedor entregou em outro local; ele não comprova que a mesma estrutura de riscos, limites e responsabilidades se aplique ao projeto em análise.
Quando um comprador precisa de comprovação de capacidade geral, um certificado pode servir a esse propósito dentro do escopo declarado. Quando um comprador precisa de comprovação de desempenho para a configuração oferecida, um relatório de teste referente a essa configuração atende ao objetivo de forma mais direta. Quando um comprador precisa avaliar se a experiência de um fornecedor é aplicável a um novo projeto, um projeto de referência fornece evidências mais relevantes para a decisão real de compra do que um certificado, desde que o contexto operacional e os limites sejam descritos com detalhes suficientes para permitir a comparação.
O fator que altera essa avaliação é o grau de especificidade ou abrangência com que o escopo declarado no documento está redigido. Um certificado cujo escopo se limita a uma empresa geralmente não se estende a uma linha específica de produtos, e um relatório de teste cujo escopo se limita a uma configuração não se estende a uma variante, a menos que o relatório ou o fornecedor confirme que a variante foi coberta. Os revisores que aceitam um documento simplesmente por ele existir, sem ler o que ele realmente afirma, transferem essa lacuna para o projeto. EudraLex Volume 4 Anexo 15 apoia a prática de revisar a documentação do fornecedor em relação a critérios de aceitação predefinidos e documentar os desvios, em vez de aceitar as declarações do fornecedor como completas no momento da apresentação; essa lógica de revisão se aplica à forma como uma equipe de projeto deve tratar qualquer um dos três tipos de evidência antes de se basear neles.
Verificações de certificados quanto ao emissor, à entidade, ao escopo e à validade
Um certificado é uma declaração emitida por um órgão específico sobre uma entidade, um produto ou um local específico, válida sob condições específicas, e cada um desses elementos pode divergir do que o comprador supõe, sem que o próprio certificado seja falso. A lacuna mais comum na análise comercial é entre a entidade detentora do certificado e a entidade que o apresenta na proposta: um certificado emitido para uma empresa controladora, uma unidade fabril ou uma entidade jurídica diferente dentro da mesma estrutura corporativa não se estende automaticamente à entidade que assumirá a responsabilidade contratual pelo projeto.
A mesma lógica se aplica ao escopo. Um certificado pode ser preciso e atual, abrangendo uma classe de equipamentos, um sistema de gestão ou uma instalação, sem, no entanto, abranger a configuração específica do sistema proposta para o projeto. Quando o escopo do certificado menciona uma família de produtos em termos gerais, a tarefa do comprador é confirmar se o sistema proposto se enquadra nessa família, conforme testado ou avaliado, e não presumir a pertença à família apenas com base no nome do produto. As datas de validade apresentam uma condição semelhante: um certificado válido no momento do encerramento da licitação pode expirar antes da entrega ou dos testes de aceitação, e um projeto com um longo prazo de entrega precisa acompanhar se o certificado permanece válido ao longo das etapas em que é utilizado como referência.
| Verificação de certificado | Com o que combinar | Limite de decisão |
|---|---|---|
| Pessoa jurídica | A entidade indicada no certificado e a entidade que o apresenta | Uma incompatibilidade de entidade permanece sem solução até que seja esclarecida |
| Órgão emissor | O órgão emissor identificado no certificado | Confirme o emissor antes de considerar o certificado como prova |
| Número do certificado | O número do certificado indicado no documento | Use o número para rastrear o certificado que está sendo analisado |
| Escopo | O escopo declarado do certificado e o sistema proposto | Um certificado apenas no nível da empresa não é suficiente para validar o sistema proposto |
| Produto ou site | O produto ou local aplicável mencionado no certificado | Confirme se o certificado se aplica ao produto ou local proposto |
| Data de validade | A data de validade indicada no certificado | Verifique a validade antes de confiar no certificado |
Caso qualquer um dos seguintes elementos — emissor, entidade, escopo, produto, local ou data de validade — não corresponda ao declarado na proposta, o certificado não é considerado inválido de imediato, mas deixa de funcionar como prova autônoma e passa a ser um ponto que requer esclarecimento antes de poder servir de base para o registro do projeto.
Verificações do relatório de teste relativas à configuração, método, calibração, resultados e aprovação
Um relatório de teste só é útil na medida em que consiga demonstrar que um resultado declarado decorreu de um teste definido, realizado em uma configuração definida, utilizando instrumentos rastreáveis. Uma declaração de aprovação sem esses elementos de apoio indica ao leitor que algo foi aprovado, sem identificar o que foi testado ou como o resultado foi obtido. A correspondência da configuração é a primeira condição a ser confirmada: quando um fornecedor apresenta um relatório referente a um projeto anterior ou a uma revisão anterior do produto, o comprador precisa saber se as diferenças entre essa configuração e a que está sendo oferecida são relevantes para o resultado citado, pois um relatório referente a uma configuração diferente não valida os resultados para a oferta atual.
O método de teste e a instrumentação estão sujeitos a uma condição relacionada. Um método não especificado significa que o leitor não pode avaliar se a abordagem do teste corresponde ao que o projeto exigirá, e registros de calibração omitidos significam que as medições relatadas carecem de uma base rastreável. Os critérios de aceitação funcionam como o padrão em relação ao qual o resultado é avaliado; um relatório que apresente um resultado sem indicar os critérios utilizados para avaliá-lo obriga o leitor a aceitar a conclusão do fornecedor, em vez de verificá-la de forma independente.
As observações brutas e os desvios documentados alteram o peso que um resultado resumido pode ter. Um relatório elaborado inteiramente com base em uma declaração de aprovação resumida, sem as observações subjacentes, não permite que o leitor verifique se os resultados marginais foram arredondados de forma favorável ou se ocorreu um desvio que foi resolvido antes da aprovação. Quando um desvio é documentado, mas sua resolução não é, o desvio permanece em aberto e requer revisão antes que o relatório possa servir de base para a aceitação do projeto. A aprovação encerra a cadeia de custódia do relatório, confirmando quem revisou e aprovou o resultado declarado; um relatório sem aprovação não concluiu seu próprio processo interno, independentemente do que o corpo do relatório afirme.
| Verificação do relatório de teste | O que verificar | Limite de decisão |
|---|---|---|
| Configuração oferecida | A configuração testada corresponde à configuração oferecida | Um relatório referente a uma configuração diferente não apresenta resultados para a oferta |
| Método de ensaio | O método de ensaio é identificado | Uma instrução `pass` sem o método não mostra como o resultado foi obtido |
| Instrumentos e calibração | Os instrumentos e sua calibração estão documentados | A falta de um instrumento ou de detalhes de calibração limita a rastreabilidade da medição |
| Critérios de aceitação | Os critérios de aceitação estão definidos | Avalie os resultados com base nos critérios estabelecidos, em vez de se basear apenas na indicação de “aprovado” |
| Observações brutas | As observações brutas corroboram o resultado relatado | Não confie apenas em uma declaração resumida de aprovação |
| Desvios | Quaisquer desvios são documentados | Os desvios não resolvidos devem ser analisados antes da aceitação |
| Aprovação | O relatório inclui a aprovação | Verifique a aprovação antes de considerar o relatório como prova completa |
Essas verificações são mais importantes na fase de revisão que antecede os testes de aceitação, quando a equipe do projeto decide se as evidências geradas anteriormente podem substituir ou reduzir o escopo dos testes planejados para a unidade específica que está sendo entregue; a abordagem de revisão descrita em [Quais documentos de validação um fornecedor de equipamentos de contenção deve apresentar antes dos testes FAT e SAT?] aborda essa mesma questão relativa aos limites das evidências do ponto de vista do fornecedor.
Verificações em projetos de referência quanto a riscos, limites e escopo de fornecedores comparáveis
Um projeto de referência é uma prova de experiência, não uma prova de desempenho para a compra atual, e a diferença entre essas duas coisas depende do grau de semelhança entre o projeto citado e aquele que está sendo planejado. A comparabilidade dos riscos é o primeiro filtro: a experiência de um fornecedor com uma classe de risco não se transfere diretamente para uma classe de risco diferente, pois as pressões de projeto e de teste variam de acordo com o que o equipamento está protegendo e contra o que ele está protegendo. Quando o objetivo principal do projeto citado difere do objetivo principal do projeto atual, a referência reflete a experiência geral de entrega, e não a adequação à meta específica de proteção em questão.
A comparabilidade dos limites do equipamento determina se a referência descreve o mesmo escopo de responsabilidade física e funcional que está sendo proposto atualmente. Um projeto de referência em que o fornecedor entregou uma parte delimitada de um equipamento dentro de um sistema maior construído por terceiros descreve uma função do fornecedor mais restrita do que aquela em que o mesmo fornecedor assumiu a responsabilidade pelas interfaces, integração ou aceitação em um escopo mais amplo. Se a proposta atual atribuir ao fornecedor um escopo mais amplo ou mais restrito do que o da referência citada, a referência não confirma a capacidade do fornecedor de atuar no escopo agora proposto.
O escopo do teste e o contexto operacional acrescentam condições adicionais. Um projeto de referência testado em condições semelhantes ao ambiente operacional planejado tem maior relevância do que um testado em condições diferentes; e uma referência em que a responsabilidade contratual do fornecedor correspondia ao que é proposto atualmente tem maior relevância do que uma em que a responsabilidade foi dividida de maneira diferente entre várias partes. Quando uma equipe de projeto não consegue determinar o escopo do teste, o contexto operacional ou a responsabilidade do fornecedor com base no que foi fornecido, a referência funciona como uma alegação de experiência, e não como evidência comparável.
| Ponto de comparação | Pergunta a ser feita |
|---|---|
| Risco | A referência envolve um risco comparável ao da compra planejada? |
| Limite do equipamento | Os limites do equipamento de referência são comparáveis aos da compra planejada? |
| Escopo do teste | O projeto citado inclui um escopo de teste comparável? |
| Contexto operacional | O contexto operacional corresponde ao uso previsto? |
| Responsabilidade do fornecedor | A responsabilidade do fornecedor é comparável àquela que está sendo proposta? |
| Detalhes da evidência | A referência fornece detalhes suficientes, além de logotipos ou número de projetos, para avaliar a adequação? |
Logotipos e o número de projetos refletem o alcance, não a adequação. Uma lista de clientes anteriores ou o número de instalações concluídas não indica à equipe de avaliação se algum desses projetos se assemelhava à estrutura de riscos, limites e responsabilidades do projeto que está sendo planejado; solicitar esses detalhes sobre um número menor de referências genuinamente comparáveis gera evidências mais úteis do que pedir uma lista mais extensa.
Medidas de esclarecimento para provas ausentes, incompatíveis ou não verificáveis
Quando um certificado, relatório de teste ou projeto de referência não atende a uma das verificações acima, a equipe do projeto precisa decidir o que fazer em relação à lacuna, e não se ela realmente existe. As ações disponíveis geralmente se enquadram em três categorias: solicitar o reenvio de evidências corrigidas ou completas, exigir que um teste ou inspeção seja testemunhado de forma independente ou exigir que o teste seja repetido em condições que a equipe do projeto possa verificar diretamente.
A ação adequada depende do tipo de discrepância identificada. Um certificado com nome de entidade incorreto pode ser resolvido por meio de reenvio, no qual o fornecedor pode apresentar o certificado equivalente emitido para a entidade correta ou esclarecer como a entidade mencionada se relaciona com aquela que está apresentando a proposta. Um relatório de teste sem registros de calibração ou observações brutas também pode ser resolvido por meio de um novo envio, caso os registros subjacentes existam e simplesmente não tenham sido incluídos. Quando a lacuna diz respeito à correspondência entre uma configuração testada e a configuração oferecida, o simples reenvio não resolve o problema se as configurações testada e oferecida forem realmente diferentes; nesse caso, a equipe do projeto precisa de um novo relatório para a configuração correta ou de uma decisão para incluir testes específicos para essa configuração no próprio plano de verificação do projeto.
A presença de uma testemunha torna-se relevante quando a preocupação não é a existência de um resultado, mas a confiança na forma como ele foi gerado. Uma equipe de projeto que não tenha certeza se as práticas de teste internas de um fornecedor correspondem ao que o projeto exige pode solicitar que um teste repetido ou futuro inclua uma testemunha independente, em vez de repetir todo o escopo do teste. A repetição do teste torna-se necessária quando não há resultados anteriores para a configuração correta, quando desvios não foram resolvidos ou quando a comparabilidade de riscos ou limites das evidências anteriores não pode ser estabelecida de forma suficientemente clara para substituir o teste direto.
Cada discrepância não resolvida identificada durante a revisão das evidências deve ser registrada como um pedido de esclarecimento, indicando especificamente qual verificação falhou, quais evidências resolveriam a questão e se essas evidências devem ser reenviadas, autenticadas ou repetidas antes que o projeto possa considerá-las válidas. Deixar uma discrepância sem registro, mesmo quando a equipe do projeto pretende abordá-la verbalmente, elimina a rastreabilidade da qual as etapas posteriores do projeto dependem para confirmar que os itens em aberto foram encerrados antes da aceitação. A abordagem comparativa descrita em [Como comparar fornecedores de equipamentos de alta contenção com base na qualidade da resposta da URS e no escopo das evidências] considera essa mesma disciplina de esclarecimento como parte do processo de avaliação das respostas dos fornecedores durante a seleção, e não apenas durante a aceitação final.
Limites de aceitação antes que as evidências do fornecedor sejam incluídas no registro do projeto
Decidir quando uma evidência é suficientemente válida para ser incluída no registro do projeto é uma avaliação distinta de decidir se a evidência existe. Um certificado, relatório de teste ou projeto de referência pode ser genuíno, atual e descrito com precisão, mas ainda assim não atender aos requisitos do registro do projeto se seu escopo não corresponder à entidade, configuração ou às condições de risco e limites da compra que está sendo realizada. O limite de aceitação não é um único critério aplicado de maneira uniforme; ele depende de qual verificação o documento estava sendo utilizado para atender e quais são as consequências decorrentes de se basear nele.
Quando um certificado é utilizado para comprovar que um fornecedor opera sob um sistema reconhecido de qualidade ou gestão, um escopo no nível da empresa pode ser suficiente para essa finalidade limitada, mesmo que o mesmo certificado não seja suficiente para comprovar que um sistema específico proposto atenda a um requisito de desempenho. Quando um relatório de teste é utilizado para reduzir ou substituir os testes planejados durante as próprias etapas de verificação do projeto, o limite de aceitação é mais restrito, pois o registro do projeto se baseia nesse relatório como se ele tivesse sido gerado sob a supervisão do próprio projeto; uma incompatibilidade de configuração, um desvio não documentado ou uma aprovação ausente, cada um desses fatores, por si só, impede que o relatório tenha esse peso até que seja resolvido. Quando um projeto de referência é utilizado para fundamentar uma decisão de seleção de fornecedor, em vez de substituir testes diretos, o limite de aceitação pode tolerar mais informações parciais, desde que as lacunas sejam reconhecidas, em vez de tratadas como resolvidas.
A condição que altera esses limites é o que as evidências representam. As evidências utilizadas para descrever a capacidade geral do fornecedor podem ter um escopo mais amplo do que aquelas usadas para atender a um requisito específico de verificação. Quando as informações do projeto são enviadas para uma revisão de configuração ou cotação no QUALIA, a mesma distinção se aplica: certificados gerais e materiais de referência apoiam uma avaliação inicial de adequação, enquanto as evidências de teste específicas da configuração se tornam relevantes assim que o escopo do projeto em revisão se restringe a um sistema específico proposto. Uma equipe de projeto que mantenha essa distinção explícita evita tanto a dependência excessiva de documentos gerais quanto a subutilização deles para os fins a que se destinam legitimamente. A conversão do objetivo de proteção de um projeto em critérios de aceitação contra os quais o fornecedor pode ser avaliado, conforme descrito em [Como converter os requisitos dos projetos BSL e OEB em critérios de aceitação que possam ser verificados pelos fornecedores], oferece à equipe do projeto um padrão definido pelo qual cada elemento de evidência apresentado pode ser avaliado, em vez de ser julgado caso a caso.
Perguntas frequentes
Q: O que devemos preparar antes de analisar as evidências dos fornecedores?
A: Elabore uma lista de rastreabilidade que relacione a configuração proposta, o risco, o escopo do equipamento, o escopo do teste e os critérios de aceitação ao documento esperado para cada item. Isso permite identificar evidências ausentes ou incompatíveis antes que sejam consideradas como comprovação do projeto.
Q: Um certificado em nível da empresa é suficiente para validar o sistema de contenção proposto?
A: Não. Verifique se a pessoa jurídica, o órgão emissor, o número do certificado, o escopo, o produto ou local especificado e a data de validade correspondem à oferta; qualquer discrepância deve ser tratada como um esclarecimento da proposta até que seja resolvida.
Q: Como devemos lidar com um relatório de teste de uma configuração que é semelhante, mas não idêntica, à proposta?
A: Não presuma que o resultado seja aplicável à configuração oferecida. Registre as diferenças, confirme o método de teste, os instrumentos e sua calibração, os critérios de aceitação, as observações brutas, os desvios e a aprovação; em seguida, especifique se as evidências devem ser reapresentadas, atestadas por testemunhas ou se os testes devem ser repetidos antes da aceitação.
Q: E se um cliente de referência não puder autorizar a divulgação completa do projeto?
A: Considere a referência como uma evidência incompleta, e não como prova de adequação. Solicite detalhes que possam ser compartilhados sobre o risco, os limites do equipamento, o escopo do teste, o contexto operacional e a responsabilidade do fornecedor, e registre qualquer ponto de comparação que permaneça não verificável.
Q: É necessário preencher todas as lacunas probatórias na mesma fase?
A: Não. Separe as discrepâncias que impedem uma comparação justa entre as propostas das evidências que possam ser reapresentadas, atestadas ou repetidas antes da aceitação do projeto, e registre a ação necessária e o limite de aceitação para cada discrepância não resolvida.
