13 Fevereiro 2017

Proposta de Auditoria para um Portal Cognos de BI

Este artigo baseia-se na implementação de um conjunto de dashboards que têm como objetivo a auditoria de um portal de Cognos e a perceção do processo diário de refrescamento de cubos. O objetivo desta implementação é compreender a utilização do portal, assim como efetuar o controlo do processo diário dos cubos, a sua performance e cumprimento de SLAs. Para a construção desta solução, a ferramenta utilizada para a construção dos dashboards, foi o Tableau Desktop. No texto que se segue, será explicado o processo de desenvolvimento, assim como as respetivas soluções propostas.

Utilização do Portal

Para a obtenção dos dados de auditoria necessários a esta implementação, foi utilizado o package de Audit do Cognos. Nesta funcionalidade transversal ao Cognos, temos acesso a um conjunto extenso de modelos de auditoria. Uma vez que a implementação deste caso de estudo, se encontra no âmbito de um cliente de grandes dimensões, não existe a possibilidade de aceder diretamente às bases de dados de Cognos. Para ultrapassar esta restrição, a solução passou pela criação de reports com base nos dados do package de Audit, tendo sido criado um schedule para a extração dos reports no formato “.csv” para uma pasta, contendo informação dos últimos 10 dias de dados.

Sendo os ficheiros extraídos para uma localização, seria possível ter os mesmos como fonte de dados para o desenvolvimento dos dashboards, no entanto foi tomada a decisão de ter uma base de dados consolidada. Para tal foi criado um projeto utilizando a ferramenta SSIS com um processo de ETL para a importação da tabela factual, onde foi utilizada a função de hash para permitir apenas a importação de novos dados.

O produto final desta proposta é a elaboração de dashboards, que tem como finalidade, para o ano atual, a obtenção de respostas, de uma forma rápida e visual, a perguntas como:

· Quantos utilizadores têm acesso ao portal?

· Quantos utilizadores, no universo de utilizadores com permissões de acesso, efetivamente utilizam o portal?

· Qual a evolução da utilização do portal ao longo do tempo?

· Qual o tempo despendido pelos utilizadores nas suas análises?

· Quais as horas do dia com mais utilização?

Após a análise dos modelos de Audit e a fim de dar resposta às questões em análise focou-se no modelo de Logins.

 

Data Source utilizada

Abaixo encontra-se o modelo utilizado para o desenvolvimento dos dashboards.

Análise de Métricas

Para além das métricas já existentes na tabela fatual, existiu a necessidade de criar as métricas abaixo apresentadas.

> # Logins

Esta métrica tem como objetivo perceber o número de sessões (logins) que os colaboradores efetuam. Na tabela factual estão listados todos os logins dos utilizadores e o objetivo desta métrica é saber o número agregado de logins, que mais uma vez, os utilizadores efetuam.

> # Employees

Esta métrica tem como objetivo perceber o número de colaboradores existentes. Na tabela fatual estão listados todos os logins dos utilizadores e como tal, o mesmo utilizador tem múltiplos registos. Para algumas análises surgiu a necessidade da criação desta métrica que conta o número distinto de utilizadores.

> Avg. Employees Logins

Esta métrica foi criada com o intuito de obter o número médio de vezes que um utilizador acede ao portal, e a mesma surgiu da necessidade de mostrar esta informação em análises.

Dashboard: Country Usage

Este dashboard pretende apresentar para o ano atual, a quantidade de utilizadores com permissões de acesso ao portal, o número de logins que os utilizadores fazem e a utilização efetiva do portal. Como utilização efetiva do portal, entende-se no universo de utilizadores com permissões de acesso ao portal, quantas pessoas se conectam ao portal.

 

Dashboard: Date & Time Usage Distribution

Este dashboard pretende apresentar uma análise mais detalhada da utilização do portal. O mesmo tem como principal objetivo mostrar, para os dados do ano atual, em que período existe um maior número de acessos ao portal e o tempo despendido por parte dos utilizadores no mesmo.

 

Controlo do Processo Diário dos Cubos

O objetivo do processo de controlo diário de execução dos cubos é o de compreender a percentagem de sucesso na criação dos cubos (diários), por outro lado entender quais as razões quando os cubos não são construídos corretamente e ainda entender a margem para alterações a processos existentes tendo em conta a existência de um SLA (Service Level Agreement), ou seja, um tempo limite em que os cubos devem ser entregues aos utilizadores de negócio.

O processo de monitorização de execução de cubos teve por base os dados introduzidos num portal de Sharepoint, onde diariamente uma equipa que acompanha os processos de execução noturnos (onde se incluem a construção/carregamento dos cubos) introduz informações relevantes do processo tais como: nome do cubo, frequência do cubo (diário, mensal ou semanal), tempo final de construção do cubo, tempo limite, estado da execução (entregue no tempo com/sem erros, entregue fora do tempo), tipo de erro, entre outros.

Esta informação, através de um conjunto de processos ETL, é mais tarde refletida em tabelas em SQL Server que servem de base aos dashboards de Tableau exibidos de seguida. De referir que a fonte de dados, ao ter associado um fator humano (equipa que introduz os dados no site), revelou alguns problemas de dados o que obrigou a algum tratamento dos mesmos e redução do período de dados em análise – no dashboard seguinte a análise está limitada ao período entre janeiro e junho de 2016.

O resultado final desta proposta é a elaboração de um dashboard, a fim de dar resposta de uma forma rápida e visual a perguntas como:

· Qual o número de vezes que cada cubo foi executado num mês?

· Qual o número de vezes que um cubo foi construído com sucesso, em comparação com o número de vezes que o processo falhou?

· Quando não foi possível construir o cubo qual foi a razão mais comum?

· Qual a margem em horas que em média um cubo termina antes do limite definido?

Data Source utilizada

Abaixo encontra-se o modelo utilizado para o desenvolvimento do dashboard de monitorização do processo de construção dos cubos.

O modelo é bastante simples, onde os dados são obtidos através de um inner join entre uma view denominada VW_F_CUBE_DELIVERIES onde estão todos os pormenores de execução dos cubos (Cube Name, Date Delivery, DateTime Delivery, Deletion Status, Frequency, Issue Type, Target Time, Time Delivery) e a tabela D_CALENDAR que corresponde à dimensão temporal.

Análise de Métricas

Para além da métrica disponibilizada pelo modelo (Number of Runs) foram criadas mais três métricas: Issue Run, No Issue Run e Date Difference.

De seguida apresentam-se as métricas criadas para a análise.

> # Issue Run

Esta métrica tem como objetivo perceber o número de execuções em erro na criação dos cubos. Foi criado um campo calculado no Tableau Desktop através da fórmula:

> # No Issue Run

Esta métrica tem como objetivo perceber o número de execuções com sucesso na criação dos cubos. Foi criado um campo calculado no Tableau Desktop através da fórmula:

> # Date Difference

Esta métrica tem como objetivo perceber a média em horas que os cubos terminam antes do SLA definido como tempo limite de execução. Foi criado um campo calculado no Tableau Desktop através da fórmula:

Este valor foi arredondado a uma casa decimal para melhor visualização.

Dashboard: Cube Run Analysis

Este dashboard pretende apresentar uma análise de execução dos cubos com uma distribuição mensal, onde é possível verificar o número de execuções bem-sucedidas comparativamente às execuções em erro, para as execuções em erro perceber quais as causas mais comuns e ainda perceber para cada cubo o número de horas que em média o término da sua construção termina antes do tempo limite definido.

 

Conclusões

Este artigo evidencia um conjunto de análises operacionais que demonstram, através de uma ferramenta de reporting denominada Tableau Desktop, suportadas por fontes de dados desenvolvidas em SSIS e/ou SQL Server, a possibilidade de tomar decisões e entender fluxos de utilização dos sistemas, bem como fatores de sucesso em determinados processos como a criação de cubos, indo por isso ao encontro do propósito definido para a sua elaboração e enquanto prova de conceito.

Ao longo do artigo demonstrou-se ser possível desenvolver diversas análises onde qualquer empresa que possua um sistema de Cognos e que necessite de monitorizar processos tais como: número de utilizadores que acedem ao portal, a que hora(s) a distribuição de acessos é superior, em que países o portal é mais utilizado, entre outros. Por outro lado, foram também apresentadas análises ao nível do sucesso na construção de cubos. As mesmas análises poderiam ter sido alargadas, por exemplo, ao número de relatórios entregue aos utilizadores de negócio diariamente – a informação existia na fonte de dados. Este sistema, pode ser visto como um pequeno módulo que poderia ser estendido e/ou implementado em diversas empresas nas quais questões de gestão operacional são vistas como críticas.

Os dashboards criados no âmbito deste artigo são certamente uma mais-valia para inúmeras empresas que ainda utilizam ferramentas e/ou processos arcaicos para obtenção do mesmo tipo de informação. O facto de o Tableau ser uma ferramenta self-service, possibilita aos utilizadores destes dashboards e workbooks a oportunidade de criar as suas próprias análises estendendo eles mesmos o módulo apresentado no artigo. Embora tenha sido utilizada a ferramenta Tableau, existem outras no mercado que possibilitam o mesmo tipo de análises tais como Qlik Sense, Tibco Spotfire ou Microsoft Power BI.

.
.
.
.
.
.
.
        Ana Russo
        Consultant
   Sérgio Carvalho
       Consultant