Implantação de sistema ERP: como a perícia verifica se o projeto foi realmente concluído?

O que significa implantar um sistema?

A implantação de um ERP ou de outro sistema corporativo normalmente envolve um conjunto de etapas técnicas e operacionais. A simples disponibilização do programa em um servidor ou computador não demonstra, isoladamente, que o projeto contratado foi concluído.

Dependendo do escopo, a implantação pode envolver levantamento de requisitos, parametrizações, customizações, migração de dados, integrações, criação de usuários, testes, treinamento, homologação, entrada em produção e acompanhamento posterior.

Por isso, uma perícia precisa partir do escopo efetivamente contratado e confrontá-lo com aquilo que pode ser tecnicamente comprovado.

Como saber se a implantação foi efetivamente concluída?

A resposta não depende de uma única tela ou documento. A análise busca elementos convergentes que demonstrem quais etapas foram executadas e em que estado o projeto se encontrava.

Por exemplo, um sistema pode estar instalado e possuir usuários cadastrados, mas ainda não ter dados migrados, integrações concluídas ou funcionalidades homologadas. Em outro cenário, o sistema pode ter entrado em produção parcialmente, enquanto determinados módulos permaneceram pendentes.

O objetivo é reconstruir tecnicamente a situação encontrada e separar entrega parcial, implantação incompleta, operação efetiva e conclusão do escopo contratado.

Instalação, implantação, homologação e operação são coisas diferentes

Esses conceitos costumam aparecer misturados em controvérsias contratuais, mas representam momentos distintos do projeto.

• Instalação: disponibilização técnica do software em determinado ambiente.
• Parametrização: configuração do sistema conforme regras e necessidades do negócio.
• Migração e integração: transferência de dados e comunicação com outros sistemas.
• Testes e homologação: verificação das funcionalidades e aceitação das entregas previstas.
• Entrada em produção: utilização efetiva do sistema nas rotinas da organização.

Uma perícia bem delimitada identifica quais dessas etapas estavam previstas no contrato e quais possuem evidências de execução.

Quais evidências podem ser analisadas?

A depender do caso, diferentes fontes documentais e digitais podem ser correlacionadas:

• contratos, propostas comerciais e documentos de escopo;
• cronogramas, atas de reunião e planos de projeto;
• e-mails e comunicações entre fornecedor e contratante;
• chamados técnicos e tickets de suporte;
• bancos de dados e registros de migração;
• parametrizações, configurações e customizações existentes;
• usuários, perfis de acesso e registros de utilização;
• logs de sistema, integrações e eventos operacionais;
• registros de testes, aceite e homologação;
• evidências de treinamento e entrada em produção.

O valor probatório não está apenas na existência isolada desses documentos, mas na coerência entre eles e na capacidade de reconstruir o desenvolvimento do projeto.

E se o projeto não tiver sido concluído?

Constatar que a implantação não alcançou todas as etapas contratadas é apenas parte da análise. Em muitos processos, também é necessário identificar quais acontecimentos técnicos contribuíram para que o projeto não avançasse.

Os fatores podem estar relacionados ao fornecedor, à contratante ou a dependências compartilhadas. Alguns exemplos incluem funcionalidades não entregues, parametrizações pendentes, problemas de integração, dados não disponibilizados, atrasos em validações, alterações sucessivas de escopo, requisitos insuficientemente definidos ou ausência de infraestrutura necessária.

A perícia determina quem é o culpado?

Não é adequado transformar o trabalho pericial em julgamento de culpa ou responsabilidade jurídica. A função técnica é identificar fatos verificáveis: o que estava previsto, o que foi executado, o que permaneceu pendente, quais dependências existiam e quais eventos são compatíveis com o resultado observado.

Essa separação é importante porque o Código de Processo Civil determina que o perito permaneça dentro dos limites do objeto técnico e apresente método, fundamentação e respostas aos quesitos, sem extrapolar para opiniões pessoais alheias ao exame científico ou técnico.

A valoração jurídica desses fatos — inclusive eventual responsabilidade contratual — cabe ao Juízo.

Por que a linha do tempo é importante?

Projetos de implantação costumam gerar grande volume de informações: e-mails, chamados, atas, entregas, testes, reuniões e alterações. Analisar cada documento isoladamente pode ocultar a sequência real dos acontecimentos.

Uma linha do tempo pode organizar eventos como contratação, levantamento de requisitos, parametrização, migração, testes, homologação, entrada em produção, surgimento de pendências e eventual rescisão. Quando esses marcos são associados às evidências correspondentes, torna-se mais fácil identificar em qual etapa o projeto avançou, foi interrompido ou passou a apresentar divergências.

Como isso pode ajudar em um processo judicial?

Em uma perícia judicial, a análise pode auxiliar na resposta a questões como:

• o sistema foi efetivamente instalado?
• as parametrizações previstas foram realizadas?
• houve migração de dados e integração com outros sistemas?
• as funcionalidades contratadas estavam disponíveis?
• existem evidências de testes, homologação e uso em produção?
• quais etapas permaneceram pendentes?
• quais problemas foram comunicados e quando ocorreram?
• quais fatores técnicos contribuíram para o resultado observado?

Na assistência técnica, o mesmo conjunto de informações pode ser utilizado para formular quesitos, identificar documentos relevantes, acompanhar diligências, revisar criticamente o laudo e elaborar parecer técnico.