BPO e tecnologia: integração de sistemas

O BPO usa o sistema da empresa ou o próprio?

Há dois modelos principais de integração, e cada um tem implicações distintas para o controle do gestor: o BPO opera no sistema da empresa, com acesso concedido ao prestador; ou o BPO opera no sistema próprio e exporta dados periodicamente para a empresa. A escolha — ou a combinação — depende do escopo, do porte da empresa e do nível de controle que o gestor quer manter.

Modelo 1 — BPO acessa o sistema da empresa: o prestador recebe credenciais de acesso ao ERP, sistema financeiro ou plataforma de emissão de notas da contratante. O gestor mantém visibilidade direta — pode acompanhar os lançamentos em tempo real — e os dados ficam na estrutura da empresa. O risco é de segurança: o prestador acessa o sistema interno, e o controle de permissões precisa ser rigoroso. O prestador deve acessar apenas o módulo necessário para executar o escopo contratado, com usuário individual e log de ações rastreável.

Modelo 2 — BPO opera no sistema próprio e exporta dados: o prestador usa sua própria plataforma para executar o processo e entrega relatórios, arquivos ou exportações periódicas para a empresa. O risco é de visibilidade reduzida: o gestor recebe o resultado, mas não tem acesso ao processo em andamento. A dependência do formato e da periodicidade de entrega do prestador é mais alta — e o risco de lock-in dos dados aumenta ao encerrar o contrato.

O que definir sobre sistemas antes de assinar o contrato

A integração de sistemas é o ponto da contratação de BPO que mais gera problemas não discutidos previamente — e que mais frequentemente aparece como reclamação depois que o contrato já está em vigor. Cinco pontos precisam estar definidos antes da assinatura, não depois.

1. Qual sistema o BPO vai usar: o sistema da empresa, o sistema próprio do prestador, ou uma combinação. Essa definição determina onde os dados ficam armazenados e quem controla o acesso a eles.
2. Quais acessos o prestador recebe: definir por módulo, por usuário e por ação permitida — não dar acesso administrativo amplo quando o escopo é de um único processo. O princípio do mínimo necessário se aplica aqui tanto por segurança quanto por LGPD.
3. Como os dados transitam: o formato de troca de dados (arquivo CSV/XLSX, API, acesso direto), a frequência (diária, semanal, mensal) e quem é responsável por cada transferência precisam estar documentados, não apenas combinados verbalmente.
4. Onde os dados ficam armazenados e por quanto tempo: os dados da empresa armazenados na plataforma do prestador precisam de prazo de retenção definido e protocolo de descarte. Sem isso, a empresa perde controle sobre o ciclo de vida dos seus próprios dados.
5. O que acontece com os dados ao encerrar o contrato: cláusula de portabilidade é obrigatória — a empresa tem o direito de receber todos os dados em formato utilizável ao fim do contrato. Sem essa cláusula, o prestador pode reter os dados como mecanismo de lock-in, tornando a troca de prestador tecnicamente complexa e cara.

Quem é responsável pela integração de sistemas no BPO

A responsabilidade pela integração depende do modelo escolhido e do que foi acordado no contrato — mas o ponto de partida é que o gestor administrativo não pode ser o único responsável por uma decisão técnica que envolve sistemas, segurança e dados. Envolver a área de TI antes da assinatura não é burocracia — é evitar uma integração que nunca funciona de fato.

Como referência de mercado, os problemas mais relatados por gestores em contratações de BPO envolvem exatamente a integração: a promessa de que o BPO "se integra com qualquer ERP" que, na prática, se traduz em meses de tentativas e transferência de arquivos manual enquanto a integração "está em desenvolvimento". Definir no contrato quem executa a integração, em qual prazo e com quais recursos evita esse cenário.

O modelo de responsabilidade mais comum é: o prestador é responsável pela adequação do seu sistema ao formato de troca de dados da empresa; a TI da empresa é responsável pela concessão e revogação de acessos; o gestor administrativo é responsável por validar que os dados entregues correspondem ao que foi operado. Quando o prestador também é responsável pela integração com o ERP da empresa, o contrato deve especificar o prazo, o formato técnico e o que acontece se a integração não for concluída no prazo.

Segurança no compartilhamento de acesso ao sistema

Conceder acesso ao sistema interno para um terceiro é uma decisão que tem implicações de segurança, de rastreabilidade e de LGPD — e que precisa ser controlada durante todo o contrato, não apenas no momento da concessão. Três controles são inegociáveis independentemente do porte da empresa.

1. Acesso com usuário individual: cada colaborador do prestador que acessa o sistema da empresa deve ter um usuário próprio e identificado — não uma senha compartilhada entre a equipe do BPO. Usuário individual permite rastrear qual ação foi feita por quem e em qual momento.
2. Permissões restritas ao escopo: o prestador acessa apenas o módulo ou a funcionalidade necessária para executar o processo contratado. Acesso administrativo geral, acesso a outros módulos do ERP ou acesso a dados que não fazem parte do escopo são riscos desnecessários.
3. Revogação formal ao encerrar o contrato: ao término do contrato, todos os acessos concedidos ao prestador são revogados imediatamente e de forma documentada. Isso inclui usuários no sistema, senhas de e-mail de serviço, acessos a plataformas bancárias e qualquer outra credencial entregue durante o contrato.

O que fazer quando os sistemas não são compatíveis

Incompatibilidade entre o sistema da empresa e o sistema ou o formato de trabalho do BPO é situação mais comum do que o esperado — especialmente quando a empresa usa um ERP específico de setor ou uma versão mais antiga de um sistema. Quando identificada antes da assinatura do contrato, a incompatibilidade tem três caminhos possíveis.

O primeiro é renegociar o escopo: se a integração direta não é viável, acordar o protocolo de troca de arquivos que funcione para os dois lados — frequência, formato, responsável por cada etapa. Não é a solução ideal, mas é funcional quando o volume permite.

O segundo é usar um arquivo intermediário padronizado: a empresa exporta os dados do ERP em formato acordado (CSV, XLSX, OFX) e o BPO importa na sua plataforma. O risco é o retrabalho de formatação e o atraso que pode gerar — especialmente em processos com prazo apertado como fechamento fiscal.

O terceiro é avaliar outro prestador: se a integração é crítica para o escopo — como acontece em BPO financeiro com alto volume de transações — e o prestador não tem solução viável, buscar um prestador com experiência comprovada no ERP da empresa é mais eficiente do que uma integração improvisada que gera retrabalho por todo o contrato.