Desde 2006, estamos envolvidos em sistemas de cobrança. No total - mais de 12 anos. Começamos a trabalhar com o mercado de televisão, agora entre nossos clientes existem bancos, operadoras de celular e provedores de TV na Internet. O próprio sistema de cobrança evoluiu de uma solução mais ou menos simples para a televisão para cobrança total convergente, com a possibilidade de aplicar um esquema de pré-pagamento. E durante esse tempo, conseguimos preencher muitos cones, tanto em termos de implementação quanto de suporte ao faturamento. Os erros geralmente ocorrem porque o cliente não conhece o "material" e os desenvolvedores de cobrança não entendem os medos e necessidades do cliente.O faturamento não é apenas uma calculadora
Durante muito tempo, os sistemas de cobrança não apenas mantiveram o saldo e a fatura do cliente. Eles estão profundamente integrados ao negócio: fornecem controle de tráfego, gerenciam o procedimento para fornecer acesso aos serviços, fornecem ao cliente um relatório de despesas em diferentes seções - por um mês, por um ano, a partir do momento do último pagamento. Além disso, um sistema de cobrança, por regra, deve suportar muitos saldos de usuários: monetário e diversos materiais (bônus, minutos de conversa, gigabytes de tráfego etc.). Sem mencionar programas afiliados e outras opções de venda cruzada. O que é chamado de cobrança convergente moderna. É implementado devido à integração do tarifador com outros módulos e subsistemas: CRM, PRM, BPM, etc. Para desenvolvedores, esse não é um conhecimento "secreto". Como se costuma dizer, divida funções e governe. Mas para os usuários de cobrança, mesmo tecnicamente competentes, a idéia de que é difícil se comunicar diretamente com a “calculadora”, às vezes acaba sendo nova.
Um exemplo da nossa prática. O cliente é uma empresa pequena, mas promissora. Eles não tinham o orçamento para todo o complexo de cobrança e pediram para remover o módulo BPM (gerenciamento de processos de negócios). Devemos prestar homenagem, houve bastante avançado no sentido técnico pessoal. Eles disseram que vão adotar uma solução de código aberto, configurar, integrar com o sistema. Nós concordamos. Quatro meses depois, eles "se afogaram" em suas ligações para o suporte técnico sobre dados incorretos.
O BPM é um sistema que, entre outras coisas, ao conectar um assinante, está envolvido na validação de dados e não o pula para a próxima etapa até que você complete todos os parâmetros necessários - técnicos e pessoais. E eles recusaram o BPM e simplesmente desenharam uma interface para entrada de dados. As pessoas que aceitam solicitações de conexão não são especialistas altamente remunerados, há uma grande rotatividade e um curto tempo de treinamento para a equipe. Naturalmente, eles constantemente cometiam erros ao inserir dados. Conclusão - no final do mês, a empresa emite faturas e o tarifário não possui parâmetros. Ele "jura", dá mensagens de erro. O cliente liga para o suporte. No final, decidimos atribuir-lhes BPM nas configurações padrão. Todos começaram a convergir e nosso suporte técnico ficou com menos dor de cabeça. Agora, não vendemos o faturamento sem o BPM, a menos que ele já esteja implementado e haja opções para sua integração. Se o cliente não tiver dinheiro suficiente para o conjunto mínimo necessário, oferecemos aluguel ou arrendamento com a possibilidade de resgate em cinco anos. Ou, se isso é algum tipo de startup, mas é claro que as pessoas levam a sério o assunto e têm perspectivas, oferecemos um esquema de ruibarbo. De qualquer forma, isso protege as células nervosas para nós e para o gerenciamento da empresa cliente.
Flexibilidade é um conceito flexível.
A arquitetura mal concebida do sistema de cobrança resulta não apenas em falhas técnicas. Em nossa experiência, em 70% dos casos, surge a necessidade de substituir o faturamento devido à sua flexibilidade de marketing insuficiente. O mercado de telecomunicações agora está super saturado, e as empresas podem obter novos clientes apenas repelindo-os dos concorrentes. Até grandes fornecedores, dominando novos nichos e expandindo sua presença, começam a despejar, e o próprio Deus ordenou que novos players no mercado atraíssem atenção com ofertas exclusivas. Uma verdadeira guerra de tarifas está se desenrolando. E aqui os profissionais de marketing já estão cerrados: “Poderemos lançar sua nova tarifa inovadora de Super-Ano Novo apenas em julho”, uma mensagem vem do departamento de TI.
Qual é o problema Em um número muito pequeno de sistemas de cobrança, existe, por exemplo, um módulo de catálogo de produtos separado, que facilita a combinação de serviços em pacotes e a configuração de promoções. Os parâmetros que ele opera podem ser serviços e parâmetros individuais, como minutos de conversa, pacotes de tráfego ou serviços oferecidos por parceiros (os chamados serviços de terceiros), por exemplo, bilhetes de cinema ou viagens de táxi. Acredita-se que um catálogo de produtos geralmente seja um elemento de um sistema de CRM, não de cobrança. Mas, mesmo assim, nem todas as empresas têm um CRM separado. Muitos serviços ao cliente levam diretamente ao sistema de cobrança. E isso significa que qualquer novo serviço, nova tarifa, nova promoção - e o pessoal de TI não precisa coletá-lo no designer, mas adicionar campos e escrever linhas de código. Agora, julho está chegando.
É verdade que os profissionais de marketing geralmente não entendem o que um fornecedor quer dizer dizendo que seu sistema é "bastante flexível". O suficiente para quê? O “Kommersant” está principalmente interessado no tempo de lançamento no mercado, o tempo necessário para lançar um serviço no mercado. Uma vez que representantes de um cliente - um operador regional em cuja região os jogadores federais compareceram - diretamente à reunião de apresentação, trouxeram uma descrição de três casos de concorrentes que eles não conseguiam realizar em casa. Eles colocaram a questão com uma vantagem: por quanto tempo você pode configurar no seu sistema? Não é pecado se vangloriar - montamos um caso no ambiente de teste com eles enquanto a apresentação acontecia. Em geral, com uma arquitetura bem pensada de cobrança de qualquer item e usando um catálogo de produtos, qualquer pacote ou estoque pode ser personalizado e levado ao mercado em 2-3 dias, sem contar o tempo de marketing e testes funcionais. É melhor verificar se esse pode ser um faturamento específico no estágio de namoro. Porque há casos frequentes em que a criação de uma nova tarifa em um sistema "suficientemente flexível" leva vários meses.
Entre centralização e autonomia
As grandes empresas de marketing enfrentam problemas semelhantes em termos de marketing e vendas, que cresceram devido à aquisição de operadores regionais. Diferentes sistemas de cobrança nas filiais não permitem, por exemplo, o lançamento de promoções em grande escala imediatamente em todo o país. Os relatórios e as análises sofrem: é simplesmente impossível coletar dados sobre conexões e uso de serviços de todos esses sistemas díspares. Uma solução parcial para o problema é o CRM abrangente, no qual existe um catálogo de produtos. Algumas empresas fazem exatamente isso - negociam com CRM e cobram pelo faturamento. Para isso, a empresa deve ter um departamento de TI verdadeiramente avançado. Integrar sistemas de cobrança escritos em diferentes idiomas e em diferentes princípios com um único CRM não é uma tarefa fácil.
Mas há um eterno problema que os sistemas distribuídos não podem resolver - essa é uma fraude comum no terreno. Tivemos vários exemplos. Em particular, na Ucrânia, onde introduzimos o faturamento centralizado, transferindo dados de agências regionais adquiridas recentemente. Quando migramos os dados, fazemos uma série de verificações e comparações, todas as inconsistências caem nos relatórios correspondentes e, depois disso, o serviço de segurança da empresa cliente geralmente começa a se mover. O que não está aí. Assinantes conectados por sistemas de contabilidade, planos tarifários “zero”, etc. ... Houve uma fraude franca: a empresa foi vendida e os recibos dos assinantes foram mantidos em detalhes por mais algum tempo.
A organização de um único centro de liquidação torna todas essas situações transparentes; nas regiões, apenas a função de serviço de informações ao assinante permanece, portanto praticamente não há oportunidade de fraude. Além disso, uma grande base de clientes, combinada em um único sistema, nos permite analisar e prever o comportamento do cliente em um nível completamente diferente. Aos poucos, estamos começando a aplicar nossos sistemas de análise baseados no aprendizado de máquina a esses grandes dados. Por exemplo, podemos identificar na base de clientes "grupos de risco" - aqueles que em breve poderão recusar os serviços da empresa. Isso é revelado pela maneira como as pessoas pagam, como usam os serviços, sua conta pessoal, como se comunicam com a central de atendimento, quanto e por que razões têm um bloqueio.
É verdade que a centralização do faturamento traz outros problemas. É necessário que as agências regionais mantenham uma parte da independência técnica. Caso contrário, se de repente o centro de cobrança central estiver "fora da zona de acesso", o atendimento ao cliente na região poderá sofrer. Resolvemos isso às custas de “compensações” para a periferia: servidores de autorização, elementos de coleta e processamento de tráfego, elementos de provisionamento de serviços. Em particular, para operadoras de telefonia móvel, nossa plataforma Forward Fusion pode cobrar serviços offline e aguardar até que a conexão seja restaurada para sincronizar os dados com o centro de cobrança. Ao mesmo tempo, os assinantes regionais podem perceber que sua conta pessoal se tornou indisponível, mas a degradação do serviço fornecido não ocorre.
O servidor que Jack instalou: onde estão os dados armazenados?
Existem muitas opções de como e onde colocar o sistema de cobrança. Muitas vezes, as empresas se preocupam com a segurança dos dados dos clientes, compram os próprios servidores e os instalam em seus datacenters. Mas nem todos podem obter um serviço de qualidade. Às vezes, um cliente quebra algo, mas ele nem entende que está do lado dele. Ligue para o suporte técnico e nossos administradores já informam onde está a falha, qual servidor não está respondendo. Nosso sistema está configurado para que “monitore” constantemente os sistemas que estão sendo atendidos de várias maneiras e emita um alarme se algo estiver errado. Assim, podemos informá-lo com antecedência que a memória está acabando ou que a velocidade de um processo importante caiu abaixo do normal. Mas isso infelizmente não cancela força maior.
Outra opção é quando o cliente deseja se hospedar, e nós entregamos o complexo de hardware e software, isso é feito quando o cliente deseja que agendemos uma determinada performance para os serviços críticos para ele. Nesse caso, o custo do "hardware" inclui imediatamente o custo do suporte de três anos do fabricante. Em seguida, eles mantêm peças de reposição e, se algo quebrar, seus especialistas vão ao local com peças de reposição dentro de 24 horas e reparam a avaria.
Há situações em que, pelo contrário, eles trazem seus servidores e os colocam em nosso data center certificado de Nível III.
Outra opção comum - alugamos tudo. Então, somos totalmente responsáveis pelo hardware - tanto pela manutenção quanto pelo aumento das capacidades necessárias no prazo. Por esse motivo, em algum momento, começamos a usar nuvens privadas. Se aumentamos a carga, alteramos as configurações e recebemos mais poder computacional. Não é necessário se envolver incessantemente em uma “atualização” não essencial de equipamentos para nós. Infelizmente, as empresas russas que hoje oferecem serviços em nuvem pública ainda não podem fornecer o nível de desempenho garantido exigido pelo sistema de cobrança. Eles podem hospedar sites, você pode implantar lojas online ou colocar 1C. Portanto, ainda precisamos participar ativamente da otimização e teste de soluções para várias nuvens privadas. Por exemplo, recentemente começamos a usar o OpenStack.
Bancos de dados: é importante não apenas onde, mas como
É difícil superestimar a importância de escolher um banco de dados para cobrança. O alto desempenho aqui pode ser alcançado apenas pela otimização do sistema de cobrança de um produto específico. O Forward Billing é otimizado para trabalhar com dois DBMSs: Oracle Database e PostgreSQL). No ano passado, o Forward Billing foi incluído no registro de software russo aprovado para uso em empresas estatais. E, recentemente, chegaram as notícias de que, em seis meses, o registro começará a excluir o desenvolvimento baseado em DBMSs estrangeiros. Do ponto de vista do estado, isso é compreensível. Em condições em que quase todos os dias as novas empresas russas são sujeitas a sanções, elas querem garantir a total independência do software russo. Mas para os fornecedores, isso representa um custo adicional decente. Penso que, nesta matéria, nós, como o resto do mercado, aguardamos explicações mais claras dos legisladores a esse respeito, e depois disso ajustaremos nossa estratégia.
SLA: Definir prioridades
Em algum lugar do mundo ideal, o nível de suporte técnico do fornecedor é determinado pelo SLA - Service Level Agreement claramente definido, que também é o Service Level Agreement. Como o SLA é diferente de apenas um contrato no qual as horas de suporte definidas para o cliente são registradas? Ele define requisitos específicos para o serviço: a velocidade de recebimento de um aplicativo, o tempo para resolver o problema - e um sistema de multas que são impostas ao fornecedor se os requisitos não forem atendidos.
Como mostra a prática, para que o SLA se torne uma ferramenta eficaz para regular as relações entre o cliente e o fornecedor, o cliente terá que realizar algum trabalho analítico. Você precisa entender como os incidentes serão críticos para uma empresa em particular e quais não valem a pena entrar em pânico. A maioria dos nossos clientes, de uma maneira ou de outra, usa nossos SLAs básicos que são testados repetidamente e, em nossa opinião, são ótimos.
Parte do fato é que pequenas empresas que compram soluções de cobrança prontas para uso em caixa, em caso de problemas, acabam ficando 376 na fila para suporte técnico. Geralmente, para essas empresas, a ajuda da comunidade de usuários deste produto no fórum on-line é mais rápida.
É verdade que outros extremos ocorrem. Um cliente em potencial, uma pequena operadora de telefonia móvel virtual, veio até nós logo depois de ser “queimado” fortemente com suporte a um sistema de cobrança. Como resultado, esse cliente nos ofereceu um SLA "louco", multiplicando nossos requisitos padrão para tempos de resposta e multas quase cem vezes. Infelizmente, não conseguimos convencê-lo e ele continua atendendo seus assinantes por seu próprio risco.