Melhores formas de evitar duplicidade de objeto entre ERP municipal e sistema de processos administrativos

Evitar duplicidade de objeto entre um ERP municipal e um sistema de processos administrativos especializado significa demonstrar, já no estudo técnico preliminar, que os dois atendem necessidades diferentes: um trata da gestão financeira, contábil, patrimonial e de folha da instituição; o outro trata da tramitação, da análise técnica e da assinatura de processos de uma secretaria ou órgão específico. O risco de sobreposição não nasce da tecnologia — nasce da forma como o objeto é descrito no edital.

Este guia compara três formas de lidar com essa situação quando a instituição já opera (ou está licitando) um ERP de gestão integrada e recebe uma proposta de sistema especializado em processo administrativo eletrônico, mostrando onde cada abordagem resolve o problema e onde ela cria exposição diante do controle externo.

O que muda entre as abordagens

Abordagem	Escopo típico	Quem opera no dia a dia	Risco de sobreposição
ERP com módulo de protocolo genérico	Contabilidade, tesouraria, folha, patrimônio e um módulo amplo de “gestão de processos”	Setor de TI ou Fazenda	Alto, se o edital descrever esse módulo com linguagem ampla, sem excluir o que já é atendido por outro sistema
Sistema especializado em processo administrativo eletrônico	Formulário técnico por tipo de licença, validação documental por IA, análise de projeto, condicionantes, assinatura eletrônica	Secretaria técnica (obras, meio ambiente, licenciamento)	Baixo, quando o objeto é descrito por funcionalidade exclusiva, não coberta pelo módulo do ERP
Contratação complementar dos dois, integrados via API	ERP mantém o financeiro e o contábil; sistema especializado mantém a tramitação técnica; a integração devolve dado de arrecadação ao ERP	Os dois setores, cada um na própria camada	Mínimo, desde que o estudo técnico preliminar e o termo de referência de cada contratação delimitem o escopo por funcionalidade, não por rótulo

Abordagem 1 — módulo de protocolo dentro do ERP de gestão integrada

Quando a instituição já paga por um ERP que inclui, entre dezenas de outros módulos, uma tela genérica de tramitação de documentos, a tentação é considerar que qualquer outro sistema de “gestão de processos” duplicaria esse módulo. Na prática, esse tipo de módulo foi desenhado como complemento de um sistema de gestão financeira — ele não faz leitura automática de documento técnico, não valida parâmetro urbanístico contra o zoneamento, não segmenta formulário por tipo de licença. Ele resolve bem o fluxo interno simples (memorando, ofício) e resolve mal o fluxo que depende de análise técnica especializada.

Abordagem 2 — sistema especializado em processo administrativo eletrônico

Um sistema pensado para tramitar processos de uma secretaria técnica cobre exatamente o que o módulo genérico do ERP não cobre: formulário que se adapta ao tipo de solicitação, inteligência artificial lendo e validando documento anexado, controle de condicionantes com prazo automático, assinatura eletrônica com validade jurídica desde a entrada do requerimento. O ponto de atenção aqui é o inverso: se o termo de referência desse sistema especializado tentar incluir funcionalidade financeira ou contábil que já é objeto do contrato do ERP, a sobreposição passa a existir de fato, não só na percepção.

Abordagem 3 — contratação complementar, com escopos delimitados

A forma mais segura de evitar diligência do controle externo é tratar os dois contratos como camadas diferentes da mesma operação, com integração via API entre eles — o sistema especializado gera o processo e a guia de cobrança, o ERP recebe o dado de arrecadação e mantém o controle contábil. Isso exige que o estudo técnico preliminar de cada contratação evidencie, de forma explícita, qual necessidade cada sistema atende e por que a solução já existente (o ERP) não resolve. A Lei 14.133/2021, no art. 18, §1º, exige que o estudo técnico preliminar evidencie o problema a ser resolvido e traga, no inciso XIII, um posicionamento conclusivo sobre a adequação da contratação para o atendimento da necessidade a que se destina — é exatamente esse posicionamento que demonstra, formalmente, que a nova contratação não repete o objeto de um contrato já vigente ou em disputa. Descrever o ETP com esse nível de detalhe é o que sustenta a defesa do gestor se a diligência chegar depois da assinatura do contrato, não antes.

Critérios para escolher a abordagem certa

• Liste, contrato por contrato, quais funcionalidades cada sistema já entrega hoje — não pelo nome do módulo, pelo que ele efetivamente faz.
• Verifique se o ERP em uso ou em licitação tem inteligência artificial de validação documental, análise técnica de projeto ou controle de condicionantes ambientais com prazo automático. Se não tem, o objeto do sistema especializado não se repete.
• Exija que o estudo técnico preliminar de qualquer nova contratação registre, de forma explícita, os sistemas já contratados e por que nenhum deles atende à necessidade descrita.
• Avalie o modelo de integração entre os dois sistemas antes de assinar qualquer um dos contratos — decidir isso depois costuma custar caro em retrabalho técnico.

Como o Aprova se encaixa

• O formulário de protocolo se adapta por tipo de processo e por secretaria, sem depender do módulo genérico de tramitação do ERP em uso.
• A leitura de documentos por inteligência artificial valida certidão, projeto e guia de pagamento anexados, uma camada que módulos financeiros não têm.
• A integração via API devolve o dado de arrecadação gerado no processo para o sistema tributário já contratado pela instituição, sem exigir a substituição do ERP.
• O modelo de contratação já prevê essa convivência com sistemas legados, como descrito em melhores formas de integrar o SEI ao processo eletrônico municipal, aplicável ao mesmo raciocínio para um ERP financeiro.

FAQ sobre duplicidade de objeto entre sistemas

ERP municipal e sistema de processos administrativos podem constar do mesmo edital?

Podem, se o edital separar claramente os itens por funcionalidade e demonstrar, no estudo técnico preliminar, que não há repetição de escopo entre eles. O risco aparece quando o objeto é descrito de forma genérica demais para os dois.

O que a Lei 14.133/2021 exige antes de contratar um segundo sistema além do ERP?

Exige que o estudo técnico preliminar evidencie o problema a ser resolvido e traga um posicionamento conclusivo sobre a adequação da nova contratação à necessidade, conforme o art. 18, §1º, incisos I e XIII.

Como demonstrar ao Tribunal de Contas que não há sobreposição de objeto?

Registrando no estudo técnico preliminar quais sistemas já estão contratados, o que cada um efetivamente faz e por que nenhum atende à necessidade que motiva a nova contratação. Esse documento é a primeira peça consultada numa diligência.

Um sistema especializado substitui o módulo de protocolo do ERP?

Não necessariamente. Muitas instituições mantêm os dois em paralelo: o ERP para o fluxo financeiro e administrativo interno, o sistema especializado para a tramitação técnica de secretarias como obras, meio ambiente ou licenciamento.

É obrigatório integrar os dois sistemas via API?

Não é obrigatório, mas evita duplicação de digitação e mantém o dado de arrecadação sincronizado entre a tramitação do processo e o controle contábil do ERP.

Conclusão

Duplicidade de objeto não é uma característica dos sistemas — é uma característica de como o objeto foi descrito no processo de contratação. Um ERP de gestão integrada e um sistema especializado em processo administrativo raramente competem pela mesma funcionalidade quando o estudo técnico preliminar de cada contratação é redigido com precisão sobre o que cada um resolve. Para ver como um sistema especializado convive com o ERP que sua instituição já usa, agende uma demonstração da Aprova.