Self-Service Business Intelligence

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

Self-Service Business Intelligence

Eduardo Cardoso de Abreu

Mestrado Integrado em Engenharia Informática e Computação Orientador: Professor Gabriel David

(2)

(3)

Self-Service Business Intelligence

Eduardo Cardoso de Abreu

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo Júri:

Presidente: Professora Cristina Ribeiro Arguente: Professora Benedita Malheiro Vogal: Professor Gabriel David

(4)

(5)

Resumo

Os sistemas de gestão da produção nas empresas industriais produzem grandes quantidades de dados, mas de onde nem sempre é fácil retirar os indicadores necessários à tomada de decisão. A resolução deste problema é o objetivo das ferramentas de processamento analítico (Business Intel-ligence), que extraem a informação relevante dos sistemas operacionais e produzem os relatórios pedidos pelos gestores, mas, muitas vezes, recorrendo ao auxílio de especialistas.

A necessidade de ter um departamento de TI como intermediário gera atrasos, reduzindo a capacidade de decisão da empresa, pelo que houve a necessidade de criar ferramentas de Self-Service Business Intelligence (SSBI). Estas permitem que colaboradores sem conhecimentos de TI consigam interrogar a base de dados, obtendo a informação que desejam de imediato, para além de poderem explorar mais e melhor a informação armazenada.

A Critical Manufacturing (CMF), empresa onde esta dissertação foi realizada, é uma empresa de desenvolvimento de software com soluções gerais de BI e SSBI para o seu sistema de gestão de linhas de produção (MES) cmNavigo. No entanto, há muitas empresas sem disponibilidade finan-ceira para adquirir estas soluções, pelos custos consideráveis no licenciamento e infraestrutura, mas que, mesmo assim, pretendem obter alguns dos seus benefícios.

O objetivo desta dissertação é integrar no cmNavigo uma ferramenta protótipo de SSBI, que permita a não especialistas interrogar os dados e produzir dashboards através de uma interface gráfica. Para isso, selecionam-se algumas ferramentas de SSBI e de construção e visualiza-ção de dashboards e avaliam-se as suas abordagens, funcionalidades, vantagens e desvantagens, determinando-se qual o melhor caminho a tomar para o projeto. Escolhida a ferramenta, são estu-dadas abordagens diferentes à implementação de um modelo de dados simplificado, que permitem ao utilizador final a interação com os dados que considere mais relevantes.

(6)

(7)

Abstract

The production management systems in industrial companies produce large amounts of data, but from which is not always easy to gather the indicators needed for decision-making. To solve this problem is the goal of the on-line analytical processing tools (Business Intelligence), which extract the relevant information from operating systems and produce the reports requested by the managers, but, many times, using the aid of experts.

The need of an IT department as an intermediary causes delays, thereby reducing the com-pany’s decision-making ability, creating a need for tools of Self-Service Business Intelligence (SSBI). These allow employees without IT knowledge to query the database, gathering the needed information immediately, in addition to being able to better explore the stored information.

Critical Manufacturing (CMF), the company where this dissertation took place, is a software development company with BI and SSBI solutions for its Manufacturing Execution System (MES) cmNavigo. Although many companies wish to obtain some of its benefits, their financial capability does not allow them to purchase these solutions due to its considerable costs in licensing and infrastructure.

The objective of this dissertation is to integrate in cmNavigo a SSBI tool prototype, allowing non-experts to query the data and produce dashboards through a graphical interface. To do this, some SSBI and dashboard tools were evaluated for their approaches, features, advantages and disadvantages, determining what is the best path to take for the project. After choosing the tool, different approaches are studied for the implementation of a simplified data model which will allow the end user to interact with the data considered most relevant.

(8)

(9)

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away”

(10)

(11)

Conteúdo

Abreviaturas e Símbolos xiii

1 Introdução 1

1.1 Contexto/Enquadramento . . . 1

1.2 Motivação e Objetivos . . . 2

2 Estado da arte das soluções de BI 5 2.1 Microsoft Power BI . . . 8

2.2 Tableau Software . . . 14

2.3 Qlik Sense . . . 17

2.4 Conclusão do estudo das três soluções . . . 19

2.5 Klipfolio . . . 21

2.6 Dundas BI . . . 21

2.7 Telerik Reporting e Report Server . . . 23

2.8 Sisense . . . 24

2.9 Syncfusion Dashboard Platform . . . 26

2.10 Conclusão do estudo das ferramentas . . . 35

3 Solução actual do cmNavigo 37 3.1 Arquitectura geral do cmNavigo . . . 37

3.2 Dashboards actuais do cmNavigo . . . 38

3.2.1 Resource Key Performance Indicators (RKPI) . . . 38

3.2.2 Process Key Performance Indicators (PKPI) . . . 39

3.2.3 Overall Equipment Effectiveness (OEE) . . . 39

4 Simplificação do modelo de dados 41 5 Teste da solução proposta 47 5.1 Replicação dos dashboards do cmNavigo . . . 47

5.2 Dashboards embebidos na nova interface do cmNavigo . . . 52

6 Conclusões e Trabalho Futuro 57 Referências 59 A Vistas sobre o DW 61 A.1 Vista Completa (Pré-junção) . . . 61

(12)

(13)

Lista de Figuras

2.1 Magic Quadrant da Gartner, divulgado em Fevereiro de 2016. [Gara] . . . 6

2.2 Magic Quadrants da Gartner dos últimos quatro anos. [Gara] . . . 7

2.3 Interface do Power BI Desktop, com um dashboard de exemplo. . . 8

2.4 Interface de edição da fonte de dados (data source) no Power BI Desktop. . . 9

2.5 Lista de checkboxes num filtro para colunas textuais. . . 10

2.6 Exemplo de uma planta no Power BI. . . 10

2.7 Interrogações feitas nos modos de importação e DirectQuery. . . 11

2.8 Criação de parâmetros no Power BI . . . 12

2.9 Selecção de parâmetros no Power BI . . . 13

2.10 Interface de edição da fonte de dados (data source) no Tableau Desktop . . . 14

2.11 Exemplo de um dashboard no Tableau Desktop . . . 15

2.12 Criação de parâmetros no Tableau . . . 16

2.13 O primeiro valor da lista de parâmetros "Accessories"está seleccionado por defeito. 16 2.14 Ao seleccionar "Components", o Tableau actualiza o gráfico. . . 17

2.15 Interface de edição da fonte de dados (data source) do Qlik Sense. . . 18

2.16 Interface de criação de dashboards do Qlik Sense. . . 18

2.17 Interrogações feitas pelo Dundas BI. . . 21

2.18 Dashboard do Dundas BI. . . 22

2.19 Exemplo de uma planta de uma fábrica no Dundas BI. . . 23

2.20 Interface do Sisense ElastiCube Manager. . . 24

2.21 Dashboard de exemplo na interface Web do Sisense. . . 25

2.22 Interface de edição da fonte de dados no Syncfusion Dashboard Designer. . . 26

2.23 O Syncfusion pede para escolher uma junção ao adicionar uma nova tabela. . . . 27

2.24 O Syncfusion permite criar uma interrogação personalizada. . . 27

2.25 Interface de especificação dos dados de um widget. . . 28

2.26 Dashboard com um gráfico de barras e uma combobox. . . 29

2.27 O dashboard foi filtrado pela cor "Red". . . 29

2.28 Cor "Silver"adicionada ao dashboard. . . 30

2.29 Dashboard com duas comboboxes e com os filtros sem nada seleccionado. . . 31

2.30 Segunda combobox afectada pelo filtro "Red". . . 31

2.31 Seleccionada a categoria "Bikes"no dashboard. . . 32

2.32 Pelo SQL Server Profiler é possível ver o filtro por "Red"na interrogação. . . 33

2.33 Dashboard com as cores alteradas graças ao SDK. . . 34

2.34 Dashboard e interrogações duma filtragem por endereço. . . 35

3.1 Os três tipos de bases de dados envolvidos no cmNavigo e como se relacionam. . 37

3.2 DashboardRKPI no actual cmNavigo. . . 38

(14)

LISTA DE FIGURAS

3.4 DashboardOEE no actual cmNavigo. . . 40

4.1 Modelo de dados dimensional da tabela de factos FactMaterial e suas dimensões. 42 5.1 DashboardRKPI replicado no Syncfusion. . . 48

5.2 DashboardPKPI replicado no Syncfusion. . . 49

5.3 DashboardOEE replicado no Syncfusion. . . 49

5.4 DashboardRKPI replicado no Power BI. . . 50

5.5 DashboardPKPI replicado no Power BI. . . 50

5.6 DashboardOEE replicado no Power BI. . . 51

5.7 DashboardRKPI replicado no Tableau. . . 51

5.8 Interface HTML5 do cmNavigo com o dashboard RKPI embebido. . . 52

5.9 Interface HTML5 do cmNavigo com o dashboard PKPI embebido. . . 53

5.10 Interface HTML5 do cmNavigo com o dashboard OEE embebido. . . 53

(15)

Lista de Tabelas

(16)

(17)

Abreviaturas e Símbolos

AVA Availability

BI Business Intelligence CMF Critical Manufaturing

DBMS Database Management System DW Data Warehouse

ETL Extract, Transform and Load HTML HyperText Markup Language I&D Investigação e Desenvolvimento IIS Internet Information Services KPI Key Performance Indicator MDX MultiDimensional eXpressions MES Manufacturing Execution System MSSQL Microsoft SQL Server

MTBF Mean Time Between Failures MTTR Mean Time To Repair ODS Operational Data Store

OEE Overall Equipment Effectiveness PER Performance

PKPI Process Key Performance Indicator QUA Quality

RKPI Resource Key Performance Indicator RSS Rich Site Summary

SDK Software Development Kit SI Sistemas de Informação SP Stored Procedure

SQL Structured Query Language SSBI Self-Service Business Intelligence SSAS Microsoft SQL Server Analysis Services SSRS Microsoft SQL Server Reporting Services TI Tecnologias da Informação

UDF User-Defined Function URL Uniform Resource Locator UTC Coordinated Universal Time VizQL Visual Query Language

(18)

(19)

Capítulo 1

Introdução

1.1 Contexto/Enquadramento

Os sistemas de informação são um conceito bem conhecido dentro das empresas nos dias de hoje. O contributo destes é inegável para com a integração de todas as fontes de dados numa em-presa, tornando fácil e rápida a obtenção de informação útil por parte dos diferentes funcionários. Hoje em dia é possível a um gestor ter acesso quase instantâneo aos dados completos da sua empresa, mesmo que esta tenha departamentos em diferentes países ou continentes. Mas a tecnologia da informação (TI), além de unir o mundo, também reduziu o tempo de resposta. Uma linha de montagem pode gerar enormes quantidades de dados ao guardar para cada produto produzido milhares de medidas, ao qual se multiplica o número de produtos produzidos. E mesmo perante bases de dados com terabytes de informação, é possível extrair rapidamente indicadores dessa produção tais como saber o número de unidades produzidas por unidade de tempo ou o tempo médio de produção.

Ao permitir que as empresas tomem decisões com base em dados mais detalhados, mais cor-retos e de forma mais célere, estas podem crescer e esses dados tornam-se indispensáveis para se conseguirem diferenciar e obter mais lucro. Este processo foi apelidado de Business Intelligence (BI).

No entanto, houve e continuam a existir barreiras no caminho, sendo uma das mais relevantes a necessidade de especialistas de TI para implementarem consultas ou relatórios específicos a pedido dos utilizadores, pois nem todos os que procuram tirar proveito da informação armazenada na empresa têm conhecimento de como os dados da empresa estão estruturados ou de linguagens como SQL. Esta necessidade de ter um departamento de TI como intermediário cria atrasos e custos adicionais na obtenção de informação, reduzindo a capacidade de decisão da empresa.

Para responder a esta dificuldade surgiram ferramentas de Self-Service Business Intelligence (SSBI), que permitem ao utilizador interrogar as suas fontes de dados de uma forma fácil e in-tuitiva, sem necessidade de conhecer como a informação está estruturada e sem necessidade de

(20)

Introdução

conhecimentos técnicos. Isto pode ser feito permitindo-lhe, por exemplo, escolher o tipo de rela-tório e filtros como os dados financeiros do último trimestre, e depois escolher apenas a informação que lhe interessa como as receitas e as despesas. Os especialistas de TI continuam a ser neces-sários para instalar as interrogações necessárias, mas deixam de ser necesneces-sários para as executar, podendo os responsáveis da empresa obter informação útil de imediato, para além de terem a possibilidade de explorarem mais e melhor a informação armazenada.

A Critical Manufacturing (CMF), onde esta dissertação foi realizada, é uma empresa de de-senvolvimento de software focada na área da manufatura e tem no seu portfólio ferramentas de BI e SSBI. Um dos seus principais produtos é o Manufacturing Execution System (MES) cmNavigo, que é um sistema que faz a gestão de linhas de produção, como linhas de montagem, e através da automatização, monitorização e controlo dos processos produtivos consegue aumentar a eficiên-cia destas empresas. Mas os dados não servem apenas para o próprio sistema e para o nível de operação, também podem ser valiosos para as tomadas de decisão dos gestores.

Com este sistema torna-se possível monitorizar todo o processo de fabrico permitindo saber, por exemplo, quais os lotes de materiais utilizados na montagem de um determinado produto defeituoso. Isto é importante pois permite identificar e chamar de volta à fábrica todos os produtos com materiais defeituosos, evitando que coloquem em risco vidas, como nos casos de dispositivos médicos e airbags. Outras utilidades são a deteção de problemas nas máquinas, faltas de material ou necessidades de intervenção humana.

1.2 Motivação e Objetivos

As empresas têm consciência das vantagens que um sistema de informação lhes pode conferir, como são os clientes da CMF com o cmNavigo, e também das vantagens que uma ferramenta SSBI lhes pode conferir. No entanto, várias empresas que desejam este tipo de ferramentas não têm disponibilidade financeira para as adquirir, não só pelos custos consideráveis no licenciamento como também no investimento necessário em infraestrutura. Devido a isso, as soluções que o mercado atualmente oferece não são geralmente opção para essas empresas de menor dimensão.

E ainda há um outro problema, que é a personalização que cada empresa tem no seu modelo de dados. Isto significa que mesmo os clientes com um Data Warehouse (DW) só conseguem interrogar a parte do modelo de dados que vem de base no cmNavigo, sendo obrigados a pedir uma personalização ao DW ou o desenvolvimento de relatórios específicos, o que acresce ao custo total do projeto.

No entanto, mesmo clientes de menor dimensão demonstram interesse por ferramentas do tipo SSBI, pelo que se trata de um mercado ao qual a CMF quer chegar por via da implementação de uma ferramenta simplificada que possa ser integrada com o cmNavigo, de forma a que empresas de menores possibilidades também possam colher as vantagens do SSBI, aumentando a sua eficiência, o que é do interesse delas e da CMF.

(21)

Introdução

Além disto, está-se a fazer a transição da interface em Microsoft Silverlight do cmNavigo para uma nova em HyperText Markup Language versão 5 (HTML5). Os dashboards actualmente exis-tentes na primeira interface deixarão de existir e é necessário encontrar alternativas em HTML5 que sejam fáceis de criar e embeber na nova interface.

O objetivo deste trabalho de dissertação é o de desenvolver uma ferramenta protótipo de SSBI, que faça com que apenas os especialistas de TI necessitem de saber SQL e de como os dados estão estruturados, sendo encarregues de disponibilizar ao utilizador final meios de inquirir fáceis de usar. Essa ferramenta deve lidar com diferentes modelos de dados, devido às personalizações que cada empresa pode pedir por cima do modelo de base do cmNavigo.

O utilizador final deve ser capaz de produzir dashboards através de uma interface gráfica que seja fácil e intuitiva de usar e integrada no cmNavigo. Essa produção é composta pela escolha dos widgetse da respectiva fonte de dados.

Como tal, foram definidos os seguintes objetivos:

• Estudar as diferentes ferramentas de SSBI e de construção de dashboards existentes no mercado, procurando perceber quais as suas funcionalidades, vantagens e desvantagens, como abordam os diferentes desafios na implementação e se estas abordagens podem ou não ser aplicadas neste trabalho;

• Inquirir sobre as necessidades dos utilizadores que podem ser satisfeitas por uma ferramenta de SSBI, especialmente junto daqueles que trabalham com o MES cmNavigo, de forma a que o trabalho desenvolvido consiga ser bem recebido e usado nos seus sistemas;

• Estudar as diferentes abordagens à implementação de um modelo de dados simplificado, permitindo que o utilizador escolha de entre os dados que considera mais relevantes; • Conceber a solução, com base nos requisitos do cmNavigo, nas ferramentas a utilizar, nos

diferentes modelos de dados existentes e nas necessidades do front-end, de forma a se poder antecipar os desafios que existirão e procurar uma solução;

• Implementar o trabalho de uma forma iterativa, de forma a que a CMF e o orientador possam acompanhar o desenvolvimento da ferramenta e dar o seu feedback atempadamente; • Testar a ferramenta desenvolvida com o cmNavigo, usando dados reais ou semelhantes, de

forma a poder avaliar a correção, qualidade, eficiência e correspondência com as expectati-vas;

• Testar a ferramenta junto de alguns utilizadores finais, pessoas interessadas numa ferra-menta de SSBI, mas sem conhecimentos técnicos e de como os dados estão estruturados no sistema, de forma a avaliar a forma como a ferramenta desenvolvida é usada e a facilidade de uso, além de recolher sugestões.

(22)

(23)

Capítulo 2

Estado da arte das soluções de BI

O objectivo desta fase do trabalho é encontrar uma ferramenta que possibilite a um utilizador sem grandes conhecimentos técnicos criar os seus próprios dashboards, escolhendo os widgets e as fontes de dados.

Não sendo possível estudar todas as ferramentas que existem actualmente no mercado, procurou-se quais procurou-seriam as melhores ferramentas de BI. Esprocurou-se é um trabalho que a Gartner, Inc. realiza anualmente.

A Gartner é uma empresa especializada em análise e consultoria na área de apoio à decisão, com análises a centenas de áreas distintas [Garc]. As análises que permitem ter uma rápida visão geral da área são os Magic Quadrants [Garb], que apresentam as diferentes empresas da área num gráfico bidimensional, com um eixo a representar a capacidade da empresa conseguir executar as necessidade de hoje, e outro a representar o quão bem qualificadas e preparadas estão para responder às necessidades do futuro. As empresas que conseguem estar bem posicionadas em ambas as valências são apelidadas de líderes na área.

No relatório que lançou em 2016 sobre as soluções que existem na área de Business Intel-ligence, a Gartner considerou a Tableau, a Microsoft e a Qlik como empresas líderes do mer-cado [Gara], tal como se pode ver na Figura2.1. Desde 2013 - ano em que o Tableau entrou pela primeira vez na categoria dos líderes - que estas três empresas têm sido apresentadas como líderes. No arranque deste trabalho de dissertação, a análise mais recente, referente a Fevereiro de 2015, colocava o Tableau destacado, como o grande líder da área na capacidade de executar as necessidades de hoje. Mas durante a realização deste estado da arte, foi lançada a análise mais recente, de Fevereiro de 2016, onde já não aparece com o mesmo destaque, e com a Microsoft destacada na visão que tem para o mercado de BI.

O Tableau tem-se consolidado nos últimos anos como a ferramenta líder na área de Business Intelligence, como indicado nos respetivos quadrantes. A Gartner afirma que os pontos fortes do Tableau são a capacidade de execução, a versatilidade de instalação e uso, as diversas ofertas para aprendizagem e a grande quantidade de conectores para diferentes fontes de dados. Quanto aos

(24)

Estado da arte das soluções de BI

Figura 2.1: Magic Quadrant da Gartner, divulgado em Fevereiro de 2016. [Gara]

pontos negativos, foram apontados o preço elevado, alguma incapacidade de lidar com necessida-des complexas e uma fraca capacidade de integrar os dados provenientes de múltiplas fontes de dados. Esta forte opinião positiva, assim como as boas análises que possui, quer do jornalismo tecnológico, quer de clientes, levou à sua escolha para ser estudada neste trabalho.

O Power BI da Microsoft é uma ferramenta recente e que tem estado a agitar o mercado de BI. Em Fevereiro de 2016, a Gartner colocou a Microsoft como a empresa com a maior visão futura da área pela forma como consegue oferecer um dos preços mais reduzidos, combinado com muitas funcionalidades e novidades a saírem todas as semanas. A Microsoft, através dos eventos em que participa, tem-se mostrado bastante determinada em elevar a fasquia na oferta de BI através não só do elevado investimento e ritmo de evolução do Power BI, mas também pela aquisição da Datazen, especialista em BI para dispositivos móveis, da colaboração com a Pyramid Analytics e

(25)

Figura 2.2: Magic Quadrants da Gartner dos últimos quatro anos. [Gara]

das novidades reveladas em redor do SQL Server Reporting Services 2016. Os pontos negativos da ferramenta são apontados como a juventude do Power BI, a falta de capacidades de análise avançadas e as frequentes alterações de preços e requisitos. Devido aos preços competitivos e boas opiniões, esta ferramenta também foi incluída na análise.

Por fim, devido à boa opinião da Gartner sobre a Qlik ao longo dos últimos anos, esta empresa entrou no estudo através da ferramenta QlikSense, que é a mais orientada para SSBI. A Gartner salienta as soluções da Qlik pela facilidade de utilização e análises complexas que é capaz de fazer. Também possui várias fontes de dados e consegue ligá-las com maior facilidade que a concorrên-cia. Nos pontos negativos estão os preços calculados de forma complexa, preços elevados, suporte abaixo da média e a falta de aposta nos dispositivos móveis e na Cloud.

(26)

O estudo começou pelo Power BI visto que, de entre as três ferramentas, é consideravelmente mais barata.

2.1 Microsoft Power BI

O Power BI foi apresentado pela Microsoft em Setembro de 2014, confirmando uma crescente aposta da empresa na área de Business Intelligence, depois de fortalecer o Excel com o Power Map, Power Pivot, Power Query e Power View.

A ferramenta foi disponibilizada inicialmente somente para empresas, tendo sido lançada pu-blicamente no dia 24 de Julho de 2015, contando nessa altura com mais de 500 mil utilizadores de 45 mil empresas [Corc].

A CMF utiliza toda a stack de soluções da Microsoft, incluindo o Microsoft SQL Server (MSSQL), pelo que o primeiro requisito para todas as ferramentas que viessem a ser estudadas era a capacidade de recolher a informação de tabelas, vistas, User-Defined Functions (UDF) e Stored Procedures (SP) destes sistemas.

Para realizar os estudos foi necessário ter uma base de dados com uma estrutura e dados interessantes para testar, mas sem ser computacionalmente exigente. Para o estudo inicial das ferramentas optou-se por instalar um servidor de SQL Server localmente, com a base de dados AdventureWorks. A utilização dos servidores da CMF e respectivos dados ficou para uma fase de análise mais avançada.

Figura 2.3: Interface do Power BI Desktop, com um dashboard de exemplo.

(27)

O carregamento dos dados da fonte de dados é simples, através de um wizard que pergunta o nome do servidor, os dados de autenticação, o nome da base de dados, quais as tabelas, vistas ou funções a carregar e qual o modo de importação a utilizar. Existem dois modos de importação, que diferem na influência que têm na frescura dos dados recolhidos e na máquina onde faz a filtragem. A primeira opção é um simples importar de todos os objectos (Tabelas, Vistas, etc.), fazendo as operações localmente, como junções e filtragens. A outra opção é o DirectQuery, que interroga a base de dados sempre que se alteram as relações ou um filtro no dashboard.

Caso se importem tabelas que tenham relações de chaves secundárias entre elas, o Power BI automaticamente cria as relações, permitindo agregações.

No caso das relações criarem ciclos, o Power BI não estabelece as relações suficientes para o impedir. É possível gerir estas relações e o Power BI nunca permite que se active uma relação que crie um ciclo.

Figura 2.4: Interface de edição da fonte de dados (data source) no Power BI Desktop.

Depois de ter o modelo de dados pretendido, avançou-se para a criação de um dashboard que permitisse explorar a quantidade e relevância dos widgets do Power BI e o detalhe com que é pos-sível editá-los tanto a nível de filtros, como a nível de design. Em todos estes pontos, a ferramenta mostrou-se muito completa, com todos os widgets que se podiam esperar de um dashboard. E a edição do design vai longe o suficiente para, por exemplo, permitir escolher se se quer um título para o widget ou não, e qual o texto, tamanho e cor deste ou quais as cores a utilizar nesse widget. No que toca aos filtros, o Power BI permite filtrar quer ao nível visual do widget, quer da página, quer de todo o relatório, e permite-o por qualquer uma das colunas importadas, sem recorrer a SQL.

(28)

Figura 2.5: Lista de checkboxes num filtro para colunas textuais.

De seguida, explorou-se a ferramenta para conhecer se é possível criar e adicionar widgets personalizados ao Power BI. O supervisor referiu alguns widgets, que não constavam no Power BI, que seriam interessantes. Um deles era ser possível ter a planta da fábrica do cliente, destacando cada máquina ou área de forma dependente das métricas aplicadas, como o Uptime/Downtime, o Mean Time Between Failures(MTBF) ou o Mean Time To Repair (MTTR).

Foi encontrado um widget externo desenvolvido pela SQLBI chamado Synoptic Panel que permitiria realizar esse widget. A simplicidade de criação e uso das plantas impressionou, visto que basta ir à página http://synoptic.design/, importar uma imagem, desenhar as áreas que se pre-tende e dar-lhes o nome ao qual estarão associadas no dashboard, por exemplo o ID da máquina. Depois, é só seleccionar o widget Synoptic Panel e escolher a dimensão, como o ID da máquina, e a medida, como o MTBF. A Figura2.6mostra uma planta de exemplo, com valores associados a cada divisão e coloridas de acordo com intervalos de valores especificados.

Figura 2.6: Exemplo de uma planta no Power BI.

Para além disso, foi explorada a possibilidade de criar os próprios widgets, algo que a Micro-soft permite que seja feito no seu Power BI online, recorrendo à linguagem TypeScript [Cora].

(29)

De seguida, avançou-se para o estudo da forma como o Power BI inquire e recolhe os dados do SQL Server, nomeadamente, se utiliza os filtros escolhidos no dashboard. Isto é importante pois as bases de dados do cmNavigo possuem grandes quantidade de dados, podendo tornar a interrogação excessivamente demorada e pesada. Por este motivo era importante saber se o Power BI, na interrogação que faz à base de dados, utiliza os filtros definidos no dashboard, importando com um tamanho gerível.

Recorrendo ao SQL Server Profiler foi possível ver que o Power BI diverge neste ponto entre os dois modos de importação, com e sem o DirectQuery. No lado esquerdo da Figura2.7estão as interrogações feitas no modo de importação, pedindo todos os valores. No lado direito, estão as interrogações feitas no modo DirectQuery quando se filtra por "Accessories", "Bikes"e "Clothing". No modo de importação não há filtros, pois são feitos na própria máquina, ao contrário do Direct-Query.

Figura 2.7: Interrogações feitas nos modos de importação e DirectQuery.

Quando o modo escolhido é o de importação, o Power BI inquire pedindo individualmente todos os objectos no modelo quando estes são escolhidos. Quando as relações ou filtros são altera-dos, não ocorrem interrogações ao SQL Server, dando a entender que são feitos localmente. Esta solução pode ser vantajosa quando há memória suficiente para os dados e não se quer realizar pro-cessamento no servidor, tendo a desvantagem dos dados não serem frescos aquando da abertura do

(30)

dashboard, sendo necessário pedir uma actualização manual dos dados para importar novamente os objectos, além de poder ser impraticável o uso sobre objectos de grandes dimensões.

Quando o modo escolhido é o DirectQuery, e sempre que os filtros são alterados, o Power BI interroga a base de dados para obter um novo dataset. Para o fazer recorre apenas a uma interro-gação, com um JOIN entre todas as tabelas e um WHERE no final com o filtro definido, tal como mostra o SQL Server Profiler na Figura2.7. No entanto, caso a interrogação já tenha sido feita du-rante a sessão, não é feita qualquer interrogação, o que significa que recorre a um armazenamento temporário de todas as interrogações feitas durante a sessão do dashboard. Portanto, o Power BI deixa para o SQL Server todas as operações sobre os dados, evitando a importação de grandes volumes de dados.

De seguida, tratou-se de estudar se era possível criar argumentos, utilizáveis em interrogações, que pudessem ser manipulados pelo dashboard. O objetivo era saber se era possível, por exemplo, manipular os argumentos de uma User-defined Function ou Stored Procedure através do dashbo-ard. Na altura em que a ferramenta foi estudada, não foi encontrado como o fazer, mas numa actualização a 28 de Abril foi incluída uma funcionalidade que satisfaz este requisito [Cord].

Através do menu de edição das interrogações, é agora possível criar um Parâmetro, definir o seu tipo, valores e valor por defeito, e utilizá-lo, por exemplo, numa função, tal como exemplifi-cado na Figura2.8.

Figura 2.8: Criação de parâmetros no Power BI

Na Figura2.8é possível ver a função dbo_ufnGetInventorycom Category como argu-mento, que é o parâmetro criado. O parâmetro Category é do tipo texto e possui um lista de valores

(31)

introduzidos manualmente. Outra opção seria permitir que o utilizador escrevesse o texto a passar como argumento.

Voltando ao dashboard, é possível alterar o valor do parâmetro através do botão Edit Queries e depois Edit Parameters. No menu aparecem os parâmetros existentes e respectivas opções. Ao premir OK o Power BI automaticamente volta a carregar o dataset utilizando o novo valor como argumento da função. Este menu é mostrado na Figura2.9.

Figura 2.9: Selecção de parâmetros no Power BI

Por fim, no que toca à publicação dos dashboards, de momento, apenas é possível publicá-los para a Cloud do Power BI. Assim, para visualizar um dashboard sem a necessidade de ter o Power BI instalado ou através de dispositivos móveis, este tem de estar alojado na Cloud disponibilizada pela Microsoft. E este é, para a Critical Manufacturing, um factor eliminatório. A confidenciali-dade da informação presente nos sistemas não permite que sejam publicados na Cloud porque iria contra as políticas de segurança dos clientes. Este é o maior ponto negativo do Power BI e que impediu que fosse a ferramenta escolhida.

A Microsoft colocou no seu roadmap [Corb] e anunciou numa conferência [Core] que no futuro será possível publicar os dashboards no SQL Server Reporting Services (SSRS), mas não forneceu quaisquer datas, pelo que se optou por descartar esta ferramenta. O trabalho deverá ter em conta uma possível migração para o Power BI, se no futuro se justificar.

(32)

2.2 Tableau Software

Entre 1999 e 2002, o professor Pat Hanrahan da Universidade de Stanford e um dos seus alu-nos, Chris Stolte, procuraram comercializar o seu trabalho, que consistia numa nova linguagem num sistema que a utilizava. A Visual Query Language (VizQL) combinava SQL com uma lin-guagem descritiva para renderização gráfica [Pat06] e era o núcleo do Polaris, uma interface de visualização de dados armazenados [PCD]. Em 2003 é então fundada a Tableau Software, que se dedica a desenvolver produtos na área de BI.

Recentemente, no anúncio dos resultados fiscais referentes a 2015, reveleram receitas de 654 milhões de dólares, com 424 a referirem-se exclusivamente a licenças vendidas aos mais de 39 mil clientes [Sofb] [Sofa]. Estes fortes resultados, somados às análises da Gartner, colocam-na como uma ferramenta líder no mercado de BI, pelo que faz todo o sentido explorar o Tableau e perceber se pode ser a solução.

Figura 2.10: Interface de edição da fonte de dados (data source) no Tableau Desktop

O Tableau Desktop, ferramenta para a criação de dashboards, tem uma forma muito seme-lhante à do Power BI no que toca à escolha de uma fonte de dados SQL Server, pedindo o nome do servidor, autenticação e nome da base de dados. As escolhas seguintes são distintas pois o Tableau não possui a mesma capacidade de automatizar as relações como o Power BI. Isto porque vê o primeiro objecto (Tabela, Vista ou Função) como uma espécie de tabela de factos, procurando ligar todos os objectos importados a seguir ao primeiro objecto, como se fossem as suas dimen-sões. Cabe ao utilizador corrigir as associações erradas. Na Figura2.10é possível ver as tabelas relacionadas entre si.

(33)

No que toca à criação dos widgets, há grandes diferenças. O Tableau possui uma grande riqueza, não tanto na diversidade de widgets, que é muito boa, mas pela personalização que lhes pode conferir, juntando a isso uma interface intuitiva e simples de utilizar, o que confere uma boa experiência ao utilizador.

Em relação à publicação de dados provenientes do SQL Server, o Tableau Desktop possui dois destinos distintos:

• Uma solução na Cloud, apelidada de Tableau Online, que não é solução pelo mesmo motivo da Cloud do Power BI, as políticas de segurança não permitirem que os dados saiam da intranet;

• E uma solução on-premises, apelidada de Tableau Server. Cabe ao Tableau Desktop pu-blicar para um servidor com este software, que por sua vez o disponibiliza através de uma página Web. Desta forma, apenas quem necessita de criar os dashboards é que deve ter o Tableau Desktop instalado no seu computador, podendo os colegas aceder através da Web, sem qualquer outro requisito para além do browser.

Figura 2.11: Exemplo de um dashboard no Tableau Desktop

Mostra-se então possível publicar on-premises, cumprindo este requisito fundamental. Durante este estudo analisou-se também se era possível criar interrogações personalizadas e utilizar argumentos nessa interrogação que pudessem ser manipulados pelo dashboard. O objetivo era saber se era possível, por exemplo, manipular os argumentos de uma UDF ou SP através do dashboard.

(34)

O Tableau permite criar de forma bastante simples interrogações personalizadas, bastando para isso ir ao editor da fonte de dados, clicar em New Custom SQL e introduzi-la. Para introduzir um novo parâmetro, basta escolher a opção “Insert Parameter”, depois “Create a new Parameter”, definir o seu nome, tipo e valor por defeito e fazer Ok.

Figura 2.12: Criação de parâmetros no Tableau

Depois de criado o parâmetro, na lista de medidas e dimensões do dashboard, surge o nome desse parâmetro personalizado, sendo possível arrastá-lo e utilizá-lo no dashboard e, inclusiva-mente, alterá-lo através dos filtros. Isto significa que, por exemplo, seria possível obter os dados de uptime, MTBF e MTTR para determinados equipamentos ou intervalo de tempo.

(35)

Figura 2.14: Ao seleccionar "Components", o Tableau actualiza o gráfico.

Um dos pormenores importantes do Tableau era saber qual o seu preço. Como é pretendida uma solução on-premises, o Tableau Server é a única opção. Este tem, no pacote mais barato de 10 utilizadores, um preço de 10 mil dólares no primeiro ano e 2 mil e quinhentos por ano nos restantes. Foi considerado um preço excessivo, principalmente para uma solução que se queria de baixo custo e que chegasse a empresas de menores orçamentos, tendo o Tableau sido descartado.

2.3 Qlik Sense

A Qlik foi fundada na Suécia em 1993, como uma empresa de software na área de BI. Três anos após, foi lançado o QlikView, ferramenta de exploração e análise de dados que até hoje tem sido aperfeiçoada e é tida como uma das líderes na área pela Gartner. Mas embora a ferramenta seja poderosa, não é fácil de aprender a utilizar e requer algum nível de conhecimentos tecnoló-gicos. Posteriormente, surgiu o QlikSense, uma ferramenta de SSBI fácil e intuitiva para criação de dashboards. Não tem a complexidade de análise e exploração do QlikView, mas tem a sim-plicidade de criação de visualizações, permitindo a exploração dos dados e posterior criação de dashboardssem grandes conhecimentos iniciais.

O QlikSense mostrou-se simples de utilizar. O carregamento dos dados é feito tal e qual os concorrentes Power BI e Tableau, que apenas diferem nas junções. Esta ferramenta não cria relações entre os objectos automaticamente como o Power BI, mas é capaz de sugeri-las, dizendo inclusivamente qual o seu grau de certeza quanto à sugestão.

Trabalha com o SQL Server, um requisito fundamental, e produz dashboards facilmente. A Qlik tem soluções Cloud, já rejeitadas devido às políticas de segurança das empresas da área da manufactura, pelo que a única solução para empresas é a Qlik Sense Enterprise, que tem um preço baseado em “tokens”. Um token pode ser utilizado para conceder uma licença ilimitada a um utilizador ou para conceder 10 acessos de 1 hora a utilizadores por mês. A empresa disponibiliza um PDF [AB] a explicar o funcionamento dos tokens, o que também deixa perceber que eles próprios reconhecem a complexidade do cálculo dos preços.

(36)

Figura 2.15: Interface de edição da fonte de dados (data source) do Qlik Sense.

(37)

Cada token custa actualmente mil e quinhentos dólares no momento da aquisição e depois 300 dólares (20%) por ano. Comparando com o Tableau, que para o preço base com 10 utilizadores custa 10 mil dólares no primeiro ano e 2 mil e quinhentos por ano nos seguintes, o Qlik Sense Enterprise para os mesmos 10 utilizadores custa:

• 15 mil dólares no primeiro ano e 3 mil por ano nos seguintes no caso de terem todos acesso ilimitado;

• 7 mil e quinhentos dólares no primeiro ano e mil e quinhentos dólares por ano nos seguintes no caso que a Qlik coloca como o mais comum, que é o de cada utilizador fazer 4 acessos mensais, a que se adiciona mais 20% de acessos de folga, resultando na necessidade de 5 tokens.

Não sendo significativamente mais barato que o Tableau, acrescido à complexidade no cálculo do preço, o estudo do Qlik Sense ficou-se por aqui.

2.4 Conclusão do estudo das três soluções

Estudaram-se as três ferramentas líderes da área de BI segundo a Gartner, sem que nenhuma tivesse satisfeito as necessidades de publicação ou de preço acessível. Por esse motivo a pro-cura alargou-se a outras ferramentas potencialmente interessantes nos quadrantes da Gartner, mas também a ferramentas de simples criação de dashboards, sem as funcionalidades de exploração, análise ou previsão das de BI, mas que permitissem ainda assim a criação de dashboards a partir de dados retirados do SQL Server.

Dos quadrantes da Gartner, explorou-se, para além das três líderes, o Sisense. As restantes foram excluídas:

• Pelo seu preço excessivo, naquelas em que é possível sabê-lo facilmente, como a SAP Bu-siness Objects, SAS ou Information Builders;

• Pela falta de acesso à ferramenta, inclusivamente para experimentar, como no caso da Birst, que apenas disponibiliza demonstrações da ferramenta aos interessados.

Para além do Sisense, adicionou-se à lista de ferramentas a explorar, o Klipfolio e o Dundas BI, por serem duas ferramentas com vários prémios e boas opiniões, além de anunciarem for-tes clienfor-tes internacionais, como a Intel, Google, Adobe, IKEA, Deloitte, Philips ou BMW, no primeiro caso, e a Coca-Cola, Siemens, HP, Microsoft ou a farmacêutica Bayer, no segundo caso. Por serem ferramentas de criação de dashboards conhecidas de colegas da CMF, também foram adicionadas à lista as soluções da Telerik e da Syncfusion.

O estudo das três ferramentas anteriores permitiu ganhar algum conhecimento sobre as fun-cionalidades das ferramentas na área de BI, o método de como as estudar e também uma melhor definição dos objectivos do estudo e requisitos que as ferramentas devem preencher. Por este

(38)

motivo foi desenvolvida uma lista de requisitos, de forma a fazer uma análise sistemática às ferra-mentas seguintes. Esta lista, mais tarde, serviu para criar uma tabela de comparação de todas as ferramentas estudadas.

A lista de requisitos inclui:

• Se é possível importar dados on-premises do SQL Server. Requisito eliminatório. A ferramenta deve ser capaz de recolher dados de um servidor local de SQL Server visto ser a DBMS do cmNavigo e os dados não deverem sair da intranet.

• Como é feita a interrogação e carregamento dos dados.

Se os dados são importados e interrogados localmente ou se são feitas interrogações di-rectamente à fonte de dados. A importação pode colocar problemas de descarregamento e operação local de datasets de grandes dimensões, além da frescura dos dados. No entanto, uma boa capacidade de filtragem e actualização dos dados pode ultrapassar este problema. • Intuitividade, simplicidade e funcionalidade dos dashboards.

A ferramenta final deve ser intuitiva e fácil de usar de forma a que utilizadores sem co-nhecimentos técnicos consigam criar dashboards, devendo ser apontadas dificuldades de utilização pertinentes.

• Se é possível publicar os dashboards num servidor on-premises. Requisito eliminatório. Devido às políticas de segurança das empresas de manufactura, que procuram proteger pa-tentes, processos e dados de fabrico, os dados nunca devem sair da rede da empresa. As soluções de BI deverão ser on-premises, descartando soluções Cloud, como acontece actu-almente com o Power BI.

• Se tem uma versão móvel e se é aplicação ou uma página responsiva.

O crescimento do mercado e desempenho dos dispositivos móveis tornou possível aceder a várias aplicações que antes eram exclusivas dos computadores pessoais. Hoje os utilizadores querem ter acesso à informação no smartphone ou tablet em qualquer lado. As ferramentas de BI oferecem soluções bastante díspares nesta matéria. Umas oferecem aplicações nativas como o Power BI ou o Tableau, outras oferecem interfaces Web responsivas e outras ainda não apresentam qualquer solução móvel.

• Se permite a criação e adição de widgets (visualizações) personalizados

Embora não seja fundamental que o dashboard possua uma planta de uma fábrica, como foi estudado com o Power BI, este é um factor diferenciador. E, para além deste caso, poderão existir outros que a CMF pretenda cobrir, pelo que convém perceber se a ferramenta em causa permite ou não a criação e adição de novos widgets.

• Como são calculados os preços e quais os preços

Com duas ferramentas estudadas excluídas e outras excluídas da selecção devido ao preço excessivo, é importante saber qual o preço das ferramentas a estudar, inclusivamente nos casos onde este não é divulgado publicamente e é necessário contactar a equipa de vendas.

(39)

2.5 Klipfolio

Fundada em 2001 no Canadá, a Klipfolio Inc. é uma uma empresa de software cujo foco se concentrou na área de BI em 2007 quando se aperceberam do sucesso do seu dashboard, inicial-mente desenvolvido para agregadores de notícias e RSS.

O Klipfolio possui um criador de dashboards na Cloud, tal como o Power BI, só que sem qualquer tipo de solução de desenvolvimento on-premises. Ou seja, os dados seriam trabalhados fora da rede da empresa. Embora rapidamente descartado, o pormenor da criação dos dashboards necessitar de ser igualmente on-premises foi adicionado à lista de requisitos.

Foi possível verificar que o Klipfolio importa dados de um servidor SQL Server e possui uma página responsiva para lidar com dispositivos móveis. Recolher os preços só faria sentido numa comparação com as ofertas na Cloud do Power BI, Tableau e QlikSense, mas não teria relevância para o objectivo deste estudo por não serem on-premises.

2.6 Dundas BI

A Dundas Software foi fundada em 1992 no Canadá como uma empresa de desenvolvimento de soluções para visualização de dados, nomeadamente dashboards. O seu sucesso levou à aqui-sição de algumas das suas soluções pela Microsoft em 2007 para integrar o SSRS a partir do SQL Server 2008, nomeadamente o Dundas Chart, Dundas Map, Dundas Gauge e Dundas Calendar. Convém frisar que a empresa em si não foi comprada, mas sim as soluções referidas.

Figura 2.17: Interrogações feitas pelo Dundas BI.

O Dundas BI é uma solução on-premises, tal como exigido pelos requisitos, mas ao contrário das três ferramentas líderes estudadas anteriormente, esta tem uma interface totalmente baseada na Web. Ou seja, o servidor Dundas BI disponibiliza um serviço Web capaz de funcionar numa intranet, onde é possível criar os dashboards, para além de ser onde ficam publicados e de onde podem ser visualizados.

O Dundas BI importa de SQL Server, preenchendo esse requisito fundamental. No que toca à forma como interroga os dados, interroga a base de dados de forma simples, com as junções

(40)

necessárias, conforme demonstrado pelo SQL Server Profiler na Figura2.17, onde é possível ver uma interrogação para cada dataset utilizado no dashboard.

O servidor recorre a uma cache interna [DDV] para armazenamento das interrogações que foram feitas, de forma a aumentar o desempenho dos dashboards e diminuir a carga na base de dados, algo que foi possível comprovar visto que as interrogações foram feitas apenas uma vez, no primeiro carregamento do dashboard. O recarregamento da página do dashboard ou o reiniciar limpo do navegador não obrigam o servidor a actualizar o dataset interrogando novamente a base de dados. Apenas foi possível forçar esse refrescamento dos datasets com um reiniciar do servidor através do Internet Information Services (IIS) Manager.

Figura 2.18: Dashboard do Dundas BI.

Toda a interface Web do Dundas BI é responsiva, o que a torna mais fácil de utilizar em dispositivos móveis. No entanto, os dashboards não se adaptam às dimensões dos ecrãs, pelo que devem ser criados propositadamente. O maior exemplo da falta de adaptação é não conseguir visualizar adequadamente um dashboard feito para um ecrã na horizontal num dispositivo que esteja com a orientação na vertical.

No que toca a visualizações personalizadas, esta solução não só o permite, como já disponibi-liza de raiz um widget de diagramas que permite, nomeadamente, a readisponibi-lização do caso das plantas de fábricas. Um exemplo fornecido pela Dundas é exactamente esse, mostrando a planta de uma fábrica com cada zona a ser colorida de acordo com um intervalo de valores mostrado em legenda (Figura2.19).

Como o preço não é público e não foi encontrado nada para além de comentários online sobre o custo da ferramenta, foi necessário contactar a equipa de vendas.

(41)

Figura 2.19: Exemplo de uma planta de uma fábrica no Dundas BI.

O Dundas BI possui dois pacotes distintos. Um primeiro, dependente do número de utiliza-dores e utilização do servidor, que torna o pagamento complexo e imprevisível, o que é algo que a CMF pretende evitar. E o segundo, com número ilimitado de instalações, para empresas que procuram integrar a solução nos seus próprios produtos, como é o caso. O custo é de 6 mil e qui-nhentos dólares anuais mais uma percentagem das receitas do produto onde será embebido, neste caso, o cmNavigo, o que a CMF igualmente rejeitou.

2.7 Telerik Reporting e Report Server

A Telerik é uma empresa de software búlgara fundada em 2002 e adquirida em 2014 pela Progress Software. No seu portfólio conta com diversas soluções de interfaces gráficas e de visu-alização de dados e de navegação, para diversas tecnologias, entre as quais ASP.NET e Microsoft Silverlight. As suas soluções para Silverlight levaram a que a CMF tenha constituído uma parceria com a Telerik para potenciar a actual interface do cmNavigo.

O programa Telerik Report Designer, ferramenta on-premises para desenvolvimento de rela-tórios, tem uma interface familiar, semelhante às que a Microsoft desenvolveu para o Office ou o explorador de ficheiros do Windows. Esta ferramenta foi capaz de importar os dados do MS-SQL, utilizá-los para criar relatórios semelhantes aos que se encontram no SSRS e publicar esses relatórios no Report Server instalado.

Com o Report Server foi possível visualizar através de um navegador os relatórios criados e o MSSQL Profiler mostrou que faziam as interrogações, a cada carregamento da página Web.

O preço do Report Server é de 1499 dólares anuais, com direito a 15 utilizadores. Para permitir o acesso de mais utilizadores ao servidor, a Telerik vende incrementos de 5 a 500 dólares cada

(42)

incremento. Este é pago apenas uma vez. A licença do Report Designer vai dos 599 aos 1999 dólares anuais. Os pacotes mais caros incluem outros produtos de desenvolvimento de interfaces. Os 2098 dólares anuais são um preço bem mais apelativo que as ferramentas anteriores.

No entanto, a ferramenta e os relatórios criados mostraram-se visualmente antiquados e ne-cessitariam de trabalho adicional para serem embebidos na interface HTML5 mais recente do cmNavigo. Por esse motivo avançou-se para o estudo da ferramenta seguinte.

2.8 Sisense

A Sisense é uma empresa de software israelita fundada em 2004 que lançou em 2010 a sua solução atual de BI.

A criação de dashboards é diferente de todas as outras ferramentas estudadas. O Sisense possui um programa à parte para definir a fonte de dados, o Sisense ElastiCube Manager. Toda a criação e visualização de dashboards é feita através do servidor Web Sisense, que disponibiliza uma página Web onde se pode seleccionar a fonte de dados definida no referido programa.

Figura 2.20: Interface do Sisense ElastiCube Manager.

O ElastiCube é a solução do Sisense para as necessidades de BI. O Sisense ElastiCube Mana-ger (Figura2.20) é uma ferramenta de Extract, Transform and Load (ETL) que permite a impor-tação de dados de diversas fontes, entre as quais o MSSQL, relacionar as colunas dos diferentes objectos, manipular esses dados e, no final, preparar um dataset para ser utilizado pelos dashbo-ards.

(43)

Estes ElastiCubes podem ser definidos com dois modos diferentes de actualização dos dados: • Definir um intervalo de tempo após o último build, por exemplo, fazer builds de 30 em 30

minutos;

• Ou especificar uma hora de criação do build, podendo ser ainda definido em que dias se pretende que o build ocorra, por exemplo, fazer builds todos os dias úteis às 6 da manhã. Este intermediário na obtenção dos dados tem os seus pontos positivos e negativos. Os as-pectos positivos residem no facto de não ser necessário inquirir frequentemente a base de dados, através da realização espaçada de builds frequentes ou em horas de menor processamento, redu-zindo a carga sobre o sistema e obtendo os dados de forma mais célere. Por outro lado, os dados não são os mais actuais.

Figura 2.21: Dashboard de exemplo na interface Web do Sisense.

Estando a fonte de dados definida e o build concluído, já pode ser utilizada pelos dashboards. Ao aceder ao servidor Web do Sisense para criar o dashboard, a primeira coisa que temos de indicar é o nome do Elasticube que vai ser utilizado. A partir daqui, a criação do dashboard dá-se de forma semelhante às restantes ferramentas testadas: escolha do widget, das colunas que irão compôr os seus eixos e métricas e as habituais opções para filtrar ou alterar o aspecto visual do widgetescolhido. As páginas Web do Sisense também mostraram ser responsivas.

O único problema encontrado no Sisense foi o preço. O pacote base, para 1 licença de edição, 10 licenças de visualização e 75 milhões de transacções por Elasticube fica por 20 mil dólares anuais. O dobro do pacote base do Tableau no primeiro ano e oito vezes mais caro nos anos seguintes. Para cada licença de criação adicional acresce mil dólares anuais e por cada licença de visualização mais 450 dólares.

(44)

2.9 Syncfusion Dashboard Platform

Fundada em 2001, a empresa de desenvolvimento de software Syncfusion tem actualmente sede na Carolina do Norte dos Estados Unidos da América. O seu portfólio tem algumas seme-lhanças com o da Telerik, contando com várias frameworks para tecnologias Web e dispositivos móveis, e também soluções de BI, para o desenvolvimento e gestão de dashboards e relatórios.

Figura 2.22: Interface de edição da fonte de dados no Syncfusion Dashboard Designer.

A sua solução para dashboards, Dashboard Platform, divide-se entre um programa on-premises de criação de dashboards, Dashboard Designer, e um servidor Web para a publicação e gestão dos dashboards, o Dashboard Server.

Na criação de uma fonte de dados, depois dos habituais dados de acesso ao servidor e base de dados, o Syncfusion mostra o modelo de dados (Figura2.22) dividido pelos diferentes esquemas e dentro de cada um tem os objectos organizados pelos diversos tipos, nomeadamente Tabelas, Vistas e Stored Procedures. Em baixo estão os dados do dataset.

Depois de inserido o primeiro objecto na fonte de dados, a cada nova inserção o Syncfusion pede para que seja definida a junção (Join) com algum dos objectos já inseridos (Figura2.23). Ou seja, o Syncfusion obriga a que uma fonte de dados tenha os seus objectos todos ligados, de forma a que resulte num só dataset. No entanto, é possível criar e utilizar várias fontes de dados num dashboard.

Para além de ser possível definir a fonte de dados arrastando os objectos pretendidos, também é possível defini-lo escrevendo o código manualmente (Figura2.24). Na barra superior é possível alterar para a vista de código para introduzir código SQL personalizado.

(45)

Figura 2.23: O Syncfusion pede para escolher uma junção ao adicionar uma nova tabela.

(46)

O desenvolvimento visual do dashboard também é baseado no arrastamento de um dos widgets disponíveis para o dashboard, sendo necessário editá-lo individualmente para lhe associar os dados de uma fonte de dados, para além das personalizações visuais.

Na definição dos dados de um widget (Figura2.25), escolhe-se a fonte de dados da lista e são listadas as diferentes colunas entre medidas, valores numéricos e dimensões, datas e strings. Estas colunas podem ser arrastadas para os campos de valores e colunas, sendo que em alguns casos podem constar várias colunas, formando uma hierarquia onde é possível fazer drill-down. Também é possível criar colunas personalizadas, contendo valores por omissão ou calculados através de outras colunas.

Figura 2.25: Interface de especificação dos dados de um widget.

As definições visuais permitem desligar e ligar diferentes funcionalidades, como o título do widget, os nomes dos eixos e as legendas. Não permite alterar as cores dos gráficos através deste menu de personalização ao invés de outras ferramentas estudadas.

Para além de widgets de visualização como gráficos de barras, gráficos de linhas, gráficos de área, gráficos circulares ou KPI, o Syncfusion também disponibiliza widgets que permitem filtrar os dados através do dashboard. Um widget de combobox dá ao utilizador a escolher um valor ou múltiplos valores de entre uma lista de opções. Essa lista é obtida escolhendo uma das colunas da fonte de dados, da qual o Syncfusion irá buscar os valores distintos.

Na Figura2.26temos uma combobox que filtra os dados pela cor escolhida. Ao escolher a cor vermelha (Red) apenas são mostradas duas barras das quatro originais pois as duas retiradas não contêm qualquer elemento com a cor vermelha e vice-versa (Figura2.27). Os valores também reduziram. Também é possível filtrar por múltiplos elementos. Na Figura 2.28é mostrado um

(47)

Figura 2.26: Dashboard com um gráfico de barras e uma combobox.

(48)

Figura 2.28: Cor "Silver"adicionada ao dashboard.

filtro pela cor vermelha (Red) e prateada (Silver) surgindo uma terceira barra no gráfico, além de um aumento dos valores.

Sobre os filtros convém acrescentar que, no caso de existirem múltiplos widgets de filtragem, estes influenciam-se mutuamente. Assim, num dashboard com duas comboboxes, se filtrarmos numa delas, a outra combobox poderá aparecer com menos elementos, fruto de esses elementos filtrados não preencherem os requisitos da filtragem feita como se demonstra nas (Figura2.29) e (Figura 2.30). O mesmo acontece caso se filtre na segunda combobox. A primeira actualiza-se com menos elementos por não satisfazerem os requisitos da segunda filtragem(Figura2.31).

Para desfazer os filtros têm-se 3 alternativas. Pode-se seleccionar a opção All em cada widget, pode-se carregar no ícone no canto superior direito para desfazer o filtro desse widget ou pode-se desfazer os filtros todos do dashboard de uma vez só, indo ao Filters Overview, no canto superior direito do dashboard.

O Syncfusion Dashboard Designer possui um botão de pré-visualização no canto superior direito que permite ver a aparência do dashboard num navegador, criando uma página Web pelo IIS Express com o dashboard.

Para publicar efectivamente o dashboard é necessário ter uma máquina com o Dashboard Server instalado. Quando se tenta publicar a partir do Dashboard Designer, é necessário introduzir o endereço e porta do Dashboard Server, juntamente com os dados de autenticação, que podem ser do painel de gestão do Syncfusion ou do Windows. Depois da autenticação no servidor, é permitido ao utilizador publicar o dashboard, introduzindo dados como a pasta onde este deverá ser guardado, título e descrições. Depois de publicado, o utilizador pode optar por ver o dashboard através do Dashboard Server e confirmar o sucesso dessa publicação.

(49)

Figura 2.29: Dashboard com duas comboboxes e com os filtros sem nada seleccionado.

(50)

Figura 2.31: Seleccionada a categoria "Bikes"no dashboard.

Através do MSSQL Profiler (Figura2.32) é possível ver que o dashboard, sempre que é car-regado no navegador, inquire a base de dados assim como quando é alterado um dos filtros.

Através do servidor Web do Dashboard Server é possível gerir o dashboard, sendo possível organizá-los em pastas, criar novos utilizadores e definir as suas permissões de acesso, entre outras funcionalidades. O Syncfusion permite, para além da publicação dos dashboards, a publicação de fontes de dados e widgets para o servidor, que podem ser descarregados para o Dashboard Designer para serem reutilizados num outro dashboard.

As páginas mostraram-se responsivas, adaptáveis a diferentes resoluções. Actualmente, não é possível criar widgets personalizados.

No que toca ao preço, a Syncfusion Dashboard Platform oferece uma licença comunitária (Community License), tornando-a gratuita para empresas com receitas inferiores a um milhão de dólares anuais e limitada a 5 utilizadores. A licença empresarial fica por 1995 dólares anuais até 50 utilizadores, sendo que acresce 500 dólares anuais por cada incremento de 25 utilizadores. Ao conhecer o projecto da CMF, a equipa de vendas da Syncfusion propôs um número ilimitado de licenças e utilizadores por seis mil dólares anuais.

O Syncfusion foi escolhido porque cumpre todos os requisitos e possui um preço atrativo. No que toca à fonte de dados, importa saber se é capaz de invocar vistas, UDF e SP. Na definição da fonte de dados do Syncfusion, a barra lateral esquerda lista os esquemas da base de dados escolhida, sendo possível encontrar, para além das tabelas, as vistas e SP a que o utilizador tem acesso.

No caso das vistas, o Syncfusion trata-as tal como se fossem tabelas, pedindo para referir qual a junção que deve ser feita aquando da introdução de um novo objecto.

(51)

Figura 2.32: Pelo SQL Server Profiler é possível ver o filtro por "Red"na interrogação.

No caso das SP, a interface pede para introduzir os valores dos argumentos bloqueando a vista de código (Code View) e a adição de novos objectos. Também não é possível adicionar uma SP quando já existem tabelas ou vistas no modelo.

As UDF não são listadas. No entanto, caso sejam conhecidas do utilizador, é possível chamá-las através do modo de código. No modo de código, e neste modo apenas, é possível criar parâ-metros personalizados e utilizá-los na interrogação. No entanto, estes parâparâ-metros apenas podem ser editados na fonte de dados. Não é possível editar o valor do parâmetro noutro local, seja no dashboard, no widget ou por argumento no URL.

Na personalização dos widgets, o Dashboard Designer não permite, por exemplo, a alteração das cores utilizadas num gráfico de barras. A cor azul é aplicada a todas e não é possível ser alterada através deste editor. Para o conseguir, é necessário descarregar o Syncfusion Dashboard SDK, que contém exemplos de ficheiros .sydx (extensão dos dashboards Syncfusion guardados localmente) embebidos numa página Web e as stylesheets e scripts necessários para personalizar o aspecto e experiência dos dashboards. Para efeitos de demonstração, foi criado um exemplo simples onde foram colocados elementos em redor do dashboard e personalizadas as cores de fundo e do gráfico de barras do dashboard.

Outro aspecto estudado foi a autenticação. A utilização de contas criadas através do painel de gestão do servidor Syncfusion acrescenta não só trabalho extra na gestão de utilizadores e suas permissões, como também obriga os utilizadores a possuírem uma nova conta. Para evitar isso, o Syncfusion permite a autenticação com contas Windows através do Active Directory.

(52)

Figura 2.33: Dashboard com as cores alteradas graças ao SDK.

No que toca a manter os dados do dashboard actualizados quando se pretende que estes es-tejam abertos durante longos períodos, o Syncfusion permite estabelecer um refrescamento do mesmo em intervalos de tempo personalizáveis. Para activar e configurar esse refrescamento é ne-cessário editá-lo com o Dashboard Designer, indo ao menu superior, escolhendo Server e depois Refresh Settings.

Na finalização deste estudo e ao ver como a nova interface HTML5 estava estruturada, uma das questões que surgiu foi se era possível o dashboard receber parâmetros através do URL para serem utilizados na filtragem.

A passagem de argumentos é bastante simples, bastando para isso utilizar a sintaxe:

<Endereço>:<Porta>/?<Nome da coluna a filtrar>=<Valor>,<Valor2> &<Nome da segunda coluna a filtrar>=<Valor>,<Valor2>

Exemplo:

http://localhost:6765/?Color=white,grey

Este endereço filtra a fonte de dados com a coluna “Color” pelos valores “White” e “Grey”. Na Figura2.34é possível ver que o dashboard aparece filtrado, tanto no gráfico de barras como na combobox. É possível ver através do Profiler que o dashboard, no carregamento de uma página que contenha os parâmetros mencionados, adiciona à interrogação a filtragem especificada.

O dashboard aparece filtrado, não só no gráfico de barras, como também na combobox, que permite posteriormente filtrar especificamente por um dos dois valores resultantes.

(53)

Figura 2.34: Dashboard e interrogações duma filtragem por endereço.

Infelizmente, não é possível passar argumentos pelo URL que possam ser utilizados nos ar-gumentos das SP ou UDF. Os arar-gumentos de SP e UDF apenas podem ser alterados na fonte de dados.

2.10 Conclusão do estudo das ferramentas

Concluindo o estudo das ferramentas, é possível compará-las nos diferentes requisitos listados. Esta comparação ajuda a perceber quais são as alternativas ao Syncfusion e que ferramentas po-derão ser melhores alternativas caso ocorra mudanças, nomedamente uma solução de publicação on-premisesno Power BI ou preços mais atractivos em soluções como o Tableau.

Todas as ferramentas foram simples de instalar e configurar, exceptuando o Klipfolio, que não é on-premises. O único pormenor a ter em atenção é nas configurações dos servidores Web para os dashboards, que envolve escolher uma porta que não entre em conflito com outros servidores Webou programas.

À lista de requisitos mencionada anteriormente, foi adicionado um outro não obrigatório: • Se a ferramenta é capaz de inquirir SQL Server Analysis Services (SSAS).

O cmNavigo disponibiliza de base, para além das bases de dados operacionais, um DW. O cliente final pode ou não ter capacidade de interagir com o SSAS. Se a ferramenta for capaz de interagir com o DW é uma qualidade extra.

(54)

(55)

Capítulo 3

Solução actual do cmNavigo

3.1 Arquitectura geral do cmNavigo

As instalações dos servidores MSSQL do cmNavigo contam no mínimo com duas máquinas. Uma primeira máquina com uma base de dados relacional Online, onde são efectuadas todas as transacções por parte das máquinas envolvidas na produção e uma segunda máquina com uma base de dados relacional Operational Data Store (ODS) e um DW.

Figura 3.1: Os três tipos de bases de dados envolvidos no cmNavigo e como se relacionam.

A instância ODS mantém-se actualizada com a Online, sincronizando os dados de 5 em 5 segundos. A base de dados ODS mantém todo o histórico de informação, enquanto a Online mantém apenas um histórico recente. O número de horas de histórico da Online depende do processo de produção do cliente, tendo sido dado como exemplo 5 horas. Ao mesmo tempo, a ODS também pode servir como backup da Online em caso de falha.

As interrogações feitas pelos utilizadores, nomeadamente na interface de gestão do cmNavigo, recorrem à informação armazenada na ODS para não perturbar o funcionamento da base de dados

(56)

Solução actual do cmNavigo

de produção Online. Essa informação presente na ODS também é utilizada nas builds do DW, que ocorrem com frequências diferentes para cada cliente, incluindo desde builds de 5 em 5 minutos até builds diárias.

3.2 Dashboards actuais do cmNavigo

As versões actuais do cmNavigo, desenvolvidas em Silverlight, possuem três dashboards de base, podendo os clientes pedir alterações a esses ou a criação de novos conforme as suas necessi-dades específicas.

Os valores apresentados nos dashboards são as médias dos recursos da fábrica excepto no cronograma do Resource Key Performance Indicators (RKPI), que mostra os diferentes estados ao longo do tempo para cada recurso seleccionado.

Esses dashboards são:

3.2.1 Resource Key Performance Indicators (RKPI)

Este dashboard possui indicadores de quanto tempo as máquinas estiveram em condições de produzir (Uptime) e o tempo em que não estiveram (Downtime), o tempo médio entre as suas falhas ou Mean Time Between Failures (MTBF) e o tempo médio entre reparações ou Mean Time To Repair(MTTR).

Para além destes indicadores relativos aos últimos dias, semanas ou meses, conforme a escolha do utilizador, também é mostrado o tempo em que as máquinas estiveram em cada um dos estados e um cronograma (Timeline) com os estados de cada uma das máquinas seleccionadas.

(57)

De base, no cmNavigo as máquinas podem ter os estados de Produção (Productive), Sem programação (NonScheduled), Em espera (StandBy), Manutenção não programada (Unscheduled Down), Manutenção programada (Scheduled Down) e Engenharia (Engineering).

3.2.2 Process Key Performance Indicators (PKPI)

Este dashboard possui indicadores das unidades produzidas com sucesso em relação ao total previsto no início do processo (Yield), o tempo de ciclo desse processo (Cycle Time) e quais os problemas mais frequentes na produção, medidos quer em frequência, quer em percentagem.

Figura 3.3: Dashboard PKPI no actual cmNavigo.

3.2.3 Overall Equipment Effectiveness (OEE)

Este dashboard possui indicadores de:

• Eficácia da produção (OEE), que pode ser calculado através da multiplicação das percenta-gens das métricas Availability (AVA), Quality (QUA) e Performance (PER).

OEE = AVA × QUA × PER

• Disponibilidade para operar ou uptime (AVA)

• Unidades produzidas com sucesso em relação ao total iniciado (QUA) • Desempenho medido em relação à velocidade projectada (PER)

(58)

Estes indicadores são apresentados, quer para o valor actual nos widgets superiores, quer nos últimos dias, semanas ou meses, indicado nos widgets inferiores.

Figura 3.4: Dashboard OEE no actual cmNavigo.

Para cada um destes dashboards é possível ao utilizador filtrar pelo intervalo de tempo que deseja ver nos gráficos, podendo escolher entre Dias, Semanas ou Meses.

Segundo a CMF a criação destes dashboards foi morosa, pelo que as ferramentas de criação de dashboards resultam também num desenvolvimento mais fácil por parte da CMF. Isto significa que os dashboards pedidos pelos clientes podem ser desenvolvidos e entregues mais rapidamente e potencialmente a uma maior diversificação dos dashboards de base. No entanto, o principal objectivo é tornar o cliente final capaz de desenvolver os seus próprios dashboards.