Altaia Enabling SOC Transformation - Operations Interviews - May2017 _v1...

SAVE OFFLINE

Altaia Oi

www.alticelabs.com

 

 

 

Introdução 

Este relatório apresenta uma consolidação dos resultados das sessões realizadas com as diversas áreas das operações (Desempenho, Suporte e Monitoração), no período de 15/05 a 23/05, com vista a potenciar a utilização do Altaia para uma vertente de Serviço.



Foram abordados nestas sessões os seguintes tópicos: •

Qual o tipo de utilização atual do Altaia na área,

•

Identificar os principais gaps/oportunidades existentes

•

Identificar novas funcionalidades que possam contribuir para o trabalho na área

•

Identificar novas integrações com fontes de informação/domínios tecnológicos

3

Evoluções Altaia 2017 (já planeadas)

• • • • • •

• • •

•

•

• • •

• • •

•

4

5

Áreas entrevistadas

o

Domínios

Domínios

Domínios

Domínios

RAN e CORE

RAN, CORE CS e PS

RAN, CORE CS e PS, Plataformas

Suporte ao sistema ALTAIA

Utilização hoje pouco

Utilização hoje muito

Utilização hoje algo frequente

Área de suporte à plataforma,

frequente com elevado

frequente e com elevado

mas com âmbitos restritos

utiliza frequentemente o

potencial de suporte a

potencial de ampliação, com

processos da monitoração

integração de novas fontes

Altaia potencia proactividade na

o

Altaia potencia o salto para visão de

sistema

o

Possibilidade de evoluções para

o

Evoluções previstas com novo

identificação de problemas para

serviço com integração de dados de

integração com comandos e alguns

módulo Manager serão

redes e serviços, com base no seu

eventos/xDR amplificando as

KPIs com periodicidades mais

fundamentais para o despiste de

altamente configurável motor de

capacidades de troubleshooting e

elevadas. Possibilidade de ter

problemas com fontes de

LIMIARES

contribuição para processos de

módulo especifico para atividade

informação e uma atuação mais

monitoramento

de suporte com monitorias a pedido

rápida e proactiva

e invocação de comandos em elementos (Reset, etc)

6

Monitoração



O sistema hoje é utilizado nas vertentes de alarmes de performance e análises em cockpits. Na vertente de alarmes de performance existem algumas configurações simples efetuadas com contributos da equipa de desempenho offline. Na vertente de análises em cockpits são realizadas consultas especificas para avaliar a tendência de KPIs, validar/efetuar o troubleshooting de problemas e suportar janelas de manutenção da rede onde é necessário comprovar o a estabilização do comportamento da rede após intervenção



Não existe um conhecimento completo sobre as capacidades e funcionalidades do ALTAIA



Utilização limitada de alarmes de performance - Por exemplo não existem processos que dependam de configuração de limiares mais avançados como os de CURVA, com adaptação/regeneração automática de PERFIL



Utilização do Altaia para providenciar dashboards de performance - sobre perspetivas geográficas, administrativas e de serviço, etc. Utilização em modo videowall, Possibilidade de tirar partido do novo Portal de Assurance do Altaia



Utilização limitada de funcionalidades de troubleshooting – gravação de análises, gráficos interativos, drill-down de contadores



Desconhecimento da existência de dados online - coletados por via de comandos nos elementos, para o domínio do CORE CS, que foram alvo de integração em 2013 no arranque do sistema – ex - Trafficability, Destinations, Clear Code, etc

7

Monitoração

!

• •

Colocado problema de delay como elemento desfavorável

•

Reforçado que data/hora apresentada diz respeito ao inicio do intervalo de

para uma operação em near realtime

medida, i.e. dados das 09h dizem respeito ao intervalo das 09:00 às

Sentimento de delay transmitido de 3 a 4 horas

09:59, devendo-se levar em conta este fator na contabilização do delay

•

Análise de delay atual, validada com os usuários, para métricas horárias é em média entre 40 e 90 minutos. Para KPIs do CORE (UDR) o delay verificado é em média 15 a 30 minutos

•

Nova versão 6.3 introduz uma nova arquitetura da camada de mediação onde será possível reduzir o delay

•

Adicionalmente o novo Módulo Manager fornecerá um meio para suporte OSS poder identificar e mitigar atrasos existentes nas fontes de informação e que não são originados pelo sistema

8

Monitoração

!

•

Para efeitos de monitoração e alarme de falha (baseados

•

O Altaia poderá trabalhar com periodicidades de KPIs a partir de 5

em KPIs mais básicos que mapeiam diretamente com falha,

minutos. O aumento da frequência de cálculo serve propósitos de

por exemplo disponibilidade, erros de determinado tipo,

monitoração de falha mas por vezes não é recomendável para efeitos de

conjunto de CC, etc) periodicidade de KPIs horários não

análise de performance.

favorece. • •

Uma outra possibilidade pode passar pela definição de KPIs especiais que

No domínio do CORE, apesar de haver KPIs com

são calculados com base em periodicidades mais baixas e que fazem uso

periodicidade de 15 minutos no UDR, os restantes sub

de uma janela deslizante para reforçar o seu resultado (por exemplo de 15

domínios permanecem aos 60 minutos

em 15 min, consolidando os últimos 4 intervalos)

•

Em termos de boas práticas é recomendável ter os KPIs do CORE com periodicidades de 15 minutos, enquanto que os KPIs do domínio do RAN é recomendável manter os 60 minutos 9

Monitoração

!

•

Apesar de existir na versão atual do Altaia dashboards, a

•

sua configuração é limitada e não é possível ser realziada

Foram demonstradas funcionalidades de dashboards relativos à nova versão que vão ao encontro desta necessidade

de forma simples pelos usuários.

•

Inexistência de refresh automático

•

Quando é aberto um alarme é necessário um despiste

•

Fica endereçado com a nova versão 6.3, já em plano 2017

•

Na versão 6.3 do Altaia o alarme de performance do Altaia, enviado para

rápido do problema com recurso a um workflow de análise

SICAWEB, será acompanhado de um URL para um “retorno” ao Altaia de

que deve ser facilitado pela aplicação

forma contextualizada na performance da entidade e que atua como um “âncora” permitindo uma análise complementar do alarme

10

Monitoração



Reconfiguração de periodicidade dos KPIs do CORE CS e PS de 60 para 15 minutos (alinha com boa pratica para análises nas redes CORE)



Para os contadores e indicadores mais críticos do domínio do CORE PS, avaliar integração direta com outputs de comandos, para uma recolha mais rápida de contadores e trabalhar com periodicidades até 5 minutos nestas métricas



Considerar a integração com fontes de informação do tipo xDR, mais ricas para visão de SERVIÇO, onde as possibilidades são por via de RTT do TRAFFICA, Probes da Tektronix, Call Traces (Layer 3), etc)



Identificação de fontes de informação com maior delay - avançar com ações de avaliação junto dos OSS e/ou sistema Altaia



É necessário haver uma discriminação sobre o tipo de alarmes a configurar (FALHA ou DEGRADAÇÃO de performance) e com isso avaliar a melhor forma de o sistema poder contribuir nos processos da monitoração. Um alarme de performance tipicamente antecipa a quebra do serviço (FALHA) e isso deve ser levado em conta na discriminação de que KPIs e regras devem ter periodicidades de calculo mais elevadas



A definição de regras de limiar deve ser construída com o know-how de cada área: offline/online/suporteN2-N3 e existir uma referência única para evitar sobreposição de alarmes com a mesma finalidade. Neste alinhamento deverá ser identificada a periodicidade mais indicada, que poderá variar dependendo da situação 11

Desempenho



O sistema é amplamente utilizado por ambas as equipas que são especializadas análise de desempenho das redes CORE (CS/PS) e RAN. Os indicadores são (re)configurados frequentemente para adequar alterações nas evoluções das tecnologias/rede e suportam vários relatórios/painéis executivo que são elaborados periodicamente pela área. Uma das componentes fundamentais do sistema para a área é a geração de indicadores ANATEL e as capacidades de manutenção com processos de edição simples de indicadores, freezing, expurgo e formatos específicos para entrega ao regulador. Ambas as equipas configuram regras de limares, existindo regras para deteção de FALHA e outras para DEGRADAÇÃO. Alguns alarmes estão seguindo para o SICAWEB enquanto que outros são analisados pela área ou junto das regionais



Existe um conhecimento avançado das capacidades e funcionalidades do sistema



Integração com fontes de xDR – A fonte de informação com mais potencial para a análise de desempenho é o NSN Traffica. Os dados provenientes dos eventos de utilização permitem construir uma visão de serviço mais efetiva e complementar as atuais visões de contador que em alguns casos não permitem chegar à causa raiz do problema.



Integração com CDRs, atualmente tratados pelo CDR View – Esta integração apesar de não ser a mais rica em termos de detalhe de informações que suportam as perspetivas de desempenho, alimenta vários indicadores ANATEL



Visões em Portal de Assurance – este novo módulo permitirá expandir as perspetivas hoje segmentadas por tecnologia e domínios, para visões mais transversais de assurance, com novos dashboards e integrações 12

Desempenho

!

•

Uma vez que as fontes atualmente integradas se baseiam

•

Traffica permitirão complementar as atuais análises

somente em contadores, as visões de serviço alcançadas são limitadas (exemplos de visões de serviço hoje no sistema passam

A cobertura de novas fontes de informação como os RTT do NOKIA

•

Por exemplo no CORE CS será possível ir descer num detalhe de clear

pelas perspetivas ANATEL no RAN ou mapeamento de rotas do

code (CC) mais granular relativamente aquele que é reportados hoje nos

CORE com serviços específicos da Oi como *996, *880, etc).

contadores. No Core PS permitiria identificar de forma mais precisa qual o ponto na rede onde uma determinada degradação de ativação do PDP Context está a ocorrer

•

Falhas de dados poderão ocorrer por motivos de

•

Com a introdução do novo módulo MANAGER o Altaia dotará as equipas

desativação de medição, constantes alterações na planta

de suporte de capacidades de monitoria de fontes de informação para

da rede, migrações de elementos, reconfigurações no OSS,

detetar falhas na entrega de dados por IP, medição, tecnologia, domínio,

etc, impondo falhas de dados com consequências na

etc.

qualidade de alguns indicadores

13

Desempenho

!

•

Produção de valores de indicadores em situações de falha de

•

Por default o comportamento do módulo de métricas é de invalidar o cálculo de valor do KPI quando um contador não esteja disponível. Este

medição

facto poderá acontecer por atraso na medição, ou ausência de dados. •

Validação da qualidade de cálculo dos indicadores e inter-

Caso não seja desejável este comportamento as expressões poderão ser

perspectivas (administrativa,rede, global, etc)

complementadas de forma a tratarem nulos ou o resultado ser influenciado em função de um condicionalismo

•

Com o novo módulo Manager será introduzida uma capacidade para despiste de atrasos e falta de dados em fontes de informação e/ou medições que permitirá mitigar estas variáveis que acabam por influenciar a confiabilidade dos indicadores

14

Desempenho



Aumento da periodicidade de KPIs do CORE CS e PS para 15 minutos (alinha com boa pratica para análises nas redes CORE)



Integração com fontes de informação do tipo xDR de forma a proporcionar uma análise de performance do serviço e troubleshooting mais eficaz. Neste domínio os RTT (fonte NOKIA Traffica) são os que revelam mais informação de detalhe da utilização dos serviços, quer para o domínio da Voz, quer para o domínio dos Dados.



Disponibilizar informação macro de confiabilidade de indicadores (após introdução do módulo Manager) que confira uma maior visibilidade de eventuais falhas de dados nas fontes de informação que depois poderão influenciar os resultados em relatórios e dashboards.



Com a entrada do Ransharing e o aumento do volume de sites compartilhados, a troca de informação de PM e CM entre operadoras aumentou exponencialmente e os processos de partilha de arquivos revela-se um ponto frágil que condiciona fortemente os resultados dos indicadores e relatórios em Altaia. Os processos intermediários deverão ser melhorados de forma a que exista uma melhor expectativa sobre delays e numero de entidades envolvidas.

15

Suporte N2/N3



O Altaia atualmente é utilizado pelas equipas de suporte N2/N3 do RAN e CORE (CS/PS) em situações de despiste de problemas quando é necessário uma validação da tendência dos KPIs. Os principais módulos do Altaia utilizados são os performance cockpits do RAN e do CORE CS/PS. As equipas de suporte de plataformas utilizam o Altaia para consulta e análise sobre KPIs para as plataformas: MMSC, IN, IVAS, RBT, M2M e brevemente MCO).



Não são configurados alarmes em Altaia a partir do módulo de limiares, existindo pouca visibilidade nas áreas destas duas equipas, sobre as suas capacidades.



Integração do domínio Mobile Backhaul (MBH) – A complementaridade de perspetivas relativas à rede MBH permitirá um melhor suporte ao despiste de problemas na rede móvel. Integração com fontes de xDR para messaging (SMS) – A integração dos xDRs dos SMS permitiria uma atuação mais proactiva sobre este domínio, a partir da configuração de limiares sobre perspetivas geográficas, administrativas, de configuração, etc. Nota: O Altaia tem já hoje disponível um pack off-the-shelf para o SMSC da Accision Integração com fontes de xDR – A fonte de informação com mais potencial para a análise de desempenho são os RTT do NOKIA Traffica. Os dados provenientes dos eventos de utilização permitem construir uma visão de serviço mais efetiva e complementar as atuais visões de contador, que em alguns casos não permitem chegar à causa raiz do problema Pack de monitorias online sobre elementos, ativadas a pedido – Possibilidade de ter um pacote de monitorias mais completas e com periodicidades mais baixas – por exemplo 5 minutos mas podendo até chegar ao nível de minuto. Estas seriam ativadas somente sobre os elementos alvo de foco da equipa de suporte no âmbito de uma atividade.







16

Suporte N2/N3

!

•

Colocado problema de delay como elemento desfavorável

•

Reforçado que data/hora apresentada diz respeito ao inicio do intervalo de

para uma operação em near realtime, uma vez que atividades

medida, i.e. dados das 09h dizem respeito ao intervalo das 09:00 às

de suporte exigem uma avaliação o mais tempo real possível

09:59, devendo-se levar em conta este fator na contabilização do delay

de problemas existentes ou de validações decorrentes de ações.

•

Análise de delay atual, validada com os usuários, para métricas horárias é em média entre 40 e 90 minutos. Para KPIs do CORE (UDR) o delay verificado é em média 15 a 30 minutos

•

Nova versão 6.3 introduz uma nova arquitetura da camada de mediação onde será possível reduzir o delay

•

Adicionalmente o novo Módulo Manager fornecerá um meio para suporte OSS poder identificar e mitigar atrasos existentes nas fontes de informação e que não são originados pelo sistema

17

Suporte N2/N3

!

•

Para efeitos de monitoração e alarme de falha (baseados

•

O Altaia poderá trabalhar com periodicidades de KPIs a partir de 5

em KPIs mais básicos que mapeiam diretamente com falha,

minutos. O aumento da frequência de cálculo serve propósitos de

por exemplo disponibilidade, erros de determinado tipo,

monitoração de falha mas por vezes não é recomendável para efeitos de

conjunto de CC, etc) periodicidade de KPIs horários não

análise de performance.

favorece. • •

Uma outra possibilidade pode passar pela definição de KPIs especiais que

No domínio do CORE, apesar de haver KPIs com

são calculados com base em periodicidades mais baixas e que fazem uso

periodicidade de 15 minutos no UDR, os restantes sub

de uma janela deslizante para reforçar o seu resultado (por exemplo de 15

domínios permanecem aos 60 minutos

em 15 min, consolidando os últimos 4 intervalos)

•

Em termos de boas práticas é recomendável ter os KPIs do CORE com periodicidades de 15 minutos, enquanto que os KPIs do domínio do RAN é recomendável manter os 60 minutos 18

Suporte N2/N3



Redução da periodicidade de KPIs do CORE CS e PS para 15 minutos (alinha com boa pratica para análises nas redes CORE)



Integração com fontes de informação do tipo xDR de forma a proporcionar uma melhor análise de performance do serviço e troubleshooting. Neste domínio os RTT (fonte NOKIA Traffica) são os que revelam mais informação de detalhe da utilização dos serviços, quer para o domínio da Voz, quer para o domínio dos Dados



Avaliar evolução para capacitar o Altaia de um pacote de monitorias online sobre elementos principais, que seriam ativadas a pedido, para utilização quando determinado problema está a acontecer na rede e que necessita de uma avaliação rápida dos sintomas, ou nas situações de monitoramento preventivo como o de eventos, migrações de versão, swaps na rede, trabalhos, etc). Este pacote de monitorias online poderia também disponibilizar a execução de ações nos elementos de rede (como ajuste de parâmetros específicos, reset, etc) e que façam parte das rotinas de despiste de casos já conhecidos, tratados de forma recorrente pelas equipas de suporte N2/N3.



Configuração de dashboards para visualização rápida do estado de elementos de rede.



Com a entrada da nova versão 6.3 do Altaia, a feature de consulta de contadores no módulo de evolução, permite que os usuários menos experientes com o módulo adhoc, consultem qualquer medição ou contador integrada no sistema. Esta funcionalidade facilitará o acesso a mais contadores, alguns dos quais necessários para encontrar a causa raiz de problemas. 19

Suporte OSS



A equipa da área de suporte OSS tem responsabilidades de suporte N1 do sistema Altaia. As suas atividades centram-se na análise de problemas que sejam identificados pela área usuária e em algumas reconfigurações do sistema em termos de reprocessamento de arquivos, recalculo de indicadores ou (re)consolidações temporais.



Existem atividades de extração e entrega mensal de dados brutos da ANATEL, que são também garantidos pela equipa



Monitorias proporcionadas pelo novo módulo Manager - Um dos temas críticos para esta área de suporte, é a visibilidade dos problemas que podem afetar a qualidade dos dados, como sendo a falta de dados proveniente das fontes de informação por motivos, processos/plataforma Altaia ou infraestrutura/HW. A partir do novo módulo Manager será possível configurar alarmes para detetar situações anómalas na entrega/disponibilização dos dados, pelas fontes de informação, permitindo descer até ao nível de medição e controlar a performance da aplicação e IFT



Processo de identificação de discrepâncias e data quality de inventário/BDU – Evolução no processo de deteção de discrepâncias para reforçar condições identificação de sites válidos/inválidos



Estatísticas sobre dados que são para ser entregues à ANATEL – Criação de estatísticas de controlo (volumes de dados com aberturas até ao Município) sobre domínios que exijam entrega de dados à ANATEL 20

Suporte OSS

!

•

Despiste de faltas de dados e apuramento rápido de causa raiz

•

Estas necessidades ficarão supridas com a entrada do novo módulo Manager, onde existirá um controlo que permite despistar a disponibilidade e qualidade na entrega de dados por parte de cada uma

•

Controlo de falta de dados provenientes de outras

das fontes de informação integradas em Altaia, processos de mediação e

operadoras em modo de compartilhamento de rede

calculo de KPIs em Altaia

(Ransharing)

21

Suporte OSS

!

•

Processo atual de identificação de discrepâncias de

•

O Altaia usa informações de BDU para identificar que determinado site se

cadastro/BDU não cruza com informação do estado dos

encontra ao serviço e que deverá ter dados de PM/CM sendo

elementos na rede, não estando imune a erros de

disponibilizados pelo OSS . Porém em algumas situações de definição

definição do estado dos sites em cadastro

incorreta do estado em BDU, que apresenta um estado incoerente com o vigente na rede, os dados de PM/CM poderão ser desconsiderados pelo Altaia

•

Foi sugerida a integração com uma leitura do estado da rede (proporcionada por execução de comando nos elementos – ex ZEDO no

2G) que permitiria validar o estado (LOCKED/UNLOCKED) de cada célula/ site, melhorando desta forma o processo de identificação de discrepâncias de BDU

22

Suporte OSS



Configuração de monitorias sobre novo módulo Manager que permitam detetar alterações no padrão de disponibilização de dados por fonte de informação e em medições que sejam identificadas como alvo



Melhorar processos de transferência de dados de PM/CM de outras operadoras, no sentido de se criarem SLAs para controlo do volume de dados que são disponibilizados, assim como do seu atraso



Tipificação em cada OSS do atraso normal de disponibilização de dados de PM/CM, de forma a ser possível endereçar ações de correção que estejam associadas aos elementos ou configuração no OSS

23

24

Ações O levantamento efetuado em cada área permitiu identificar um conjunto ações, possíveis de endereçar a curto/médio prazo, com vista a potenciar o sistema em cada uma das áreas, complementando as visões de rede e podendo evoluir para as vertentes de serviço. De seguida é listada uma consolidação de ações, com análise de impacto (SC-Sem Custo| CC-Com Custo) e âmbito:

#

Ação

Âmbito

Ganho

Impacto

1

Redução da periodicidade dos KPIs do Core de 60 para 15 minutos

Transversal

Potencia a configuração de mais alarmística para âmbito de falha e/ou degradação

SC*

2

Configuração de KPIs de 5 ou 15 minutos com reforço de valores (últimos 4 ou 12 períodos, por exemplo)

Monitoração

Potencia a configuração de alarmes específicos no RAN para efeitos de monitoração

SC*

3

Integração com comandos sobre elementos de rede do CORE PS e CS, para indicadores relevantes na monitoria online

Transversal

Potencia visões online, com periodicidades mais baixas, relevantes para atividades de suporte e monitoração da rede/serviços. Configuração de alarmes.

CC

4

Levantamento/caracterização de delays reais, existente em cada domínio/fonte de informação

Transversal

Permite caracterizar o delay normal e esperado em cada fonte de informação e identificar alguma falha de configuração hoje existente junto dos OSS, NE ou Altaia

SC

5

Integração com RTTs provenientes do sistema NOKIA Traffica

Transversal

Fonte com maior potencial para produção de uma visão de Serviço e que é relevante para todas as áreas das Operações, com possibilidade de indicadores aos 5 minutos e configuração muito rica de alarmes em Altaia

CC

* Demanda que não exige custo associado a investimento em novos módulos, versões ou Packs Altaia, sendo apenas alvo de serviços de (re)configuração

25

#

Ação

Âmbito

Ganho

Impacto

CC

CC

6

Integração com CDRs, atualmente tratados por CDR View

Transversal

Poderá ser considerado com alternativa aos RTTs do NOKIA Traffica mas o tipo de CDRs não é tão rico para análises detalhadas com foco na performance para Voz e Dados. No caso dos CDRs de dados o facto de serem extraídos com base em informação ao nivel do GGSN, retira detalhe relevante para análises de performance e serviço. Sinergia de indicadores ANATEL já hoje em Altaia

7

Integração com xDRs de Messaging, SMS – via Accision/XURA

Transversal

Potencia visão de serviço, análises de performance em múltiplas perspetivas do serviço, configuração de alarmes e indicadores/relatórios para ANATEL

8

Integração de dados da rede Mobile Backhaul (MBH)

Transversal

Complementa a visão da rede móvel com capacidade para se avançar posteriormente em visões SQM E2E (RAN METRO

CC

CORE)

9

Pack monitorias online sobre NE, ativadas a pedido

Suporte N2/N3

Potencia eficiência operacional nas equipas de suporte N2/N3 contribuindo para uma diminuição do tempo de resposta no despiste de um problema

CC

10

Pack interativo para execução de comandos em NE

Suporte N2/N3

Potencia eficiência operacional nas equipas de suporte N2/N3 contribuindo para uma diminuição do tempo de resposta no despiste de um problema

CC

11

Configuração de dashboards que sirvam as áreas em termos de visualização e publicação de indicadores, com recurso a novas funcionalidades da versão 6.3

Maior visibilidade de indicadores de performance, publicação, consulta rápida de sintomas/problemas

SC

Transversal

* Demanda que não exige custo associado a investimento em novos módulos, versões ou Packs Altaia, sendo apenas alvo de serviços de (re)configuração

26

#

Ação

Âmbito

Ganho

Impacto

Monitoração

Aumenta a eficiência operacional orientando o usuário pela análise do problema e causa raiz

CC

Transversal

Mitiga problemas em Inventário/BDU relacionados com o estado de sites, que em alguns casos acaba por inibir entrada de dados em Altaia e consequentemente falta de dados

CC

SC

CC

12

Configuração de análises customizadas a serem invocadas em âmbito de alarme, para suporte ao processo de despiste de um problema/alarme

13

Corelacionamento de dados de BDU com status de sites na rede (LOCKED/UNLOCKED)

14

Workshops para disseminação de conhecimento de novas funcionalidades 6.3, com destaque para a configuração de limiares e dashboards

Transversal

Disseminação de conhecimento sobre capacidades existentes hoje em Altaia , assim como as mais recentes que advêm da entrada em funcionamento da versão 6.3, que desta forma poderão ser melhor exploradas pelas áreas usuárias

15

Consultoria para criação de alarmes

Transversal

Aconselhamento em estratégia de configuração, ajuste de valores limite e validação de resultados

* Demanda que não exige custo associado a investimento em novos módulos, versões ou Packs Altaia, sendo apenas alvo de serviços de (re)configuração

27

28

Planeamento De seguida é apresentada uma proposta de timeline, sujeita a revisão de acordo com prioridades e validação de ações com a Oi:

NOTA: Somente foram dispostas na timeline as ações mais relevantes de forma a ilustrar uma possibilidade de evolução em termos de projeto. Requer validação de estratégia, priorização com a Oi.

29

30

Notas Finais 

As sessões realizadas em cada área permitiram identificar várias oportunidades de evolução para uma adequação do Altaia ao suporte de mais processos dentro das equipas das Operações, nas vertentes de monitoria e performance



O Altaia é um sistema com uma arquitetura capaz de processamento de dados em tempo real. As suas características e funcionalidades gerais permitem endereçar processos de monitoração online, visões de rede/serviço /cliente, integração e normalização de múltiplas fontes de dados incluindo o processamento de eventos/CDRs e geração de alarmística



Apesar do Altaia ter nascido na Oi como um sistema essencialmente para uma atuação offline o mesmo tem flexibilidade, a partir de simples (re)configurações dos domínios e/ou KPIs, para acompanhar as necessidades da Oi no suporte de processos de monitoração/SOC



O Altaia permite a unificação da gestão de desempenho de redes, serviços e cliente para redes móvel e fixo. A evolução para o tratamento de xDRs no móvel e fixo, permitirá consolidar visões de serviço e criar as fundações para o salto do domino de cliente, possível de proporcionar no Altaia a partir do seu módulo CQM - Customer Quality Management

31

Altaia Oi

Rua Eng. José Ferreira Pinto Basto, 3810 - 106 Aveiro Portugal T: +351 234 403 200 F: +351 234 424 723

The present document has information purposes only and does not constitute a formal binding offer. The information conveyed does not constitute an undertaking to sell the identified products and services. The present document is subject to change without notice and Altice Labs cannot be held liable for any possible error or outdated information or for losses or damages of whatever nature resulting from the use of the information.