Modelo conceptual de desenvolvimento, implementação e utilização de BI&A em PMEs
Abstract
Atualmente, para que as organizações se mantenham competitivas e acompanhem o mercado em constante crescimento, é essencial adotar tecnologias modernas de forma eficaz. O desenvolvimento de sistemas de apoio à decisão permite o planeamento, controlo e acompanhamento eficazes de todos os processos das empresas e dada a conjuntura do mercado, utilizando indicadores-chave de desempenho. A identificação de oportunidades de melhoria nos sistemas de produção e de negócio contribui para melhorar os níveis de qualidade dos produtos e serviços oferecidos e a sustentabilidade do negócio. Este projeto foi realizado, com o propósito de desenvolver um Data Warehouse completo implementável em Pequenas e Médias Empresas (PMEs), abrangendo todas as etapas cruciais da construção do Data Warehouse, utilizando como suporte uma base de dados fornecida pela Microsoft, designada por “AdventureWorks”. Ao longo desta dissertação, são detalhados todos os processos de Extração, Transformação e Carregamento (ETL) realizados utilizando o SQL Server Integration Services (SSIS) e o SQL Server. O processo de ETL envolveu a extração de dados, a transformação desses dados para garantir consistência e qualidade, e o carregamento no Data Warehouse em um formato otimizado para análise. Além disso, foram desenvolvidos dashboards em Power BI para a visualização e análise dos dados. Esses dashboards permitem que os utilizadores explorem e analisem informações por meio de gráficos e relatórios interativos, proporcionando uma visão clara dos indicadores de desempenho mais importantes. Tal como a base de dados de origem, o relatório encontra-se subdividido em quatro temas principais: Recursos Humanos, Compras, Produção e Vendas. Para validar o projeto, foram conduzidas quatro entrevistas semiestruturadas com especialistas em Business Intelligence/Analytics (BI&A). As entrevistas tiveram como objetivo avaliar a eficácia da solução desenvolvida neste projeto, a usabilidade dos dashboards e o impacto da solução no suporte à tomada de decisão. As respostas fornecidas pelos entrevistados contribuíram para melhorar o projeto e a garantir sua relevância no contexto da digitalização das empresas, nomeadamente, ao nível da utilização de BI&A.
Full text
Universidade do Minho Escola de Engenharia Ana Francisca Dias Faria Modelo conceptual de desenvolvimento, implementação e utilização de BI&A em PMEs outubro de 2024 Modelo conceptual de desenvolvimento, implementação e utilização de BI&A em PMEs Ana Francisca Dias Faria UMinho |2024
Universidade do Minho Escola de Engenharia Ana Francisca Dias Faria Modelo conceptual de desenvolvimento, implementação e utilização de BI&A em PMEs Dissertação de Mestrado Engenharia de Sistemas Trabalho realizado sob orientação do Professor Doutor Paulo Sérgio Lima Pereira Afonso outubro de 2024
I DIREITOS DE AUTOR E CONDIÇÕES DE “Utilização” DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho.
II DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de “Utilização” indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho.
III Agradecimentos A conclusão desta tese marca o fim de uma jornada repleta de desafios. Não poderia ter chegado até aqui sem o apoio de pessoas incríveis, às quais expresso minha profunda gratidão. Ao professor doutor Paulo Afonso, meu orientador, pela orientação constante, paciência e encorajamento ao longo deste trabalho. Pelas suas sugestões e críticas que foram fundamentais para o desenvolvimento desta pesquisa. Ao meu orientador de estágio na Gstep, agradeço sinceramente pela orientação prática, paciência e pela partilha de conhecimentos valiosos. A sua orientação foi e continua a ser fundamental para o meu crescimento académico e profissional. À minha família, especialmente aos meus pais, pelo amor incondicional e apoio inabalável, e por serem patrocinadores desta e outras aventuras académicas. Um agradecimento especial também aos seus respetivos companheiros de vida, pelo carinho e compreensão contínuos, mas especialmente valorizados durante este período. Aos meus amigos, pelo apoio emocional, agradeço pelas palavras de incentivo e momentos de descontração que foram essenciais. A todos vocês, meu mais sincero agradecimento.
IV Modelo conceptual de desenvolvimento, implementação e utilização de BI&A em PMEs Resumo Atualmente, para que as organizações se mantenham competitivas e acompanhem o mercado em constante crescimento, é essencial adotar tecnologias modernas de forma eficaz. O desenvolvimento de sistemas de apoio à decisão permite o planeamento, controlo e acompanhamento eficazes de todos os processos das empresas e dada a conjuntura do mercado, utilizando indicadores-chave de desempenho. A identificação de oportunidades de melhoria nos sistemas de produção e de negócio contribui para melhorar os níveis de qualidade dos produtos e serviços oferecidos e a sustentabilidade do negócio. Este projeto foi realizado, com o propósito de desenvolver um Data Warehouse completo implementável em Pequenas e Médias Empresas (PMEs), abrangendo todas as etapas cruciais da construção do Data Warehouse , utilizando como suporte uma base de dados fornecida pela Microsoft , designada por “AdventureWorks”. Ao longo desta dissertação, são detalhados todos os processos de Extração, Transformação e Carregamento (ETL) realizados utilizando o SQL Server Integration Services (SSIS) e o SQL Server . O processo de ETL envolveu a extração de dados, a transformação desses dados para garantir consistência e qualidade, e o carregamento no Data Warehouse em um formato otimizado para análise. Além disso, foram desenvolvidos dashboards em Power BI para a visualização e análise dos dados. Esses dashboards permitem que os utilizadores explorem e analisem informações por meio de gráficos e relatórios interativos, proporcionando uma visão clara dos indicadores de desempenho mais importantes. Tal como a base de dados de origem, o relatório encontra-se subdividido em quatro temas principais: Recursos Humanos, Compras, Produção e Vendas. Para validar o projeto, foram conduzidas quatro entrevistas semiestruturadas com especialistas em Business Intelligence/Analytics (BI&A). As entrevistas tiveram como objetivo avaliar a eficácia da solução desenvolvida neste projeto, a usabilidade dos dashboards e o impacto da solução no suporte à tomada de decisão. As respostas fornecidas pelos entrevistados contribuíram para melhorar o projeto e a garantir sua relevância no contexto da digitalização das empresas, nomeadamente, ao nível da utilização de BI&A. Palavras chave: KPI, Dashboards ; ETL; Business Intelligence ; Business Analytics ; Pequenas e Médias Empresas (PMEs)
V Conceptual model for developing, implementing and using BI&A in SMEs Abstract Currently, for organizations to remain competitive and keep up with a constantly growing market, it is essential to effectively adopt modern technologies. The development of decision support systems enables effective planning, control, and monitoring of all business processes using key performance indicators, considering the market conditions. Identifying opportunities for improvement in production and business systems helps enhance the quality levels of products and services offered and ensures business sustainability. This project was carried out with the purpose of developing a comprehensive Data Warehouse implementable in Small and Medium Enterprises (SMEs), covering all the crucial stages of Data Warehouse construction, using a database provided by Microsoft called "AdventureWorks" as a foundation. Throughout this dissertation, all the Extraction, Transformation, and Loading (ETL) processes carried out using SQL Server Integration Services (SSIS) and SQL Server are detailed. The ETL process involved extracting data, transforming that data to ensure consistency and quality, and loading it into the Data Warehouse in an optimized format for analysis. In addition, dashboards were developed in Power BI for data visualization and analysis. These dashboards allow users to explore and analyze information through interactive charts and reports, providing a clear view of the most important performance indicators. Like the source database, the report is divided into four main themes: Human Resources, Purchasing, Production, and Sales. To validate the project, four semi-structured interviews were conducted with experts in Business Intelligence/Analytics (BI&A). The interviews aimed to assess the effectiveness of the solution developed in this project, the usability of the dashboards, and the impact of the solution on decision support. The feedback provided by the interviewees helped to improve the project and ensure its relevance in the context of digital transformation in companies, particularly in the use of BI&A. Keywords: KPI, Dashboards, ETL, Business Intelligence, Business Analytics, Small and Medium Enterprises (SMEs)
VI Índice Agradecimentos ........................................................................................................................ III Resumo .................................................................................................................................... IV Abstract ..................................................................................................................................... V Lista de Figuras ...................................................................................................................... VIII 1 INTRODUÇÃO ................................................................................................................... 1 1.1 Enquadramento ................................................................................................................ 1 1.2 Metodologia de Investigação .............................................................................................. 3 1.3 Estrutura da Dissertação ................................................................................................... 4 2 REVISÃO DA LITERATURA ................................................................................................. 6 2.1 Business Intelligence ......................................................................................................... 6 2.2 Business Intelligence nas Pequenas e Médias Empresas.................................................. 12 2.3 Business Analytics ........................................................................................................... 13 2.4 Business Intelligence vs Business analytics ...................................................................... 14 2.5 Sistemas de Data Warehouse .......................................................................................... 19 2.5.1 Processo de ETL ..................................................................................................... 22 2.5.2 Data Mart ................................................................................................................ 22 2.5.3 Sistemas de Apoio à decisão ................................................................................... 23 2.5.4 Data Visualization .................................................................................................... 24 2.5.5 Requisitos ............................................................................................................... 27 3 IMPLEMENTAÇÃO DE UM DATAWAREHOUSE ................................................................. 29 3.1 Microsoft Adventure Works 2019 ..................................................................................... 29 3.2 Arquitetura do Sistema .................................................................................................... 30 3.3 Levantamento de Requisitos ............................................................................................ 31 3.4 Processos de ETL ............................................................................................................ 32 3.4.1 Extração de Dados .................................................................................................. 33 3.4.2 Area Staging ............................................................................................................ 34 3.4.3 Data Mart ................................................................................................................ 36 3.4.4 Carregamento de Dados .......................................................................................... 38
VII 3.4.5 Criação de Views ..................................................................................................... 58 3.5 Visualização de Dados ..................................................................................................... 58 3.5.1 Importação de Dados .............................................................................................. 59 3.5.2 Desenvolvimento Power BI ...................................................................................... 61 4 APLICAÇÃO DO MODELO ................................................................................................ 75 5 CONCLUSÕES ................................................................................................................ 79 REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................. 81 ANEXOS ................................................................................................................................. 87 Anexo I – Requisitos ............................................................................................................... 87 Anexo II – Criação das tabelas da Area Staging - AW2019_Staging .......................................... 92 Anexo II – Criação das tabelas da DW - AW2019_DW ............................................................ 103 Anexo III – Processo de logs ................................................................................................. 107 Anexo IV – Update das tabelas da Area Staging - AW2019_Staging........................................ 109 Anexo V – Carregamento das tabelas – Data Mart – AW2019_DW ........................................ 112 Anexo VI – Criação de Views – Data Mart – AW2019_DW ..................................................... 124 Anexo VII – Desenvolvimento Power BI – Tabela Dim_Tempo ................................................ 129 Anexo XII – Desenvolvimento Power BI – Comum a todas as páginas .................................... 131 Anexo XIII – Entrevistas ........................................................................................................ 136
3 amplamente utilizada em ambientes de demonstrações e projetos de desenvolvimento de sistemas, pois fornece uma representação realista de cenários comerciais comuns. No contexto do projeto supracitado, esta base de dados serviu como fonte de dados principal para a elaboração do Data Warehouse . Os processos de Extração, Transformação e Carregamento (ETL) serão realizados utilizando o SQL Server Integration Services (SSIS) e o SQL Server , garantindo a integridade e qualidade dos dados transferidos para o Data Warehouse. Além disso, serão desenvolvidos dashboards no Power BI para a visualização e análise dos dados armazenados no Data Warehouse . Esses dashboards são idealizados com o objetivo de oferecer insights valiosos para a gestão de uma Pequena e Média Empresas (PMEs), permitindo uma tomada de decisão mais informada e eficiente. Por fim, o projeto será validado por meio da realização de entrevistas direcionadas a consultores de Business Intelligence e representantes de Pequenas e Médias Empresas (PMEs), com o intuito de avaliar a eficácia e utilidade do Data Warehouse implementado, tanto em termos técnicos quanto práticos. 1.2 Metodologia de Investigação Para a realização deste projeto foram utilizadas várias tecnologias para garantir a eficiência e eficácia do projeto. O Microsoft SQL Server foi a principal ferramenta de gestão de bases de dados, utilizando Structured Query Language (SQL) para a manipulação, controlo e consulta de dados. (Microsoft, 2024). O Visual Studio , como Ambiente de Desenvolvimento Integrado (IDE), foi utilizado para incorporar os módulos SSIS, SSAS e SSRS do SQL Server. O Microsoft SSIS (SQL Server Integration Services) é uma plataforma de criação de soluções de integração de dados, incluindo pacotes ETL (extração, transformação e carregamento), com ferramentas gráficas e assistentes para a criação e depuração de pacotes (Microsoft, 2023). O Power BI , um software de Inteligência Empresarial, permite analisar grandes volumes de dados de diversas fontes e integrá-los em dashboards e relatórios. Consiste no Power BI Desktop , Power BI Service e Power BI Mobile para dispositivos Windows , iOS e Android (Microsoft, 2024).
4 As linguagens utilizadas incluem SQL para a manipulação de dados e DAX (Data Analysis Expressions) para cálculos personalizados e agregações dinâmicas em modelos de dados. A decisão de explorar a relevância da implementação de um Data Warehouse em Pequenas e Médias Empresas (PMEs) fundamenta-se na significativa importância que estas empresas têm para a economia de Portugal. De acordo com o Instituto Nacional de Estatística (2020), as PMEs representam 99,9% das empresas em Portugal e empregam cerca de 77% da força de trabalho do setor privado. As PMEs são responsáveis por cerca de 60% do valor acrescentado bruto do país, sendo cruciais para a economia (Instituto Nacional de Estatística, 2020). A capacidade de inovação das PMEs é significativa, especialmente nos setores de tecnologia e biotecnologia (Directorate-General for Research and Innovation (European Commission) et al., 2022). Políticas de apoio, como o Plano de Recuperação e Resiliência de Portugal (RRP), promovem a digitalização e inovação das PMEs para melhorar a sua competitividade (Commission Economic & Affairs European Economy Institutional Papers, 2023). Para validar a relevância, aplicabilidade e sucesso do estudo, foram realizadas entrevistas semiestruturadas com consultores de Business Intelligence , indivíduos que foram relevantes e várias PMEs. Estas entrevistas forneceram insights valiosos e feedback prático sobre a aplicação das tecnologias de BI em contextos reais de PMEs. A metodologia descrita proporciona uma base sólida para a implementação do Data Warehouse e a demonstração das capacidades do BI em PMEs, utilizando tecnologias e práticas avançadas para alcançar os objetivos do projeto. 1.3 Estrutura da Dissertação A estrutura do presente projeto assenta em cinco capítulos, cada um cumprindo um papel fundamental na compreensão e realização dos objetivos propostos. No primeiro capítulo, é realizada uma introdução detalhada ao contexto do projeto. Inicialmente, é apresentada uma visão geral do tema, destacando-se a sua relevância e importância no cenário empresarial contemporâneo. Aqui, são definidos os objetivos específicos do projeto, delineando claramente as metas a serem alcançadas. Por fim, é apresentada a metodologia de pesquisa adotada, detalhando os métodos e técnicas utilizados para atingir os objetivos propostos.
5 O segundo capítulo, intitulado "Revisão da Literatura", constitui uma análise aprofundada dos conceitos fundamentais necessários para o entendimento e desenvolvimento do projeto. São abordados temas como Business Intelligence , Data Warehousing , processos de ETL (Extração, Transformação e Carregamento) bem como ferramentas tecnológicas relevantes, como o SQL Server Integration Services (SSIS) , o Power BI , entre outos conceitos. Esta revisão da literatura proporciona uma base teórica sólida para o desenvolvimento do caso prático, permitindo uma compreensão abrangente do tema e dos conceitos subjacentes. No terceiro capítulo, denominado "Implementação de um Datawarehouse", centra-se na aplicação dos conhecimentos adquiridos nos capítulos anteriores. Aqui, é detalhado o caso prático desenvolvido no âmbito do projeto, incluindo a construção do Data Warehouse utilizando a base de dados " AdventureWorks2019 " da Microsoft , os processos de ETL realizados no SSIS e SQL Server , bem como a criação dos dashboards no Power BI . Este capítulo apresenta uma visão detalhada e abrangente do trabalho realizado, demonstrando a aplicabilidade dos conceitos teóricos na prática com a ambição de alcançar insights valiosos para a gestão e análise de dados empresariais. No quarto capítulo, aborda-se a aplicabilidade do projeto, destacando os aspetos práticos e as possíveis implementações e o resumo das entrevistas realizadas. Por fim, no último capítulo, apresentam-se as conclusões finais do estudo. No seu conjunto, esta estrutura proporciona uma abordagem holística e sistemática à compreensão e desenvolvimento do tema proposto. Cada capítulo complementa os restantes, contribuindo assim para uma análise abrangente e uma aplicação prática dos conhecimentos adquiridos.
6 2 Revisão da Literatura Neste capítulo, apresenta-se uma revisão da literatura relativa às áreas do conhecimento bem como aos conceitos abordados neste projeto. Para tal, efetuou-se uma pesquisa em fontes bibliográficas que tratam destas questões, bem como em áreas do conhecimento relacionadas, visando obter uma compreensão alargada do estado atual do conhecimento neste domínio. 2.1 Business Intelligence Os Chief Information Officers (CIOs) das organizações concentraram a sua atenção em soluções de Business Intelligence durante os anos de 2008 e 2009 (Gartner Research, 2008, 2009). Ficou evidente que os dados representavam um dos ativos mais valiosos de uma organização, pois é deles que são extraídas informações vitais. Muitos estudos apoiaram essa perceção, revelando que a grande maioria das empresas manifestou interesse em investir em soluções de BI (Fedouaki et al., 2013). Como a Inteligência artificial é cada vez mais proeminente, as empresas são obrigadas a reconsiderar as suas estratégias e práticas. Neste contexto tecnológico, é importante considerar a questão de saber quando a automatização comercial substituirá a mão de obra humana. Esta disputa mais abrangente envolve não apenas os procedimentos laborais, mas também os modelos de administração empresarial. É fundamental explorar minuciosamente as potencialidades dos dados, alcançando níveis ainda mais elevados de eficiência e competitividade, num contexto onde a sobrevivência no mercado se torna uma verdadeira batalha. Esta situação exige, sem dúvida, um ajuste estratégico mais amplo entre as exigências do setor empresarial e as transformações que ocorrem constantemente. (Cooper & Cooper, 2012). Nos últimos vinte anos, o conceito de Business Intelligence (BI) ganhou um considerável destaque, impulsionado pelo crescente volume de dados e pelos avanços tecnológicos, tornandose uma das maiores áreas de interesse e de pesquisa académica (Chuah et al., 2011). A visão da Quarta Revolução Industrial, como descrita por Schwab (2016), enfatiza a automação dos processos de trabalho, especialmente nas chamadas "Fábricas Inteligentes”. Estas fábricas adotam soluções tecnológicas para melhorar, automatizar e modernizar as suas operações de produção, servindo-se de tecnologias como “ Internet das Coisas” (IoT), computação em nuvem e inteligência artificial (Schwab, 2016).
7 Figura 2 –Características chaves das Fábricas Inteligentes (Adaptação de Deloitte, 2017) No relatório de 2017 da Deloitte (Burke et al., 2017), intitulado "The Smart Factory" , são identificadas cinco caraterísticas fundamentais dessas fábricas inteligentes: conetividade, otimização, transparência, produtividade e flexibilidade. Embora a maturidade desta área não seja questionável, ainda não existe um consenso universal sobre a definição de BI (Jagielska et al., 2003; Negash, 2004). Segundo (Karim, 2011), essa definição é um tanto fluida, variando conforme o contexto e a visão do autor. Isso sugere que o conceito de BI não é estático, mas sim moldado pelas preferências individuais, motivações ou perspetivas de cada autor (Cooper & Cooper, 2012). O investigador Howard Dresner (1989), frequentemente citado como o pioneiro do BI , e posteriormente analista da Gartner Research, introduziu o termo como uma "categoria abrangente de softwares e soluções projetadas para recolher, consolidar, analisar e fornecer acesso aos dados de forma que os funcionários de uma organização possam tomar decisões de negócios mais informadas".
8 Apesar de algumas suposições em contrário, o conceito de Business Intelligence (BI) não é muito recente. A sua origem remonta a Hans Peter Luhn, um pesquisador da IBM , que em outubro de 1958, num artigo do "IBM Journal of Research and Development ", definiu BI como a habilidade em compreender as relações entre factos apresentados para alcançar um objetivo desejado (H. P. Luhn, 1958). Uma das definições mais amplamente aceitas de Business Intelligence (BI) é a proposta por Wixom & Watson (2010), que descreve BI como "Uma ampla categoria de tecnologias, aplicações e processos para recolher, armazenar, aceder e analisar dados para ajudar os utilizadores a tomar melhores decisões." (Wixom & Watson, 2010). Essa definição tem semelhanças com a de Howard Dresner, mas inclui componentes adicionais, como a referência aos processos de gestão que podem englobar atividades como a extração de dados e a gestão de projetos de BI , entre outros. É essencial a participação de pessoas em todas as suas etapas. Os investigadores Wixom & Watson (2010) também especificam que, nos dias atuais, o BI se tornou um requisito fundamental para a competitividade no mercado. No mesmo estudo, eles apresentam o que consideram ser as melhores práticas no ambiente de BI , delineando um panorama das empresas onde o BI é crucial, que eles designam como "BI-based organizations" (Wixom & Watson, 2010). O Business Intelligence (BI) tem como objetivo primordial aperfeiçoar o processo de tomada de decisão nas organizações. De acordo com Negash & Gray (2008), o BI representa uma evolução de sistemas anteriores, todos direcionados para a melhoria da tomada de decisões. A sua função principal é converter dados essenciais do negócio em informações relevantes e acessíveis, fornecendo uma base sólida para as decisões da alta administração. Essa conceção está alinhada com a definição de Azvine et al. (2006), que descrevem o BI como um conjunto de práticas e tecnologias destinadas a capturar, aceder, compreender, analisar e transformar os dados brutos da empresa em insights acionáveis. O objetivo final é melhorar o desempenho empresarial por meio de uma gestão informada e estratégica. Os investigadores Vitt et al. (2002) observaram a ampla aplicação do termo BI, que é usado por diferentes especialistas e fornecedores de software para descrever uma grande variedade de tecnologias, plataformas de software, aplicações específicas e processos. Assim, o BI é concebido como uma ferramenta que ajuda a identificar informações úteis e relevantes para o processo de tomada de decisões. Por outro lado, autores como Chaudhuri et al. (2011)
9 descrevem o BI como um conjunto de tecnologias de suporte à tomada de decisões, com o objetivo de capacitar analistas, gestores e diretores a tomarem resoluções mais informadas e rápidas. Para garantir a eficácia operacional, as empresas devem assegurar o acesso oportuno à informação correta para os stakeholders relevantes (Guarda et al., 2013b). Segundo Wells (2008), implica uma perspetiva mais ampla de BI , descrevendo-a como a capacidade de uma organização entender, planear, prever, resolver problemas, pensar de forma abstrata, compreender, inovar e aprender para ampliar o conhecimento organizacional. Essa definição ressalta a importância de fornecer informações para fundamentar decisões, facilitar a sua eficácia e, assim, contribuir para o alcance dos objetivos de negócio. No ambiente empresarial, os dados utilizados pelas ferramentas de BI vêm de diversas fontes, internas e externas, porém com a maioria proveniente das bases de dados internas da empresa. Sauter, 2011, destaca que os sistemas de BI devem realizar várias tarefas essenciais, incluindo exploração, integração, agregação e análise multidimensional precisa dos dados de vários sistemas de informação. Esses dados são então armazenados num Data Warehouse , geralmente utilizando sistemas de gestão de bases de dados relacionais (SGBDR) para facilitar o armazenamento e a consulta. (Chaudhuri et al., 2011; van Vugt & Jacobsen, 2017). Segundo Olszak & Ziemba (2012), os sistemas de inteligência empresarial ( BI ) englobam uma ampla gama de processos, de tomada de decisões, análise de informações e gestão do conhecimento, combinados com interações entre indivíduos e sistemas computacionais. Eles também estabelecem conexões entre o BI e outras plataformas, como MIS (sistemas de informações gerenciais), DSS (sistema de suporte à decisão), EIS (sistemas de informações executivas), entre outros, ressaltando as distinções marcantes entre essas abordagens. Os sistemas de BI unem as funcionalidades de diversos sistemas para capacitar as organizações com as ferramentas necessárias para conquistar vantagens competitivas. Olszak e Ziemba são reconhecidos pela sua dedicação a esse tema, com uma ampla coleção de estudos já publicados. Eles argumentam que os sistemas de Inteligência Empresarial podem ser abordados sob duas perspetivas distintas: uma técnica e, outra de teor organizacional ou de negócios. Na visão técnica, destacam um conjunto de ferramentas, tecnologias e softwares usados para recolher dados de diversas fontes, integrá-los e analisá-los, tornando-os mais acessíveis. Isso inclui: • Ferramentas de ETL (Extração, Transformação e Carga);
10 • Data Warehouses ; • Ferramentas analíticas, como OLAP (Processamento Analítico On-Line); • Ferramentas de Mineração de Dados; • Ferramentas para análises ad hoc ; • Presentation layer - aplicações projetadas para apresentar informações de maneira conveniente e acessível, através de gráficos e conteúdos multimídia. No entanto, do ponto de vista da organização, os sistemas de BI abraçam uma filosofia e abordagem específicas, centradas na gestão de dados e conhecimentos, comunicação aberta e partilha de informações, em conjunto com uma análise detalhada dos processos empresariais. Representam soluções que transformam dados em insights , enquanto promovem um ambiente propício para decisões efetivas e a implementação de estratégias ponderadas. Para ambas as perspetivas, a habilidade de obter informações cruciais para instigar mudanças na empresa - como adquirir novos clientes, introduzir novos produtos, entre outros - ressalta o valor intrínseco desses sistemas (Chaudhary, 2004; Olszak & Ziemba, 2004). Para Fedouaki et al. (2013), a implementação de um sistema de BI transformou-se num fator essencial para garantir uma margem de vantagem competitiva e lidar de forma eficaz com as crescentes pressões do mercado, reconhecendo os dados como ativos cruciais das organizações modernas. Eles destacam que o papel do BI se tem modificado ao longo do tempo, passando de meras ferramentas analíticas para soluções muito válidas usadas em previsões, controlo operacional e análise de rentabilidade de produtos, entre outras aplicações. Okar et al., (2012) dividem o conceito de BI em três partes: Data Capture/Acquisition , Data Storage e Data Access & Analysis . Ademais, o BI capacita as empresas a obterem informações muito pormenorizadas sobre o resultado dos seus investimentos, tanto interno quanto externo. Enquanto uma parte procura informações sobre a indústria e os principais concorrentes para melhor compreender o ambiente externo e tomar decisões fundamentadas, a outra parte concentra-se em recolher dados operacionais da organização para avaliar seu desempenho (Chung & Tseng, 2012). Setores como o retalhista, a banca entre outros, já adotaram amplamente o BI como uma ferramenta eficaz e valiosa. Muitas empresas nesses setores experimentaram benefícios tangíveis, como uma melhor capacidade de atrair novos clientes. No entanto, outras enfrentaram desafios
11 na implementação do BI , destacando a complexidade desse processo como um obstáculo significativo a ser superado (Okar et al., 2012). O trabalho de Chuah et al. (2009) oferece uma perspetiva abrangente sobre as diferentes definições de Business Intelligence (BI) existentes até aquela data. Ao organizá-las em três grupos distintos - Managerial/Process , Technological e Product - eles destacam as várias dimensões e abordagens que os autores utilizaram para definir o conceito. A abordagem Managerial/Process enfatiza a importância do processo de recolha, análise e interpretação de dados para melhorar a tomada de decisões. Isso sugere que o BI não é apenas sobre as ferramentas e tecnologias, mas também acerca da forma como esses dados são utilizados para influenciar as decisões empresariais. Por outro lado, a abordagem Technological concentra-se nas ferramentas e tecnologias que possibilitam a recolha, manipulação e análise de dados. Isso destaca a importância das infraestruturas tecnológicas subjacentes ao funcionamento eficaz do BI. Finalmente, a abordagem Product vê o BI como o resultado ou produto de uma análise profunda dos dados empresariais. Isso ressalta a importância de transformar os dados em informações significativas e com grande utilidade prática, facilmente acessíveis pelas empresas. A citação de Turban et al. (2007) “Um termo abrangente que inclui ferramentas, arquiteturas, bases de dados, Data Warehouses , gestão de desempenho, metodologias etc., que são integrados num único software ” ilustra como uma definição pode sobrepor-se a mais de uma categoria, enfatizando a complexidade e a versatilidade do termo BI . Essa versatilidade é realçada ainda mais pela conclusão de Chan et al., que argumenta que os sistemas de BI não devem ser vistos como uma entidade isolada, mas sim como um produto evolutivo que integra várias ferramentas e técnicas computacionais. Essa perspetiva está alinhada com a visão de Negash & Gray (2008) e destaca a natureza dinâmica e em constante evolução do campo de BI . Os Data Warehouse Corporativos são frequentemente considerados uma plataforma de BI ou um conjunto de ferramentas para transformar os dados em informações comerciais úteis nos programas de Business Intelligence (TDWI 2013). Howard Dresner, consultor da Gartner, definiu a inteligência empresarial ( BI ) como um conjunto de conceitos e métodos amplos para melhorar a tomada de decisões através do uso de sistemas de informação baseados em factos (Power, 2003). A Gartner, menciona que "não existe uma definição única de BI , assim, a área tecnológica
12 (TI) e a área de negócio podem ver o BI de forma diferente.". A área de TI considera o BI como uma ferramenta, enquanto na área de negócios que o BI é percebido como informação. O processo de obtenção de informação na área de negócio, que transforma dados em informação e esta última em conhecimento, é o cerne do BI , de acordo com o mesmo artigo. 2.2 Business Intelligence nas Pequenas e Médias Empresas O conceito de Business Intelligence (BI) é associado frequentemente a grandes corporações, deixando muitas pequenas e médias empresas (PMEs) com a impressão de que essas tecnologias estão aquém das suas possibilidades (Tutunea & Rus, 2012). Uma observação da literatura revela que a pesquisa sobre BI geralmente concentra-se em empresas de grande dimensão, abordando os seus benefícios, desafios e fatores críticos de sucesso, enquanto as informações específicas sobre a relação entre BI e PMEs são escassas (Olszak & Ziemba, 2012). Essa lacuna é ainda mais evidente no contexto português, onde a pesquisa em repositórios online não oferece resultados conclusivos. No entanto, estudos de caso noutros países, como aqueles apresentados por outros autores (Olszak & Ziemba, 2012) na Polónia e a pesquisa na Bósnia Herzegovina, (Kasim et al., 2018) oferecem insights valiosos. Torna-se crucial reconhecer o papel significativo que as PMEs desempenham na economia, e entender que o seu desenvolvimento é essencial para garantir a competitividade. Embora alguns argumentem que as ferramentas de BI são exclusivas para as grandes empresas e não são viáveis para PMEs (Legendre, 2005); (Gangadharan, 2004), é importante destacar que essas empresas enfrentam desafios semelhantes ao organizarem e interpretarem grandes volumes de dados para os transformar em informação útil, (Guarda et al., 2013a). Neste sentido, Tutunea & Rus (2012) apontam para soluções de BI de baixo custo baseadas em nuvem, projetadas especificamente para PMEs, como uma forma de aumentar a sua vantagem competitiva. No entanto, a falta de conhecimentos técnicos para selecionar a solução adequada pode resultar em falhas na sua implementação. Apesar das dificuldades, as PMEs representam a maioria dos utilizadores de BI , embora isso esteja mais relacionado com a sua presença predominante no mercado do que a uma forte motivação para adquirir sistemas de BI (Ali et al., 2017). O estudo enfatiza a necessidade de um entendimento mútuo entre PMEs e BI para impulsionar o desempenho de ambos. Torna-se crucial reconhecer que uma abordagem única não se aplica a todas as indústrias, e as soluções de BI
19 Além de compartimentarem em fases, Chen et al. também mencionaram cinco possíveis usos de BI&A, descrevendo a sua utilização com tecnologias básicas e possíveis pesquisas futuras, conforme indicado na Figura 5. 2.5 Sistemas de Data Warehouse O Data Warehouse é uma infraestrutura fundamental que se baseia num conjunto de dados orientada por assuntos, integrada, variável no tempo e não volátil, esta visão essencial para suportar o processo de tomada de decisões das empresas. O papel de Bill Inmon, conhecido como Figura 5 - BI&A Applications: From Big Data to Big Impact (Adaptação de Chen et al., 2012)
20 o "pai do Data Warehousing ", é crucial nesse contexto, pois ele popularizou o conceito e estabeleceu critérios de definição amplamente aceitos (Inmon, 2005). Um Data Warehouse é um repositório de dados que possui as seguintes caraterísticas: I. Orientado por assuntos: Todos os dados relacionados com um determinado assunto. Permitindo uma visão unificada e abrangente das informações dentro de um contexto específico. II. Integrado: Essa é considerada a característica mais crucial de um Data Warehouse (Inmon, 2005). Os dados que alimentam o DW vêm de várias fontes e sistemas diferentes. III. Não-volátil: Após serem carregados, os dados tendem a permanecer estáticos e históricos. IV. Variável no tempo: O Data Warehouse armazena não apenas dados atuais, mas também dados históricos, permitindo análises e comparações temporais. Um Data Warehouse bem construído oferece uma visão integrada e completa da organização, permitindo o acesso a dados históricos confiáveis. Isso facilita a tomada de decisões, sem sobrecarregar os sistemas operacionais da empresa (Klauer e Brobst, 1998). Existem diferentes abordagens de design, como top-down e bottom-up , cada uma com as suas vantagens e desafios. Essas abordagens, quando combinadas de maneira adequada, podem resultar num Data Warehouse eficiente que atende às necessidades da organização empresarial (Inmon, 2005; Kimball & Ross, 2002). A necessidade de obter informações estratégicas levou ao desenvolvimento do conceito de Data Warehouse como um novo tipo de Sistema de Informação. Ele serve como um repositório lógico de toda a informação de um negócio, permitindo análises detalhadas e insights valiosos para a empresa (Boar, 1997). No entanto, a implementação de um Data Warehouse não é uma tarefa simples. Requer um investimento significativo em termos de recursos materiais e humanos. Uma vez construído, o Data Warehouse pode ser fragmentado em Data Marts menores, que são estruturas de dados multidimensionais focadas em áreas específicas, como marketing, vendas ou finanças (Kimball et al., 1998). Isso permite um acesso mais ágil e rápido às informações relevantes para diferentes departamentos da organização. Em suma, o Data
21 Warehouse desempenha um papel fundamental na eficiência operacional e na tomada de decisões estratégicas das empresas, mas a sua implementação requer cuidado e planeamento adequados. Kimball, em 2002, propõe uma estrutura para um Data Warehouse com quatro componentes principais: os sistemas de origem operacional, a área de preparação dos dados, a área de armazenamento dos dados e as ferramentas de acesso aos mesmos. Os sistemas de origem operacional são responsáveis por capturar as transações comerciais e mantêm pequenos dados históricos para análise futura. A área de preparação dos dados é onde ocorrem os processos de Extração, Transformação e Carregamento (ETL), conectando as fontes originais dos dados à sua apresentação final. Os dados são armazenados e organizados na área de apresentação, onde ficam disponíveis para consulta pelos utilizadores finais através de diversas ferramentas. As ferramentas de acesso aos dados proporcionam aos utilizadores finais a capacidade de transformar simples visualizações de dados em informações relevantes para a tomada de decisão (Figura 6). Figura 6 - Estrutura do DW - Componentes (Adaptação de Kimball e Ross, 2002)
22 2.5.1 Processo de ETL As ferramentas de ETL desempenham um papel crucial no sistema de Business Intelligence (BI), sendo o acrónimo ETL referente a Extrair-Transformar-Carregar. Este processo é composto por três fases para combinar dados de diversas fontes. Após a sua conclusão, os dados são carregados num Data Warehouse ou Data Mart . Um estudo de 2011 da Bloomberg BusinessWeek Research Services aponta que a qualidade, integridade e consistência dos dados representam o maior desafio na adoção de processos de análises de dados. Cerca de 70% do tempo na implementação e manutenção de um Data Warehouse é dedicado ao processo de ETL (Behrend & Jörg, 2010). Na etapa de extração, os dados são recolhidos das diferentes fontes e transferidos para uma área de preparação (Staging Area), onde são tratados e selecionados. Posteriormente, na etapa de transformação, os dados são ajustados para melhorar a sua qualidade e consistência. Finalmente, na etapa de carga, os dados são carregados no DW. É fundamental que os dados sejam tratados corretamente durante o processo de ETL para garantir a precisão das análises e decisões baseadas neles. Williams & Williams, 2007, descrevem as ferramentas de ETL como maduras, reduzindo o tempo de desenvolvimento e gerindo o fluxo de dados ao longo da cadeia de valor do BI. A escolha de uma solução de ETL depende das necessidades e capacidades financeiras da empresa (M. Olszak & Ziemba, 2006). Além disso, as ferramentas OLAP (Online Analytical Processing) permitem consultas de dados e análises, facilitando a compreensão das necessidades de negócio favorecidos pelos dados e contribuindo para processos de decisão baseados em factos (Burstein & Clyde, 2008). Em resumo, o processo de ETL é essencial na implementação de BI , garantindo a qualidade, integridade e consistência dos dados para análises precisas e decisões fundamentadas. 2.5.2 Data Mart Um Data Mart é uma parte de um Data Warehouse (DW) direcionada para os requisitos específicos de um departamento ou negócio, desenvolvida com base nas necessidades dos utilizadores finais (Inmon, 2005).
23 Construídos com modelos de dados multidimensionais, representados em forma de cubo, os Data Marts seguem esquemas como o Esquema em Estrela, o Esquema Floco de Neve (Kimball & Ross, 2013). Na modelação dimensional, o Esquema em Estrela é o modelo mais comum, caracterizado pela redundância para melhorar o desempenho do sistema (Kimball & Ross, 2013). Outro modelo aplicado é o Esquema Floco de Neve, semelhante ao anterior, mas neste esquema, as Tabelas Dimensão podem ter sub-dimensões próprias (Sidi et al., 2016). As Tabelas Facto armazenam medidas de desempenho resultantes de eventos ocorridos na organização, como quantidade vendida de um produto, enquanto as Tabelas Dimensão descrevem quem, o quê, quando e onde esses eventos ocorrem (Kimball & Ross, 2013; Song et al., 2001). É importante garantir que todas as chaves estrangeiras nas Tabelas Facto estejam corretamente ligadas às chaves primárias das Tabelas Dimensão para garantir a integridade referencial (Kimball & Ross, 2013) . Em resumo, os Data Marts são elementos cruciais em sistemas de BI , adaptados às necessidades específicas de cada departamento ou negócio, e elaborados com base em modelos de dados multidimensionais como o Esquema em Estrela e o Esquema Floco de Neve. 2.5.3 Sistemas de Apoio à decisão Os sistemas de apoio à decisão, conhecidos como Decision Support Systems (DSS) em inglês, são essenciais para melhorar as tomadas de decisão dos gestores, representando cerca de 10% das investigações em sistemas de informação. Surgiram pela primeira vez no trabalho de (Scott-Morton, n.d.) e são definidos como sistemas que apoiam atividades de gestão em decisões semiestruturadas ou não estruturadas. Os DSS visam melhorar a eficácia da tomada de decisões humanas, constituindo uma filosofia de desenvolvimento dos sistemas de informação. Os Sistemas de Apoio à Decisão (SAD) fazem parte do conjunto de Sistemas de Informação empresariais. Eles diferem dos Sistemas de Informação (SI) ao focarem-se no suporte a decisões que requerem julgamento humano, não totalmente suportadas por algoritmos. Os SAD abrangem uma variedade de sistemas e tecnologias, destinados a auxiliar as pessoas na tomada de decisões, onde o utilizador desempenha um papel crucial.
24 Ambos os sistemas, DSS e SAD, são fundamentais para as empresas, proporcionando suporte e orientação em diferentes tipos de decisões, desde semiestruturadas até aquelas que requerem intervenção humana (Arnott & Pervan, 2014). 2.5.4 Data Visualization Atualmente, a representação visual abrange todas as áreas, tanto empresariais como do quotidiano. Enquanto as representações visuais podem simplificar a transmissão de factos e padrões complexos, também podem ser confusas e, por vezes, enganosas (Engelbertsen & Kennedy, 2020). Conforme observado por Shadare et al., 2016 a visualização de dados implica apresentar informações de forma pictórica ou gráfica, tornando-as mais acessíveis e auxiliando na compreensão e na identificação de ações apropriadas. Esta prática, embora não recente, remonta ao século XIX, com William Playfair reconhecido como pioneiro na criação de métodos gráficos modernos, como gráficos circulares, de barras e de linhas (Friendly & Wainer, 2021). Data Visualization em BI Data Visualization em BI visa mostrar dados relacionados com negócios para procurar, transmitir e analisar informações na tomada de decisões empresariais (Munoz, 2017). Os objetivos estão centrados na facilidade que os utilizadores passam a ter para visualizarem métricas principais de forma rápida e clara, além de proporcionar uma maneira interativa de explorar os dados. As vantagens incluem facilitar a carga cognitiva do processamento de informações, fornecer uma perspetiva visual de conjuntos de dados complexos, despertar a atenção do utilizador para áreas de interesse e explorar o sistema visual humano para extrair informações adicionais (Munoz, 2017). As três formas mais comuns de BI data visualization são: gráficos, elementos visuais baseados na localização, e dashboards . As ferramentas como o Microsoft Power BI são utilizadas para produzir esses elementos visuais, permitindo aos utilizadores monitorizar de perto a performance do negócio e medir o progresso em relação aos objetivos estabelecidos (Ong et al., 2011).
25 Dashboards Os dashboards são ferramentas de visualização de dados amplamente reconhecidas nos dias de hoje. Segundo Few (2006), são definidos como exposições visuais da informação mais importante necessária para alcançar objetivos consolidados, dispostos num único ecrã para uma leitura instantânea. Um dashboard consiste numa aplicação integrada de dados com elementos visuais e uma interface do utilizador ( UI ), como descrito por Munoz. Os dados apresentados incluem métricas, Key Performance Indicators (KPIs) e informação textual. Outros elementos comuns nos dashboards são valores para análise histórica, tendências, distribuições, previsões, comparações e relações (Munoz, 2017). C. J. Costa & Aparicio, 2019, defendem a concentração da informação num único ecrã para facilitar a monitorização, enquanto (Few, 2006) identifica problemas típicos no design de dashboards , como exceder os limites do ecrã, referenciar contextos inadequados para os dados e mostrar demasiados detalhes. Fatores como distribuição, carga cognitiva e interatividade dos elementos visuais contribuem para a eficácia de um dashboard e o valor que oferece aos seus utilizadores (Pappas & Whitman, 2011). Segundo várias fontes, os dashboards podem ser classificados em três tipos diferentes: estratégico, operacional e analítico. Os dashboards estratégicos são comumente utilizados em contextos empresariais, com o objetivo de comunicam o desempenho da empresa em relação aos objetivos. Destacam medidas de alto nível de desempenho e previsões, como comparações com o passado ou metas (Pappas & Whitman, 2011). Por outro lado, os dashboards operacionais são projetados para controlar e gerir as operações em tempo real ou em intervalos de tempo mais curtos. São concebidos para uma rápida análise visual, permitindo a identificação imediata de potenciais problemas, tendências e oportunidades de melhoria (Pappas & Whitman, 2011). Por fim, os dashboards analíticos, os quais têm como objetivo principal detetar padrões, tendências e relações em grandes conjuntos de dados através de um processo interativo. São frequentemente utilizados por analistas e investigadores para explorar e analisar os dados em profundidade (Munoz, 2017). O sucesso na visualização de dados, como observado por Knaflic (2015), reside na capacidade de contar histórias por meio dos dados, um conceito conhecido como data storytelling .
26 A importância do contexto, conforme discutido por Knaflic (2015) é fundamental antes da elaboração de visualizações de dados para apresentar informações quantitativas. Adaptar as visualizações a um grupo específico é essencial para maximizar a eficácia da mensagem. Além disso, compreender o nível técnico da audiência é decisivo no design das visualizações. Knaflic (2015) destaca dois tipos de análise nesse contexto: análise exploratória e análise explicativa. A análise exploratória refere-se ao trabalho preliminar de compreender os dados e destacar o que pode ser útil anotar, enquanto a análise explicativa visa transmitir uma mensagem. Existem diversos tipos de visualizações, desde texto simples até tabelas, gráficos e mapas, como destacado por Deacon et al. (2020). No contexto de visualização de dados empresariais, os gráficos são focados em exibir valores quantitativos, como KPIs e outras métricas (Munoz, 2017). A escolha do gráfico depende dos dados e da informação a ser comunicada ao utilizador. Existem quatro tipos principais de gráficos comumente utilizados: • Gráficos de Comparação: auxiliam comparação de valores ao longo do tempo e identificar tendências. Os exemplos comuns incluem o bar chart, o line chart e o bar line chart (Dijk, 2015). • Gráficos de Composição: ajudam os utilizadores a visualizar como uma parte dos dados se compara ao todo. Os exemplos incluem o pie/doughnut chart, o stacked bar chart e o stacked area chart (Dijk, 2015). • Gráficos de Distribuição: permitem que os utilizadores identifiquem facilmente a forma ou tendência dos dados. Como exemplos comuns temos o histogram, o bar chart e os mapas em caso de dados geográficos. • Gráficos de Relações: ajudam os utilizadores a visualizar correlações e relações nos dados. Entre os exemplos incluem-se scatter plots, bubble charts e grouped bar charts . Conforme apontado por C. J. Costa & Aparicio (2019), os gráficos devem apresentar os dados de modo que o espetador esteja focado na substância em vez do design gráfico, metodologia ou tecnologia.
27 A visão é o sentido humano mais dominante, com aproximadamente 70% dos recetores sensoriais dedicados a ela (Few, 2006). Nesta seção, serão abordados os princípios da Gestalt e os preattentive attributes como ferramentas de perceção visual. • Princípio da Proximidade: O cérebro tende a agrupar naturalmente elementos próximos em conjuntos, o que pode ser utilizado para destacar padrões (Knaflic, 2015). • Princípio da Similaridade: Objetos com caraterísticas semelhantes, como tamanho, cor e forma, são percebidos como parte do mesmo grupo (Shadare et al., 2016). • Princípio do Enclausuramento: Percebidos como pertencentes a um grupo específico, podendo ser destacados com o uso de sombras e margens (Knaflic, 2015). • Princípio do Encerramento: Remover elementos desnecessários destaca os dados que se deseja apresentar (Knaflic, 2015). • Princípio da Continuidade: Os olhos tendem a procurar o caminho mais fácil ao depararem-se com um objeto, criando a ideia de continuidade, mesmo que este não exista fisicamente (Knaflic, 2015). • Princípio da Conexão: Elementos visualmente conectados são percebidos como estando relacionados ou agrupados (Shadare et al., 2016). 2.5.5 Requisitos As organizações têm uma necessidade cada vez maior de informação para conseguirem tratar os problemas atuais e futuros com rapidez e qualidade (S. Costa & Santos, 2012). Esta informação é preciosa, pois permite que aquelas ajam de uma forma mais prudente e eficaz perante os problemas que possam ser detetados, ou até mesmo previstos. No entanto, é necessário que um sistema de BI siga alguns requisitos, garantindo a eficácia do sistema desenvolvido (Kimball & Ross, 2013). No ambiente dinâmico das organizações, a consistência da informação é crucial para garantir a confiabilidade das análises e decisões. Ao integrar dados de diferentes fontes num
28 sistema de Business Intelligence (BI) , é possível assegurar a viabilidade da informação e das análises resultantes (S. Costa & Santos, 2012). Além disso, o timing da disponibilidade da informação desempenha um papel fundamental na melhoria do desempenho organizacional. As informações confiáveis e oportunas proporcionam à empresa uma vantagem competitiva, permitindo a antecipação e mitigação de potenciais problemas (S. Costa & Santos, 2012). A acessibilidade da informação também é um aspeto essencial a considerar. Um sistema de BI deve possuir uma interface amigável, oferecendo uma análise iterativa e simples que traduza eficazmente os dados em informações pertinentes para a organização (Turban et al., 2014). A capacidade de analisar o desempenho de processos, setores ou da organização como um todo, deve ser simplificada através da apresentação direta e compreensível das informações. Por fim, a segurança da informação é uma preocupação central, dada a sensibilidade dos dados armazenados em um Data Warehouse (DW). Torna-se fundamental que esses dados sejam partilhados apenas com as entidades apropriadas, de acordo com as políticas de segurança estabelecidas (S. Costa & Santos, 2012). Garantir a confidencialidade e integridade dos dados é essencial para proteger os interesses da organização e manter a confiança dos stakeholders .
35 Figura 10 - Criação da Area Staging - AW2019_Staging (Fonte Própria) Posteriormente, inicia-se o processo de criação de todas as tabelas presentes na base de dados descarregada. Como já explicado, esta base de dados é composta por um total de 68 tabelas, agrupadas em diferentes categorias, como Recursos Humanos, Pessoas, Produção e Vendas. Esta divisão não foi replicada na área de staging , uma vez que não se considerou necessário. A Figura 11 demonstra um exemplo de código para a criação de uma das tabelas, sendo possível consultar todo o código no tópico "Anexo II – Criação das tabelas da Area Staging - AW2019_Staging ". Figura 11 - Criação da tabela "Stg_Department" na Area Staging (Fonte Própria)
36 3.4.3 Data Mart Após uma análise aprofundada da base de dados original e dos requisitos identificados, a mesma foi reduzida de 68 para 14 tabelas. Esta redução significativa envolveu a integração de informações de múltiplas tabelas em tabelas unificadas, refletindo a transição de uma área de staging para um data mart . O primeiro passo neste processo foi identificar as relações e as possíveis integrações de informação entre tabelas, garantindo a manutenção da organização e coerência dos dados. Com estas ligações devidamente estabelecidas, procedeu-se à elaboração das novas tabelas. Graças à limpeza de informação que não era útil para o projeto e à agregação de tabelas, a base de dados passou a ser dividida entre os assuntos: Recursos Humanos, Vendas, Compras e Produção. Esta reorganização foi necessária porque os requisitos também dividem os dados nestes quatro grandes temas. Esta nova estrutura simplificada e otimizada facilita o acesso e a análise dos dados, proporcionando um panorama mais eficiente e alinhado com os requisitos especificados. As novas tabelas foram projetadas para permitir a integração de dados de várias fontes, assegurando uma visão abrangente e consistente da informação disponível. À semelhança das anteriores, esta etapa do projeto inicia-se com a criação de uma nova base de dados “ AW2019_DW ” (Figura 12). Figura 12 - Criação da DW - AW2019_DW (Fonte Própria)
37 A Figura 13 apresenta um exemplo de código da criação de uma das tabelas. Para analisar o código de todas as tabelas criadas nesta base de dados, deve-se consultar o ponto Anexo II – Criação das tabelas da DW - AW2019_DW. Figura 13 - Criação da tabela "Dim_Colaborador" na DW (Fonte Própria) É importante ressaltar que tal como mencionado ao longo da revisão da literatura, o objetivo é que esta base de dados seja inserida no Power BI , sendo, portanto, crucial que o modelo seja compreendido por essa ferramenta. Para tal, o modelo conceptual deve ser em estrela ou em floco de neve, e isso também foi tido em conta ao longo do desenvolvimento do Data Warehouse . Neste modelo, uma tabela de factos central é conectada a várias tabelas de dimensão. A tabela factual armazena os dados quantitativos sobre o negócio, enquanto as tabelas de dimensão armazenam os atributos descritivos relacionados às dimensões do negócio. No contexto deste projeto, as tabelas de dimensão e de factos estão categoricamente nomeadas para facilitar a identificação e a utilização no Power BI e interpretação do utilizador. Por exemplo, a dimensão do colaborador é representada pela tabela "Dim_Colaborador", enquanto uma tabela factual é representada por "Fact_PVC". Isto é, as tabelas dimensão apresentam o prefixo “Dim_” enquanto as factuais apresentam o prefixo “Fact”. Esta nomenclatura clara e estruturada ajuda na organização e na interpretação dos dados, garantindo uma integração mais eficiente e compreensível. Dessa forma, ao utilizar o modelo em estrela ou em floco de neve, é possível otimizar a análise e a visualização dos dados, tornando o processo mais intuitivo e eficiente para os utilizadores finais.
38 3.4.4 Carregamento de Dados A integração entre SSIS e SQL Server para carregar tabelas é um processo estruturado onde o SSIS atua como a ferramenta de ETL para mover dados de várias fontes para o SQL Server . Este processo envolve várias etapas. Primeiramente, os dados são extraídos de outras bases de dados. Em seguida, esses dados passam por uma transformação, onde podem ser limpos, agregados, ou combinados de maneiras específicas para atender aos requisitos do negócio. Por fim, os dados transformados são carregados nas tabelas de destino no SQL Server . Durante este processo, o SSIS utiliza uma série de componentes como Data Flow Tasks , que geram a extração, transformação e carregamento dos dados. Conexões são estabelecidas entre os pacotes SSIS e o SQL Server para permitir a transferência de dados. Além disso, o SSIS pode implementar transações para garantir a integridade dos dados durante o carregamento, bem como utilizar checkpoints para retomar o processo onde parou em caso de falhas. Esta integração robusta e flexível facilita a manutenção e a execução eficiente dos processos de ETL, garantindo que os dados sejam movidos e transformados consoante o necessário, enquanto se mantém um registo detalhado de todas as operações realizadas. Processo de logs Para um maior controlo deste fluxo é recomendado criar o processo de logs . Este processo envolve a captura e o armazenamento de informações detalhadas sobre a execução de pacotes SSIS . Esses logs são essenciais para supervisionar, corrigir e auditar os processos de ETL ( Extract, Transform, Load ). Durante a execução de pacotes SSIS , eventos como início e fim de tarefas, erros, avisos e informações personalizadas podem ser registados. Estes logs são armazenados no SQL Server numa tabela específica, permitindo uma análise detalhada do desempenho e comportamento dos pacotes, já que cada carregamento será um novo registo nesta tabela. Para implementação deste processo é necessário criar a tabela onde serão armazenados estes dados e dois procedimentos ( Stored Procedures ). O primeiro ( Create_log ) tem por finalidade inserir um registo na tabela de logs indicando o início de um processo ou tarefa. Esta stored procedure pode incluir parâmetros como o nome, a data e hora de início bem como outras informações relevantes. Já o segundo ( Close log ) deverá atualizar o registo de log com informações de fim, como a data e hora do fim e o estado final do processo. Estas duas stored procedure deverão ser executadas
39 sempre que existir um carregamento de dados, ou seja, sempre que um pacote do SSIS também for executado. O código completo deste processo está disponível no Anexo III – Processo de logs. Figura 14 - Criação da tabela de logs na base de dados AW2019_Staging (Fonte Própria) Figura 15 - Stored Procedure - create log (Fonte Própria)
40 Figura 16 - Stored Procedure - close log (Fonte Própria) Carregamento das tabelas da Area Staging O SSIS encontra-se disponível no Visual Studio com a extensão de Integration Services Project , opção disponível quando se seleciona um novo projeto.
41 Figura 17 - Novo projeto Integration Services Project (SSIS) no Visual Studio (Fonte Própria) Figura 18 - Criação do projeto "AdventureWorks2019" de "Integration Services Project" no Visual Studio (Fonte Própria) Para garantir um maior controlo sobre os processos de carregamento, deve-se registar o início e o fim de cada package na tabela de logs , conforme já explicado anteriormente. Posto isto, todos os packages devem iniciar-se e terminar com a execução das stored procedures referentes ao início e fim de um log . Para isso, o primeiro passo é criar as variáveis necessárias para o efeito (Figura 19): • COD_DIA_FIM – Regista o fim da execução do carregamento de dados; • COD_DIA_INI – Regista o início da execução do carregamento de dados; • COD_DTS – Indica a tabela de destino, onde são carregados os dados; • COD_MODULO – Indica a que área pertence, no caso, é a área staging ( stg ); • DESC_DTS – Descrição da ação e do local onde os dados são carregados;
42 • ID_LOG – Cada carregamento tem um Id único associado, esta variável cria esse Id. • TABELA_DESTINO – Esta variável só é criada para facilitar a criação dos packages, uma vez que são sempre iguais no que toca às variáveis, basta fazer uma cópia do anterior e alterar esta variável para a nova tabela que vai ser carregada. Figura 19 - Exemplo de criação de um package SSIS – Area Staging - Variáveis para o processo de logs (Fonte Própria) Posteriormente, cria-se a Task onde a stored Proceure referente ao início de um log será executada (Figura 20). Dentro desta Task é necessário adicionar uma conexão com a base de dados onde se encontra o processo de logs - AW2019_Staging (Figura 21) e parametrizar devidamente as variáveis criadas (Figura 22).
43 Figura 20 - Exemplo de criação de um package SSIS – Area Staging – Adicionar task do início do processo de logs (Fonte Própria) Figura 21 - Exemplo de criação de um package SSIS – Area Staging – Adicionar conexão à base de dados - AW2019_Staging (Fonte Própria)
44 Figura 22 - Exemplo de criação de um package SSIS – Area Staging – Parametrização das Variáveis do Processo de Início de logs (Fonte Própria) O objetivo principal é criar um espelho da base de dados “ AdventureWorks2019 ” na “ AW2019_Staging ”. Para isso, sempre que os dados forem carregados, é necessário limpar previamente os dados existentes nas tabelas de staging , utilizando o código TRUNCATE TABLE . Desta forma evita-se a duplicação de dados. Noutros casos também se costuma eliminar apenas uma parte da tabela, mas neste projeto não se aplica porque se pretende criar histórico. Para este processo cria-se uma variável “EXPR_TRUNCATE_TABLE” (Figura 23). Apenas com o intuito de facilitar a criação dos próximos carregamentos, à semelhança da variável “TABELA_DESTINO”.
51 que a etapa de conexão às bases de dados só se realiza na primeira vez. Seguindo esta prática, garante-se que o carregamento de dados nas tabelas de staging seja eficiente e controlado, permitindo uma replicação fiel dos elementos da base de dados “ AdventureWorks2019 ” na “ AW2019_Staging ”. Figura 33 - Exemplo de criação de um package SSIS – Area Staging – Execução do para a tabela Stg_Address (Fonte Própria) Figura 34 - Exemplo de criação de um package SSIS – Area Staging – Resultado da tabela dos registos de carregamento (Fonte Própria)
52 Figura 35 - Exemplo de criação de um package SSIS – Area Staging – Visão total do processo (Fonte Própria) Carregamento das tabelas do Data Mart – DW Este carregamento pode ser desenvolvido no mesmo projeto das tabelas da Area Staging . À semelhança do anterior, os carregamentos desta área devem começar pelo início da criação de um log. Para isso, é necessário replicar esse mesmo passo. No SSIS (SQL Server Integration Services), o processo de tratamento de registos "indefinidos" para evitar a duplicação de dados é uma técnica e estratégia usada para garantir que cada registo inserido seja único, evitando duplicações indesejadas. Como se trata de dimensões o id da tabela deve ser único, uma vez que este processo garante que isso aconteça. Para isto é necessário adicionar duas variáveis SQL_DEL_IND e a SQL_INS_IND (Figura 36), a primeira terá a função de eliminar valores e a segunda de os inserir.
53 Figura 36 - Exemplo de criação de um package SSIS – Data Mart - Variáveis para o processo de indefinidos (Fonte Própria) Figura 37 - Exemplo de criação de um package SSIS – Data Mart - Task para o processo de eliminar indefinidos (Fonte Própria) Pelas mesmas razões explicadas anteriormente, no carregamento da área staging , também é necessário eliminar todos os registos da tabela antes de a carregar com novos dados (Figura 38).
54 Figura 38 - Exemplo de criação de um package SSIS – Data Mart - Variável “EXPR_TRUNCATE_TABLE” (Fonte Própria) Consoante mencionado anteriormente, a composição das colunas das tabelas Dimensão e Factual resulta da junção de várias tabelas da área de staging . Devido a isso, o carregamento dessas tabelas não pode ser realizado apenas através de um simples mapeamento entre as colunas das tabelas envolvidas. A solução encontrada foi utilizar a instrução MERGE INSERT , que é executada através da variável “EXPR_MERGE” (Figura 39 e Figura 40). Todos os códigos utilizados neste processo estão disponíveis para consulta no ponto Anexo V – Carregamento das tabelas – Data Mart – AW2019_DW em linguagem SQL.
55 Figura 39 - Exemplo de criação de um package SSIS – Data Mart - Variável “EXPR_MERGE” (Fonte Própria) Figura 40 - Exemplo de criação de um package SSIS – Data Mart - Task para o carregamento de dados (Fonte Própria) Após o carregamento dos dados, é necessário concluir o processo de tratamento dos registos "indefinidos" para garantir a integridade e a unicidade dos elementos na base de dados. Esse procedimento visa evitar duplicações e assegurar que cada registo seja único (Figura 41).
56 Figura 41 - Exemplo de criação de um package SSIS – Data Mart - Task para o processo de inserir indefinidos (Fonte Própria) Tal e qual como para o carregamento da área Staging , este processo também termina com o fim do procedimento de logs que será registado na mesma tabela “stgx_log_carregamento”. O procedimento explicado para o carregamento de todas as tabelas do data mart segue sempre o mesmo padrão. Portanto, neste projeto, foi especificado apenas um exemplo de como este processo é realizado, detalhando os passos essenciais.
57 Figura 42 - Exemplo de criação de um package SSIS – Data Mart – Execução do para a tabela Dim_Cliente (Fonte Própria) Figura 43 - Exemplo de criação de um package SSIS – Data Mart – Resultado da tabela dos registos de carregamento (Fonte Própria) Figura 44 - Exemplo de criação de um package SSIS – Data Mart – Visão total do processo (Fonte Própria)
58 3.4.5 Criação de Views A criação de views é uma etapa crucial na preparação de dados para o Power BI . Essas consultas SQL simplificam e consolidam dados complexos, tornando-os acessíveis para análise, são uma prática recomendada para organizar, simplificar e proteger os dados, fornecendo uma base sólida para análises eficazes no Power BI . Como a lógica do código de todas as views é similar, apenas é demonstrado um exemplo. Contudo o código encontra-se completo no ponto Anexo VI – Criação de Views – Data Mart – AW2019_DW Figura 45 - Exemplo de código SQL de criação de views 3.5 Visualização de Dados A fase de visualização de dados iniciou-se com a criação de um logotipo (Figura 46) que representará visualmente a identidade da Adventure Works . Este logotipo foi concebido a partir de uma imagem encontrada na internet , a qual foi personalizada e adaptada especificamente para este projeto. Figura 46 - Logotipo da AdventureWorks 2019 (Fonte Própria)
59 Esta fase também envolveu a seleção cuidadosa de uma paleta de cores, que desempenha um papel crucial na comunicação visual e na compreensão dos dados apresentados. As cores escolhidas para a Adventure Works (Figura 47) foram selecionadas para garantir clareza, coesão e apelo visual, facilitando a interpretação dos dados e destacando as informações mais relevantes. 3.5.1 Importação de Dados Para importar os dados da base de dados AW2019_DW para o Power BI , utiliza-se a fonte de dados " SQL Server ". Nessa fonte, é necessário inserir o servidor e a base de dados que se deseja aceder. Em seguida, selecionam-se as tabelas que serão utilizadas no projeto. Esta abordagem permite que o Power BI se conecte diretamente à base de dados, facilitando a importação e a análise dos mesmos. Figura 47 - Palete de Cores do Projeto (Fonte Própria)
60 Figura 48 - Ligação à fonte de dados SQL Server - Power BI (Fonte Própria) Figura 49 - Seleção das tabelas para análise (Fonte Própria) Nesta fase, a única transformação de dados realizada no Power Query foi a alteração de algumas colunas que eram do tipo DateTime para o tipo Date . Este passo é essencial para evitar problemas futuros ao relacionar essas colunas com a coluna “ Date ” da tabela “Dim_Tempo”. A importância desta tabla assim como a sua elaboração estão explicadas no início do ponto 3.5.2. Desenvolvimento Power BI.
67 Figura 58 - Apresentação da página "Fornecedores" da área das Compras (Fonte Própria) Figura 59 - Apresentação da página "Tabela de Pesquisa" da área das Compras (Fonte Própria) Produção Tal como nas anteriores, esta análise inicia-se com uma visão geral. Nesta seção, é possível validar a quantidade encomendada, produzida e rejeitada, além de permitir realizar comparações entre os custos planeados e reais, entre outras possíveis análises. Em seguida, apresenta-se uma análise detalhada da produtividade, onde se avaliam valores relativos à disponibilidade, qualidade, produtividade e eficiência global, assim como outros destaques
68 considerados relevantes. Por último, foram criadas mais duas páginas: uma que representa graficamente as ordens de produção e outra que é a tabela de pesquisa, seguindo o mesmo modelo dos temas anteriores. Figura 60 - Apresentação da página "Geral" da área da Produção (Fonte Própria) Figura 61 - Apresentação da página "Produtividade" da área da Produção (Fonte Própria)
69 Figura 62 - Apresentação da página "Ordens de Produção" da área da Produção (Fonte Própria) Figura 63 - Apresentação da página "Tabela de Pesquisa" da área da Produção (Fonte Própria) Vendas No que toca às vendas, pretende-se obter uma visão geral que abrange o valor das vendas, a quantidade e as ordens de venda, entre outras métricas. A análise das vendas é dividida em mais quatro páginas. A primeira página é dedicada à análise do carrinho de compras, permitindo compreender quais os produtos que costumam ser comprados em conjunto, com a possibilidade de análise tanto por território como por produto específico. Em seguida, apresenta-se a análise das ordens de venda, com comparações entre períodos homólogos. Posteriormente, foi construída
70 uma página focada na relação entre vendedores e clientes, avaliando o valor monetário, a localização e a assiduidade das interações. Por último, está disponível uma tabela de pesquisa com as mesmas funcionalidades das análises anteriores, mas adaptada ao tema das vendas, permitindo uma consulta detalhada e personalizada. Figura 64 - Apresentação da página "Geral" da área de Vendas (Fonte Própria) Figura 65 - Apresentação da página "Carrinho de Compras" da área de Vendas (Fonte Própria)
71 Figura 66 - Apresentação da página "Clientes & Vendedores" da área de Vendas (Fonte Própria) Figura 67 - Apresentação da página " Tabela de Pesquisa” da área de Vendas (Fonte Própria)
72 Figura 68 - Apresentação da página "Tabela de Pesquisa – Ordem de Vendas" da área de Vendas (Fonte Própria) Geral A página geral agrupa os quatro temas principais. Esta página é projetada para ser a primeira consulta para qualquer pessoa que não pertença a um departamento específico, oferecendo uma visão abrangente e consolidada do desempenho geral da empresa. Ela facilita a compreensão dos principais indicadores financeiros e operacionais, servindo como um ponto de partida essencial para uma análise mais detalhada em áreas específicas. Todas as medidas utilizadas nesta página do relatório foram criadas nos âmbitos anteriores. Figura 69 - Apresentação da página Geral (Fonte Própria)
73 Página Inicial A página inicial do projeto funciona como a capa, oferecendo a opção de selecionar o tema desejado para acesso prioritário. Além disso, disponibiliza o manual de técnico para auxiliar os utilizadores, caso necessário. Essa página serve como ponto de entrada centralizada, proporcionando uma navegação intuitiva e facilitando o acesso rápido a informações relevantes. Para além disto, esta página contém o manual de utilização do documento onde é explicado detalhadamente cada medida criada no projeto, com o intuito de simplificar e agilizar qualquer dúvida do utilizador final. É projetada para garantir uma experiência fluida e eficiente para todos os utilizadores do Power BI . Figura 70 - Apresentação da página Inicial (Fonte Própria) Acesso ao link do Manual de Técnico – Manual de Técnico. Para encerrar este tópico, 3.5.2 Desenvolvimento Power BI, falta apenas realizar um resumo dos aperfeiçoamentos aplicados na ferramenta, consoante pode ser verificado na Figura 71.
74 Figura 71 - Resumo dos Desenvolvimentos no Power BI (Fonte Própria
75 4 Aplicação do Modelo Este capítulo tem como objetivo analisar a aplicabilidade do projeto desenvolvido no contexto empresarial, com foco particular na implementação de um Data Warehouse . Para alcançar esse propósito, foram conduzidas entrevistas com diversos profissionais da área, consultores e gestores de empresas de diferentes tipos: duas que já possuem um Data Warehouse em funcionamento, outra que ainda não teve qualquer contato com essa tecnologia e está numa fase inicial de transformação digital. Além disso, uma quarta entrevista foi realizada com um diretor comercial especializado na área de modo a também ter a perspetiva de quem vende este tipo de serviços. A metodologia proposta para a implementação do Data Warehouse (DW) foi desenvolvida com base nas melhores práticas da área de Business Intelligence , dividindo o processo em etapas claras e replicáveis. O objetivo da abordagem era que o relatório desenvolvido fosse possível de aplicar como um todo ou apenas alguns temas, e conseguir com que a maioria das empresas se identificasse com esses temas. Esse equilíbrio assegura que diferentes empresas, independentemente de sua maturidade digital ou setor, possam extrair valor do relatório, aplicando as recomendações e insights às suas realidades específicas. Daí a importância de diversidade e ao mesmo tempo profundidade dos temas. As etapas da metodologia incluem um diagnóstico principal e levantamento de requisitos, a escolha da arquitetura a implementar, os processos de ETL, desenvolvimento de relatórios. Num projeto com um cliente final específico seria importante incorporar ainda uma fase de testes e outra de formação aos utilizadores finais e, assim, garantir uma maior segurança nos dados do projeto. Na primeira etapa, o levantamento de requisitos foi realizado para identificar as necessidades empresariais e personalizar o Data Warehouse . O principal desafio foi a falta de conhecimento profundo sobre os dados disponíveis, dificultando a identificação de áreas de interesse. Na segunda fase, foi idealizada a estrutura do Data Warehouse , definindo o modelo de dados com base nas informações anteriores e escolhendo entre as arquiteturas em estrela ou floco de neve. Os principais desafios foram garantir escalabilidade e possibilitar a evolução deste data warehouse .
76 O processo de ETL foi automatizado com o uso do SQL Server Integration Services (SSIS). Durante esta fase, garantiu-se que as transformações de dados respeitassem regras de negócios específicas, mantendo a qualidade das informações. A maior dificuldade enfrentada foi a grande quantidade de dados e o tempo despendido para organizar e estruturar essa informação. Para mitigar atrasos e garantir a integridade dos dados, foram estabelecidos prazos flexíveis e um sistema de controlo contínuo durante o processo de ETL, permitindo ajustes rápidos e eficazes conforme necessário. Após a implementação do DataWarehouse , foi construído o relatório no PowerBI , permitindo análises intuitivas dos dados. Era importante que o relatório abordasse as questões de negócio identificadas anteriormente, assegurando uma visualização clara dos indicadores-chave de desempenho (KPIs). Para lidar com os desafios de personalização e evitar sobrecarga de informações, foi desenvolvida uma página geral com tabelas de pesquisa que permitem selecionar subtemas, facilitando também a exportação de dados quando necessário. As entrevistas abordaram uma variedade de tópicos, começando com a apresentação do projeto desenvolvido, seguida por questões sobre a relevância e a necessidade de um DataWarehouse , os principais desafios associados à sua implementação, as competências e condições exigidas, a gestão interna dos processos, e os obstáculos enfrentados ao longo do caminho. Por fim, foram discutidas algumas questões adicionais e sugestões de melhoria. O objetivo das entrevistas foi captar as opiniões e perceções acerca do antes e após a implementação de um DataWarehouse , bem como obter insights valiosos de profissionais com vasta experiência na área. É possível consultar as entrevistas em pormenor no Anexo XIII – Entrevistas. Os entrevistados destacaram a importância dos dashboards e data warehouses na tomada de decisão. A utilização dos dashboards permite uma análise de dados mais acessível, facilitando a compreensão mesmo para quem tem pouca experiência em análise de dados. Estes instrumentos são essenciais para controlar o negócio, apoiar decisões informadas, comparar dados históricos e traçar estratégias futuras, mesmo em organizações com menos experiência em Business Intelligence. Houve consenso entre os entrevistados quanto à necessidade de um data warehouse para assegurar a competitividade e eficiência das empresas. Este é considerado essencial para o desenvolvimento de inteligência artificial, validação de dados, centralização e
83 Gartner Research. (2008). "Gartner EXP Worldwide Survey of 1,500 CIOs Shows 85 Percent of CIOs Expect “Significant Change” Over Next Three Years”. Gartner Research . Gartner Research. (2009). Gartner EXP Worldwide Survey of More than 1,500 CIOs Shows IT Spending to Be Flat in 2009.". Gartner Research . Gröger, C., Hillmann, M., Hahn, F., Mitschang, B., & Westkämper, E. (2013). The operational process dashboard for manufacturing. Procedia CIRP , 7 , 205–210. https://doi.org/10.1016/j.procir.2013.05.035 Guarda, T., Santos, M., Pinto, F., Augusto, M., & Silva, C. (2013a). Business Intelligence as a Competitive Advantage for SMEs. International Journal of Trade, Economics and Finance , 187–190. https://doi.org/10.7763/ijtef.2013.v4.283 Guarda, T., Santos, M., Pinto, F., Augusto, M., & Silva, C. (2013b). Business Intelligence as a Competitive Advantage for SMEs. International Journal of Trade, Economics and Finance , 187–190. https://doi.org/10.7763/ijtef.2013.v4.283 Gyulai, D., Bergmann, J., Gallina, V., & Gaal, A. (2020). Towards a connected factory: Shop-floor data analytics in cyber-physical environments. Procedia CIRP , 86 , 37–42. https://doi.org/10.1016/j.procir.2020.01.016 H. P. Luhn. (1958). A Business Intelligence System. IBM Journal of Research and Development , 2 , 314– 319. https://ieeexplore.ieee.org/document/5392644 Inmon, W. H. (2005). Building the Data Warehouse . https://books.google.pt/books/about/Building_the_Data_Warehouse.html?id=QFKTmh5IFS4C&red ir_esc=y Instituto Nacional de Estatística. (2020). Empresas em Portugal-2020 . https://www.ine.pt/xportal/xmain?xpid=INE&xpgid=ine_publicacoes&PUBLICACOESpub_boui=154 13305&PUBLICACOESmodo=2 Inyang, B. J. (2013). Defining the Role Engagement of Small and Medium-Sized Enterprises (SMEs) in Corporate Social Responsibility (CSR). International Business Research , 6 (5). https://doi.org/10.5539/ibr.v6n5p123 Jagielska, I., Darke, P., & Zagari, G. (2003). Business intelligence systems for decision support: Concepts, processes and practice. Conference of the International Society for Decision Support Systems , 215–228. Karim, A. J. (2011). The value of Competitive Business Intelligence System (CBIS) to Stimulate Competitiveness in Global Market. In International Journal of Business and Social Science (Vol. 2, Issue 19). https://www.academia.edu/7603065/The_value_of_Competitive_Business_Intelligence_System_ CBIS_to_Stimulate_Competitiveness_in_Global_Market Kasim, T., Zijad, D., Mahir, H., & Merima, H. (2018). The use of business intelligence (BI) in small and medium-sized enterprises (SMEs) in Bosnia and Herzegovina. Economic Review . Kimball, R., & Ross, M. (2002). The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling . http://artemisa.unicauca.edu.co/~ecaldon/docs/bd/the_dw_Toolkit.pdf Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling .
84 https://books.google.pt/books/about/The_Data_Warehouse_Toolkit.html?id=4rFXzk8wAB8C&redir _esc=y Kimball, R., Ross, M., Thornthwaite, W., & Reeves, L. (1998). The Data Warehouse Lifecycle Toolkit . Knaflic, C. (2015). Storytelling with Data: A Data Visualization Guide for Business Professionals . https://books.google.pt/books/about/Storytelling_with_Data.html?id=retRCgAAQBAJ&redir_esc=y Kristoffersen, E., Mikalef, P., Blomsma, F., & Li, J. (2021). The effects of business analytics capability on circular economy implementation, resource orchestration capability, and firm performance. International Journal of Production Economics , 239 . https://doi.org/10.1016/j.ijpe.2021.108205 Legendre, R. (2005). Es la inteligencia de negocio aplicable a las Pymes? Revista Hispana de La Inteligencia Competitiva , 17 , 4–9. Lusch, R., Lui, Y., & Chen, Y. (2010). The Phase Transition of Markets and Organizations: The New Intelligence and Entrepreneurial Frontier. Intelligent Systems, IEEE . https://www.researchgate.net/publication/297886072_The_Phase_Transition_of_Markets_and_O rganizations_The_New_Intelligence_and_Entrepreneurial_Frontier M. Olszak, C., & Ziemba, E. (2006). Business Intelligence Systems in the Holistic Infrastructure Development Supporting Decision Making in Organisations. Interdisciplinary Journal of Information, Knowledge, and Management , 1 , 047–058. https://doi.org/10.28945/113 Manuere, F., Gwangwava, E., & Gutu, K. (2012). INTERDISCIPLINARY JOURNAL OF CONTEMPORARY RESEARCH IN BUSINESS BARRIERS TO THE ADOPTION OF ICT BY SMES IN ZIMBABWE: AN EXPLORATORY STUDY IN CHINHOYI DISTRICT. Institute of Interdisciplinary Business Research. , 1142–1156. Meissner, A., Müller, M., Hermann, A., & Metternich, J. (2018). Digitalization as a catalyst for lean production: A learning factory approach for digital shop floor management. Procedia Manufacturing , 23 , 81–86. https://doi.org/10.1016/j.promfg.2018.03.165 Microsoft. (2023). SSIS: How to create an ETL package . Microsoft. (2024). What is SQL Server? https://learn.microsoft.com/pt-br/sql/sql-server/what-is-sqlserver?view=sql-server-ver16 Munoz, M. (2017). Global Business Intelligence . https://books.google.pt/books/about/Global_Business_Intelligence.html?id=CmcPEAAAQBAJ&redi r_esc=y Negash, S. (2004). Business Intelligence. Communications of the Association for Information Systems , 13 . https://doi.org/10.17705/1CAIS.01315 Negash, S., & Gray, P. (2008). Handbook on Decision Support Systems 2 Variations . https://link.springer.com/chapter/10.1007/978-3-540-48716-6_9 Okar, C., Fedouaki, F., & Barrijal, S. (2012). How using business intelligence can improve SCPMS project maturity: an empirical investigation in large sized Moroccan companies. In Article in International Journal of Computer Science Issues . https://www.researchgate.net/publication/304330686_How_using_business_intelligence_can_im prove_SCPMS_project_maturity_an_empirical_investigation_in_large_sized_Moroccan_companies
85 Olszak, C. M., & Ziemba, E. (2004). Business intelligence systems as a new generation of decision support systems. Proceedings of PISTA 2004, International Conference on Politics and Information Systems: Technologies and Applications . Olszak, C. M., & Ziemba, E. (2012). Critical Success Factors for Implementing Business Intelligence Systems in Small and Medium Enterprises on the Example of Upper Silesia, Poland. In Interdisciplinary Journal of Information, Knowledge, and Management (Vol. 7). https://www.informingscience.org/Publications/1584 Ong, I., Siew, P., & Wong, S. (2011). A Five-Layered Business Intelligence Architecture. Communications of the IBIMA , 1–11. https://doi.org/10.5171/2011.695619 Pappas, L., & Whitman, L. (2011). Riding the Technology Wave: Effective Dashboard Data Visualization . https://www.academia.edu/1121392/Riding_the_technology_wave_effective_dashboard_data_vis ualization Power, D. J. (2003). A Brief History of Decision Support Systems . https://www.researchgate.net/publication/200027140 Sallam, R. L., Richardson, J., Hagerty, J., & Hostmann, B. (2011). Magic Quadrant for Business Intelligence Platforms. Gartner Group, Stamford, CT . https://www.gartner.com/en/documents/1531017 Sauter, V. L. (2011). Decision Support Systems for Business Intelligence. https://books.google.pt/books?id=ebv2QwAACAAJ Schwab, K. (2016). The fourth industrial revolution . Scott-Morton, M. S. (n.d.). A framework for management information systems . https://www.researchgate.net/publication/38008090 Shadare, A. E., Musa, S. M., Akujuobi, C., Sadiku, M. N. O., Akujuobi, C. M., & Perry, R. G. (2016). Data Visualization. International Journal of Engineering Research And Advanced Technology . https://www.researchgate.net/publication/311597028 Sidi, E., El, M., & Amin, E. (2016). Star Schema Advantages on Data Warehouse: Using Bitmap Index and Partitioned Fact Tables. International Journal of Computer Applications , 134 (13), 11–13. https://doi.org/10.5120/ijca2016908108 Song, I.-Y., Rowen, W., Medsker, C., & Ewen, E. (2001). An Analysis of Many-to-Many Relationships Between Fact and Dimension Tables in Dimensional Modeling. An Analysis of Many-to-Many Relationships Between Fact and Dimension Tables in Dimensional Modeling . https://www.researchgate.net/publication/220841965_An_Analysis_of_Many-toMany_Relationships_Between_Fact_and_Dimension_Tables_in_Dimensional_Modeling Thong, J. Y. L., & Yap, C. S. (1997). Effects of resource constraints on information technology implementation in small businesses . https://insights.sei.cmu.edu/library/overcoming-barriers-totechnology-adoption-in-small-manufacturing-enterprises-smes/ Tokola, H., Gröger, C., Järvenpää, E., & Niemi, E. (2016). Designing Manufacturing Dashboards on the Basis of a Key Performance Indicator Survey. Procedia CIRP , 57 , 619–624. https://doi.org/10.1016/j.procir.2016.11.107 Turban, E., Sharda, R., Aronson, J. E., & King, D. (2007). Business intelligence: A managerial approach: Vol. 1 edition .
86 Turban, E., Sharda, R., & Delen, D. (2014). Business Intelligence and Analytics: Systems for Decision Support . https://books.google.pt/books/about/Business_Intelligence_and_Analytics_Syst.html?id=0P6pBw AAQBAJ&redir_esc=y Tutunea, M. F., & Rus, R. V. (2012). Business Intelligence Solutions for SME’s. Procedia Economics and Finance , 3 , 865–870. https://doi.org/10.1016/s2212-5671(12)00242-0 van Vugt, M., & Jacobsen, O. (2017). The Role of Business Intelligence in the Internationalisation process of SMEs. Halmstad University . Vitt, E., Luckevich, M., & Misner, S. (2002). Business Intelligence: Making Better Decisions Faster. https://books.google.pt/books?id=sWOKQgAACAAJ Wells, D. (2008). Business analytics – Getting the point . Williams, S., & Williams, N. (2007). The Profit Impact of Business Intelligence . https://doi.org/10.1016/B978-0-12-372499-1.X5000-5 Wixom, B., & Watson, H. (2010). The BI-Based Organization. International Journal of Business Intelligence Research , 1 (1), 13–28. https://doi.org/10.4018/jbir.2010071702
87 Anexos Anexo I – Requisitos Quanto aos Recursos Humanos, foram identificados dados relacionados com: • Departamento; • Funcionário; • Histórico do Departamento dos Funcionários; • Candidatos a Emprego; • Turnos. Consequentemente os Requisitos que foram identificados passaram por: • Colaboradores por departamento, cargo e por género; • Média de anos de permanência na empresa; • Idade e Estado Civil dos Colaboradores; • Horas de Férias; • Horas de Licença; • Contratações de Colaboradores; • Rescisão de Colaboradores; • Alterações de Departamento; • Taxa de Empregabilidade consoante os candidatos e número de colaboradores; • Satisfação dos Candidatos quanto ao cargo/área final, consoante a que se propõe; • Organograma da empesa através do departamento e cargo; • Turnos apresentando os horários por cargo/área e, se possível adicionar no organograma. No que respeito às vendas, a informação inicial abrange os seguintes tópicos:
88 • Ordem de Venda e detalhes; • Motivo da Venda; • Histórico de Cotas dos Vendedores; • Território; • Vendedor; • Loja; • Produto; • Promoções; • Taxa de Vendas; • Clientes; • Cartão de Crédito e detalhes; • Moeda por Região/País; • Taxa de Câmbio. Como resultado surgiram os seguintes requisitos: • Melhor vendedor por loja; • Localização de cada uma das lojas por volume de negócio; • Motivo da Compra; • Produtos em Stock; • Stock de segurança; • Produtos mais vendidos em cada um dos territórios e loja; • Estado da Ordem de Venda; • Total de vendas discriminado por categoria de produto; • Comparar ano atual com ano anterior; • Meta de vendas anual, mensal e alcance;
89 • Meta de novos clientes anual e alcance Custo de aquisição do cliente; • Ticket médio - custo médio por venda, • Taxa de conversão - identificar a eficiência da equipa de vendas; • Ciclo de venda e recompras pelos clientes. No âmbito das vendas, os dados inicialmente percebidos diziam respeito a: • Ordem de Produção e detalhes; • Roteamento da Ordem de Produção; • Produto; • Razão de Obsoletos; • Análise do Produto; • Descrição do Produto; • Inventário de Produtos; • Categoria do Produto; • Subcategoria do Produto; • Modelo do Produto; • Descrição do Modelo do Produto por Cultura; • Cultura do Produto; • Localização do Produto; • Transações; • Histórico de Transações; • Lista de Materiais; • Histórico de preços da lista de produtos; • Histórico de custos do produto; • Foto do Produto; Modelo;
90 • Documento do Produto. Os requisitos da Produção • Necessidade de Produção; • Status da Ordem de Produção; • Identificação de roturas de stock; • Produtos obsoletos e respetivo motivo e custo; • Tempo Médio Para Reparo; • Custo total de Produção; • Custos por produto; • Stock de produtos; • Número de Produtos Produzidos; • Produtividade homem/hora; • Tempo de inatividade; • Tempo Médio Entre Falhas; • Horas trabalhadas na produção; • Nível de utilização da capacidade instalada. Relativamente aos Clientes os requisitos assentam na informação disponível nas Vendas: • Conseguir filtrar por loja e cliente; • Localização do Produto independentemente do canal da compra; • Histórico de compras do cliente e produtos comprados; • Informações da ficha de cliente; • Loja frequentemente utilizada/habitual; • Produtos em Promoção, valor do desconto, valor do produto com desconto; • Motivo da compra do cliente para facilitar até o atendimento ao cliente;
91 • Stock em loja; • Utilizar valores em dólares para além das outras moedas; • Ranking de clientes por Território, Região ou País; Com esta informação recolhida, foi ainda possível contabilizar outros requisitos para uma abordagem mais geral da empresa, que incluem: • Lucro líquido; • Margem de lucro líquida; • Margem de lucro bruta; • OEE % - Disponibilidade; • Performance; • Qualidade; • Market Share ; • Ticket Médio; • Taxa de retenção dos funcionários; • Qualidade e Conformidade (peças refeitas); • Distribuição de custos; • Volume de negócios por território.
92 Anexo II – Criação das tabelas da Area Staging - AW2019_Staging use [AW2019_Staging] -- 1. Stg_Department CREATE TABLE Stg_Department ([DepartmentID] smallint not null, [Name] nvarchar(50) not null, [GroupName] nvarchar(50) not null, [ModifiedDate] datetime not null) -- 2. Stg_Employee CREATE TABLE Stg_Employee ([BusinessEntityID] int not null, [NationalIDNumber] nvarchar(15) not null, [LoginID] nvarchar(256) not null, [OrganizationNode] hierarchyid null, [OrganizationLevel] smallint null, [JobTitle] nvarchar(50) not null, [BirthDate] date not null, [MaritalStatus] nchar(1) not null, [Gender] nchar(1) not null, [HireDate] date not null, [SalariedFlag] bit not null, [VacationHours] smallint not null, [SickLeaveHours] smallint not null, [CurrentFlag] bit not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 3. Stg_EmployeeDepartmentHistory CREATE TABLE Stg_EmployeeDepartmentHistory ([BusinessEntityID] int not null, [DepartmentID] smallint not null, [ShiftID] tinyint not null, [StartDate] date not null, [EndDate] date null, [ModifiedDate] datetime not null) -- 4. Stg_EmployeePayHistory CREATE TABLE Stg_EmployeePayHistory ([BusinessEntityID] int not null, [RateChangeDate] datetime not null, [Rate] money not null, [PayFrequency] tinyint not null, [ModifiedDate] datetime not null) -- 5. Stg_JobCandidate CREATE TABLE Stg_JobCandidate ([JobCandidateID] int not null, [BusinessEntityID] int null, [Resume] xml null, [ModifiedDate] datetime not null) -- 6. Stg_Shift CREATE TABLE Stg_Shift ([ShiftID] tinyint not null, [Nome] nvarchar(50) not null, [StartTime] time(7) not null, [EndTime] time(7) not null,
99 [ModifiedDate] datetime not null) -- 46. Stg_PurchaseOrderDetail CREATE TABLE Stg_PurchaseOrderDetail ([PurchaseOrderID] int not null, [PurchaseOrderDetailID] int not null, [DueDate] datetime not null, [OrderQty] smallint not null, [ProductID] int not null, [UnitPrice] money not null, [LineTotal] money not null, [ReceivedQty] decimal(8,2) not null, [RejectedQty] decimal(8,2) not null, [StockedQty] decimal(9,2) not null, [ModifiedDate] datetime not null) -- 47. Stg_PurchaseOrderHeader CREATE TABLE Stg_PurchaseOrderHeader ([PurchaseOrderID] int not null, [RevisionNumber] tinyint not null, [Status] tinyint not null, [EmployeeID] int not null, [VendorID] int not null, [ShipMethodID] int not null, [OrderDate] datetime not null, [ShipDate] datetime null, [SubTotal] money not null, [TaxAmt] money not null, [Freight] money not null, [TotalDue] money not null, [ModifiedDate] datetime not null) -- 48. Stg_ShipMethod CREATE TABLE Stg_ShipMethod ([ShipMethodID] int not null, [Name] nvarchar(50) not null, [ShipBase] money not null, [ShipRate] money not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 49. Stg_Vendor CREATE TABLE Stg_Vendor ([BusinessEntityID] int not null, [AccountNumber] nvarchar(15) not null, [Name] nvarchar(50) not null, [CreditRating] tinyint not null, [PreferredVendorStatus] bit not null, [ActiveFlag] bit not null, [PurchasingWebServiceURL] nvarchar(1024) null, [ModifiedDate] datetime not null) -- 50. Stg_CountryRegionCurrency CREATE TABLE Stg_CountryRegionCurrency ([CountryRegionCode] nvarchar(3) not null, [CurrencyCode] nchar(3) not null, [ModifiedDate] datetime not null) -- 51. Stg_CreditCard CREATE TABLE Stg_CreditCard ([CreditCardID] int not null, [CardType] nvarchar(50) not null,
100 [CardNumber] nvarchar(25) not null, [ExpMonth] tinyint not null, [ExpYear] smallint not null, [ModifiedDate] datetime not null) -- 52. Stg_Currency CREATE TABLE Stg_Currency ([CurrencyCode] nchar(3) not null, [Name] nvarchar(50) not null, [ModifiedDate] datetime not null) -- 53. Stg_CurrencyRate CREATE TABLE Stg_CurrencyRate ([CurrencyRateID] int not null, [CurrencyRateDate] datetime not null, [FromCurrencyCode] nchar(3) not null, [ToCurrencyCode] nchar(3) not null, [AverageRate] money not null, [EndOfDayRate] money not null, [ModifiedDate] datetime not null) -- 54. Stg_Customer CREATE TABLE Stg_Customer ([CustomerID] int not null, [PersonID] int null, [StoreID] int null, [TerritoryID] int null, [AccountNumber] varchar(10) not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 55. Stg_PersonCreditCard CREATE TABLE Stg_PersonCreditCard ([BusinessEntityID] int not null, [CreditCardID] int not null, [ModifiedDate] datetime not null) -- 56. Stg_SalesOrderDetail CREATE TABLE Stg_SalesOrderDetail ([SalesOrderID] int not null, [SalesOrderDetailID] int not null, [CarrierTrackingNumber] nvarchar(25) null, [OrderQty] smallint not null, [ProductID] int not null, [SpecialOfferID] int not null, [UnitPrice] money not null, [UnitPriceDiscount] money not null, [LineTotal] numeric(38,6) not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 57. Stg_SalesOrderHeader CREATE TABLE Stg_SalesOrderHeader ([SalesOrderID] int not null, [RevisionNumber] tinyint not null, [OrderDate] datetime not null, [DueDate] datetime not null, [ShipDate] datetime null, [Status] tinyint not null, [OnlineOrderFlag] bit not null, [SalesOrderNumber] nvarchar(25) not null,
101 [PurchaseOrderNumber] nvarchar(25) null, [AccountNumber] nvarchar(15) null, [CustomerID] int not null, [SalesPersonID] int null, [TerritoryID] int null, [BillToAddressID] int not null, [ShipToAddressID] int not null, [ShipMethodID] int not null, [CreditCardID] int null, [CreditCardApprovalCode] varchar(15) null, [CurrencyRateID] int null, [SubTotal] money not null, [TaxAmt] money not null, [Freight] money not null, [TotalDue] money not null, [Comment] nvarchar(128) null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 58. Stg_SalesOrderHeaderSalesReason CREATE TABLE Stg_SalesOrderHeaderSalesReason ([SalesOrderID] int not null, [SalesReasonID] int not null, [ModifiedDate] datetime not null) -- 59. Stg_SalesPerson CREATE TABLE Stg_SalesPerson ([BusinessEntityID] int not null, [TerritoryID] int null, [SalesQuota] money null, [Bonus] money not null, [CommissionPct] smallmoney not null, [SalesYTD] money not null, [SalesLastYear] money not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 60. Stg_SalesPersonQuotaHistory CREATE TABLE Stg_SalesPersonQuotaHistory ([BusinessEntityID] int not null, [QuotaDate] datetime not null, [SalesQuota] money not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 61. Stg_SalesReason CREATE TABLE Stg_SalesReason ([SalesReasonID] int not null, [Name] nvarchar(50) not null, [ReasonType] nvarchar(50) not null, [ModifiedDate] datetime not null) -- 62. Stg_SalesTaxRate CREATE TABLE Stg_SalesTaxRate ([SalesTaxRateID] int not null, [StateProvinceID] int not null, [TaxType] tinyint not null, [TaxRate] smallmoney not null, [Name] nvarchar(50) not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null)
102 -- 63. Stg_SalesTerritory CREATE TABLE Stg_SalesTerritory ([TerritoryID] int not null, [Name] nvarchar(50) not null, [CountryRegionCode] nvarchar(3) not null, [Group] nvarchar(50) not null, [SalesYTD] money not null, [SalesLastYear] money not null, [CostYTD] money not null, [CostLastYear] money not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 64. Stg_SalesTerritoryHistory CREATE TABLE Stg_SalesTerritoryHistory ([BusinessEntityID] int not null, [TerritoryID] int not null, [StartDate] datetime not null, [EndDate] datetime null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 65. Stg_ShoppingCartItem CREATE TABLE Stg_ShoppingCartItem ([ShoppingCartItemID] int not null, [ShoppingCartID] nvarchar(50) not null, [Quantity] int not null, [ProductID] int not null, [DateCreated] datetime not null, [ModifiedDate] datetime not null) -- 66. Stg_SpecialOffer CREATE TABLE Stg_SpecialOffer ([SpecialOfferID] int not null, [Description] nvarchar(255) not null, [DiscountPct] smallmoney not null, [Type] nvarchar(50) not null, [Category] nvarchar(50) not null, [StartDate] datetime not null, [EndDate] datetime not null, [MinQty] int not null, [MaxQty] int null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 67. Stg_SpecialOfferProduct CREATE TABLE Stg_SpecialOfferProduct ([SpecialOfferID] int not null, [ProductID] int not null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null) -- 68. Stg_Store CREATE TABLE Stg_Store ([BusinessEntityID] int not null, [Name] nvarchar(50) not null, [SalesPersonID] int not null, [Demographics] xml null, [rowguid] uniqueidentifier not null, [ModifiedDate] datetime not null
103 Anexo II – Criação das tabelas da DW - AW2019_DW use [AW2019_DW] --1. Dim_Colaborador CREATE TABLE Dim_Colaborador (IdColaborador int PRIMARY KEY, Candidato int, NrIdentificacaoNacional nvarchar(15), NodoOrganizacional hierarchyid, NivelOrganizacional smallint, Cargo nvarchar(50), DataNascimento date, EstadoCivil nchar(1), Genero nchar(1), DataContratacao date, ColaboradorAssalariado bit, HorasFerias smallint, HorasLicenca smallint, ColaboradorAtivo bit, DepartamentoAtual nvarchar(50), GrupoDepartamentoAtual nvarchar(50), Turno nvarchar(50), HoraIncioTurno time(7), HoraFimTurno time(7), SalarioHora money, Nome nvarchar(50), Sobrenome nvarchar(50), Cidade nvarchar(30), CodigoPosal nvarchar(15), Estado nvarchar(50), Pais nvarchar(50), Email nvarchar(50), NrTelefone nvarchar(25)) --2.Dim_HistPagColaboradores CREATE TABLE Dim_HistPagColaboradores (IdColaborador int, DataAltTaxa datetime, TaxaPagamento money, FrequenciaPagamento tinyint) -- 3. Dim_HistDeparColaboradores CREATE TABLE Dim_HistDeparColaboradores (IdColaborador int, DepartamentoAnterior nvarchar(50), GrupoDepartamentoAnterior nvarchar(50), Turno nvarchar(50), HoraIncioTurno time(7), HoraFimTurno time(7), DataContratacao date, DataDespedimento date) -- 4. Dim_Produto CREATE TABLE Dim_Produto (IdProduto int,
104 Nome nvarchar(50), Produzido bit, ProdutosAcabados bit, Cor nvarchar(15), NivelStockSeguranca smallint, CustoPadrao money, PrecoPadrao money, DiasProducao int, Subcategoria nvarchar(50), Categoria nvarchar(50), DataInicioVenda datetime, DataFimVenda datetime, DataDescontinuacao datetime) --5. Dim_OrdemCompras CREATE TABLE Dim_OrdemCompras (IdOrdemCompras int PRIMARY KEY, IdColaboradorCompras int, IdFornecedor int, DataRealizacaoOrdemCompra datetime, DataEnvioCompra datetime, SubTotal Money, SubtotalPadrao Money, ValorImposto Money, CustoEnvio money, CustoTotalCompra money) -- 6. Dim_HistFornecedor CREATE TABLE Dim_HistFornecedor (IdProduto int, IdFornecedor int, LeadTime int, CompraOnline nvarchar(1024), CustoUnitPadrao money, CustoUnitUltimaCompra money, DataUltimaCompra datetime, QuantMin int, QuantMax int, QuantEmOrdem int, Localizacao geography) -- 7. Dim_Fornecedor CREATE TABLE Dim_Fornecedor ( IdFornecedor int, Fornecedor nvarchar(50), PreferenciaForn bit, FornecedorAtivo bit, CompraOnline nvarchar(1024), Cidade nvarchar(30), CodigoPosal nvarchar(15), Estado nvarchar(50), Pais nvarchar(50)) -- 8. Dim_OrdemVendas CREATE TABLE Dim_OrdemVendas (IdOrdemVendas int, DataOrdemVenda datetime, DataRealizacaoVenda datetime, DataEnvio datetime, VendaOnline bit,
105 SubTotal money, TxImposto money, PrecoEnvio money, PrecoTotalVenda money, IdRazaoVenda int, RazaoVenda nvarchar(50), DataTxCambio datetime, CodMoedaOrigem nchar(3), CodMoedaDestino nchar(3), MediaTxCambio money, TxCambio money, Moeda nvarchar(50)) --9. Dim_Cliente CREATE TABLE Dim_Cliente (IdCliente int, Nome nvarchar(50), Sobrenome nvarchar(50), Email nvarchar(50), NrTelefone nvarchar(25), Cidade nvarchar(30), CodigoPostal nvarchar(15), Estado nvarchar(50), Pais nvarchar(50), Territorio nvarchar(50)) --10. Dim_ColaboradorVendedor CREATE TABLE Dim_ColaboradorVendedor (IdVendedor int, QuotaVendas money, Bonus money, ComissaoPercentagem smallmoney, VendasAnoAtual money, VendasAnoAnterior money) --11. Dim_Loja CREATE TABLE Dim_Loja (IdLoja int, Loja nvarchar(50), CidadeLoja nvarchar(30), CodigoPostalLoja nvarchar(15), LocalizacaoLoja geography, EstadoLoja nvarchar(50), PaisLoja nvarchar(50), TerritorioLoja nvarchar(50)) -- 12. Dim_VendedorHistoricoQuotas CREATE TABLE Dim_VendedorHistoricoQuotas (IdVendedor int , DataQuota datetime, QuotaVendas money) -- 13. Dim_TerritorioVendas CREATE TABLE Dim_TerritorioVendas (IdTerritorio int, Territorio nvarchar (50), Continente nvarchar(50), VendasAnoAtual money, VendasAnoAnterior money, CustoAnoAtual money, CustoAnoAnterior money)
106 -- 14. Fact_PVC CREATE TABLE Fact_PCV (Fact nvarchar(4), IdProduto int, IdColaborador int, DataRealização datetime, P_IdOrdemProducao int, P_QuanProdEnco int, P_QuantParaStock int, P_QuantRejeitada smallint, P_RazaoQuantRejeitada nvarchar(50), P_DataInicioProducao datetime, P_DataIdealizadaFimProducao datetime, P_DataInicioProdPrevista datetime, P_DataFimProdPrevista datetime, P_DataInicioProdReal datetime, P_DataFimProdReal datetime, P_HorasProducao decimal(9,4), P_CustoProdPlaneado money, P_CustoProdReal money, C_IdOrdemCompras int, C_IdOrdemCompraDetalhes int, C_IdFornecedor int, C_DataRealizacaoOrdemCompra datetime, C_DataEnvioCompra datetime, C_DataPrevistaEntrega DATETIME, C_QuantCompEnc smallint, C_QuantRecebida decimal(8,2), C_QuantRejeitada decimal(8,2), C_QuantParaStock decimal(9,2), C_CustoUnitario money, C_CustoUnitarioPadrao money, V_IdOrdemVendas int, V_IdOrdemVendaDetalhes int, V_IdCliente int, V_IdLoja int, V_IdTerritorio int, V_QunatOrdemVenda smallint, V_PrecoUnitario money, V_ValorUnitarioPromocao money, V_Subtotal numeric(38,6), V_PercentagemPromocao smallmoney, V_RazaoPromocao nvarchar(50), V_CategoriaPromocao nvarchar(50), V_DataInicioPromo datetime, V_DataFimPromo datetime)
107 Anexo III – Processo de logs /*Criação da tabela de carregamento de logs*/ CREATE TABLE [dbo].[stgx_log_carregamento]( [id_log] [int] IDENTITY(1,1) NOT NULL, [cod_modulo] [varchar](50) NULL, [cod_dts] [varchar](50) NULL, [desc_dts] [varchar](250) NULL, [desc_estado] [varchar](50) NULL, [cod_dia_ini] [int] NULL, [cod_dia_fim] [int] NULL, [data_ini] [datetime] NULL, [data_fim] [datetime] NULL, [tempo_execucao] [int] NULL, PRIMARY KEY CLUSTERED ( [id_log] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO /*Criação da Stored Procedure Create LOG*/ create PROCEDURE [dbo].[CREATE_LOG] @cod_modulo VARCHAR(50), @cod_dts VARCHAR(50), @desc_dts VARCHAR(250), @cod_dia_ini int, @cod_dia_fim int, @id_log INT OUTPUT AS BEGIN DECLARE @MAX_ID int, @data_ini datetime -- SET NOCOUNT ON ADDED TO PREVENT EXTRA RESULT SETS FROM -- INTERFERING WITH SELECT STATEMENTS. SET NOCOUNT ON; SELECT @MAX_ID=max(ID_LOG), @data_ini = getdate() from [AW2019_Staging].dbo.stgx_log_carregamento BEGIN TRAN INSERT INTO [AW2019_Staging].dbo.stgx_log_carregamento (cod_modulo, cod_dts, desc_dts,desc_estado, cod_dia_ini, cod_dia_fim, data_ini, data_fim,tempo_execucao) SELECT cod_modulo = RTRIM(@cod_modulo), cod_dts = @cod_dts, desc_dts = @desc_dts, desc_estado = 'Em Execução', cod_dia_ini = @cod_dia_ini, cod_dia_fim = @cod_dia_fim, data_ini = @data_ini, data_fim = null , tempo_execucao = null
108 -- SE NÃO HOUVER ERROS ENTÃO COMMIT SENÃO ROLLBACK IF @@ERROR = 0 BEGIN COMMIT TRAN END ELSE ROLLBACK TRAN -- EXTRAI A CHAVE DO LOG SELECT @ID_LOG = max(id_log) from [AW2019_Staging].dbo.stgx_log_carregamento where cod_modulo = RTRIM(@cod_modulo) and cod_dts = @cod_dts and desc_dts = @desc_dts and desc_estado = 'Em Execução' and cod_dia_ini = @cod_dia_ini and cod_dia_fim = @cod_dia_fim END /*Criação da Stored Procedure Close LOG*/ create PROCEDURE [dbo].[CLOSE_LOG] @id_log INT AS BEGIN -- SET NOCOUNT ON ADDED TO PREVENT EXTRA RESULT SETS FROM -- INTERFERING WITH SELECT STATEMENTS. SET NOCOUNT ON; BEGIN TRAN UPDATE [AW2019_Staging].dbo.stgx_log_carregamento SET data_fim = getdate(), desc_estado = 'Finalizado', tempo_execucao = datediff(mi, data_ini , getdate()) FROM [AW2019_Staging].dbo.stgx_log_carregamento WHERE @id_log = id_log -- SE NÃO HOUVER ERROS ENTÃO COMMIT SENÃO ROLLBACK IF @@ERROR = 0 BEGIN COMMIT TRAN END ELSE ROLLBACK TRAN END
115 LEFT JOIN [AW2019_Staging].[dbo].[Stg_ProductSubcategory] B ON A.[ProductSubcategoryID] = B.[ProductSubcategoryID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_ProductCategory] C ON B.[ProductCategoryID] = C.[ProductCategoryID]) S ON T.IdProduto = S.[ProductID] WHEN MATCHED THEN UPDATE SET T.Nome = S.[Product], T.Produzido = S.[MakeFlag], T.ProdutosAcabados = S.[FinishedGoodsFlag], T.Cor = S.[Color], T.NivelStockSeguranca = S.[SafetyStockLevel], T.CustoPadrao = S.[StandardCost], T.PrecoPadrao = S.[ListPrice], T.DiasProducao = S.[DaysToManufacture], T.Subcategoria = S.[Subcategory], T.Categoria = S.[Category], T.DataInicioVenda = S.[SellStartDate], T.DataFimVenda = S.[SellEndDate], T.DataDescontinuacao = S.[DiscontinuedDate] WHEN NOT MATCHED THEN INSERT (IdProduto,Nome,Produzido,ProdutosAcabados,Cor,NivelStockSeguranca,CustoPadrao,PrecoPadrao,DiasProduc ao,Subcategoria,Categoria,DataInicioVenda,DataFimVenda,DataDescontinuacao) VALUES (S.[ProductID], S.[Product], S.[MakeFlag], S.[FinishedGoodsFlag], S.[Color], S.[SafetyStockLevel], S.[StandardCost], S.[ListPrice], S.[DaysToManufacture], S.[Subcategory], S.[Category], S.[SellStartDate], S.[SellEndDate], S.[DiscontinuedDate]); -- 5. Dim_OrdemCompras MERGE [AW2019_DW].[dbo].[Dim_OrdemCompras] T USING (SELECT a.[PurchaseOrderID], [EmployeeID], [VendorID], [OrderDate], [ShipDate], a.[SubTotal], [TaxAmt],[ Freight], [TotalDue], SUM(B.[OrderQty]*C.[StandardPrice]) as SubtotalPadrao from [AW2019_Staging].[dbo].[Stg_PurchaseOrderHeader] a LEFT JOIN [AW2019_Staging].[dbo].[Stg_PurchaseOrderDetail] B ON a.PurchaseOrderID=B.PurchaseOrderID LEFT JOIN [AW2019_Staging].[dbo].[Stg_ProductVendor] C ON A.VendorID=C.BusinessEntityID and B.[ProductID]=C.[ProductID] group by a.[PurchaseOrderID],[EmployeeID],[VendorID],[OrderDate],[ShipDate],a.[SubTotal],[TaxAmt],[Freight],[ TotalDue]) S ON T.IdOrdemCompras = S.[PurchaseOrderID] WHEN MATCHED THEN UPDATE SET T.IdColaboradorCompras = S.[EmployeeID], T.IdFornecedor = S.[VendorID], T.DataRealizacaoOrdemCompra = S.[OrderDate], T.DataEnvioCompra = S.[ShipDate],
116 T.SubTotal = S.[SubTotal], T.SubtotalPadrao = S.SubtotalPadrao, T.ValorImposto = S.[TaxAmt], T.CustoEnvio = S.[Freight], T.CustoTotalCompra = S.[TotalDue] WHEN NOT MATCHED THEN INSERT (IdOrdemCompras,IdColaboradorCompras,IdFornecedor,DataRealizacaoOrdemCompra,DataEnvioCompra,SubTo tal,SubtotalPadrao,ValorImposto,CustoEnvio,CustoTotalCompra) VALUES (S.[PurchaseOrderID],S.[EmployeeID],S.[VendorID],S.[OrderDate],S.[ShipDate],S.[SubTotal],S.SubtotalPadrao,S.[ TaxAmt],S.[Freight],S.[TotalDue]); -- 6. Dim_HistFornecedor MERGE [AW2019_DW].[dbo].[Dim_HistFornecedor] T USING (SELECT A.[ProductID], A.[AverageLeadTime], A.[BusinessEntityID], A.[StandardPrice], A.[LastReceiptCost], A.[LastReceiptDate], A.[MinOrderQty], A.[MaxOrderQty], A.[OnOrderQty], B.[PurchasingWebServiceURL], D.[SpatialLocation] FROM [AW2019_Staging].[dbo].[Stg_ProductVendor] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_Vendor] B ON A.[BusinessEntityID] = B.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_BusinessEntityAddress] C ON A.[BusinessEntityID] = C.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_Address] D ON C.[AddressID] = D.[AddressID])S ON T.IdProduto = S.[ProductID] WHEN MATCHED THEN UPDATE SET T.IdFornecedor = S.[BusinessEntityID], T.LeadTime = S.[AverageLeadTime], T.CompraOnline = S.[PurchasingWebServiceURL], T.CustoUnitPadrao = S.[StandardPrice], T.CustoUnitUltimaCompra = S.[LastReceiptCost], T.DataUltimaCompra = S.[LastReceiptDate], T.QuantMin = S.[MinOrderQty], T.QuantMax = S.[MaxOrderQty], T.QuantEmOrdem = S.[OnOrderQty], T.Localizacao = S.[SpatialLocation] WHEN NOT MATCHED THEN INSERT (IdProduto,IdFornecedor,LeadTime,CompraOnline,CustoUnitPadrao,CustoUnitUltimaCompra,DataUltimaCompra ,QuantMin,QuantMax,QuantEmOrdem,Localizacao) VALUES ( S.[ProductID],S.[BusinessEntityID],S.[AverageLeadTime],S.[PurchasingWebServiceURL],S.[StandardPrice],S.[Las tReceiptCost],S.[LastReceiptDate],S.[MinOrderQty],S.[MaxOrderQty],S.[OnOrderQty], S.[SpatialLocation]); -- 7. Dim_Fornecedor
117 MERGE [AW2019_DW].[dbo].[Dim_Fornecedor] T USING (SELECT A.[BusinessEntityID], B.[Name], B.[PreferredVendorStatus], B.[ActiveFlag], B.[PurchasingWebServiceURL], D.[City], D.[PostalCode], E.[Name] as StateProvince, F.[Name] as Country FROM [AW2019_Staging].[dbo].[Stg_ProductVendor] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_Vendor] B ON A.[BusinessEntityID] = B.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_BusinessEntityAddress] C ON A.[BusinessEntityID] = C.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_Address] D ON C.[AddressID] = D.[AddressID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_StateProvince] E ON D.[StateProvinceID] = E.[StateProvinceID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_CountryRegion] F ON E.[CountryRegionCode] = F.[CountryRegionCode] GROUP BY A.[BusinessEntityID], B.[Name], B.[PreferredVendorStatus], B.[ActiveFlag], B.[PurchasingWebServiceURL],D.[City], D.[PostalCode], E.[Name],F.[Name] ) S ON T.IdFornecedor = S.[BusinessEntityID] WHEN MATCHED THEN UPDATE SET T.Fornecedor = S.[Name], T.PreferenciaForn = S.[PreferredVendorStatus], T.FornecedorAtivo = S.[ActiveFlag], T.CompraOnline = S.[PurchasingWebServiceURL], T.Cidade = S.[City], T.CodigoPosal = S.[PostalCode], T.Estado = S.[StateProvince], T.Pais = S.[Country] WHEN NOT MATCHED THEN INSERT (IdFornecedor,Fornecedor,PreferenciaForn,FornecedorAtivo,CompraOnline,Cidade,CodigoPosal,Estado,Pais) VALUES ( S.[BusinessEntityID],S.[Name],S.[PreferredVendorStatus],S.[ActiveFlag],S.[PurchasingWebServiceURL],S.[City],S. [PostalCode],S.[StateProvince],S.[Country]); -- 8. Dim_OrdemVendas MERGE [AW2019_DW].[dbo].[Dim_OrdemVendas] T USING (SELECT A.[SalesOrderID], A.[OrderDate], A.[DueDate], A.[ShipDate], A.[OnlineOrderFlag], A.[SubTotal], A.[TaxAmt], A.[Freight], A.[TotalDue], C.[SalesReasonID], D.[SalesReason], E.[CurrencyRateDate],
118 E.[FromCurrencyCode], E.[ToCurrencyCode], E.[AverageRate], E.[EndOfDayRate], F.[Currency] FROM [AW2019_Staging].[dbo].[Stg_SalesOrderHeader] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_SalesTerritory] B ON A.[TerritoryID] = B.[TerritoryID] LEFT JOIN (select [SalesOrderID],[SalesReasonID] FROM [AW2019_Staging].[dbo].[Stg_SalesOrderHeaderSalesReason] WHERE [SalesOrderID] in (SELECT [SalesOrderID] FROM [AW2019_Staging].[dbo].[Stg_SalesOrderHeaderSalesReason] GROUP BY [SalesOrderID] HAVING COUNT([SalesOrderID]) = 1) UNION ALL SELECT DISTINCT [SalesOrderID],0 FROM [AW2019_Staging].[dbo].[Stg_SalesOrderHeaderSalesReason] WHERE [SalesOrderID] in (SELECT [SalesOrderID] FROM [AW2019_Staging].[dbo].[Stg_SalesOrderHeaderSalesReason] GROUP BY [SalesOrderID] HAVING COUNT([SalesOrderID]) > 1) ) C ON A.[SalesOrderID] = C.[SalesOrderID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_SalesReason] D ON C.[SalesReasonID] = D.[SalesReasonID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_CurrencyRate] E ON A.[CurrencyRateID] = E.[CurrencyRateID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_Currency] F ON E.[ToCurrencyCode] = F.[CurrencyCode]) S ON T.IdOrdemVendas = S.[SalesOrderID] WHEN MATCHED THEN UPDATE SET T.DataOrdemVenda = S.[OrderDate], T.DataRealizacaoVenda = S.[DueDate], T.DataEnvio = S.[ShipDate], T.VendaOnline = S.[OnlineOrderFlag], T.SubTotal = S.[SubTotal], T.TxImposto = S.[TaxAmt], T.PrecoEnvio = S.[Freight], T.PrecoTotalVenda = S.[TotalDue], T.IdRazaoVenda = S.[SalesReasonID], T.RazaoVenda = S.[SalesReason], T.DataTxCambio = S.[CurrencyRateDate], T.CodMoedaOrigem = S.[FromCurrencyCode], T.CodMoedaDestino = S.[ToCurrencyCode], T.MediaTxCambio = S.[AverageRate], T.TxCambio = S.[EndOfDayRate], T.Moeda = S.[Currency] WHEN NOT MATCHED THEN INSERT (IdOrdemVendas,DataOrdemVenda,DataRealizacaoVenda,DataEnvio ,VendaOnline ,SubTotal ,TxImposto ,PrecoEnvio ,PrecoTotalVenda ,IdRazaoVenda,RazaoVenda ,DataTxCambio ,CodMoedaOrigem ,CodMoedaDestino ,MediaTxCambio ,TxCambio ,Moeda ) VALUES (S.[SalesOrderID] , S.[OrderDate], S.[DueDate], S.[ShipDate], S.[OnlineOrderFlag], S.[SubTotal], S.[TaxAmt], S.[Freight], S.[TotalDue], S.[SalesReasonID], S.[SalesReason], S.[CurrencyRateDate], S.[FromCurrencyCode], S.[ToCurrencyCode] ,S.[AverageRate] ,S.[EndOfDayRate], S.[Currency]);
119 --9. Dim_Cliente MERGE [AW2019_DW].[dbo].[Dim_Cliente] T USING (SELECT A.[CustomerID], C.[FirstName], C.[LastName], D.[EmailAddress], E.[PhoneNumber], G.[City], G.[PostalCode], H.[StateProvince], I.[Country], J.[Territory] FROM [AW2019_Staging].[dbo].[Stg_Customer] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_Store] B ON A.[StoreID] = B.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_Person] C ON A.[PersonID] = C.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_EmailAddress] D ON C.[BusinessEntityID] = D.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_PersonPhone] E ON C.[BusinessEntityID] = E.[BusinessEntityID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_BusinessEntityAddress] F ON C.[BusinessEntityID] = F.[BusinessEntityID] and [AddressTypeID]=2 LEFT JOIN [AW2019_Staging].[dbo].[Stg_Address] G ON F.[AddressID] = G.[AddressID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_StateProvince] H ON G.[StateProvinceID] = H.[StateProvinceID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_CountryRegion] I ON H.[CountryRegionCode] = I.[CountryRegionCode] LEFT JOIN [AW2019_Staging].[dbo].[Stg_SalesTerritory] J ON A.[TerritoryID] = J.[TerritoryID]) S ON T.IdCliente = S.[CustomerID] WHEN MATCHED THEN UPDATE SET T.Nome = S.[FirstName], T.Sobrenome = S.[LastName], T.Email = S.[EmailAddress], T.NrTelefone = S.[PhoneNumber], T.Cidade = S.[City], T.CodigoPostal = S.[PostalCode], T.Estado = S.[StateProvince], T.Pais = S.[Country], T.Territorio = S.[Territory] WHEN NOT MATCHED THEN INSERT (IdCliente,Nome,Sobrenome,Email,NrTelefone,Cidade,CodigoPostal,Estado,Pais,Territorio) VALUES (S.[CustomerID],S.[FirstName],S.[LastName],S.[EmailAddress],S.[PhoneNumber],S.[City],S.[PostalCode],S.[Stat eProvince],S.[Country],S.[Territory]); --10. Dim_ColaboradorVendedor MERGE [AW2019_DW].[dbo].[Dim_ColaboradorVendedor] T USING [AW2019_Staging].[dbo].[Stg_SalesPerson] S ON T.IdVendedor = S.[BusinessEntityID] WHEN MATCHED THEN
120 UPDATE SET T.QuotaVendas = S.[SalesQuota], T.Bonus = S.[Bonus], T.ComissaoPercentagem = S.[CommissionPct], T.VendasAnoAtual = S.[SalesYTD], T.VendasAnoAnterior = S.[SalesLastYear] WHEN NOT MATCHED THEN INSERT (IdVendedor,QuotaVendas,Bonus, ComissaoPercentagem, VendasAnoAtual, VendasAnoAnterior) VALUES (S.[BusinessEntityID],S.[SalesQuota],S.[Bonus],S.[CommissionPct],S.[SalesYTD],S.[SalesLastYear]); --11. Dim_Loja MERGE [AW2019_DW].[dbo].[Dim_Loja] T USING (SELECT B.[BusinessEntityID], B.[Name], D.[City], D.[PostalCode], D.[SpatialLocation], E.[StateProvince], F.[Country], G.[Territory] FROM [AW2019_Staging].[dbo].[Stg_Store] B LEFT JOIN [AW2019_Staging].[dbo].[Stg_BusinessEntityAddress] C ON B.[BusinessEntityID] = C.[BusinessEntityID] and [AddressTypeID]=3 LEFT JOIN [AW2019_Staging].[dbo].[Stg_Address] D ON C.[AddressID] = D.[AddressID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_StateProvince] E ON D.[StateProvinceID] = E.[StateProvinceID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_CountryRegion] F ON E.[CountryRegionCode] = F.[CountryRegionCode] LEFT JOIN [AW2019_Staging].[dbo].[Stg_SalesTerritory] G ON E.[TerritoryID] = G.[TerritoryID]) S ON T.IdLoja = S.[BusinessEntityID] WHEN MATCHED THEN UPDATE SET T.Loja = S.[Name], T.CidadeLoja = S.[City], T.CodigoPostalLoja = S.[PostalCode], T.LocalizacaoLoja = S.[SpatialLocation], T.EstadoLoja = S.[StateProvince], T.PaisLoja = S.[Country], T.TerritorioLoja = S.[Territory] WHEN NOT MATCHED THEN INSERT (IdLoja,Loja,CidadeLoja,CodigoPostalLoja,LocalizacaoLoja,EstadoLoja,PaisLoja,TerritorioLoja) VALUES (S.[BusinessEntityID],S.[Name],S.[City],S.[PostalCode],S.[SpatialLocation], S.[StateProvince],S.[Country],S.[Territory]); --12. Dim_VendedorHistoricoQuotas MERGE [AW2019_DW].[dbo].[Dim_VendedorHistoricoQuotas] T USING [AW2019_Staging].[dbo].[Stg_SalesPersonQuotaHistory] S ON T.IdVendedor = S.[BusinessEntityID] WHEN MATCHED THEN UPDATE SET T.DataQuota = S.[QuotaDate], T.QuotaVendas = S.[SalesQuota]
121 WHEN NOT MATCHED THEN INSERT (IdVendedor,DataQuota,QuotaVendas) VALUES (S.[BusinessEntityID],S.[QuotaDate],S.[SalesQuota]); -- 13. Dim_TerritorioVendas MERGE [AW2019_DW].[dbo].[Dim_TerritorioVendas] T USING [AW2019_Staging].[dbo].[Stg_SalesTerritory] S ON T.IdTerritorio = S.[TerritoryID] WHEN MATCHED THEN UPDATE SET T.Territorio = S.[Territory], T.Continente = S.[Group], T.VendasAnoAtual = S.[SalesYTD], T.VendasAnoAnterior = S.[SalesLastYear], T.CustoAnoAtual = S.[CostYTD], T.CustoAnoAnterior = S.[CostLastYear] WHEN NOT MATCHED THEN INSERT (IdTerritorio,Territorio,Continente,VendasAnoAtual,VendasAnoAnterior,CustoAnoAtual,CustoAnoAnterior) VALUES (S.[TerritoryID],S.[Territory],S.[Group],S.[SalesYTD],S.[SalesLastYear],S.[CostYTD],S.[CostLastYear]); -- 14. Fact_PVC ---Inserir valores relacionados com a Producao - FACT = P INSERT [AW2019_DW].[dbo].Fact_PCV (Fact,P_IdOrdemProducao,IdProduto,P_QuanProdEnco,P_QuantParaStock,P_QuantRejeitada,P_RazaoQuantRej eitada,P_DataInicioProducao,DataRealização,P_DataIdealizadaFimProducao,P_DataInicioProdPrevista,P_DataFi mProdPrevista,P_DataInicioProdReal,P_DataFimProdReal,P_HorasProducao,P_CustoProdPlaneado,P_CustoPro dReal) SELECT 'P', A.[WorkOrderID], A.[ProductID], A.[OrderQty], A.[StockedQty], A.[ScrappedQty], B.[Name], A.[StartDate], A.[EndDate], A.[DueDate], MIN(C.[ScheduledStartDate]) AS [ScheduledStartDate], MAX(C.[ScheduledEndDate]) AS [ScheduledEndDate], MIN(C.[ActualStartDate]) AS [ActualStartDate], MAX(C.[ActualEndDate]) AS [ActualEndDate], SUM(C.[ActualResourceHrs]) AS [ActualResourceHrs], SUM(C.[PlannedCost]) AS [PlannedCost], SUM(C.[ActualCost]) AS [ActualCost] FROM [AW2019_Staging].[dbo].[Stg_WorkOrder] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_ScrapReason] B ON A.[ScrapReasonID] = B.[ScrapReasonID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_WorkOrderRouting] C ON A.[WorkOrderID] = C.[WorkOrderID] GROUP BY A.[WorkOrderID], A.[ProductID], A.[OrderQty], A.[StockedQty], A.[ScrappedQty], A.[StartDate], A.[EndDate], A.[DueDate],B.[Name] ---Inserir valores relacionados com a Compras - FACT = C INSERT [AW2019_DW].[dbo].Fact_PCV
122 (Fact,C_IdOrdemCompras,C_IdOrdemCompraDetalhes,IdColaborador,C_IdFornecedor,C_DataRealizacaoOrdem Compra,C_DataEnvioCompra,DataRealização,C_DataPrevistaEntrega,IdProduto,C_QuantCompEnc,C_QuantRec ebida,C_QuantRejeitada,C_QuantParaStock,C_CustoUnitario,C_CustoUnitarioPadrao) SELECT 'C', A.[PurchaseOrderID],A.[PurchaseOrderDetailID], B.EmployeeID,B.VendorID, B.[OrderDate],B.[ShipDate], A.[DueDate], DATEADD(DAY,C.[AverageLeadTime],B.[OrderDate]) AS ExpectedDueDate, A.[ProductID], A.[OrderQty], A.[ReceivedQty], A.[RejectedQty], A.[StockedQty], A.[UnitPrice], C.[StandardPrice] FROM [AW2019_Staging].[dbo].[Stg_PurchaseOrderDetail] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_PurchaseOrderHeader] B ON A.PurchaseOrderID=B.PurchaseOrderID LEFT JOIN [AW2019_Staging].[dbo].[Stg_ProductVendor] C ON B.VendorID=C.BusinessEntityID AND A.ProductID=C.ProductID ---Inserir valores relacionados com a Colaborador - FACT INSERT [AW2019_DW].[dbo].Fact_PCV (Fact,DataRealização,IdColaborador) Select 'Co',A.[HireDate], A.BusinessEntityID From [AW2019_Staging].[dbo].[Stg_Employee] A ---Inserir valores relacionados com hist_depart INSERT [AW2019_DW].[dbo].Fact_PCV (Fact,DataRealização,IdColaborador) Select 'HCo',A.[DataDespedimento], A.[IdColaborador] From [AW2019_DW].[dbo].[Dim_HistDeparColaboradores] A ---Inserir valores relacionados com Vendas INSERT [AW2019_DW].[dbo].Fact_PCV (Fact,V_IdOrdemVendas,V_IdOrdemVendaDetalhes,IdColaborador,V_IdCliente,V_IdLoja,V_IdTerritorio,IdProduto, DataRealização, V_QunatOrdemVenda, V_PrecoUnitario,V_ValorUnitarioPromocao,V_Subtotal,V_PercentagemPromocao,V_RazaoPromocao,V_Categori aPromocao,V_DataInicioPromo, V_DataFimPromo) SELECT 'V', A.[SalesOrderID], A.[SalesOrderDetailID], B.[SalesPersonID], B.[CustomerID], C.[BusinessEntityID], B.[TerritoryID], A.[ProductID], B.[DueDate], A.[OrderQty], A.[UnitPrice], A.[UnitPriceDiscount], A.[LineTotal], E.[DiscountPct], E.[Type], E.[Category], E.[StartDate], E.[EndDate]
123 FROM [AW2019_Staging].[dbo].[Stg_SalesOrderDetail] A LEFT JOIN [AW2019_Staging].[dbo].[Stg_SalesOrderHeader] B ON A.SalesOrderID = B.SalesOrderID LEFT JOIN [AW2019_Staging].[dbo].[Stg_Customer] D ON D.[CustomerID] = B.CustomerID LEFT JOIN [AW2019_Staging].[dbo].[Stg_Store] C ON c.[BusinessEntityID] = D.[StoreID] LEFT JOIN [AW2019_Staging].[dbo].[Stg_SpecialOffer] E ON A.[SpecialOfferID] =E.[SpecialOfferID]
124 Anexo VI – Criação de Views – Data Mart – AW2019_DW --1. Dim_Colaborador CREATE VIEW VDim_Colaborador AS SELECT [IdColaborador] ,[Candidato] ,[NrIdentificacaoNacional] ,[NodoOrganizacional] ,[NivelOrganizacional] ,[Cargo] ,[DataNascimento] ,[EstadoCivil] ,[Genero] ,[DataContratacao] ,[ColaboradorAssalariado] ,[HorasFerias] ,[HorasLicenca] ,[ColaboradorAtivo] ,[DepartamentoAtual] ,[GrupoDepartamentoAtual] ,[Turno] ,[HoraIncioTurno] ,[HoraFimTurno] ,[SalarioHora] ,[Nome] ,[Sobrenome] ,[Cidade] ,[CodigoPosal] ,[Estado] ,[Pais] ,[Email] ,[NrTelefone] FROM [AW2019_DW].[dbo].[Dim_Colaborador] -- 2. Dim_HistDeparColaboradores CREATE VIEW VDim_HistDeparColaboradores AS SELECT [IdColaborador] ,[DepartamentoAnterior] ,[GrupoDepartamentoAnterior] ,[Turno] ,[HoraIncioTurno] ,[HoraFimTurno] ,[DataContratacao] ,[DataDespedimento] FROM [AW2019_DW].[dbo].[Dim_HistDeparColaboradores] -- 3. Dim_HistDeparColaboradores CREATE VIEW VDim_HistPagColaboradores AS SELECT [IdColaborador] ,[DataAltTaxa]
131 Anexo XII – Desenvolvimento Power BI – Comum a todas as páginas Através do auxílio da ferramenta externa “Tabular Editor” foi adicionado um “Grupo de cálculo” (Figura 78). Esse passo tem como objetivo otimizar e facilitar a manutenção e atualização das fórmulas, promovendo a consistência nos relatórios e eficiência no desenvolvimento de análises. Neste grupo, serão adicionados vários itens calculados (Figura 79), embora criados aqui, poderão ser utilizados em todos os gráficos, adaptando-se a qualquer medida. Este facto reduz significativamente o número de medidas criadas, simplificando o processo e melhorando a gestão das análises. Os itens calculados adicionados foram: • Ano Atual: Assume o valor de uma medida já criada (Figura 80 e Figura 81); • Homólogo: Calcula o valor que essa medida assume no ano anterior ao selecionado (); • Variação Homólogo [%]: Representa a variação relativa entre as duas medidas Anteriores. Aqui, é tido em conta que caso se use uma taxa ou um valor em percentagem, a variação homóloga é calculada através da diferença entre o Ano Atual e o Homólogo. Caso contrário, recorre-se à fórmula da variação que consiste na divisão entre a diferença do Ano Atual pelo homólogo pelo ano homólogo (Figura 82); • Variação Absoluta [Qtd]: Representa a variação relativa entre as duas medidas Anteriores (Figura 83). Para uma melhor compreensão a Figura 84 apresenta um exemplo de utilização do grupo calculado.
132 Figura 78 - Criação de um Grupo de Calculo (Fonte Própria) Figura 79 - Criação de um Item Calculado no Grupo de Calculo (Fonte Própria)
133 Figura 80 - Criação do Item Calculado “Ano Atual” no Grupo de Calculo (Fonte Própria) Figura 81 - Criação do Item Calculado “Homólogo” no Grupo de Calculo (Fonte Própria)
134 Figura 82 - Criação do Item Calculado “Variação Homólogo [%]” no Grupo de Calculo (Fonte Própria) Figura 83 - Criação do Item Calculado “Variação Homólogo [Qtd]” no Grupo de Calculo (Fonte Própria)
135 Figura 84 - Exemplo de utilização do grupo calculado (Fonte Própria)
136 Anexo XIII – Entrevistas Setor da Empresa: Imobiliário Cargo: Business Intelligence Analyst Objetivo da Entrevista: Consultor e empresa que tem um datawarehouse aplicado a) Utilização: 1. Despois de analisar o dashboard , o que achou mais interessante? Os destaques, são indicadores que pessoas que não analisam com tanto detalhe vão gostar de ver. A interatividade dos page navigatores e o facto de ter sempre a mesma estrutura facilita a perceção mais rápida e fácil dos dados. A análise estruturada dos diferentes temas faz com que a análise seja intuitiva, rápida e objetiva, que é o objetivo primário para uma análise de qualidade. 2. Seria útil para a tomada de decisão, do dia a dia ou mesmo decisões mais estratégicas? Ajuda na tomada de decisão e para aquilo que são as interpretações lógicas do dia a dia ou que queiramos que sejam comprovadas. Análises gerais e intuitivas são ótimas para pessoas mais altas na hierarquia, mas o detalhe também é importante tal como está no dashboard. b) Relevância e Necessidade de um datawarehouse: 3. Qual é que acha que é a importância da aplicação de um datawarehouse, acha que interfere com a competitividade no mercado? E em que medida acha que pode beneficiar a empresa? Acho que para apostar na inteligência artificial, que é o futuro, é necessário ter uma estrutura como esta de datawarehouse e análise de dados para perceberes o que vem a seguir. Neste caso, em específico, na aplicação numa empresa acho que é muito importante, primeiro para que não haja o hábito de “astrologia”, ou seja, para comprovar os factos e distinguir o que é a realidade ou não. Para que a empresa possa beneficiar disto é necessário que haja uma boa adaptação na empresa e educação para que possa ser usado por toda a empresa de forma clara e útil para todos. É importantíssimo que haja uma boa implementação e formação naquilo que são estas novas ferramentas, porque como sabemos a maior parte das pessoas atualmente ainda estão muito adversas à mudança. Por mais que seja uma ótima ferramenta se só houver uma ou duas pessoas a tirar usufruto dela, a empresa não vai tirar vantagem competitiva no futuro. c) Desafios de implementação: 4. Achas que é muito difícil ensinar os utilizadores finais a mexer no Power BI?
137 Achas que é necessário oferecer formações aos colaboradores para mexer na ferramenta ou é mais para perceber as medidas? Acho que é um pouco dos dois e acho que é difícil ensinar as pessoas a usar isto se elas não tiverem naturalmente uma predisposição para aquilo que é a tecnologia. Porque as métricas, no fundo, se nós as apresentarmos em papel eles vão acabar por perceber. Daquilo que experienciei e que não teve muito sucesso naquilo que é a educação e por toda a gente a mexer e a mexer bem, acho que é importante numa fase inicial durante dois meses uma ou duas vezes por semana como se fosse um curso, que teria por exemplo 25 horas. Acho que este caminho é mesmo importante, não com toda a gente. Começar pelos diretores de departamento, gravar as sessões e depois se fizer sentido partilha-se as formações para os colaboradores de segundo nível e garantir que eles vão ver. Assim, acho que vai funcionar! 5. Dentro da tua empresa tiveste em todas as fases da criação de um datawarehouse, desde extração, tratamento de dados e visualização que é que achaste mais difícil? Na experiência que eu tive, o mais difícil passa pelo tratamento de dados e fluxo dos dados porque depois a implementação em si e a construção dos dashboards e a validação dos dados. A parte da construção dos dados acho que por mais difícil que seja é mais compensadora. As outras estás ali em testes à espera que dê bemsucedido. No fundo, visualização e implementação acho que é o mais fácil e tratamento e construção de dados é o mais difícil. d) Competências e condições necessárias: 6. Achas que já existia uma equipa que conseguia suportar todas as necessidades que um datawarehouse acarreta? A nível técnico não, daí a minha entrada na empresa. Até ao ponto de definir as necessidades do negócio a empresa estava preparada, a partir daí necessitava de alguém que tivesse mais conhecimento da parte técnica. Relativamente aos dados, a empresa era capaz muito porque a responsável de tecnologia e toda a gente até eu entrar para empresa para quem não tinha suporte nem conhecimento técnico os dados estavam muito bem organizados e preparados para aquilo que era a estrutura e capacidades técnicas. Noutras empresa e pela minha experiência, normalmente, este processo envolve muito mais trabalho. 7. Qual a sua opinião sobre o orçamento necessário para a implementação e manutenção de um datawarehouse ? Pela minha experiência, de uma forma geral o dinheiro é efetivamente bem aplicado. Claro que a lei da oferta e da procura influencia muito naquilo que é o valor deste tipo de mão de obra qualificada e como ainda não existe muita acho que é um preço um pouco elevada para o tempo. Das experiências que eu tive o orçamento vs o tempo de desenvolvimento foi justo, mas o orçamento vs o tempo inicialmente estipulado é um pouco exagerado. No fundo acho que é um dinheiro bem empregue, mas ainda é um pouco caro. Se fosse justamente repartido por quem faz a estratégia, quem vai planear e quem desenvolve acho que seria bem aplicado. Em Portugal, acho que quem desenvolve deveria ser mais valorizado, porque lá fora é mais valorizado.
138 e) Gestão Interna e desafios? 8. Qual a sua opinião sobre a gestão dos dados? Acho que deve ser a primeira questão a ser abordada, como está a infraestrutura no momento do início do projeto. Esta pode ser a razão do projeto ser alongado consoante a sua previsão. Acho que como no final os dados são fornecidos de uma forma tão clara e intuitiva pensam que os dados que estão na base também estão assim, mas para isso a base de dados tem de ser cuidada. 9. Achas então que será o ponto mais importante da construção de um datawarehouse? Sim, tratamento de dados e construção das estruturas das bases de dados. f) Considerações Finais – Feedback 10. Queres sugerir alguma melhoria para o dashboard que mostrei? Melhoraria um pouco a nível estético. 11. Se pudesses resumir numa frase o maior benefício da implementação de um datawarehouse dentro de uma empresa? Há uma fase que eu gosto muito “Os dados inteligentes possibilitam uma maior proximidade entre o utilizador final e os melhores resultados do negócio.” Setor da Empresa: Vinícola Cargo: Administrativa Objetivo da Entrevista: Empresa que não tem nenhum contacto bom BI nem tem um datawarehouse aplicado a) Utilização: 1. Depois de analisar o dashboard, o que achou mais interessante? Achei interessante o facto de termos acesso a dados de forma mais organizada, de podermos usar os filtros para selecionar informação. E parece-me ser uma ferramenta bastante útil. 2. Achas que tem utilidade prática na decisão estratégica ou de dia a dia? Sim, sem dúvida! Porque pode-se comparar diversos aspetos como vendas, clientes ao longo de vários anos e perceber um bocado como é que podem ser dirigidas as próximas estratégias. b) Relevância e Necessidade de um datawarehouse:
139 3. Qual a tua opinião sobre a implementação de um datawarehouse numa empresa? Achas que pode aumentar a competitividade ou beneficiar de certa forma a empresa? Sim, acho que é um aspeto positivo, mas depende da finalidade do projeto a desenvolver. Aumentar a competitividade penso que seja mais a nível interno, a nível externo não acho que seja tão benéfico. No fundo penso que serve mais para conhecer a empresa a ele própria do que ao mercado. 4. Se atualmente se fosse implementar um data warehouse aí na empresa, que desafios ou problemas é que achas que poderia resolver? Primeiro acho que a rapidez, praticidade e dos dados estarem todos concentrados numa plataforma só. Colocando na primeira situação prática que consigo pensar agora vamos imaginar que chega um agricultor e quer ver a evolução dos kilos de uvas entregues nos últimos quatro anos. Seria muito mais fácil se os dados estivessem todos reunidos num só sítio, ao contrário de agora que tenho que abrir o Excel referente a cada ano. c) Desafios de implementação: 5. Qual é que achas que seria a um dos maiores desafios? A adaptação. Acho que a faixa etária daqui não é assim tão jovem nem instruída tecnicamente para podemos considerar uma fácil e rápida adaptação. d) Aplicabilidade e Sucesso da Implementação 6. A nível de orçamento, achas que mesmo não tendo contacto nenhum com a área achas que é um bom investimento? Acho que neste momento não é algo que sinto a necessidade. Neste momento há outras coisas prioritárias que se poderia investir. e) Competências e condições necessárias: 7. Achas que já existia uma equipa que conseguia suportar todas as necessidades que um datawarehouse acarreta? Teria de haver alguém externo para fazer toda a parte prática, mas sempre com o auxílio de alguém interno para que as diretrizes do projeto estejam sempre bem definidas e de acordo com os objetivos da empresa. Para a manutenção também seria necessário alguém, assim como, temos noutros programas como a faturação. f) Gestão Interna e desafios? 8. Quais é que achas que seriam as limitações na implementação de um datawarehouse? Falaste que ainda têm muitos dados em papel. Achas que era difícil informatizar esses dados?
140 Primeiro acho seria necessário perceber o objeto da implementação. Mas a dificuldade seria mais compilar todas as informações necessárias e perceber que informações é que seriam mais relevantes de visualizar em cada dashboard . 9. Achas que existiria muita resistência à mudança? Como é que a empresa iria lidar com esta situação? Acho que no início iria precisar de imenso apoio por ser uma coisa nova. A adaptação também dependeria do objetivo da implementação, mas seria bastante útil. g) Considerações Finais – Feedback 10. Queres sugerir alguma melhoria para o dashboard que mostrei? Não, a informação parece-me bastante clara e organizada. A parte da utilização da ferramenta em si também me parece bastante intuitiva. 11. Se pudesses resumir um benefício de uma possível implementação de um datawarehouse qual seria? Nós tivemos o lançamento de um novo produto à cerca de um ano e meio e seria interessante perceber a evolução dele. Apesar de eu neste momento o conseguir fazer se calhar com este tipo de visualizações seria mais fácil Setor da Empresa: Cibersegurança Cargo: Diretor Comercial Objetivo da Entrevista: Com mais de 10 anos de experiência na área do Business Intelligence. a) Utilização: 1. Achas que tem utilidade prática na decisão estratégica ou de dia a dia? Sim, sem dúvida! b) Relevância e Necessidade de um datawarehouse: 2. Qual a tua opinião sobre a implementação de um datawarehouse numa empresa? Achas que pode aumentar a competitividade ou beneficiar de certa forma a empresa? A maior vantagem que traz para a empresa é o facto de ter os dados centralizados, de uma forma incontestável e com os devidos acessos restritos a quem realmente pode editar ou só ver os dados. A implementação de um datawarehouse numa empresa pode começar de várias formas e com objetivos diferentes. É possível iniciar esta abordagem pela parte administrativa e ir abrangendo o resto da empresa aos poucos em vez de abordar um projeto muito grande inicialmente. Traz vantagem competitiva porque se pressupõe que quando os dados ficam disponíveis a várias