Empresa financeira de corretagem

A Instituição Financeira do caso de estudo é uma corretora financeira que efetua operações de compra e venda de instrumentos financeiros (e.g. acções, obrigações, unidades de participação) por conta de solicitações de clientes, não tendo como tal carteira própria para negociação de títulos.

A base do negócio assenta na segmentação de clientes (empresas, particulares), produtos (e.g. ações, obrigações e fundos de investimento), comercializados por serviços de corretagem (trading e custódia de títulos) através de canais presenciais (parceiros e lojas) e dependente de parceiros (e.g. bolsas e brokers).

144

Para a investigação considerou-se um subconjunto de componentes do sistema de informação para análise:

• Sistema operacional: tem um sistema ERP para contabilidade, compras e fornecedores e um sistema de processamento de negócio com um front-office e back-office, além de sistemas complementares para relação com clientes no canal não presencial internet; • Sistema business intelligence: não tem um sistema de business intelligence, sendo que

se extrai vários ficheiros do sistema de processamento de negócio para análise de informação de gestão em Microsoft Excel;

• Sistema de representação de conhecimento: não é utilizado um sistema de arquitetura empresarial. Os sistemas de informação e o modelo da organização é caracterizado em documentação em formato Microsoft Word e Microsoft Excel no contexto de políticas, processos e procedimentos.

7.3.1 Arquitetura empresarial

7.3.1.1 Arquitetura organizacional

Ao nível da ontologia, sem elementos instanciados, tal como apresentada na Figura 7.16, pode-se destacar a necessidade de criar um grupo com a estrutura orgânica de acordo com a relação entre os tipos de unidades (e.g. administração, direção, departamento), mas depois teve-se que criar uma generalização do conceito para servir de base para relacionar com funções que cada unidade orgânica necessita e os contratos FSE (fornecimentos e serviços externos) que estabelecem.

Os contratos de FSE (fornecimentos e serviços externos) são estabelecidos e geridos por unidades orgânicas, envolvendo fornecedores e imobilizado (e.g. edifícios, carros, software, hardware), sendo que esses contratos geram transações de custos. Por outro lado, o imobilizado está sediado em determinados locais, sendo que nesses locais existem igualmente colaboradores. Os colaboradores assumem funções em unidades orgânicas e têm contratos de trabalho com a organização (“Contratos Pessoal”). Estes contratos geram transações de custos com pessoal. Temos assim que as métricas estão associadas às transações de custos, sendo que os restantes conceitos correspondem a dimensões. O modelo é equivalente ao apresentado no caso de estudo anterior pois as arquiteturas organizacionais dependem do mesmo tipo de conceitos pois são genéricos, razão pela qual na arquitetura de solução tentou-se generalizar os mesmos para depois se testar esta realidade em cada caso de estudo. Os ajustamentos resultam normalmente de campos de informação específicos a recolher em cada organização.

145

Figura 7.16: Modelo de ontologia da arquitetura organizacional de empresa financeira

O modelo instanciado numa lógica de arquitetura empresarial é apresentado na Figura 7.17, para mais tardar se comparar com a visualização via dashboard. Não são representados elementos de contratos, imobilizado, fornecedores e pessoal por função, pelo impacto visual complexo que tal acarretava, sendo essa uma das vantagens de se utilizar dashboard em business intelligence.

146

O modelo de arquitetura de informação correspondente à arquitetura organizacional é apresentado na Figura 7.18, onde se destaca um alinhamento mais direto entre conceito e tabela. A exceção são conceitos como “função”, “contrato FSE” e “contrato pessoal” onde não foi possível modelar e testar os dados devido a falta de acesso a alguns sistemas que gerem essa informação.

Figura 7.18: Modelo de relação entre arquitetura organizacional e arquitetura de informação de empresa gestora de infraestrutura

7.3.1.2 Arquitetura negócio

Ao nível da ontologia, sem elementos instanciados, apresentada na Figura 7.19, os canais são utilizados para comercializar oferta comercial através de contratos de proveitos estabelecidos com clientes. Os contratos têm transações associadas e que envolvem “títulos” enquanto produtos, além de “parceiros” (e.g. bolsas, brokers). Os clientes são tipificados por segmentos (e.g. particular, empresa).

147

O modelo instanciado numa lógica de arquitetura empresarial é apresentado na Figura 7.20, para mais tardar se comparar com a visualização via dashboard. Não são representados elementos de lojas, parceiros, transações e clientes, pelo impacto visual complexo que tal acarretava, sendo essa uma das vantagens de se utilizar dashboard em business intelligence. O modelo de arquitetura de informação correspondente à arquitetura de negócio é apresentado na Figura 7.21., sendo de destacar o seguinte:

• Desagregação do conceito “Transações” em tabelas de dados FT_Proveitos, LK_TipoMovimento e LK_TipoEvento;

• Ausência de relações diretas entre conceitos como “Contrato Proveitos” e “Oferta Comercial” com tabelas de dados;

• Ligação do conceito “Parceiro” com tabela de dados LK_Bolsas, somente para efeito de teste, sendo que num caso mais detalhado, seria necessário representar igualmente outros parceiros como é o caso de “Brokers”.

148

Figura 7.21: Modelo de relação entre arquitetura de negócio e arquitetura de informação de empresa gestora de infraestrutura

7.3.2 Business intelligence

7.3.2.1 Base de dados

O modelo apresentado na Figura 7.22 e relações entre tabelas apresentadas na Figura 7.23 foi criado em Microsoft PowerBI Desktop a partir de tabelas em Microsoft SQLServer. A estrutura da base de dados foi desenhada tendo por base os conceitos da organização face à definição em arquitetura empresarial sendo assim uma implementação da ontologia sobre esta forma de representação de conhecimento. Foi delimitada a factos de proveitos por não ter sido possível utilizar-se informação de custos no ambiente tecnológico utilizado para investigação. O modelo é caracterizado pelo seguinte:

• Centralidade da tabela FT_Proveitos a partir do qual se organiza um modelo em snowflake com dimensões como cliente (LK_Cliente) que por sua vez tem uma dimensão específica de segmento (LK_Segmento), localização geográfica pela morada (LK_Geografia) ou loja a que está associado (LK_Lojas);

• Definição de tabelas de custos, como é o caso de unidade orgânica (LK_EstruturaOrganica) e colaboradores (LK_CapitalHumano), mas sem tabela de factos associada a custos. Neste caso a ausência dessa tabela deve-se à impossibilidade de se obter os dados em causa como parte do caso de estudo com a organização.

149

Figura 7.22: Modelo de dados empresa financeira em PowerBI Desktop

150

Como resultado, o modelo deste caso de estudo é caracterizado pelo seguinte:

• Tabela central de factos FT_Proveitos associada a dimensões críticas de clientes (LK_Clientes), transações (LK_Eventos e LK_Movimentos), produtos (LK_Titulos) e parceiros (LK_Bolsas);

• Tabela de clientes (LK_Clientes) como dimensão, mas com uma relação com segmentação (LK_Segmento), localizações (LK_Geografia) e canal de lojas (LK_Lojas) pois de acordo com a ontologia de negócio os clientes são a base destas relações;

• Estrutura orgânica (LK_Estrutura Orgânica) e sua relação com colaboradores (LK_CapitalHumano);

• Utilização de tempo (LK_Tempo) como forma de introduzir o conceito de histórico no modelo, como é normal em modelos informacionais. Neste caso foi colocado só ao nível de tabelas de factos, apesar da modelação poder incluir também esta dimensão em tabelas de dimensões.

7.3.2.2 Integração de dados

O processo de ETL (extraction, transform and load) foi criado utilizando-se a ferramenta Microsoft Integration Services. Os processos foram organizados em agrupamentos com a mesma lógica de conceitos, da arquitetura empresarial tal como apresentado na Figura 7.24. Por essa razão, foram criados dois grupos, “Orgânica” e “Negócio” onde se considerou tarefas especificas de carregamento por tabela. As tabelas transversais como LK_Geografia e LK_Tempo foram colocadas fora destes agrupamentos.

Figura 7.24: Processo ETL empresa financeira

Por outro lado, tal como apresentado na Figura 7.25, para cada tarefa existe um processo de ligação a tabelas origem (extraction), seguido de uma transformação (transform) e por fim o carregamento na tabela destino (load). Neste caso não foram efetuadas muitas transformações pois o modelo de base já tinha os campos preparados para carregamento.

151

Figura 7.25: Processo ETL empresa financeira. Exemplo de transformação por tabela

7.3.2.3 Dashboard para exploração de dados

Face à orientação da arquitetura de hipótese de solução, foi criado um dashboard com três sheets relativas a “Estrutura organizacional”, “Estrutura negócio” e “Proveitos” enquanto áreas temáticas de análise da organização. Ficou em falta a sheet de “Custos” por falta de dados. De notar que os dados apresentados são fictícios visto terem sido mascarados a partir de dados originais da empresa em caso de estudo. Na sheet “Estrutura Organizacional” na Figura 7.26, pode-se observar a estrutura orgânica representada num gráfico “heat map” para permitir “drill” a partir da hierarquia orgânica sendo que o tamanho das zonas do gráfico representa a quantidade de colaboradores. Por outro lado, face aos locais de atividade da empresa, é apresentado sobre a forma de um mapa as zonas do país com o tamanho das “bolas” relacionada com a quantidade de colaboradores. São assim apresentados os conceitos de estrutura orgânica, colaboradores e locais, que fazem parte da modelação em arquitetura empresarial.

152

Na sheet “Estrutura Negócio” na Figura 7.27, pode-se observar a representação de parceiros (e.g. Bolsas), produtos (e.g. serviços por tipologia de movimentos e produtos enquanto títulos comercializados), canais e segmentação de clientes.

Figura 7.27: Sheet “Estrutura Negócio” do dashboard de empresa financeira

Na sheet “Proveitos” na Figura 7.28, pode-se observar que são reutilizadas as dimensões ao nível de “arquitetura de negócio”, mas acrescentado somente uma visão de tempo associado às transações e quantidade de transações.

153

7.3.3 Analisador de expressões de negócio

Tendo como base a ontologia, é possível antes de mais detetar na visualização de dashboard que as expressões “métricas por dimensões” é nativa na própria ferramenta, como se repara na legenda que a ferramenta coloca em gráficos (e.g. #Mov por CodEvento; #Mov por TipoTitulo). Testando algumas expressões com a experimentação de Processamento de Língua Natural reutilizando a ontologia criada, temos um resultado adequado, tal como apresentado na Figura 7.29 para a expressão “Analisar ValorTotal, ValorUnitario de Efectuados por CodBolsa, CodCliente para CodBolsa = Euronext.”:

Figura 7.29: Analisador de expressões de negócio de empresa financeira