SACP - ACOMPANHAMENTO DE CONSULTA PÚBLICA

Para imprimir o texto da consulta sem formatação, clique em IMPRIMIR no final da página.
Para visualizar os dados, clique em DADOS DA CONSULTA

CONSULTA PÚBLICA Nº 41

Introdução

1. Objetivos

O presente processo de Request for Information tem por objetivo realizar consulta ampla ao mercado acerca de possíveis soluções de TI para a Agência Nacional de Telecomunicações.

Nesse sentido, espera-se obter informações que poderão vir a subsidiar processo de planejamento que poderá culminar em eventual contratação de nos termos definidos pela IN 04/2014 - MP/SLTI. Dessa forma, o principal objetivo é a identificação das possíveis soluções, modelos de fornecimento, precificação e condições de fornecimento para o atendimento às necessidades da Anatel.

Para tanto, estarão descritos no presente documento, de forma sumarizada e preliminar, os casos de negócios, minuta das especificações técnicas, requerimentos funcionais e não funcionais e premissas em análise para o projeto em pauta.

O presente processo não representa qualquer compromisso de compra, assim como, por se tratar de processo meramente consultivo, as características e requisitos apresentados nesse documento não necessariamente serão refletidos em eventuais processos de aquisição posteriores.

2. Sobre a Anatel

A Agência Nacional de Telecomunicações -- Anatel -- é uma autarquia especial criada pela Lei Geral de Telecomunicações (lei 9.472, de 16 de julho de 1997), dotada de independência e autonomia financeira vinculada ao Ministério das Comunicações.

Sua missão é a promoção do desenvolvimento das telecomunicações do País de modo a dotá-lo de uma moderna e eficiente infraestrutura de telecomunicações, capaz de oferecer à sociedade serviços adequados, diversificados e a preços justos, em todo o território nacional.

Compete à Agência adotar as medidas necessárias para o atendimento do interesse público e para o desenvolvimento das telecomunicações brasileiras, atuando com independência, imparcialidade, legalidade, impessoalidade e publicidade.

3. Termos e Condições

A participação no processo é livre a quaisquer empresas interessadas que venham a ter conhecimento dessa RFI e será, necessariamente, sem ônus à Anatel mesmo que a título de compensação de despesas para participação no processo, submissão de respostas ou qualquer outro motivo.

O presente processo não representa compromisso de aquisição de bens ou serviços por parte da Anatel, assim como, as especificações e condições aqui apresentadas não necessariamente serão utilizadas em processos futuros de contratação. Da mesma forma, a resposta a essa RFI não representa compromisso de venda ou participação em eventual processo de aquisição nem implica na obtenção de nenhuma vantagem direta ou indireta em posterior processo de aquisição por parte da administração.

Essa RFI deverá ser, além de divulgada nos meios oficiais, enviada às empresas que, reconhecidamente, atuem no mercado com ofertas que guardem semelhança com a solução descrita no presente processo.

Além disso, em cumprimento aos princípios da publicidade e impessoalidade, deve ser publicado convite aberto no site da Anatel para que quaisquer outros interessados em atender ao convite por informações possam apresentar suas respostas e contribuições.

Os interessados poderão apresentar suas respostas conforme os padrões descritos no presente documento, juntamente com quaisquer outras informações que julgar necessário para dar maior segurança à análise por parte da Anatel.

Após a entrega das respostas, poderá a Anatel solicitar novos esclarecimentos às respondentes com o intuito de obter as melhores informações possíveis.

Poderá a equipe da Anatel, a seu critério, durante ou após o prazo para a apresentação de respostas, agendar reuniões presenciais ou virtuais (conforme conveniência do interessado), a pedido dos interessados ou de ofício, para conhecimento das soluções possíveis e propostas, esclarecimento de dúvidas ou levantamento de informações adicionais. Eventuais despesas decorrentes de apresentações, discussões, submissão de respostas ou qualquer outro motivo, não caberão à Anatel..

A participação ou não no presente processo, não habilita ou impede a eventuais interessados que estes participem de procedimentos subsequentes de avaliação, provas de conceito ou mesmo de eventual processo de aquisição que do presente se resulte.

3.1. Da Confidencialidade

As empresas interessadas, seus empregados e representantes não poderão sem prévio consentimento formal, por escrito da Anatel, no que tange ao objeto dessa RFI:

1. Fazer declarações, anúncios, divulgações ou qualquer outra publicidade envolvendo o uso do nome, abreviaturas e símbolos da Anatel;

2. Divulgar direta ou indiretamente que qualquer produto do fornecedor ou das empresas que representa foi aprovado, homologado ou endossado pela Anatel;

3. Referir-se à existência dessa RFI em comunicados à imprensa, avisos ou em qualquer material publicitário distribuído ao público.

3.2. Do Cronograma

O cronograma deverá seguir aos prazos estipulados na Tabela 1 contados em dias corridos contados a partir da data de publicação (dia D). A Anatel poderá, a seu critério, modificar esse cronograma caso se faça necessário.

Fase	Prazo (dias corridos)
Publicação no site da Anatel	D
Envio do convite às empresas do setor	D
Esclarecimento de dúvidas e reuniões (a critério da agência)	D + 10
Apresentação de respostas	D + 42
Esclarecimento de dúvidas por parte da Anatel e visitas técnicas (a critério e ônus da Agência)	D + 52
Provas de conceito	A critério da Agência
Pedido de quotação detalhado (RFQ)	A critério da Agência

Tabela 1 - Cronograma proposto para a RFI

3.3. Do esclarecimento de dúvidas

Os interessados poderão submeter suas dúvidas exclusivamente por meio de correio eletrônico no meio do endereço eletrônico RFI@anatel.gov.br, usando como título Sistema de Atendimento e Suporte aos Usuários de Serviços de Telecomunicações, ou por meio do sistema SACP: http://sistemas.anatel.gov.br/SACP.

3.4.Da apresentação das respostas

As respostas à RFI poderão ser encaminhadas por correio eletrônico ao endereço RFI@anatel.gov.br se forem menores do que 10 MB. Se forem maiores, deverão ser encaminhadas em meio eletrônico (CD, DVD ou pendrive) ao endereço:

Agência Nacional de Telecomunicações - Anatel

Ref: Consulta Púlica nº 41/2014 (RFI Ferramenta de atendimento e suporte aos usuários de serviços de telecomunicações)

SAUS, Quadra 6, Bloco F, Térreo, Biblioteca

70070-940 BRASÍLIA, DF

Fax: (061) 2312–2002

rfi@anatel.gov.br

4. Visão geral do projeto

4.1. Objetivo do projeto

Atualmente a Anatel utiliza o sistema de suporte aos usuários dos serviços de telecomunicações – FOCUS, como ferramenta de CRM. O sistema FOCUS foi desenvolvido pela própia Anatel em 2004, adaptado do ambiente das centrais de atendimento a clientes dos mais variados setores da economia, o sistema FOCUS traduz as especificidades da Agência em sua necessidade de diálogo com a sociedade.

Consequência dessas idiossincrasias: fluxo de encaminhamento particular de demandas entre Agência e regulados, canal para requisição de esclarecimentos institucionais, abertura, tratamento e consulta em tempo real pelos diferentes atores sistêmicos, quando da especificação original da ferramenta optou-se por seu desenvolvimento interno adquirindo-se licença de uso de aplicação externa voltado à extração de informações dos dados obtidos pelas interações empreendidas para a geração dos relatórios gerenciais (ferramenta BusinessObjects, hoje em fase de roll-out).

Destaque-se, ainda, o quadro das telecomunicações vigente em 2006, caracterizado pela existência de serviços claramente separados, com atuação restrita a suas limitações técnicas. A evolução tecnológica, outro fator indissociável às telecomunicações, rompeu tais barreiras, relegando a um segundo plano a natureza de cada rede, permitindo a convergência de serviços, em que o conteúdo transmitido torna-se determinante em lugar da sua forma de transmiti-lo, surgindo a necessidade de substituição da sistema, essencial à atuação da Agência.

Adicionalmente, as condições operacionais previstas à época em que o sistema foi desenhado, por volta do ano de 2004, já em muito foram sobrepujadas pelo atual volume de demandas. Nos últimos anos, tem se aumentado em razão aproximadamente exponencial o número de chamados abertos na central da Agência, conforme demonstrado na Figura 1.

Finalmente, o sistema foi desenvolvido em tecnologia que se encontra em fase de descontinuação pelo fabricante (Microsoft ASP 2.0 e Visual Basic), o que vem implicando em progressiva dificuldade de manutenção e evolução.

Em vista disso, pretende a Anatel buscar a modernização do sistema, por meio da atualização tecnológica, incorporação de novas necessidades, como atendimento a usuários móveis e universalização das plataformas de acesso da sociedade à Agência, melhoria dos relatórios de gestão, entre outros benefícios.

4.2. Visão geral

A solução objeto desse projeto será fundamental na atuação da Agência, as informações obtidas a partir dos processos desenvolvidos no uso do sistema, subsdiarão a atuação dos diversos braços de ação da ANATEL, desde o planejamento fiscalizatório, acompanhamento de obrigações e definição de estratégias regulamentares.

A solução será a porta de entrada da ANATEL perante o público externo, o sistema será responsável pelo acolhimento, distribuição, posicionamento e controle das diversas interações sociedade/Agência.

Portanto, torma-se necessário que a solução proposta, seja moderna, com funcionalidades de investigação e análise profunda dos dados e de sua qualidade, por meio de análises estatísticas tanto amostrais quanto da totalidade dos dados, que identifiquem preventivamente, com precisão, ocorrências de desvios de comportamento ou práticas abusivas pelas operadoras, permitindo uma ideal atuação proativa da ANATEL, evitando potenciais danos aos consumidores.

Deverá ser composta, no mínimo, pelo conjuntos de componentes arquiteturais funcionalmente distribuídos de forma a compreender as funcionalidades da Figura 2[1].

Adicionalmente, destacamos que as formas de comunicação devem ser ao menos as estabelecidas pelo e-ping, que cobre casos básicos de http e webservices, e prever a utilização de outras tecnologias de acordo com as necessidades, como por exemplo: ftp, amqp ou outros protocolos de comunicação.

Entre os meses de agosto e novembro de 2014 foi realizado um trabalho de mapeamento do novo processo de atendimento aos consumidores dentro dos canais da agência. A minuta desse novo processo, que deverá ser incorporado à nova solução de atendimento, é apresentada no anexo A desta RFI.

[1] Deve ser ressaltado que essa arquitetura deve ser considerada uma arquitetura de referência. Produtos de mercado podem ser organizados de forma distinta desde que possam prover conjunto análogo de funcionalidades.

5. Requisitos de negócio de alto nível

5.1. Visão geral dos requisitos funcionais

5.1.1. A solução deverá permitir que as suas camadas de servidores Web e de aplicação tenham escalabilidade tanto vertical (mais processadores na mesma máquina) quanto horizontal (mais máquinas).

5.1.2. A interface da aplicação deve obrigatoriamente suportar execução no navegador de internet (browser), sem que haja necessidade de instalar um cliente local da aplicação.

5.1.3. Deverá ser compatível com os browsers Internet Explorer, Google Chrome, Mozila Firefox e Apple Safari.

5.1.4. A aplicação deverá prover integração com servidores de e-Mail através dos protocolos SMTP, POP3 e IMap.

5.1.5. Deverão estar previstas as seguintes integrações com sistemas legados da Anatel a serem realizadas conforme os padrões definidos pela agência por meio de Web Services SOA ou REST a serem implementados pelo fornecedor:

5.1.5.1. Radar

5.1.5.2. STEL

5.1.5.3. SMP

5.1.5.4. SOA

5.1.5.5. FOCUS

5.1.5.6. SEI

5.1.5.7. SGQ (Qualidade)

5.1.6. Deverão estar previstos ao menos as seguintes integrações com sistemas externos na Anatel via Webservice:

5.1.6.1. Base da portabilidade via ABR Telecom

5.1.6.2. E-sic (CGU)

5.1.6.3. Sistemas de CRM e Atendimento das prestadoras para consulta e validação de protocolos (os protocolos para esse fim devem ser estabelecidos pelo fornecedor em conjunto com a Anatel, tomando com base Webservice SOA ou REST)

5.1.6.4. Consulta de CEP´s da base dos correios hospedada na Anatel por meio de Webservices

5.1.6.5. Consulta a base de CPF da Receita Federal hospedada na Anatel por meio de Webservices

5.1.7. Deverá suportar execução sob bases de dados SQL, especificar as alternativas suportadas e preferenciais. Atualmente, o padrão estabelecido na Anatel é o Microsoft SQL Server 2008.

5.1.8. A solução deve ser multi-prestadoras, permitindo que as informações dos clientes possam ser restringidas pela prestadora de destino selecionada no sistema e também permitir que estas informações possam ser compartilhadas entre as empresas usuárias da solução.

5.1.9. A solução deve permitir que um mesmo cliente possua solicitações para N empresas, permitindo que cada empresa visualize apenas as demandas de sua responsabilidade.

5.1.10. A solução deve possuir módulos de administração de usuários do sistema, controlando níveis de acesso ao sistema de acordo com o perfil do usuário ou grupos de usuários. O detalhamento dos usuários e grupos de usuários bem como seus papéis serão definidos no momento do levantamento das regras de negócios pela Contratada.

5.1.11. A solução deve suportar autenticação e autorização dos usuários através do uso de um Servidor de Diretório LDAP.

5.1.12. A solução deverá suportar autenticação e autorização dos usuários através do uso de um Servidor Microsoft Active Directory.

5.1.13. A solução deve suportar autenticação unificada (Single Sign-On) por meio de protocolo Kerberos ou outros (especificar).

5.1.14. A solução deve suportar criptografia entre o browser e o Servidor Web, utilizando HTTPS/SSL.

5.1.15. A solução deve estar apta à utilização de criptografia entre o Servidor Web e o Servidor de Aplicação.

5.1.16. A solução deve estar apta à utilização de criptografia entre o Servidor de Aplicação e a Base de Dados.

5.1.17. A solução deverá ter suporte para acessos de clientes usando protocolos utilizando IPv4 ou IPv6.

5.1.18. A solução deve estar apta à ativação de uma trilha de auditoria para qualquer objeto da aplicação. Deve ser possível ativar esta trilha seletivamente para certos objetos, sem que haja necessidade de ativá-la para todos objetos existentes. Uma vez ativada, a trilha vai registrar alterações aos campos do objeto, indicando quem fez a alteração, quando isto ocorreu, qual era o valor anterior e qual passou a ser o novo valor e qual foi o endereço IP de origem da alteração.

5.1.19. A solução deve possibilitar especificar que a trilha de auditoria deve ser registradas (respostas, acesso, etc), além de registrar acessos aos objetos, mesmo que nenhuma alteração tenha sido feita neles. Quem acessou o objeto ou executou o processo.

5.1.20. A solução deverá ser capaz de expor suas funcionalidades ao mundo exterior através de Web Services. Ela já deve possuir um conjunto pré-configurado de Web Services que exponham suas funcionalidades básicas e deve permitir que o time de implantação crie novos Web Services que exponham funcionalidades adicionais, conforme o necessário.

5.1.21. Os Web Services expostos devem ser protegidos por meios do tokens SAML ou outros mecanismos que garantam a possibilidade de uso autenticado e autorizado (especificar).

5.1.22. A solução deve ser capaz de consumir Web Services disponibilizados por outras aplicações de forma configurável de tal forma que seja possível extender a sua interface de operação com serviços de outros sistemas de forma transparente ao usuário (portlets, servlets, por exemplo).

5.1.23. A solução deverá possuir mecanismos de importação e exportação de dados em massa, de forma a permitir a construção de tarefas periódicas em batch que promovam a integração. Estes mecanismos devem ser capazes de lidar com altos volumes de dados.

5.2. MÓDULO DE REGISTRO

5.2.1. A solução deverá manter tabelas de parâmetros referentes a tipos de reclamações, motivos de manifestações, meios de comunicação, prazo para atendimentos, produtos, assuntos, quantidade de reaberturas, possibilitando o administrador do sistema realizar alterações de parâmetros preestabelecidos.

5.2.2. A solução deverá permitir a criação, alteração e inclusão de árvore de classificação das demandas em tempo real, com no mínimo 7 (sete) sub níveis. A parametrização poderá permitir o administrador do sistema utilizar quantitativo menor de nós de árvores.

5.2.3. Preferencialmente, o número de níveis da árvore de decisão deverá ser variável de forma a permitir um conjunto flexível de configurações da árvore de decisão.

5.2.4. A alteração das árvore de decisão não poderá implicar na perda do estado dos chamados e solicitações em tratamento que tenham sido criados em versões anteriores da árvore de decisão. O sistema deverá ser capaz de, ou migrar as solicitações para a nova árvore, ou manter a tramitação das solicitações na versão anterior da árvore.

5.2.5. A solução deverá encaminhar as solicitações recebidas para o fluxo de atendimento, respondendo as solicitações automaticamente para as árvores que tenham resposta padrão cadastrada, independente do canal de entrada: telefone, e-mail, autoatendimento web, chat e carta;

5.2.6. A solução deverá permitir a emissão de e-mails em formato padronizado e ainda permitir a emissão de email em formato não padronizado por meio de digitação de parte ou todo o texto da mensagem.

5.2.7. A solução deverá permitir a criação ou utilização de mailings já existentes para envio de e-mails.

5.2.8. A solução deverá permitir que os atendentes acessem base de consulta a Scripts, base de conhecimento e respostas padronizadas para atender as solicitação de informação formulada pelo cliente, por telefone ou internet.

5.2.9. A solução deverá permitir anexar documentos tanto nas manifestações quanto nas respostas aos clientes, com no mínimo as seguintes extensões: Wav, mp3, doc, docx, xls, xlsx, pdf, jpeg, gif, tif. Deverá ser possível cadastar novas extenções a ser permitida pelo sistema pelo administrador.

5.2.10. A solução deverá permitir a busca de informações de forma a facilitar ao máximo o esforço do usuário/cliente, inclusive com a utilização do recurso de busca por palavras chaves, bem como permitir que seu conteúdo possa ser indexado e acessado por meio de ferramenta de busca;

5.2.11. A solução deverá possuir uma única estrutura de menus para toda a solução, que seja parametrizável conforme o perfil dos usuários;

5.2.12. A solução deverá permitir o envio de mensagens a todos os usuários a partir de um único envio (broadcast), geradas pelo workflow e/ou pelo Administrador do Sistema;

5.2.13. A solução deverá possibilitar a configuração dos layouts dos arquivos que serão importados ou exportados no modo "batch" pata tratamento off line, como por exemplo: XML + XSD, CSV.

5.2.14. A solução deverá permitir a minimização de erros de digitação através do uso de corretor ortográfico automático, em idioma Português (Brasil). Poderá ser utilizado o dicionário disponível no navegador, desde que forneça a integração necessária e forneça a correção de forma automática;

5.2.15. A solução deverá pré-validar as entradas em cada campo de dados antes de enviar a requisição aos sistemas corporativos, de acordo com as regras de negócios definidas.

5.2.16. A solução deverá prover uma base de conhecimento estruturada, com busca de palavras-chave para resolução de problemas.

5.2.17. O conteúdo da base de conhecimento poderá ser revisado e alterado através da interface administrativa;

5.2.18. A solução deverá oferecer a função de Identificação positiva. A identificação positiva deverá ser feita através de alguns dados cadastrais escolhidos aleatoriamente de um subconjunto previamente definido. O agente digita as informações indicadas pelo cliente, que foram pedidas pelo sistema, e o sistema indica se a informação confere com o cadastro do usuário junto à agência.

5.2.19. A funcionalidade de identificação positiva, também será utilizada para geração de nova senha de acesso solicitada pelos usuários.

5.2.20. A solução deverá manter (incluir, consultar e alterar) cadastro de clientes (pessoa jurídica e pessoa física);

5.2.21. Permitir o cadastro de múltiplos endereços, telefones e e-mails: (por exemplo: comercial, residencial, recado, fax, celular);

5.2.22. Salvar vinculado ao cadastro do usuário o histórico de interações com Agência;

5.2.23. Manter (incluir, consultar e alterar) cadastro de clientes interessados em receber notícias relacionadas à Anatel.

5.2.24. Permitir que, em função das reclamações e manifestações recebidas nos canais de acesso, sejam geradas notificações, alertas e ações de acompanhamento aos usuários responsáveis pelo atendimento das demandas relacionadas;

5.2.25. Permitir identificar o consumidor e ainda o acompanhamento das atividades históricas junto ao consumidor cliente;

5.2.26. Recuperar e disponibilizar, as interações históricas do consumidor (por exemplo: atividades abertas, reclamações, manifestações, informações solicitadas, comunicações trocadas, telefonemas, cartas e e-mails enviados);

5.2.27. Permitir geração de pesquisas de opinião, específicas para cada tipo de atendimento, por meio de questionários a serem respondidos via email ou formulário Web, sobre serviços, atendimento oferecendo condições de identificar oportunidades de melhorias dos processos e de novos negócios;

5.2.28. Armazenar arquivos contendo áudio e relacioná-los às manifestações do cliente;

5.2.29. Permitir parametrizar em banco de dados os níveis de criticidade , prazo de solução e respectivos responsáveis (áreas resolvedoras) para cada tipo de manifestação;

5.2.30. Permitir controlar o cumprimento dos prazos da manifestação;

5.2.31. Permitir relacionar produtos / assuntos aos tipos de manifestações;

5.2.32. Permitir registrar várias manifestações no mesmo processo de atendimento, cada qual com data de entrada e prazos de resolução específicos, bem como produtos distintos (SCM, SMP, STFC, SeAC, TVA, etc);

5.2.33. Permitir relacionar uma pesquisa a um produto / assunto a um tipo de manifestação específica;

5.2.34. Permitir acompanhamento e registro de follow-up para cada manifestação inserida, possibilitando o registro dos eventos ocorridos até a resolução do caso, com documentação envolvidas, tarefas pendentes e respectivos responsáveis, bem como os contatos realizados.

5.2.35. Permitir criar hiperlinks para acessar funcionalidades externas ao sistema (consultas corporativas, páginas e funcionalidades de outros sistemas).

5.2.36. Antecipar-se ao cliente sobre o andamento do processo de reclamação ou de manifestação, por intermédio de eventos de acompanhamento - follow-up - das manifestações e reclamações apresentadas, inclusive por e-mail, indicando a necessidade de o cliente prestar informações complementares, se for o caso;

5.2.37. Emitir alerta de níveis críticos de atendimento às solicitações do cliente;

5.2.38. A solução deverá suportar a integração entre os diversos canais de relacionamento (1331, Portal Internet, E-Mail, Fax, Carta), mantendo toda a informação de relacionamento em base consolidada, proporcionando uma visão única do consumidor, do ponto de vista operacional. Ou seja, todos os canais devem consultar e atualizar a mesma base de dados com o cadastro e interações do consumidor. Não devem existir várias bases integradas, mas sim uma única base utilizada por todos os front-ends da aplicação.

5.2.39. Deve ser possível que um mesmo agente da central de relacionamento, seja capaz de receber uma interação vinda do consumidor por qualquer canal, incluindo telefone, e-Mail e chat.

5.2.40. Se um consumidor telefonar para a central 1331 ou se dirigir a Sala do Cidadão da Anatel para atendimento presencial, ou até mesmo consultar o portal Fale Conosco da Anatel na Web, ao informar o número do protocolo recebido na resposta de e-mail automática, ou por outro meio, o atendente ou o portal deve ser capaz de localizar o chamado aberto para aquele e-mail, bem como ter acesso ao texto do e-mail e seu respectivo tratamento.

5.2.41. A solução deverá possuir mecanismos de importação e exportação de dados em massa, de forma a permitir a construção de tarefas periódicas em batch que promovam a integração. Estes mecanismos devem ser capazes de lidar com altos volumes de dados.

5.3. Telefone

5.3.1. A solução deverá prever e possibilitar integração com os componentes de telefonia como CTI, URA e Gravador; (especificar os padrões e APIs suportados).

5.3.2. Permitir que os dados fornecidos pelos clientes no pré-atendimento telefônico (URA) sejam aproveitados no atendimento humano, inclusive quando houver redirecionamento para outra célula. O mesmo deverá ser aplicado aos dados dos clientes eventualmente registrados pelo atendente, bem como ao histórico do cliente registrado no sistema;

5.3.3. A solução deverá gerar número de protocolo oara possibilitar o registro de histórico de atendimento, mesmo quando o cliente permanecer na URA e não for para o atendimento humano;

5.3.4. Possuir rotina de importação dos dados do DNE dos Correios - CEP, visando facilitar as pesquisas de endereços e digitação dos mesmos;

5.3.5. Possibilitar além da importação, edição de endereços relacionados aos CEP´s, bem como inserção de CEP´s e endereços manualmente.

5.3.6. Com objetivo de integração com SGQ, possibilitar a validação de UF/Municipío com a base do IBGE, sem opção manual

5.3.7. Permitir integração com CTI de forma que as informações do cliente sejam disponibilizadas na tela da atendente quando receber uma ligação identificada (screen popup);

5.3.8. A solução deverá possibilitar a qualificação dos atendimentos por intermédio do Tempo de duração do registro da solicitação, ou seja, o sistema deverá ser capaz de cronometrar o tempo gasto compreendido entre a geração do número de protocolo (primeiro passo atendimento) até a sua finalização (preenchimento demais campos).

5.4. Telefone – Ativo

5.4.1. A solução deve ter a funcionalidade para a geração de chamadas a partir da central de atendimento da Agência.

5.4.2. A geração de chamadas poderá ser para follow-up de solicitações de assinantes sob demanda, individualizados ou em massa.

5.4.3. A geração de campanhas para chamadas ativas em massa deverá ser feita a partir da solução mediante a configuração de parâmetros de público alvo desejado, universo a ser atendido, número de participantes ou percentual de usuários a contactar.

5.4.4. A solução deve ser capaz de comandar a realização das chamadas por meio de integração com soluções de Call Center do tipo CTI ou análogas.

5.4.5. Deve ser ainda capaz de registrar e relatar o resultado de cada chamada e do conjunto das ações da campanha.

5.5. Redes Sociais

5.5.1. A solução deverá prover ferramenta para atendimento e monitoração por meio de redes sociais, a exemplo de twitter e facebook.

5.6. FALE CONOSCO (WEB)

5.6.1. A solução deverá disponibilizar um Portal Web para acesso direto do consumidor. Este portal deve poder ser integrado ao sítio da Anatel, hoje existente, especificamente na parte do Fale Conosco.

5.6.2. O Portal a ser disponibilizado para o consumidor, deve permitir que o próprio consumidor realize seu auto-cadastramento, criando para si um login (CPF/CNPJ) e uma senha, que permita sua autenticação no portal, tendo acesso a uma área com seus dados e solicitações específicas com seu CPF/CNPJ, independente do canal de registro da solicitação (carta, e-mail, 0800, internet, chat).

5.6.3. O sistema deve permitir apenas um cadastro por CPF/CNPJ;

5.6.4. O Portal deve permitir que o usuário no momento do seu cadastramento, registre uma pergunta e resposta secreta. Caso ele esqueça sua senha, esta resposta secreta deve poder ser usada no processo de recuperação ou recriação de sua senha, evitando que ele tenha que se recadastrar, em função de ter esquecido sua senha original.

5.6.5. Devem ser possíveis mecanismos adicionais de recuperação de senha (especificar), como por exemplo, envio de desafio para o email do usuário.

5.6.6. O Portal deve permitir que o usuário realize busca por palavra chave pela solução de um problema ou dúvida numa base de conhecimento, atualizada pela Anatel. Esta base deve ser a própria base de conhecimento utilizada pelos operadores e usuários da Anatel para buscar soluções nos demais canais, filtrada para exibir apenas as informações que façam sentido abrir para o público em geral através do Portal.

5.6.7. O Portal deve permitir a criação de listas de perguntas frequentes (FAQs - Frequently Asked Questions), com suas respostas, a fim de facilitar a busca de informações por parte do consumidor.

5.6.8. Deverá ser possível para o consumidor abrir um chamado no Portal e receber um número de protocolo, da mesma forma que ele faria se tivesse entrado em contato por outro canal, tal como o telefone ou em uma sala do cidadão (presencial). O sistema deve permitir que este chamado seja encaminhado para solução no mesmos moldes dos chamados coletados por demais canais.

5.6.9. Ao se autenticar no Portal, o consumidor deve ter acesso a todo o histórico de atendimento que ele teve com a Anatel. Isto deve incluir tanto solicitações ainda em aberto, quanto solicitações finalizadas, mesmo aquelas registradas antes de seu cadastramento no portal. Estas solicitações podem ter sido criadas em qualquer canal, incluindo os canais telefônico, presencial, e-mail e o próprio Portal.

5.6.10. Caso o consumidor seja notificado que deve tomar mais alguma ação e/ou fornecer mais alguma informação para que o processo continue caminhando, ele deve poder fazer isto através do próprio portal, como sendo mais um passo da solicitação, possibilitando inclusive a inserção de anexos no decorrer de seu atendimento.

5.6.11. O portal deve permitir integração com recurso de chat, possibilitando que o consumidor clique em um botão ou link para iniciar um chat com um atendente da central. A transcrição do chat deve ficar armazenada no sistema. Caso o consumidor esteja logado e autenticado no Portal no momento da solicitação do chat, não lhe será exigida nova identificação e a transcrição armazenada no sistema deve também figurar no histórico de atendimento do consumidor.

5.6.12. No momento que um chamado é criado no portal, deve sempre ser enviado um e-mail para o consumidor avisando que este chamado foi aberto e informando o número do protocolo. Caso o chamado tenha sido criado por outro canal e caso o cadastro do consumidor contenha um endereço de e-mail, deve também existir a possibilidade de envio das informações para este e-mail.

5.6.13. Para os consumidores que possuam um endereço de e-mail em seu cadastro no sistema, a cada passo relevante que ocorre no andamento da solicitação, um e-mail avisando o consumidor do progresso alcançado deve ser enviado. A caracterização de "passo relevante" deverá ser definida por parametrização, dependendo de cada tipo de demanda e passo do processo.

5.6.14. O Sistema deverá possibilitar alteração dos dados cadastrais pelos próprios usuários por meio da internet, sendo as respectivas alterações disponibilizadas instantaneamente para todo o sistema;

5.6.15. A solução deve permitir a adoção de leiaute flexível por meio da aplicação de skins de forma a permitir a adoção, conforme a necessidade, de novos padrões visuais, sem a necessidade de codificação.

5.6.16. A aplicação Web deve ser compatível com padrão HTML5, com páginas responsivas e em conformidade com as melhores práticas estabelecidas pelo consórcio W3C e deve ser plenamente compatível com os navegadores mais comuns do mercado: Internet Explorer, Google Chrome, Mozila Firefox, Apple Safari e Opera. Além disso, deve ser capaz de operar de forma adequada em dispositivos móveis do tipo Tablet e Smartphone, independentemente do fornecimento de aplicação cliente nativa para dispositivo móvel.

5.6.17. A solução deve obedecer aos principais padrões e às melhores práticas recomendadas pelo Modelo de Acessibilidade em Governo Eletrônico E-Mag 3.1 ou superior ou poder ser adaptada para isso (nesse caso, a adaptação deverá ser feita pelo fornecedor sem ônus, no caso da contratação), disponível em http://www.governoeletronico.gov.br/acoes-e-projetos/e-MAG.

5.6.18. A aplicação deverá possuir tradutor de Libras e conversor texto para voz em língua portuguesa e facilitar atendimento a consumidores com necessidades especiais.

5.7. FALE CONOSCO MÓVEL(Tablets e Smartphones)

5.7.1. Adicionalmente ao atendimento móvel deverá estar disponível, sem ônus para os usuários de serviços de telecomunicações, a possibilidade de instalação de um cliente móvel do serviço Fale Conosco.

5.7.2. Esse cliente móvel deverá estar disponível no mímimo para Smartphones e Tablets que executem os sistemas operacionais Android 4 ou superior, IOS 7 ou superior e Windows Phone 7 ou superior.

5.7.3. O aplicativo móvel deverá possuir as mesmas funcionalidades da versão Web permitindo o cadastro de novo usuário no sistema, de nova solicitação e o acompanhamento de solicitações existentes.

5.7.4. O aplicativo móvel poderá ser desenvolvido em tecnologia nativa das plataformas móveis ou mediante aplicativo HTML5/Javascript encapsulado como aplicativo instalável.

5.7.5. O aplicativo móvel deverá se comunicar com o sistema instalado nas premissas da Anatel por meio dos web services providos pela aplicação para execução de suas funcionalidades de forma online.

5.7.6. Se o aplicativo for utilizado em área na qual não haja cobertura de rede de dados, os formulários de preenchimento de solicitações deverão estar disponíveis para uso pelo usuário para envio posterior à Anatel de forma transparente ao usuário.

5.7.7. O aplicativo deverá ser capaz de, caso o usuário autorize expressamente, utilizar dados da linha de acesso instalada no aparelho, assim como informações referentes coletadas acerca da qualidade de sinal percebida pelo aparelho, pelas ligações telefônicas efetuadas, e dos serviços de dados utilizados, assim como a localidade da reclamação por meio do GPS do aparelho.

5.7.8. Deverá ser possível a integração do aplicativo móvel com outros aplicativos móveis da Agência como os de aferição da qualidade do serviço de dados.

5.8. SMS

5.8.1. A solução deve ser capaz de enviar mensagens SMS para o consumidor, de maneira similar à que envia mensagens de e-mail contendo o número do protocolo e posicionamento de sua solicitação. O tipo de mensagem a ser enviada deve ser parametrizável no sistema.

5.8.2. O sistema deve possibilitar o envio de resposta da solicitação por SMS, independente do canal de entrada da solicitação.

5.8.3. O fornecedor deverá descrever os componentes e serviços necessários à operação dos serviços de SMS.

5.9. ATENDIMENTO VIA CHAT

5.9.1. A mídia Chat de interação com o consumidor deve permitir uma conversa escrita em tempo real entre o consumidor e um operador da central de Atendimento.

5.9.2. A solução deve possuir monitoração, controle e administração de toda a solução através de interface integrada com a ferramenta de gestão da central de atendimento;

5.9.3. Possuir ferramenta de administração com interface web ;

5.9.4. Utilizar padrões de segurança Internet (SSL, HTTP/S tunneling, etc.) para toda comunicação entre o consumidor e a central;

5.9.5. A solução deve armazenar todo o histórico de relacionamento (inclusive texto integral de chats) para o agente, propiciando copiar/colar para o atendimento ao cliente;

5.9.6. A solução deve possibilitar a utilização de respostas automáticas através de base de conhecimento e sugestões de respostas para os atendentes.

5.9.7. A solução deve possuir corretor ortográfico em português automático, com dicionário de verbetes comum a todos os atendentes, possibilidade de inclusão, edição e exclusão de palavras ;

5.9.8. A solução deverá gerar número de protocolo para o atendimento via Chat, bem como efetuar o registro do atendimento na solução, histórico do consumidor, incluindo as mensagens trocadas.

5.9.9. Deve ser possível a um mesmo atendente, o atendimento simultâneo de mais de um consumido por meio do serviço de chat.

5.10. BASE DE CONHECIMENTO

5.10.1. A solução deverá possuir funcionalidades baseadas em perguntas e alternativas de respostas que servirão como orientação ao operador durante o atendimento.

5.10.2. A solução deverá disponibilizar uma visão estatística das respostas mais e menos utilizadas, possibilitando otimização da base com melhoria contínua.

5.10.3. A solução deverá permitir aplicar pesquisas e questionários parametrizados ao público durante o contato (ativo ou receptivo), ou ao final de um atendimento pela internet (pesquisa de satisfação).

5.10.4. A solução deve permitir a parametrização das perguntas e possíveis respostas, que podem ser do tipo texto livre, múltipla escolha e/ou "sim ou não";

5.10.5. A solução deve permitir redirecionar o fluxo ou seqüência das questões conforme o tipo de resposta, possibilitando um comportamento dinâmico conforme a pesquisa é aplicada;

5.10.6. Permitir o registro de sugestões de complemento vinculadas às respostas da pesquisa.

5.11. MÓDULO DE TRATAMENTO

5.11.1. A solução deverá possuir módulo central que permita aos gestores da ferramenta administrar e configurar os diversos módulos da solução global, assim como possibilitar, de forma otimizada, aos operadores avançados o tratamento em níveis superiores dos chamados entrantes. Tal interface deve, ainda, oferecer mecanismos para acompanhamento de produtividade de colaboradores, além da geração de inteligência a partir do universo de dados relacionados.

5.11.2. A solução deverá possibilitar acesso às diferentes áreas e funcionalidades como base no perfil do usuário. Destaque-se a existência de usuários vinculados a pessoas jurídicas e físicas, tanto em âmbito privado como público.

5.11.3. Em relação ao último ponto, também se espera da ferramenta a existência de canal de comunicação diferenciado entre a Agência e diferentes órgãos públicos de interesse, sendo tais entidades inseridas em contextos e fluxos que permitam exceções às regras negociais comuns e cadastro diferenciados em relação à implementação padrão.

5.11.4. A solução deverá possibilitar a adição de "gatilhos" - Mecanismos que disparariam alertas ou algo do tipo quando do atendimento de determinada condição, por exemplo, “n mil reclamações sobre determinado tema” ou “a violação de certo artigo da norma”, ou até mesmo “x solicitações respondidas com o mesmo texto”.

5.11.5. A solução deve conter interface de caráter gerencial voltada ao acompanhamento do desempenho de colaboradores hierarquicamente vinculados a partir da exibição de quantidades, dados e históricos de eventos sob a responsabilidade desses, permitindo, inclusive, ponderação de resultados em decorrência de notas de qualidade e pesos atribuídos para diferentes etapas de atendimentos. As informações de interesse devem poder ser parametrizáveis em funcionalidade específica, permitindo visualizações das informações pretendidas por meio de tabelas e gráficos; de forma individual, coletiva e comparativa.

5.11.6. A solução deve possuir mecanismo de escalonamento de tratativas. Nesse sentido, solicitações que atendam determinadas condições configuráveis - relacionadas a seu conteúdo, ao demandante, ao fluxo de tratamento recebido, a perda de prazos - devem ser automaticamente encaminhadas para aqueles usuários lotados hierarquicamente acima de seus responsáveis originais, em quantos níveis correspondam à estrutura da Agência. A previsão de tal escalonamento deve ser acompanhada da possibilidade de disparo de alarmes por meios como mensagens eletrônicas ou de texto via celular; configuráveis para cada cenário.

5.11.7. A solução deve dispor de mecanismos de amostragem, que listem solicitações aleatórias que se enquadrem em determinado padrão desejado, possibilitando, assim, a extração de estatísticas de interesse a partir de tal universo.

5.11.8. A solução deve ser capaz de identificar padrões textuais no histórico global de solicitações, a partir de buscas, manuais ou automatizadas, que localizem ocorrências ou repetições de texto. Ex. “Localização de respostas padrões utilizadas por prestadoras” ou “Reclamações reiteradas de mesma natureza do mesmo do mesmo usuário, ou contra a mesma operadora”.

5.11.9. Deve ser possível a realização de buscas textuais por padrões exatos, fonéticos ou semânticos (sinônimos) na língua portuguesa.

5.11.10. As funcionalidades de atendimento devem variar de acordo com o perfil do usuário, devendo ser facilmente configurável pelos gestores da ferramenta a administração de prerrogativas sistêmicas para diferentes grupos de usuários. Ex. perfil para reencaminhar solicitações, cancelar, reclassificar, etc.

5.11.11. A solução deve permitir e gerenciar o tratamento de sub-registros, ou seja, divisões de um protocolo principal, que poderão receber encaminhamentos e tratamentos diversos. A administração de vínculos e dependências entre registros "pais" e "filhos" caberá ao sistema, responsável, por exemplo, pela contagem de prazos, envio de alertas; distintos e unificados.

5.11.12. A solução deve dispor de dashboard voltado ao tratamento, configurável para as necessidades de cada operador. Tela parametrizável e personalizada, contendo alarmes, registros destacados, comentários, flags e pendências marcadas pelo usuário. Sua exibição será vinculada ao usuário, sendo a configuração salva mostrada quando do início da sessão do usuário.

5.11.13. A solução deve possibilitar vasta gama de possibilidades de buscas na base de dados transacional de registros. As telas finais de pesquisa, disponibilizadas aos usuários, deverão ser graficamente programáveis pelos administradores da ferramenta.

5.11.14. Todos os campos de identificação de um registro devem ser "pesquisáveis", obedecendo a operadores mínimos de filtragem, típicos de bancos de dados como, de forma não exaustiva, "contém todo ou parte", "igual", "diferente", "maior ou menor", além de pesquisas fonéticas ou semânticas no caso de registros do tipo texto livre. Adicionalmente, o sistema deve ser capaz de exibir os resultados da pesquisa efetuada em diferentes visões, a escolha do usuário. Dentre essas, destaca-se a exibição em tabelas do próprio sistema, em planilhas ou arquivos exportáveis, assim como gráficos básicos.

5.11.15. A solução deve possibilitar, de forma otimizada, a administração da ferramenta em alto nível, sem a necessidade de intervenção sobre código fonte. Considerando as características peculiares e a dinamicidade do setor de telecomunicações, a flexibilidade e escalabilidade da aplicação são requisitos fundamentais. Nesse sentido, as seguintes interfaces mínimas de gestão devem ser contempladas:

5.11.16. Manutenção: inclusão, exclusão, alteração, criação de novos tipos - de informações globais, relevantes ao atendimento, como, por exemplo, aquelas de interesse público - telefones de operadores, códigos de área, informações de endereço e telefone da sede da Agência e suas unidades descentralizadas - para utilização pela central de atendimento.

5.11.17. Alarmes: Sistema de envio automático de mensagens relativas aos fluxos negociais, quando do atendimento de determinada condição predeterminada ou programada. Ilustram tais cenários os seguintes cenários: mensagens de escalonamento quando da perda de prazo, alerta de abertura de registro sob responsabilidade do destinatário, atingimento de número determinado de reaberturas, resposta a um pedido de esclarecimento. Solicita-se que tal módulo permita a inclusão, alteração, exclusão, formatação das mensagens a ser encaminhadas, assim como dos componentes de suas listas de destinatários, individualmente ou em grupos, com possibilidades vinculadas ao perfil de cada usuário.

5.11.18. Controle de teor dos registros: inteligência que restrinja a inclusão de termos ofensivos ou desrespeitosos durante a utilização da ferramenta online.

5.11.19. Parâmetros globais: módulo que permita a gestão - inclusão, alteração, atualização, exclusão - em nível administrativo de variáveis ou objetos de repercussão global na ferramenta. Por exemplo, a quantidade de dias padrão para um atendimento, o prazo para que um registro seja concluído sistemicamente.

5.11.20. Cadastro prestadoras: interface de gestão das informações relacionadas, com a possibilidade de vinculação de tais entidades a responsáveis pelo tratamento de solicitações a elas encaminhadas.

5.11.21. A solução deve permitir avaliação de respostas - report com os dados referentes ao procedimento de checagem da veracidade e da qualidade das providências adotadas pelas operadoras em função das reclamações encaminhadas.

5.11.22. A solução deve prever a funcionalidade de ativo, com relatório para acompanhamento acerca do desempenho de tal célula da central, contendo quantitativos, usuários contatados, responsáveis pelas ligações, compilado das informações obtidas nos contatos, filas de atendimento.

5.11.23. A solução deve disponibilizar síntese das ações efetuadas pelos operadores, em nível individual ou de grupos, contendo quantidade de atendimentos em diferentes intervalos, protocolos vinculados, pontuações do atendimentos

5.11.24. A solução deve disponibilizar um resumo da operação, com detalhamento das características das solicitações recebidas, resumindo quantidades de cada tipo de chamado - para intervalos determináveis -, as informações mais requisitadas, motivos mais reclamados, principais causas de interrupção de atendimentos.

5.11.25. A solução deve possuir a funcionalidade de “Resposta Padrão”, módulo que permita a administração dessa informação, ou seja, os posicionamentos únicos que se adequam à parcela significativa das solicitações entrantes. Tal módulo deve possibilitar, de forma concentrada, a execução de ações como a atualização, correção, inclusão ou exclusão de posicionamentos, efetuáveis pelos gestores da ferramenta ou usuários aos quais sejam delegados essas prerrogativas.

5.11.26. Manutenção de procedimentos: módulo que permita a administração dessa informação, ou seja, a orientação ao operador da central ou do atendimento pessoal de como proceder quando deparados com determinada situação - por exemplo, a partir da constância de uma palavra-chave inserida ao longo do atendimento, o operador pode ser informado que o caso deve ser registrado como denúncia e não reclamação - nos mesmo moldes do item "Resposta Padrão".

5.11.27. Árvore de classificação: módulo que permita a administração prática dos diferentes níveis de classificação - individualmente, por nó, ou coletivamente, diagnóstico - das solicitações registradas pela Agência. Tal manutenção refere-se à atualização, habilitação, correção, inclusão e exclusão, das classificações em seus diferentes níveis, assim como das relações estabelecidas - vinculações - entre as diferentes hierarquias e dos fluxos e regras negociais atrelados a cada diagnóstico - encaminhamentos, prazos etc. Os procedimentos desejados devem poder ser efetuados individual ou coletivamente. Espera-se também que tal módulo permita a administração dos universos de solicitações sob determinado diagnóstico quando de alterações de nomenclatura, ou seja, que a ferramenta possibilite a migração entre classificações de grupos de solicitações sem perda de informações de histórico. ' Cerne de todo o processo de revisão da ferramenta, especificação para esse ponto vale ser revisada e revisada várias vezes.

5.11.28. Dados complementares: módulo que permita o gerenciamento de informações adicionais estruturadas vinculadas a determinadas classificações - por exemplo, em uma reclamação de cobrança por ligações para números desconhecidos, o sistema deve cobrar automaticamente, em campo próprio, os horários dessas ligações contestadas. O referido gerenciamento implica a possibilidade de criação, exclusão, atualização, definição de formato dos campos criados.

5.11.29. Fundamentação Legal: funcionalidade que permita a manutenção de repositório de peças regulamentares estruturadamente, a fim de que se possa vincular determinado relato ou classificação a item de normativo da ANATEL, manual ou automaticamente. Ademais, tal área deve possibilitar a geração de relatórios sob esse prisma, por exemplo, a extração de listagem dos principais artigos desrespeitados de certa resolução em determinado mês com seus respectivos quantitativos.

5.11.30. Cadastramento: área central para manutenção dos cadastros de usuários utilizados globalmente pela solução. A administração de perfis - compostos pela combinação das funcionalidades liberadas ou restritas, vinculação a empresas, áreas da Agência ou órgãos externos - deve ser acessível para os gestores da ferramenta e usuários a quem seja delegada a prerrogativa. Tal módulo deve ainda permitir a criação - e demais ações correlatas de administração - de perfis fixos, ou seja, que contenham conjunto definido de funcionalidade aplicadas, para posterior cessão aos usuários do sistema.

5.11.31. O cadastro de órgãos / setores da Anatel aptos a receberem reclamações deve ser editáveis e parametrizáveis, possibilitando habilitar ou inabilitar determinado órgão/setor independentemente da estrutura hierárquica da Anatel.

5.11.32. Para cada tipo de demanda existe um processo com vários trâmites já pré-definidos. O sistema deve criar automaticamente os trâmites a serem executados, já assinalando as áreas e pessoas responsáveis automaticamente.

5.11.33. A solução deve definir automaticamente a data máxima para conclusão de uma demanda, com base na árvore de classificação e fluxo de tratamento predefinido.

5.11.34. O sistema deve ter um cadastro de todos os Usuários, contatos, cargos e status, com as informações da área em que eles trabalham, da área geográfica que atendem e de quais são suas funções, especificando as tarefas que podem por eles ser realizadas e as áreas de conhecimento dos mesmos.

5.11.35. Os trâmites são passos de um processo para que uma demanda possa ser concluída. O sistema deve cadastrar trâmites com todas as informações pertinentes e relevantes a este, tais como: descrição das atividades executadas, tipo do trâmite, data e hora de ínicio e fim, status, responsável e outras. Todos os trâmites devem estar associados a pelo menos uma demanda. Deve ser possível também fazer alterações aos trâmites manualmente ou automaticamente através do mecanismo de workflow. Exemplo: “Um usuário deve poder, depois de entrar em contato com o cidadão, alterar o status de um trâmite de pendente para executado ou um trâmite pode ser automaticamente alterado para executado após o envio de um e-Mail, caso seja essa a ação esperada”.

5.11.36. O sistema deve possuir o conceito de equipe de uma demanda. Esta equipe é formada pelas pessoas envolvidas na resolução da demanda, as quais podem pertencer a qualquer órgão ou uma PRestadora. Todas as pessoas desta equipe devem ter visibilidade sobre os dados da demanda, para que possam cooperar para sua resolução.

5.11.37. A aplicação deverá permitir a criação de scripts dinâmicos, onde uma resposta a uma pergunta do script determina qual a próxima pergunta a ser feita. Estes scripts devem poder ser de atendimento, de campanhas, de resolução de problemas, de pesquisa de satisfação ou de qualquer outra natureza.

.38. Para certos tipos de demanda, tal como a avaliação da aprovação de um 5.11atendimento, por exemplo, é necessário que se faça uma coleta de específica de dados para dar suporte ao processo de avaliação. Para esses casos, o sistema deve prover a funcionalidade de levantamento de informações de forma organizada através da criação de questionários com perguntas, check-list de documentos e com campos que captem as respostas. Para cada resposta deve ser possível associar um peso/nota, de forma que ao final de todas as respostas dadas, a nota final possa ser utilizada como critério de avaliação.

5.11.39. O processo de tratamento de solicitações deverá ser flexível e parametrizável pela agência, variando conforme a classificação da solicitação.

5.12. MÓDULO ANALÍTICO / RELATÓRIOS

5.12.1. A ferramenta gerencial e analítica é o componente tecnológico responsável por coletar, organizar e analisar informações referentes ao universo de dados obtidos a partir dos canais de contato com a sociedade institucionalmente disponibilizados. Trata-se da ferramenta que vai operacionalizar relatórios, gráficos, análises de tendências, co-relacionamento de variáveis. Espera-se uma solução que atenda as necessidades rotineiras de relatórios assim como permita a criação de análises sofisticadas para mineração de informação e apoio à tomada de decisões.

5.12.2. A pesquisa de dados, que esse componente deve suportar, é um processo iterativo que consiste, basicamente, na seleção dos dados de entrada, na sua transformação, na execução de uma função de pesquisa, interpretação e apresentação dos resultados obtidos. Todas essas 4 etapas devem ser auxiliadas pela ferramenta de análise.

5.12.3. A seleção dos dados deve ser facilitada por interface gráfica para customização dos filtros necessários e extração das informações.

5.12.4. A etapa de transformação também deve ter o auxílio de uma Graphical User Interface, GUI, mas deve suportar também operações mais complexas de transformação por meio de linguagem de programação/script quando necessário. Deve-se minimizar a necessidade de criação de scripts para transformação de dados utilizando linguagem de programação.

5.12.5. A terceira etapa é a aplicação dos modelos matemáticos e de pesquisa em si (On-Line Analytical Processing, OLAP). Nessa fase, espera-se flexibilidade, performance e escalabilidade dos algoritmos disponíveis para a análise em termos de quantidade de informações processáveis.

5.12.6. Finalmente, a etapa de interpretação deve ser auxiliada por ferramentas que facilitem a visualização dos resultados de forma intuitiva. Espera-se uma solução que possibilite a geração de tabelas, relatórios formatados, gráficos (com diversas opções de representação), diagramas e visualizações dinâmicas, como animações e simulações.

5.12.7. A solução no ambiente do usuário deverá ser em língua portuguesa do Brasil. O ambiente do administrador deverá ser em língua portuguesa do Brasil ou língua inglesa.

5.12.8. A solução a ser ofertada deverá possuir a funcionalidade analítica, possibilitando utilizar e analisar os dados das solicitações registradas pelos cidadãos a fim de permitir avaliação da qualidade do serviço prestados pelas operadores de telecomunicações, reconhecer tendências, identificar gargalos, auxiliando na tomada de decisões pela Agência, tanto táticas quanto estratégicas.

5.12.9. A solução ofertada deverá possuir uma ferramenta de "Extraction, Transformation and Loading" - Extração Transformação e Carga ou ETL, ou funcionalidade similar, para copiar os dados da base operacional, transformá-los e carregá-los no modelo de dados da base analítica.

5.12.10. Os scripts de ETL utilizados pela ferramenta para importar os dados da base operacional para a base de dados analítica deverão ser construídos pela contratada durante o projeto de implantação ou fornecidos como parte do produto.

5.12.11. A solução deverá ser capaz de acessar simultaneamente, em tempo real, várias fontes de dados distintas e independentes e combinar, através de joins distribuídos ou forma similar, a informação destas fontes em um modelo de dados lógico, efetivamente criando uma federação destas bases. As análises propriamente ditas devem poder ser efetuadas sobre este modelo de dados lógico federado.

5.12.12. A aplicação analítica deverá possuir um conjunto de análises prontas sobre os principais métricas e indicadores da prestação de serviço e da gestão de demandas da Anatel. Estas análises devem ser constituídas por painéis analíticos e relatórios pré-construídos, com gráficos e tabelas.

5.12.13. A solução deverá possibilitar que os usuários criem novos relatórios e analisem qualquer informação existente no banco de dados analítico, permitindo a criação dos relatórios e análises por meio de funcionalidades do tipo "drag and drop" dos elementos que podem compor um relatório ou visão de negócio, formatados de acordo com as necessidades de cada usuário.

5.12.14. A solução deve possuir interface Web para geração, customização e visualização de relatórios, bastando para sua utilização o uso do browser em ambiente de "portal". Ademais, o acesso de qualquer usuário deve partir de interface padrão customizável a partir de preferências individuais selecionadas.

5.12.15. A solução deve disponibilizar opções de administração e controle de licenças e senhas, possibilitando configuração de prazos de validade destas, número máximo de tentativas de acesso sem sucesso, assim como bloqueio e controle de usuários.

5.12.16. A solução deve possibilitar controle centralizado de segurança para atribuição de privilégios a níveis e perfis de usuário, e fornecer funcionalidade para integração com outro sistema de controle de permissões.

5.12.17. A solução deve possuir estrutura de segurança aplicada a grupos de usuários e usuários distintos, para acesso aos dados e relatórios.

5.12.18. A solução deve possuir integração direta com LDAP, Active Directory e NTLM, com a finalidade de aproveitar as estruturas de segurança e conexão existentes na rede "Single Sign-On".

5.12.19. A solução deve possuir integração direta com Microsoft Analysis Services (MSOLAP) de forma nativa ou com o Pentaho BI Server, permitindo todas as funcionalidades previstas neste termo de referência. Poderá ser aceito solução alternativa desde que parte do produto fornecido (especificar)

5.12.20. A solução deve permitir análises que envolvam diferentes visualizações em uma mesma tela (gráficos e tabelas), onde as alterações em uma das visualizações reflitam automaticamente nas demais.

5.12.21. A solução deve apresentar gráficos simples e compostos, no mínimo, nos seguintes modelos barra, pizza, linha e área, em 2D e/ou 3 D, bem como mapas.

5.12.22. Implementar mecanismos que permitam a criação de dashboards a serem publicados em ambiente web, que permitam a utilização de objetos avançados (por exemplo, velocímetros e gráficos 2 D).

5.12.23. A solução deve permitir efetuar cálculos durante a análise, criando indicadores temporários que não estão presentes na estrutura OLAP (colunas calculadas).

5.12.24. A solução deverá permitir a inserção de novos cálculos ou parâmetros sem necessidade de reprocessamento dos dados da pesquisa inicial.

5.12.25. A solução deve possibilitar a configuração de alertas visuais de destaque sobre indicadores que se enquadram em regras de negócio pré-estabelecidas pelos usuários (por exemplo, a sinalização em cor diferenciada de resultado acima de limite parametrizado), bem como o envio de mensagens de alerta à lista de destinatários pré-definidos.

5.12.26. A solução deve possuir a funcionalidade de cálculo automático de tendências dos indicadores com base em comparação de resultados entre períodos correntes com os períodos anteriores.

5.12.27. A solução deve possuir função para geração de relatórios e análises que cruzem uma ou mais dimensões em linhas e colunas (crosstab).

5.12.28. A solução deve possuir Suporte a Common Gateway Interface (CGI), ISAPI ou alternativa análoga (Disponibilização de API's para customização de consultas ou extração de relatórios pré-desenhados pela sociedade no site da Agência com base na solução e nos dados por ela manipulados.)

5.12.29. A solução deve contemplar de forma nativa as arquiteturas ROLAP (Relational On Line Analytical Processing - Processamento Analítico On Line Relacional) e MOLAP (Multidimensional On Line Analytical Processing - Processamento On Line Analítico), possibilitando a criação de um único relatório acessando as fontes MOLAP e ROLAP ao mesmo tempo (Análise Comparativa).

5.12.30. A solução deve possuir função de Drill Through, acessando de forma transparente o Data Warehouse ou qualquer base de dados através de chamada a relatórios pré-desenvolvidos que contenham o detalhe das informações apresentadas nas análises gerenciais. Esta navegação deve ser dinâmica (sem a existência de hiperlinks entre relatórios)

5.12.31. A solução deve permitir a consolidação de múltiplas fontes de dados em uma mesma estrutura OLAP.

5.12.32. A solução deve permitir a criação de colunas condicionais (if-then-else) por meio gráfico e sem a necessidade de codificação ou customização.

5.12.33. A solução deve permitir aos usuários de TI, agendar a execução de relatórios baseados em tempo, datas disponíveis, calendários e outros parâmetros diversos.

5.12.34. A solução deve conter a possibilidade de importar funções e procedures criadas nos bancos de dados, para utilização em relatórios ou análises.

5.12.35. A solução deve possibilitar a criação de relatório único acessando várias fontes de dados distintas, como: Excel, Oracle, Sql-Server, DB2, Informix, bancos ODBC, web services SOA ou REST, flat-files e XML, XSD (validador) sem necessidade de customização ou desenvolvimento (programação).

5.12.36. Permitir alterações de formatação de um relatório sem a necessidade de uma nova consulta ao banco de dados.

5.12.37. A solução deve possuir ferramenta gráfica de modelagem, documentação de metadados e carga das estruturas nos metadados.

5.12.38. A solução deve possuir funcionalidade de agregação, ordenação, ranking e sumarização de indicadores existentes nas bases de dados Relacionais, Data Warehouse ou estruturas OLAP, sem a necessidade de customização ou desenvolvimento adicional.

5.12.39. A solução deve possuir funcionalidade de exportação dos relatórios desenvolvidos nos formatos (XML, PDF e Excel formatado).

5.12.40. A solução deve possibilitar, caso o usuário deseje, visualizar e editar o SQL gerado pela consulta antes de sua execução.

5.12.41. Capacidades de navegação em tabelas agregadas, possibilitando alterar automaticamente o SQL para buscar uma tabela agregada se presente.

5.12.42. Possibilitar a identificação automática de relacionamento entre tabelas (joins) em sua camada de metadados, quanto as primary e foreign key.

5.12.43. Possibilitar a verificação de integridade dos objetos criados na camada de metadados.

5.12.44. Suportar a utilização de tabelas de agregação em sua camada de metadados.

5.12.45. Permitir a utilização de múltiplos caminhos de navegação (drill).

5.12.46. A ferramenta deve atualizar automaticamente seus relatórios quando a camada de metadados sofrer alguma alteração.

.47. Permitir a pré-formatação de seus objetos dentro da camada de 5.12metadados.

5.12.48. Possuir interface gráfica.

5.12.49. A solução deve permitir que o desenvolvimento de conteúdo (relatórios, dashboards etc.) seja feito sobre a camada de metadados, evitando que os desenvolvedores tenham a necessidade de conhecer os modelos físicos dos bancos de dados.

5.12.50. Caso a solução de relatórios não seja nativa aos outros componentes do sistema, deve ser descrito os produtos utilizados para esse fim.

5.12.51. Deverão ser entregues um conjunto mínimo de relatórios de acompanhamento que incluam o cálculo do IDA -- Índice de Desempenho do Atendimento e dos Regulamentos Gerais de Qualidade (resoluções Anatel 574/2011-RGQ-SCM, 575/2011-RGC-SMP, 605/2012-RGQ-STFC), no que se aplicarem ao atendimento.

5.13. Requisitos de segurança de informação e privacidade da solução

5.13.1. O sistema deverá permitir a completa configuração dos registros de auditoria.

5.13.2. Deverá ser possível registrar, para cada alteração do sistema, quem alterou, o que alterou, qual era a informação anterior e qual foi a posterior, de onde partiu a alteração (endereço IP).

5.13.3. Deverá ser possível a plena configuração dos perfis de acesso ao sistema.

5.13.4. Deverá ser possível a delegação de autorização de administração de forma federalizada para determinados grupos de usuários por áreas da Anatel, outras operadoras ou outros órgãos. Por exemplo, usuários do sistema que sejam empregados de uma operadora de telecomunicações seriam administrados por um empregado da operadora com delegação exclusiva para essa finalidade.

5.135. Deve ser possível administrar perfis de acesso de forma a alterar as funcionalidades disponíveis a cada perfil.

5.14. Requisitos de desempenho e volumetria

5.14.1. Ao longo dos últimos anos, percebe-se uma curva crescente de registros. O quadro a seguir ilustra o exposto na Tabela 2:

Ano	Solicitações Registradas	Crescimento
2013	3.151.671	29,77%
2012	2.428.645	27,84%
2011	1.899.686	17,05%
2010	1.622.930	4,41%
2009	1.554.369	23,36%
2008	1.260.035	36,96%
2007	920.002	13,55%
2006	810.230	-

Tabela 2 - Solicitações registradas por ano na Anatel

5.14.2. Ademais o sistema FOCUS foi implementado em 2004, para o cenário e volume de demandas estimado à época. O quadro exemplificativo da Tabela 3 demonstra o crescimento vertiginoso do mercado de telecomunicações, restrito somente ao intervalo de vida útil do sistema – planta de serviços em milhões:

	2004	2014	Crescimento
Acessos Móveis	65,5	277,4	324%
Banda Larga	1,2	23,4	1.850%
TV	3,9	19,2	392%
3G/4G	0	96,1	n/a

Tabela 3 - Crescimento das redes de telecomunicações no Brasil

5.14.3. Os números observados demonstram claramente o deslocamento entre a realidade inicial e atual do mercado de telecomunicações dentro do ciclo de vida do FOCUS. Tal resultado impacta diretamente no dimensionamento inicial previsto para o sistema, no que tangem quantidade de demandas recebidas, quantidade de usuários simultâneos, reforçando assim qualidades inerentes às telecomunicações, como sua dinamicidade, adesão popular e forte potencial de expansão.

5.14.4. Atualmente a central de Atendimento da Anatel dispõe de 800 operadores dos quais, 400 simultâneos no horário de maior movimento. Estima-se que, ao todo 5.000 usuários atuam respondendo as solicitações dos consumidores, quando se consideram os operadores de call center das operadora de telecomunicações com acesso ao sistema.

5.14.5. Atualmente, na base do FOCUS existem 7,7 milhões de consumidores cadastrados. Estima-se que em média 30% das solicitações são abertas por meio da interface via Web (Fale Conosco) enquanto que o restante é aberto por meio do telefone 1331 da Anatel. Espera-se que o novo sistema tenha condições de aumentar esse percentual de forma a reduzir os custos de operação do serviço de atendimento telefônico da Agência.

5.14.6. Neste contexto, no que se refere a tempos aceitáveis de resposta, a solução disponibilizada deverá ter um tempo de resposta de até 03 (três) segundos em 90% dos casos, excetuando-se as telas de geração de relatórios gerenciais.

5.15. Requisitos de disponibilidade de confiabilidade

5.15.1. O sistema deve permitir a criação de ambiente com garantia de disponibilidade de no mínimo 99,5% por meio de redundância adequada de sua infraestrutura física e lógica.

5.15.2. Deverá ser possível realizar o backup das informações do sistema sem a necessidade de interrupção dos serviços.

5.15.3. A customização e alteração de configurações do sistema deve ser capaz de preservar o histórico de forma a permitir a recuperação posterior.

5.16. Requisitos técnicos e arquiteturais

5.16.1. O sistema deve ser implementado de forma a oferecer ao usuário mecanismos capazes de:

5.16.1.1. facilitar o aprendizado dos conceitos e operações do sistema;

5.16.1.2. otimizar o tempo de execução das tarefas (conforme critérios estabelecidos para cada tarefa);

5.16.1.3. identificar claramente o que a funcionalidade executa. Os títulos das telas do sistema devem estar coerentes com o seu objetivo;

5.16.1.4. conduzir o usuário por uma sequência lógica de etapas inerentes aos processos de negócio, dispensando a necessidade de operação por um profissional especializado;

.5.161.5. permitir a exportação de relatórios para os formatos Excel e PDF;

5.16.1.6. exibir mensagens de confirmação e de exceção claras aos usuários do sistema;

5.16.1.7. possuir material de suporte ao usuário: manual, Ajuda (on-line), guias de implantação (com requisitos da instalação e configuração), e arquivo Leia-me.

5.16.2. O sistema deverá ser construído a partir de padrões abertos.

5.16.3. Deverá o fornecedor informar quais são as tecnologias utilizadas para o desenvolvimento e construção do serviço.

5.16.4. A ferramenta deverá exportar APIs, preferencialmente, mas não limitadas, em Web Services, que permitam a extensão das funcionalidades ou o seu reuso pelos sistemas da Anatel.

5.16.5. Deverá ser informado se a ferramenta pode ser licenciada com o respectivo código fonte.

5.17. Requisitos legais

5.17.1. A solução deverá ser aderente, no que couber, aos dispositivos legais referentes à segurança de informações – normas ISO da série 27000.

5.18. Requisitos de infraestrutura

5.18.1. O fornecedor deverá apresentar os requisitos de infraestrutura de necessários para execução do sistema nas condições descritas na presente RFI considerando que todos as estruturas físicas e lógicas devem ser integralmente redundantes.

5.18.2. Deve ainda ser informados requerimentos mínimos a serem impostos sobre componentes externos ao sistema (rede, backup, storage, e outros).

6. Modelos mínimos de resposta

6.1. Descrição da solução

Deve ser descrita a solução ofertada, seus componentes, módulos e especificações técnicas. Devendo ser abordados os seguintes aspectos:

- infraestrutura de hardware e software necessárias para o funcionamento;

- software básico (sistema operacional suportados e recomendados e demais componentes);

- tecnologias adotadas para o desenvolvimento e construção do sistema (linguagens, frameworks, utilizados, padrões abertos que a aplicação obedece, etc...)

- SGBDs;

- softwares de virtualização suportados;

- soluções de backup, balanceadores de carga, estruturas de clustering e redundância;

- arquitetura: número e descrição das camadas e componentes arquiteturais;

- tipo de carga (cpu, memory, I/O ou network bound);

- critérios de dimensionamendo do servidores;

- arquitetura lógica da aplicação contendo: diagrama de blocos dos módulos e/ou diagrama de visão da solução. Descrição dos módulos descrevendo suas funções e interfaces.

6.2. Resposta Ponto a Ponto

Adicionalmente, para facilitar a análise, para cada item do capítulo 5, deverá ser apresentada uma resposta no formato tabular cujo exemplo se encontra na Tabela 4.

Deve ser lembrado que como se trata de mera consulta, não é obrigatório o atendimento a 100% da especificação, contudo, nos pontos nos quais não houver atendimento, é extremamente importante que o fornecedor explique em sua resposta as razões de seu não atendimento ou apresente alternativas que mitiguem ou suprimam essas necessidades.

Dessa forma, a Agência, como fruto de sua análise poderá, na medida do possível, segundo seu entendimento, buscar no futuro, uma especificação que possa, de forma o mais abrangente possível, abarcar um conjunto mais amplo de possíveis proponentes caso venha a estebelecer eventual processo de aquisição da solução.

Item	Atende (sim/não/parcialmente)	Observações
5.1.1	Sim	O produto atende intergralmente o item funcionando em ambiente Web
5.1.2	Não	É necessária a instalação de applet java para operar no cliente Web.
5.1.3	Parcialmente	O produto ainda não é compatível com o Apple Safari
...	...	..

Tabela 4 - Exemplo de resposta ponto a ponto

6.3. Modelos de licenciamento / comercialização

Deverá ser descrito como a solução é comercializada, seus módulos, se a comercialização se dá por licenças de usuário, por instalação ou por processador, por volume de atendimentos, ou qualquer outros fatores que interfiram no modelo de precificação do produto.

Deverá ainda ser informado como devem ser quantificados os serviços de instalação e customização, se por homens-hora ou por pontos-por-função.

Deverá informar ainda as condições para o fornecimento de códigos fontes da solução, caso faça parte do modelo de comercialização.

Também deverá ser informada a forma de serviços de manutenção e suporte, principalmente para os casos em que a solução não forneça o código fonte ou caso haja exclusividade na prestação deste tipo de serviço.

Anexo A - Minuta do novo processo de atendimento

I.1. Visão Geral