Implementação de ERP de Telecom: Integração BSS, OSS e Faturamento

A implementação do ERP de telecomunicações fica na interseção do gerenciamento de processos de negócios e da infraestrutura técnica de telecomunicações. Ao contrário da maioria dos setores onde a implementação de ERP envolve principalmente mudanças nos processos de negócios, a implementação de ERP em telecomunicações requer integração com sistemas de telecomunicações especializados – plataformas de provisionamento, sistemas de mediação, mecanismos de cobrança e sistemas de liquidação de interconexão – que possuem seus próprios padrões técnicos, modelos de dados e requisitos de desempenho em tempo real.

Este guia fornece uma estrutura de nível profissional para implementação de ERP de telecomunicações, com atenção específica à arquitetura de integração BSS/OSS, migração do sistema de faturamento e desafios de migração de dados de assinantes que distinguem as implementações de telecomunicações das comerciais.

Principais conclusões

• A arquitetura de integração BSS/OSS deve ser projetada antes do início da implementação — a avaliação da capacidade da API de sistemas legados determina a abordagem de integração
• A migração de faturamento é o componente de maior risco — um erro no sistema de faturamento afeta todos os assinantes simultaneamente
• A migração de dados de assinantes exige desduplicação extensiva e reconciliação de saldo de conta antes da transição
• A migração do inventário numérico deve incluir o histórico completo de portabilidade para conformidade com a portabilidade numérica
• A integração do provisionamento em tempo real deve ser testada em escala de produção antes da entrada em operação
• Os controles de garantia de receita devem ser validados com uma comparação completa do uso com a fatura antes da desativação do faturamento legado
• Os relatórios regulatórios (Formulário FCC 477, CPNI) devem ser validados no novo sistema antes do primeiro prazo regulatório
• A integração do mecanismo fiscal de telecomunicações deve ser testada para todos os tipos de serviços, jurisdições e tipos de clientes

---

Pré-Implementação: Avaliação da Arquitetura BSS/OSS

Antes de planejar a implementação do ERP, realize uma avaliação abrangente da arquitetura BSS/OSS existente. Esta avaliação determina quais sistemas serão substituídos pela funcionalidade do ERP, quais serão integrados ao ERP e quais permanecerão como sistemas separados.

Inventário do Sistema

Uma pilha típica de BSS/OSS de telecomunicações regionais inclui:

Avaliação de capacidade da API

A avaliação técnica mais importante é a capacidade da API de cada sistema legado. Sistemas com APIs REST bem documentadas suportam integração em tempo real. Sistemas com serviços web mais antigos ou APIs proprietárias requerem middleware. Sistemas sem capacidade de API exigem integração de arquivos em lote, introduzindo latência e complexidade.

Para sistemas de provisionamento (que devem ativar o serviço quase em tempo real), a qualidade da integração da API é crítica. Um sistema de provisionamento que requer integração de arquivos em lote não pode suportar a ativação de serviço no mesmo dia — uma desvantagem significativa na experiência do cliente.

---

Fase 1: Fundação de Finanças e RH (meses 1 a 4)

A implementação de finanças e RH ocorre de forma semelhante a outras implementações do setor, com configuração de plano de contas específico para telecomunicações.

Plano de contas de telecomunicações

O plano de contas de telecomunicações deve suportar o reconhecimento de receitas por tipo de serviço (voz, dados, vídeo, empresarial), por segmento de cliente (residencial, PME, empresarial, grossista) e por geografia. As receitas e despesas de interconexão devem ser acompanhadas separadamente das receitas de varejo. As taxas e impostos regulatórios devem ser rastreados por tipo para relatórios estaduais e da FCC.

Estrutura de Relatórios Regulatórios

Os requisitos de relatórios da FCC – incluindo o censo anual de implantação de banda larga do Formulário 477 e os dados trimestrais dos contribuintes do fundo de serviço universal do Formulário 499 – exigem dados específicos dos sistemas de cobrança e gerenciamento de clientes. O módulo financeiro deve ser configurado para capturar os elementos de dados necessários desde o primeiro dia, para que os relatórios regulatórios possam ser gerados a partir do ERP desde o primeiro período de relatório.

---

Fase 2: Catálogo de produtos e gerenciamento do plano de serviços (meses 3 a 7)

O catálogo de produtos é o elemento central de configuração que orienta o faturamento e o provisionamento. Cada serviço que pode ser solicitado – cada plano, cada complemento, cada opção de instalação de dispositivo – deve ser definido no catálogo de produtos antes que o faturamento ou o provisionamento possam funcionar corretamente.

Configuração do catálogo de produtos

A configuração do catálogo de produtos de telecomunicações é mais complexa do que a maioria dos setores devido à relação entre as definições de produto e os parâmetros de provisionamento de rede:

• Cada plano de serviço possui um conjunto de parâmetros de rede: nível de velocidade de dados, alocação de minutos de voz, permissão de SMS, permissões de roaming
• Quando um cliente ativa um plano, esses parâmetros devem ser transmitidos ao sistema de provisionamento
• Quando um cliente faz upgrade ou downgrade de seu plano, a alteração de provisionamento deve ser transmitida em tempo real

O catálogo de produtos ERP deve ser projetado com esses atributos de provisionamento incorporados em cada definição de produto. Quando o sistema de faturamento gera uma alteração no plano, os parâmetros de provisionamento associados são automaticamente incluídos na ordem de alteração transmitida ao sistema de provisionamento.

Promoção e gerenciamento de pacotes

As promoções de telecomunicações – descontos, preços de pacotes, ofertas de fidelidade – são frequentes e complexas. Uma operadora de celular pode realizar mais de 20 ofertas promocionais simultâneas a qualquer momento, cada uma com critérios de elegibilidade, duração e valor específicos. O catálogo de produtos deve suportar todas essas promoções sem exigir configuração de sistema de faturamento separado para cada uma delas.

---

Fase 3: Migração ou integração do sistema de faturamento (meses 5 a 12)

A migração do faturamento é o componente tecnicamente mais complexo e operacionalmente mais arriscado da implementação de ERP de telecomunicações. Um erro de faturamento que afeta todos os assinantes simultaneamente gera picos de volume de atendimento ao cliente, reclamações regulatórias e impacto na receita.

Substituir vs. Integrar Decisão

Para MVNOs e pequenas operadoras (menos de 100.000 assinantes), substituir o sistema de faturamento legado pelo faturamento nativo do ERP ou por uma plataforma de faturamento em nuvem integrada ao ERP normalmente é a decisão certa. O sistema de cobrança legado em pequenas operadoras costuma ser uma plataforma licenciada cara, com altos custos de suporte; substituí-lo por uma alternativa moderna gera economia de custos e maior capacidade.

Para grandes operadoras (mais de 500.000 assinantes), o sistema de faturamento legado normalmente possui uma lógica de classificação complexa que foi personalizada ao longo dos anos para lidar com produtos e promoções específicos da operadora. A substituição deste sistema requer a recriação de toda esta lógica na nova plataforma – uma tarefa de alto risco. Integração – manter o sistema de faturamento legado para classificação e usar o ERP para relatórios financeiros e gerenciamento de clientes – é a abordagem de menor risco.

Migração de dados de faturamento

A migração de dados de faturamento para transferência de assinantes requer:

1. Account balance migration: Every subscriber's current balance (charges accrued but not yet billed, credits applied, payments received) must migrate exactly. Um erro de saldo de $ 1 na conta de um assinante gera um contato de atendimento ao cliente.

2. Atribuição de ciclo de faturamento: Cada assinante tem um ciclo de faturamento mensal — o dia do calendário em que sua fatura é gerada. A migração deve preservar a atribuição do ciclo de fatura existente para evitar a geração de duas faturas em um mês ou a omissão de uma fatura para alguns assinantes.

3. Migração da forma de pagamento: Os assinantes do Autopay têm formas de pagamento (cartão de crédito, conta bancária) registradas. Esses tokens de pagamento devem ser migrados para o novo sistema de cobrança, normalmente por meio de uma transferência de tokenização com o processador de pagamentos.

4. Migração do histórico de cobrança: 24 meses de histórico de cobrança fornecem suporte suficiente para disputas de cobrança; históricos mais longos podem ser arquivados em vez de migrados.

Operação Paralela de Faturamento

O período de operação paralela de faturamento deve abranger pelo menos um ciclo de faturamento completo para cada data do ciclo de faturamento (normalmente exigindo um mês completo). Durante a operação paralela, tanto o sistema de faturamento legado quanto o novo sistema de faturamento ERP geram faturas de forma independente. Os resultados são comparados assinante por assinante para identificar discrepâncias.

Os limites de tolerância aceitáveis ​​devem ser definidos antes do início da operação paralela. Uma diferença de US$ 0,01 devido a arredondamentos é aceitável; uma diferença de US$ 10,00 requer investigação antes da entrada em operação.

---

Fase 4: Integração de provisionamento (meses 6 a 10)

A integração de provisionamento é uma integração de missão crítica em tempo real que deve funcionar corretamente antes que o ERP possa gerenciar eventos do ciclo de vida do assinante.

Provisionamento de integração de API

A integração de provisionamento deve lidar com todos os eventos do ciclo de vida do assinante:

• Ativação de novo assinante: Parâmetros do plano de serviço, atribuição de número de telefone, registro SIM
• Alteração de plano: dados atualizados e parâmetros de voz em tempo real
• Ativação de complemento: recursos adicionais (roaming internacional, dados premium) adicionados ao perfil do assinante
• Suspensão: Suspensão temporária por falta de pagamento — serviços de voz e dados deverão ser suspensos com chamadas de emergência preservadas
• Reativação: Restabelecimento do serviço completo quando o pagamento for recebido
• Rescisão: Desativação total de todos os serviços, retorno do número ao estoque

Cada um desses eventos deve ser testado no ambiente de teste do sistema de provisionamento antes da implantação em produção.

Provisionamento de tratamento de erros

Falhas de provisionamento — situações em que o comando de provisionamento é enviado à rede, mas não é executado — são uma ocorrência normal em operações de telecomunicações. O ERP deve lidar com falhas de provisionamento normalmente:

• Registrar a falha com o código de erro do sistema de provisionamento
• Gerar um alerta para a equipe de operações
• Tente novamente o comando de provisionamento automaticamente para falhas transitórias
• Escalar para intervenção manual para falhas persistentes

Sem o tratamento adequado de erros, as falhas de provisionamento resultam na cobrança de assinantes por serviços aos quais não podem acessar – um caminho rápido para escalonamentos de clientes e reclamações regulatórias.

---

Fase 5: Migração do inventário numérico (meses 4 a 8)

O gerenciamento de inventário de números de telefone – rastrear quais números estão atribuídos, quais estão disponíveis e o histórico de portabilidade de cada número – é um requisito exclusivo de telecomunicações.

Dados de inventário numérico

O módulo de inventário de números ERP deve manter:

• Todos os números do inventário da operadora, com status atual (disponível, atribuído, portabilidade, portabilidade, reservado, vencimento)
• O histórico de atribuição de assinantes para cada número
• Histórico de transações de portabilidade - sempre que um número foi portado para dentro ou para fora, a data, a operadora de obtenção e o ID da transação
• Designação geográfica (o centro da taxa e o estado associado a cada número)

Conformidade LNP

A conformidade com a portabilidade numérica local exige que a operadora processe as solicitações de portabilidade dentro dos prazos exigidos pela FCC. O fluxo de trabalho de portabilidade do ERP deve:

• Aceite solicitações de portabilidade de operadoras vencedoras minutos após o envio
• Validar se o número e as informações da conta correspondem aos registros da operadora
• Enviar solicitações de portabilidade válidas ao NPAC dentro do prazo exigido
• Rejeitar solicitações inválidas com códigos de rejeição específicos

Controles de reciclagem de números

Os números que foram portados ou entregues devem ser "antigos" antes de serem reatribuídos a um novo assinante. A prática da indústria é envelhecer um número liberado por 90-180 dias antes da reatribuição, para reduzir a probabilidade de chamadas destinadas ao assinante anterior chegarem ao novo assinante.

---

Fase 6: Integração de Garantia de Receita (Meses 8 a 14)

A integração da garantia de receita garante que todos os serviços consumidos sejam cobrados corretamente. Essa integração compara os dados de uso da rede com os dados de faturamento e identifica discrepâncias.

Reconciliação de dados de uso

A integração da garantia de receita deve conciliar:

• Registros de uso da rede (do sistema de mediação) em relação ao uso faturado
• Serviços provisionados (do sistema de provisionamento) em relação a planos de faturamento ativos
• Descontos e créditos aplicados de acordo com seus critérios de elegibilidade

As discrepâncias são classificadas por tipo e encaminhadas à equipe de operações apropriada para investigação. Discrepâncias de alto valor (potencial vazamento excedendo um limite) são escaladas imediatamente.

---

Gestão de Mudanças para ERP de Telecom

Treinamento para representantes de atendimento ao cliente

Os CSRs são o grupo de usuários mais importante para a adoção de ERP de telecomunicações. Eles lidam com grandes volumes de contatos com clientes – consultas de cobrança, alterações de serviços, reclamações – e sua eficiência afeta diretamente a satisfação do cliente e os custos operacionais.

O treinamento em RSC deve ser intensivo e prático: dramatizações com cenários reais do sistema, incluindo tipos de reclamações comuns (disputa de cobrança, problema de serviço, solicitação de atualização) e cenários menos comuns, mas de alto impacto (comprometimento de conta, assinante falecido, administração de conta comercial).

As métricas de treinamento devem incluir: tempo médio de atendimento, taxa de resolução no primeiro contato e taxa de escalonamento. Se essas métricas piorarem após a entrada em operação do ERP, o programa de treinamento precisará de correção.

Preparação do Centro de Operações

O centro de operações de rede (NOC) deve estar preparado para monitorar a integração do ERP ao provisionamento juntamente com suas responsabilidades existentes de monitoramento de rede. Os painéis de integridade da integração devem estar visíveis no NOC juntamente com os painéis de desempenho da rede.

---

Perguntas frequentes

Como lidamos com a migração de cobrança para assinantes de planos legados que não existem mais?

Os assinantes de planos adquiridos que não são mais oferecidos apresentam um desafio de migração: o novo sistema de cobrança pode não ter uma definição de plano correspondente. As opções são: criar definições de planos correspondentes no novo sistema (preservando indefinidamente os preços e termos adquiridos), migrar esses assinantes para o plano atual equivalente mais próximo (com notificação apropriada e possíveis requisitos regulatórios) ou manter o sistema de cobrança legado em modo somente leitura para esses assinantes até que o desgaste natural reduza seu número. A decisão depende do volume de assinantes adquiridos e da complexidade da migração de seus termos específicos.

Qual é o impacto regulatório dos erros de migração do sistema de faturamento?

Erros de faturamento que geram reclamações de clientes às Comissões de Serviços Públicos (PUCs) estaduais ou à FCC são investigados e podem resultar em multas, pedidos de reembolso e correção necessária do sistema. As regras estaduais de cobrança da PUC variam significativamente – algumas exigem notificação do cliente antes de alterações no sistema de cobrança, outras exigem relatórios de taxa de erro. Revise os regulamentos de cobrança em cada estado onde você atende os clientes antes de executar a transição de migração de cobrança.

Como mantemos a continuidade do serviço 911 durante o provisionamento da integração do sistema?

A continuidade do serviço E911 é um requisito regulatório e crítico para a segurança. A integração de provisionamento deve manter conectividade contínua entre o ERP e o sistema de provisionamento E911 (ou o sistema de Informação Automática de Localização). Qualquer janela de manutenção planejada que possa afetar o caminho de provisionamento do E911 deve ser agendada somente com notificação prévia à autoridade estadual E911 apropriada. As chamadas de teste E911 (para o número de teste em vez do próprio 911) devem fazer parte do script de teste de integração de provisionamento.

Qual ​​é o cronograma para conformidade com CPNI no novo sistema ERP?

A conformidade com CPNI (Informações de Rede Proprietária do Cliente) exige que o acesso aos dados de uso do cliente seja restrito a fins autorizados e que os clientes tenham a capacidade de optar por não participar de determinados usos de marketing. Antes de o ERP entrar em operação com os dados do cliente, os controles de acesso devem ser configurados para cumprir as regras do CPNI, as preferências de exclusão do sistema legado devem ser migradas e o processo anual de certificação do CPNI deve ser documentado para o novo sistema. O prazo de certificação CPNI anual da FCC é 1º de março – planeje a entrada em operação do ERP para permitir pelo menos 60 dias antes do próximo prazo de certificação.

Como gerenciamos os requisitos de latência de integração de provisionamento?

As alterações de provisionamento em tempo real (ativações de planos, suspensões, restabelecimentos) normalmente devem ser concluídas dentro de 60 a 120 segundos para atender às expectativas regulatórias e dos clientes. A integração da API de provisionamento deve ser projetada com este requisito de latência em mente: o processamento assíncrono deve ser usado para operações em massa (migrações de planos em lote), enquanto as chamadas de API síncronas lidam com eventos de assinantes individuais que os clientes esperam que entrem em vigor imediatamente.

---

Próximas etapas

As empresas de telecomunicações que planejam a modernização do ERP devem começar com uma avaliação da arquitetura BSS/OSS e uma revisão da capacidade da API para determinar a abordagem de integração para cada sistema existente. A prática de implementação da ECOSIRE oferece implantações de ERP de telecomunicações que se integram a sistemas de provisionamento, plataformas de cobrança e sistemas de relatórios regulatórios.

Explore os serviços de implementação de ERP Odoo da ECOSIRE para saber como nossa metodologia estruturada aborda os desafios exclusivos de integração e migração de dados da implementação de ERP de telecomunicações.