Mapeamento e Reengenharia de Processos
Financeiros para Robotização
Paulo Filipe Gomes Sousa Mendes
Dissertação de Mestrado
Orientador na FEUP: Prof. Manuel Pina Marques
Mestrado Integrado em Engenharia e Gestão Industrial
Resumo
Num mercado cada vez mais competitivo, as empresas procuram poupar em todos os recursos que usufruem, sejam eles recursos humanos, financeiros ou simplesmente tempo. A Robotização é uma nova tecnologia que apareceu para dar resposta a esta procura, e cuja utilização tem vindo a crescer em várias áreas do mercado.
Cada vez mais as empresas se focam nos processos, e não apenas nos produtos ou serviços que comercializam. É este foco constante nos processos que chamou a atenção para a perda de eficiência associada a atividades que não representem qualquer tipo de valor acrescentado para a empresa. Assim torna-se um objetivo para todas as empresas reduzir a quantidade de recursos gastos na realização deste tipo de atividades.
Grande parte dessas atividades são, hoje em dia, realizadas em computadores. Assim, a robo-tização, ao simular as tarefas anteriormente realizadas por um utilizador, vem dar ajudar nesse au-mento de eficiência desejado, quer seja pela redução de tempo empregue nessas tarefas ou mesmo pela redução de recursos humanos requeridos.
O objetivo deste projeto passa por: (1) perceber a viabilidade de implementação de tecnolo-gias de robotização em alguns processos financeiros, (2) otimização dos processos financeiros a robotizar e (3) mapeamento dos novos processos otimizados de maneira a estarem prontos a ser robotizados.
Para o ponto (1) estudou-se aqueles processos que estavam identificados devido a grande parte do seu tempo de execução estar relacionado com atividades que não representam valor acres-centado para o produto final. Outras características essenciais para a robotização foram também procuradas nesses mesmos processos.
Para o ponto (2), começou por se proceder ao mapeamento do estado atual, apenas com o intuito de facilitar a identificação de oportunidades de melhoria. De seguida, explorou-se essas mesmas oportunidades de melhoria procurando sempre chegar a uma versão final do processo mais precisa e eficiente quando comparada com a inicial.
Por fim, no ponto (3) procedeu-se ao mapeamento do processo otimizado, de maneira a facili-tar a robotização futura do mesmo. Este novo processo teve depois de ser testado e avaliado, antes de se tomar qualquer decisão.
Todo este trabalho foi precedido de uma pesquisa acerca dos termos envolvidos. Assim foi feito um estudo do estado da arte de temáticas como o Robotic Process Automation, o mapeamento de ficheiros, o funcionamento dos centros de serviços partilhados e ainda as funcionalidades de algumas ferramentas financeiras.
Palavras chave: Robotic Process Automation, Centro de Serviços Partilhado, Budgeting, Ma-peamento de Processos
Abstract
In an increasingly competitive market, companies seek to save on all the resources they enjoy, be they human, financial or simply time resources. Robotization is a new technology that has appeared to meet this demand, and whose use has been growing in several areas of the market.
More and more companies are focusing on processes, and not just the products or services they sell. It is this constant focus on processes that has drawn attention to the loss of efficiency associated with activities that do not represent any kind of added value for the company. Thus it becomes a goal for all companies to reduce the amount of resources spent in performing this type of activities.
Most of these activities are nowadays carried out on computers. Thus, by simulating the tasks previously performed by a user, robotization helps to increase the desired efficiency, either by reducing the time spent on those tasks or even by reducing the human resources required.
The objective of this project is: (1) realize the feasibility of implementing robotization techno-logies in some financial processes, (2) optimization of the financial processes to be robotized and (3) mapping of new optimized processes in order to be ready to be robotized.
For point (1) it was studied those processes that were identified due to a large part of their execution time being related to activities that do not represent added value for the final product. Other essential characteristics for the robotization were also searched in these same processes.
For point (2), the mapping of the current state was started, with the sole purpose of facilitating the identification of improvement opportunities. Then, these same improvement opportunities were explored, always seeking to reach a final version of the process that is more precise and efficient when compared to the initial one.
Finally, in point (3) the optimized process was mapped, in order to facilitate its future roboti-zation. This new process had to be tested and evaluated before making any decision.
All this work was preceded by a research on the terms involved. Thus, a study was made of the state of the art of issues such as Robotic Process Automation, the mapping of files, the operation of shared service centers and also the functionalities of some financial tools.
Keywords: : Robotic Process Automation, Shared Service Center, Budgeting, Process Map-ping.
Agradecimentos
Em primeiro lugar, agradeço ao professor Manuel Pina Marques pela constante disponibilidade e vontade de ajudar, assim como pelo conhecimento partilhado comigo durante todo o período desta dissertação.
Agradeço à minha orientadora na Sonae Capital, Paula Bastos, por toda a flexibilidade, apoio e compreensão, em todos os aspetos envolvidos neste projeto. Agradeço também aqueles que não só me acompanharam, mas principalmente me encaminharam ao longo do mesmo. Aos meus colegas na Sonae Mariana, Helena, Catarina, Cid, Ribeiro, Cristiana, Rogério, Ivo e a todos os outros que fizeram parte do meu dia-a-dia ao longo deste projeto.
Aos meus amigos, pela companhia e crescimento conjunto que tivemos ao longo dos anos, nas melhores e piores fases que ultrapassamos em conjunto. Mudei de escola e de cidade, mas sempre tive a felicidade de conhecer gente nova e incrível, que me ensinou muito. Um obrigado ainda maior aos que me acompanharam em todas as mudanças.
Finalmente, e acima de tudo, um muito obrigado a minha família, por todo o apoio durante toda a minha vida. Um muito obrigado por me terem dado asas para voar, um muito obrigado pelos sacrifícios e pelas dores de cabeça que tiveram de suportar. Ao meu pai um obrigado por todo o acompanhamento em todos os ramos da minha vida, um obrigado pelo exemplo que é, um obrigado por me mostrar que o nosso bem-estar é obtido muitas vezes pondo o bem-estar dos outros à frente. À minha mãe, um obrigado pela preocupação constante comigo e por fazer com que nunca me sinta sozinho, por mais longe que esteja. À minha irmã um obrigado pela companhia, pelos risos e choros e por me mostrar como o bebé que já tive nos braços se pode tornar numa mulher que me enche de orgulho. Aos meus avós e restantes familiares, o meu obrigado pelas pessoas que são e que eu tanto admiro. Aos que já não estão comigo, obrigado por fazerem parte da minha vida e por olharem por mim aí de cima. Por fim, um muito obrigado à minha menina de quatro patas, por me mostrar um amor mais puro do que eu achei possível existir, e pela irmã que foi também para mim nos anos que esteve comigo.
"At the source of every error which is blamed on the computer, you will find at least two human errors, one of which is the error of blaming it on the computer."
Tom Gilb
Conteúdo
1 Introdução 1
1.1 Objetivos e Motivação do Projeto . . . 1
1.2 Robotização de processos financeiros na Sonae Capital . . . 2
1.3 Mapeamento de processos financeiros na Sonae Capital . . . 3
1.4 Método seguido no projeto . . . 3
1.5 Estrutura da dissertação . . . 3 2 Revisão de literatura 5 2.1 Robotização de processos . . . 5 2.1.1 Definição de RPA . . . 5 2.1.2 Aplicação do RPA . . . 6 2.1.3 Vantagens do RPA . . . 6 2.1.4 Desvantagens do RPA . . . 7
2.2 Centro de Serviços Partilhados . . . 8
2.2.1 O que é um Centro de Serviços Partilhados . . . 8
2.2.2 Vantagens de um Centro de Serviços Partilhado . . . 8
2.2.3 Problemas e cuidados a ter com os Centros de Serviços Partilhados . . . 9
2.3 Orçamento económico e orçamento de Cash Flow . . . 9
2.4 Mapeamento de processos . . . 10
2.4.1 Definição de mapeamento de processos . . . 10
2.4.2 Tipos de Mapas de processos . . . 10
2.4.3 Fases do mapeamento de um processo . . . 11
3 Descrição do Problema 15 3.1 Os departamentos envolvidos no projeto . . . 15
3.1.1 Departamento Group Reporting, Tax & Treasury . . . 15
3.1.2 Departamento Group Planning & Control & Investor Relations . . . 16
3.1.3 Departamento Accounts Payable & Receivable . . . 17
3.2 O processo a mapear . . . 17
3.2.1 Transformação de Orçamento Económico em Cash Flow . . . 17
3.2.2 Cálculo dos desvios e Forecast . . . 19
3.2.3 Reporte . . . 20
3.3 Ferramentas utilizadas . . . 21
4 Metodologia e Desenvolvimento 24 4.1 Definição do tipo de mapeamento a utilizar . . . 24
4.2 Mapeamento do Estado Atual . . . 24
4.2.1 Formatação dos ficheiros . . . 25
4.2.2 Carregar as views de CMS . . . 26 vii
viii CONTEÚDO
4.2.3 Cálculo do desvio de Compras . . . 27
4.2.4 Cálculo do desvio de Vendas . . . 28
4.2.5 Cálculo do desvio de Capex . . . 28
4.2.6 Importação de gastos com pessoal e impostos . . . 29
4.3 Identificação de oportunidades de melhoria e definição de novo modelo . . . 29
4.3.1 Cálculo dinâmico de prazos de pagamento e recebimento . . . 30
4.3.2 Nova fórmula de cálculo do Forecast . . . 30
4.3.3 Floate Adiantamentos . . . 31
4.3.4 Inputsdo negócio . . . 31
4.3.5 Saldos Iniciais . . . 32
4.3.6 Análise do IVA . . . 32
4.3.7 Novos desvios a analisar . . . 33
4.3.8 Outras alterações . . . 33
4.4 Mapeamento do processo otimizado . . . 34
4.4.1 Novo Mapeamento da Formatação de ficheiros . . . 34
4.4.2 Novo Cálculo de desvio de Compras . . . 35
4.4.3 Novo cálculo de desvio de vendas . . . 35 5 Conclusões e Procedimentos Futuros 37 A Modelo Cálculo Desvios Inicial 41 B Modelo Cálculo desvios Final 43 C Modelo introdução gastos com pessoal e impostos 46
Acrónimos e Símbolos
KPI Key Performance Indicator RPA Robotic Process Automation CapEx Capital Expenditure
OpEx Operational Expenditure CMS Cash Management Service TMS Treasury Management System
Lista de Figuras
1.1 Cronograma do Projeto . . . 4
2.1 Exemplo de um Flowchart Hope (2018) . . . 11
2.2 Exemplo de um High-level Process Map Flowchart Eureka (2018) . . . 12
2.3 Exemplo de um Cross Functional Flowchart Nishadha (2018) . . . 13
2.4 Exemplo de um SIPOC Jacques (2018) . . . 13
3.1 Hierarquia organizacional do departamento financeiro. . . 16
3.2 Gráfico com representação do orçamento, real e previsão/forecast . . . 20
4.1 Processo de exportação de dados. . . 25
4.2 Modelo geral do processo de cálculo de desvios e apuramento do forecast . . . . 26
4.3 Modelo detalhado do subprocesso de formatação dos modelos utilizados . . . 26
4.4 Modelo detalhado do subprocesso de carregamento das bases de CMS . . . 27
4.5 Modelo detalhado do subprocesso de cálculo do desvio de compras . . . 28
4.6 Modelo detalhado do subprocesso de cálculo do desvio de vendas . . . 29
4.7 Cálculo desvio de Capex . . . 29
4.8 Gastos com Pessoal e Impostos . . . 30
4.9 Modelo geral do novo processo de cálculo de desvios e cálculo do forecast . . . . 34
4.10 Subprocesso detalhado do novo subprocesso de formatação dos modelos utilizados 35 4.11 Modelo detalhado do novo subprocesso de cálculo do desvio de compras . . . 36
4.12 Modelo detalhado do novo subprocesso de cálculo do desvio de vendas . . . 36
A.1 Modelo cálculo desvios inicial parte 1 . . . 41
A.2 Modelo cálculo desvios inicial parte 2 . . . 41
A.3 Modelo cálculo desvios inicial, cálculo dotações . . . 42
A.4 Modelo cálculo desvios inicial, base total SAP . . . 42
B.1 Modelo cálculo desvios Final parte 1 . . . 43
B.2 Modelo cálculo desvios Final parte 2 . . . 43
B.3 Modelo cálculo desvios Final, cálculo dotações . . . 44
B.4 Modelo cálculo desvios Final, Base de SAP . . . 44
B.5 Modelo cálculo desvios Final, cálculo de prazos . . . 44
B.6 Modelo cálculo desvios Final, Saldos iniciais . . . 45
B.7 Modelo cálculo desvios Final, forecast de vendas . . . 45
B.8 Modelo cálculo desvios Final, impostos e adiantamentos . . . 45
C.1 Modelo introdução gastos com pessoal e impostos . . . 46
C.2 Modelo introdução gastos com pessoal . . . 47 xi
xii LISTA DE FIGURAS
Lista de Tabelas
4.1 Simbologia BPMN utilizada no mapeamento . . . 25
Capítulo 1
Introdução
A Sonae Capital SGPS S.A. reconheceu recentemente a importância de implementar metodo-logias de Robotic Process Automation (RPA), em alguns dos seus principais processos financeiros. Estando inserida num mercado financeiro, onde grande parte das ações desenvolvidas são repeti-tivas e não implicam uma análise muito profunda, a eficiência dos trabalhadores, e consequente-mente da empresa, é altaconsequente-mente limitada pelo tempo que estes passam a desenvolver atividades que não representam qualquer valor acrescentado para o serviço final.
O grupo Sonae Capital tem como propósito estratégico identificar novas oportunidades de ne-gócio, em segmentos com elevado potencial de crescimento e dotá-las de recursos que potenciem o crescimento até que se tornem autossustentáveis, assegurando uma eficiente alocação de capital (https://www.sonaecapital.pt/pt)
Este projeto foi desenvolvido na área da tesouraria, mais concretamente nos processos relaci-onados com a elaboração do orçamento de Cash Flow e do reporte do mesmo.
A Sonae Capital é uma das 3 holdings pertencentes ao grupo Sonae (sendo as outras a Sonae e a Sonae Industria), e integra atualmente o índice PSI 20 (https://www.euronext.com/en).
1.1
Objetivos e Motivação do Projeto
Este projeto tem como objetivo final obter-se o mapeamento dos processos que se pretende robotizar. Para se atingir este fim dividiu-se o mesmo em três objetivos distintos
O primeiro objetivo passa por um estudo aprofundado do estado de desenvolvimento atual da tecnologia inerente aos processos de robotização (Robotic Process Automation-RPA). Nesta fase, tenta-se perceber quais os tipos de processos em que faz sentido estudar a implementação do RPA, assim como as vantagens que daí resultam. Apenas desta maneira se consegue obter uma imagem mais clara do que precisamos fazer, assim como quais os cuidados a ter quando se prepara um mapeamento com o intuito de preceder a um processo de robotização.
O segundo objetivo passou por uma análise dos processos que se pretendiam mapear, tal como estavam a ser executados no início do projeto. Esta análise é fundamental para a identificação de possíveis erros do processo, e de oportunidades de melhoria. Essas oportunidades de melhoria
2 Introdução
devem ser exploradas, testadas e controladas, sempre com o objetivo em mente de chegar a um processo mais otimizado. Ainda que possa existir um mapeamento do processo no estado atual, o mapeamento final é aquele que se espera que sirva de apoio à robotização, e deve ser realizado já depois de exploradas todas as oportunidades de melhoria.
Por fim, o terceiro objetivo passa pelo mapeamento do processo final, já após exploração das oportunidades de melhorias identificadas. Este mapeamento deve ser precedido de um estudo acerca do desenvolvimento da tecnologia de mapeamento. É importante conhecer os diferentes tipos de mapeamento existentes, assim como as vantagens e desvantagens de cada um. Este pro-cesso pode permitir-nos identificar novas oportunidades de melhoria, que devem também ser ex-ploradas, voltando a ser necessário proceder a um mapeamento. Isto torna estas ultimas duas fases em fases mais dinâmicas, pelo que as os tempos de execução de cada uma não são tão facilmente definíveis.
As principais motivações para o projeto foram as seguintes.
• o envolvimento com uma tecnologia que tem tido um crescimento exponencial, como é o RPA. O grande nível de interesse na tecnologia e o elevado número de empresas que já avan-çaram para a implementação da mesma contrasta com a pouca informação que atualmente existe sobre ela, o que, contudo, não tem feito as empresas duvidarem da sua viabilidade; • a importância reforçada que este tipo de tecnologias tem numa área como a área financeira,
principalmente quando falamos de um Centro de Serviços Partilhados, que tem como princi-pal objetivo atingir um alto nível de eficiência mantendo ainda assim um custo competitivo; • o fato de que, sendo este um projeto desenvolvido mais internamente que o que é usual, possibilita uma maior adaptação a algumas características especificas que existem na Sonae Capital. Isto deixa prever que não só os resultados finais serão mais eficientes, como ainda haverá uma maior facilidade de implementação desta nova tecnologia;
1.2
Robotização de processos financeiros na Sonae Capital
O departamento da tesouraria da Sonae Capital tem um funcionamento semelhante a um Sha-red Services Center, onde os processos de tesouraria de cerca de 100 empresas pertencentes ao grupo Sonae Capital são tratados centralmente, nos mesmos sistemas e segundo as mesmas regras, com o objetivo de aumentar as sinergias existentes, potenciando assim a eficiência. No caso da Sonae Capital, este centro terá como funções a elaboração do Orçamento de Cash Flow e reporte mensal do mesmo, o cálculo de previsões de tesouraria, a gestão diária de bancos, a centralização de liquidez, a formalização bancária, a contratação e controle de serviços bancários, a negociação com o mercado monetário e cambial de curto prazo, a gestão da política de risco de crédito de clientes e da contraparte e a negociação de produtos de cobertura do risco de crédito.
Neste projeto o processo com maior potencial de robotização será o processo relativo ao orça-mento de Cash Flow, e a elaboração do reporte do mesmo. A escolha deste processo para iniciar
1.3 Mapeamento de processos financeiros na Sonae Capital 3
a robotização deveu-se ao fato de este ser um processo transversal a todas as 100 empresas, com uma periodicidade mensal e com uma forte componente mecânica, ou seja, que não representa qualquer valor acrescentado, componente esta que representa grande parte do tempo despendido na execução das tarefas.
Assim, o principal objetivo da robotização daquele processo passa pela redução do tempo des-pendido em tarefas sem valor acrescentado, libertando o tempo dos intervenientes para atividades de análise que efetivamente aumentem o valor do produto final, como a análise critica sobre o reporte elaborado.
1.3
Mapeamento de processos financeiros na Sonae Capital
A robotização de processos não é um conceito novo para o Grupo Sonae. Contudo, nunca foi aplicado no grupo Sonae Capital. Foi decidido que o processo de implementação da robotização de processos na Sonae Capital seguiria uma metodologia diferente daquela que foi utilizado nas outras holdings.
Enquanto que nas outras holdings todo o processo precedente à robotização foi subcontratado a uma empresa externa, na Sonae Capital decidiu-se que a fase inicial, que corresponde à preparação dos processos para robotização e o mapeamento dos mesmos após a reengenharia dos processos, seria feita internamente. Não havendo um departamento dedicado apenas a este tipo de projetos, foi decido que este seria um projeto desenvolvido internamente no departamento da tesouraria.
1.4
Método seguido no projeto
O projeto pode ser dividido em 4 grandes fases estruturais: o levantamento e mapeamento do estado atual de todos os processos previamente definidos como tendo potencial de robotização, a identificação de lacunas ou imprecisões nos modelos atuais, a identificação de oportunidades de melhoria e, por fim, a criação e mapeamento de um modelo e processo atualizados.
Paralelamente a estas atividades-chave, foram ocorrendo outras pequenas atividades, vitais também para o bom desenvolvimento do projeto. O planeamento das atividades bem como as datas definidas como deadlines para cada um dos processos pode ser encontrado na figura 1.1.
1.5
Estrutura da dissertação
Esta dissertação encontra-se dividida em 5 capítulos.
No primeiro capítulo são apresentados os objetivos e motivações do projeto e é feita uma contextualização geral do mesmo. Apresenta-se também a empresa onde o projeto foi realizado.
No segundo capítulo faz-se um enquadramento teórico dos vários temas que serão depois abor-dados ao longo da dissertação, com principal incidência na tecnologia do RPA e no mapeamento de processos.
4 Introdução
Figura 1.1: Cronograma do Projeto
No terceiro capítulo encontra-se a descrição do problema, assim como os fatores que o ro-deiam. É apresentado o processo envolvido, e o seu objetivo e possíveis condicionantes.
No quarto capítulo aborda-se a metodologia utilizada na resolução do problema, os obstáculos encontrados apresentando ainda aquela que foi considerada a solução final do mesmo.
Por fim, no último capítulo, descrevem-se as principais conclusões desta dissertação e apresentam-se sugestões de trabalhos futuros a realizar.
Capítulo 2
Revisão de literatura
Este capitulo aborda as características de um RPA, o estado de desenvolvimento atual dos mesmos, assim como as suas vantagens e desvantagens e ainda os requisitos para a sua implemen-tação. Foi feito um levantamento da evolução registada nos últimos anos da análise dos processos existente nas mais variadas áreas da industria, tema este fortemente relacionado com a evolução do RPA. Dentro deste tema aborda-se então o conceito de mapeamento de processo, ou seja, não apenas os tipos de mapeamento possíveis, mas também qual a importância do mesmo.
É ainda abordada a importância de um centro de serviços partilhados nos dias de hoje, referindo-se também quais os processos mais adequados a este tipo de referindo-serviços.
Finalmente, referem-se, ainda que de uma forma mais geral, os tipos de atividades financeiras envolvidos na gestão atual de uma empresa, assim como os seus objetivos e possíveis indicadores de desempenho Key Performance Indicator - KPI.
2.1
Robotização de processos
2.1.1 Definição de RPA
Mesmo não existindo uma definição unânime acerca do significado de robotização de proces-sos (RPA), segundo o Institute for Robotic Process Automation & Artificial Inteligence, IRPAAI (http://www.irpanetwork.com/), este termo refere-se à possibilidade de possuir um robot com a capacidade de interagir com softwares e aplicações existentes em processos de uma empresa, in-terpretando dados e outcomes que surjam durante os mesmos, ao mesmo tempo que gerem bases de dados, ativam respostas e comunicam com outros sistemas digitais. Assim, quando se fala de robotização, não se fala de robôs físicos, mas sim da automação de processos que anteriormente teriam de ser realizados por humanos, Lacity et al. (2015)
Segundo Han Pin Fung (2014), o processo RPA pode também ser chamado de Information Te-chnology Process Automation(ITPA) ou ainda Run Book Automation (RBA). É ainda referido que o principal objetivo da implementação desta tecnologia passa pelo aumento da eficiência, acompa-nhada pela redução de custos. Segundo Nizri (2012), RPA refere-se à capacidade de automatizar
6 Revisão de literatura
processos que interajam com diferentes aplicações informáticas e/ou bases de dados. Assim sendo define-se também o que é um processo, que para H.P. Fung (2014) é um conjunto de tarefas que transformam os inputs recebidos nos outputs desejados.
Já Slaby (2012) acrescenta que o principal objetivo do RPA é a substituição de trabalho ante-riormente realizado por humanos por tecnologia capaz de executar o mesmo trabalho com maior eficiência, mantendo sempre a qualidade.
2.1.2 Aplicação do RPA
Durante este estudo foi também importante perceber quais as condições ideais para que se proceda à adoção do RPA. Segundo Fung (2014), o RPA é um processo a ter em conta quando se está perante processos com:
• Alto número de transações;
• Necessidade de interação entre várias aplicações informáticas; • Atividades bem definidas;
• Poucas exceções relativamente ao processo core; • Vários subprocessos bem definidos;
• Interação humana repetida e propícia a erros; • Custos de execução mensuráveis.
Estas condições não são consensuais quando se tem em conta diferentes autores. Por exemplo, Lacity et al. (2015) defendem que a tecnologia RPA está preparada para lidar com as exceções que forem necessárias, pelo que estas não devem ser vistas como uma condicionante.
Apesar de o RPA não ser exclusivo de nenhum tipo de processos em específico, as caracterís-ticas que ele requer podem ser encontradas mais facilmente em algumas áreas. Segundo Holder et al. (2016), os serviços mais propensos a serem robotizados são, entre outros, a banca, compa-nhias de seguros, áreas de saúde e atividades de logística.
O que este estudo revelou, de uma forma consensual, foi que os processos devem ser altamente repetitivos, previsíveis, estarem já num estado maduro de desenvolvimento, mas que apresentam baixa eficiência e propensão a erros causados pelo homem. Para cada caso específico é ainda aconselhado o estudo das alternativas existentes no mercado.
2.1.3 Vantagens do RPA
Quando se decide partir para a implementação de uma tecnologia como é o RPA, é importante possuir conhecimento acerca do que o negócio pode ganhar com a mesma. Quando se fez o estudo acerca de quais esses benefícios, conclui-se que as principais vantagens desta tecnologia seriam:
2.1 Robotização de processos 7
• Segundo Fung (2014), uma das principais vantagens de robotizar um processo é tornar os outcomesdo mesmo independentes do utilizador que inicia o robot;
• Hewlett-Packard (2012) diz que, pelo facto de o robot não sofrer da variabilidade associ-ada aos humanos, a robotização de processos torna a duração dos mesmos mais previsível, diminuindo também a variabilidade dos outcomes esperados;
• Outra vantagem que se encontra é o facto de, segundo Slaby (2012), haver menos utilizado-res com acesso às bases de dados, o que reduz o risco de perda ou partilha da mesma; • Nizri (2012) cita outro benefício de utilizar esta tecnologia, quando diz que, a utilização de
um robot para realizar tarefas menos desejadas pelos humanos, aumenta a satisfação destes.
2.1.4 Desvantagens do RPA
Como todas as novas tecnologias, independentemente das vantagens que as mesmas possam trazer consigo, é importante, antes da sua implementação, identificar os efeitos negativos que elas podem acarretar. Será assim possível fazer um balanço entre as vantagens e desvantagens e, desta forma, chegar a uma decisão mais ponderada e com maior probabilidade de sucesso.
Esta pesquisa permitiu identificar os seguintes efeitos nefastos associados à robotização de processos:
• Brown (2012) realça o problema ético que está associado a todos os processos relacionados com a automatização de processos. Ele utiliza o exemplo das linhas de call center que utilizam atendedores automáticos, para mostrar que esta robotização pode provocar uma maior taxa de desemprego na área das tecnologias de informação (IT), não pelo fato de os mesmos substituírem os humanos, mas porque possibilitam que um número menor de empregados consiga realizar todas as tarefas necessárias;
• Fung (2014), através do testemunho de diversas empresas da área de IT, concluiu que a adoção de tecnologias de RPA requer muitas vezes que haja uma formação dos empregados que irão lidar com o mesmo, de maneira a obterem as competências necessárias para tal; • Fung (2014) diz ainda que muitas empresas acabam por desistir da implementação deste tipo
de tecnologias devido ao elevado custo que a mesma acarreta. Contudo, Sutherland (2013) diz que, quando é feita uma análise a longo prazo, o custo de implementação é facilmente recuperado com os menores custos de operação que se irá obter;
• Singh et al. (2009), já em 2009, diz que um dos maiores problemas associados a este tipo de tecnologias é o facto de provocar uma falsa sensação de segurança. Muitas vezes o facto de os processos estarem automatizados provoca displicência nos empregados, o que, ao contrário do pretendido, vai aumentar a taxa de rejeição ou diminuir a qualidade dos outcomes.
8 Revisão de literatura
2.2
Centro de Serviços Partilhados
2.2.1 O que é um Centro de Serviços Partilhados
O conceito de Centro de Serviços Partilhados (Shared Services Center-SSC), é um conceito que tem sido altamente explorado e desenvolvido a partir do final da década de 90.
Segundo Ulrich (2006), um SSC pode ser definido como um centro que tem como objetivo otimizar os recursos corporativos existentes numa nova unidade organizacional. Segundo Rohith Ramphal (2013), podemos definir um SSC como um centro onde se concentram as atividades re-petidas e não nucleares de várias unidades de negócio pertencentes a uma organização. Já segundo Quinn et al. (2000), um SSC é criado quando diferentes unidades de negócio decidem partilhar entre elas um fornecedor de serviços, para serviços comuns a todas elas.
Tendo mais uma vez em conta Ulrich (2006), as características mais importantes que definem um SSC são:
• Funcionar como uma unidade independente, tendo uma relação fornecedor/cliente para com as outras unidades de negócio;
• Não haver necessidade de estar próximo geograficamente com as unidades de negócio com as quais interage;
• Estar munido de tecnologia de ponta;
• Haver um foco constante em oportunidades de melhoria; • Ser um serviço low cost.
2.2.2 Vantagens de um Centro de Serviços Partilhado
É importante perceber quais as vantagens que são trazidas para o negócio quando se utilizam este tipo de metodologias. Continuando a citar Ulrich (2006), conseguimos perceber que os SSC trazem para o negócio vantagens em diversas áreas, nomeadamente:
• Redução dos gastos administrativos devido ao uso de economias de escala; • Partilha de propriedade física e intelectual entre as várias unidades de negócio; • Mais facilmente justificável o investimento em tecnologias de ponta;
• Fluxo do trabalho mais bem definido e direcionado; • Aumento da eficiência.
2.3 Orçamento económico e orçamento de Cash Flow 9
2.2.3 Problemas e cuidados a ter com os Centros de Serviços Partilhados
Na pesquisa efetuada, foram encontradas referências de alguns autores relativas a alguns cui-dados a ter. Por exemplo, Mergy and Records (2001) temem que a utilização de um SSC possa provocar um descuido das equipas responsáveis pelo controlo dos processos, no sentido de os processos, ao serem efetuados no exterior, não sofrerem do mesmo nível de supervisão.
Segundo Ramphal (2013), outra preocupação ligada a esta tecnologia está relacionada com a possibilidade de, devido a se formar um centro que procura elevada eficiência, não se despender o tempo necessário na busca de oportunidades de melhoria e/ou aproveitamento das mesmas. O mesmo autor diz ainda que a utilização de tecnologia de topo pode ser um entrave à personalização necessária, tantas vezes benéfica neste tipo de processos.
Já David (2005) diz que não é consensual a fórmula de calcular os ganhos obtidos pelos SSCs, pelo que se torna difícil determinar o lucro real que a sua implementação permite obter.
2.3
Orçamento económico e orçamento de Cash Flow
O que define um orçamento, ou mesmo qual é a sua aplicação prática, não é um tema con-sensual na comunidade científica. Para alguns autores, como B.E. Khrutsky (2007), um orça-mento deve incluir também o planeaorça-mento financeiro, acompanhado de seguida por um controlo do mesmo. Por outro lado, D.A. Shevchuk (2006) diz que um orçamento deve ser visto como uma ferramenta de gestão pelo fato de consistir numa agregação de informação acerca dos vários processos que compõem o negócio.
A definição que parece ser mais abrangente e defendida por mais autores é a enunciada por M.B. Trachenko (2012), que diz que a elaboração de um orçamento é simultaneamente um pro-cesso, quando se olha à sua elaboração por uma perspetiva mais direta, mas também uma tecno-logia aquando da decomposição do negócio nos processos existentes necessária à elaboração do mesmo.
É depois importante perceber onde entra a matéria do Cash Flow neste processo orçamental. Segundo Gormley and Meade (2007), a importância da transformação de um orçamento econó-mico num orçamento de Cash Flow está relacionada com o interesse em minimizar ao máximo os requisitos de financiamento de uma empresa em todos os seus períodos de operação. Enquanto que o orçamento económico reflete as compras e vendas da atividade operacional, uma análise ao cash flow reflete a entrada ou saída de dinheiro nessa mesma unidade de negócio. Contudo, segundo Solle et al. (2010), proceder à execução de um orçamento de cash flow, trás consigo a necessidade de se executar também uma análise ao risco que lhe está associado, devido à maior incerteza existente.
Ainda segundo Solle et al. (2010), outra das grandes vantagens da análise através de cash flow é o facto de nos dar uma ideia mais realista do estado atual de um negócio, mesmo tendo em conta fluxos de dinheiro relativos a outro tempo que não o presente, nomeadamente a dívidas ou a empréstimos prestados. Ainda neste tema, é também possível introduzir o valor que a passagem
10 Revisão de literatura
do tempo representa nas previsões a efetuar, de maneira a se distinguir o valor presente e futuro dos investimentos.
2.4
Mapeamento de processos
2.4.1 Definição de mapeamento de processos
Segundo Anjard (1996), um processo define-se como sendo um conjunto de atividades com um outcome final que representa valor acrescentado relativamente aos inputs que ele possa reque-rer. Este autor defende ainda a ideia de que, de maneira a melhorar a eficiência de uma unidade de negócio, o foco da análise deve estar não nos outcomes desejados, mas sim nos processos envolvidos na obtenção dos mesmos.
Foi associado a este pensamento que surgiu a necessidade de desenvolver modelos que per-mitam uma análise mais fácil dos processos associados a cada unidade de negócio. Surgiu assim o conceito de mapear um processo, que, segundo Anjard (1996), consiste em identificar, docu-mentar, analisar e desenvolver o estado atual de um processo. Assim, ele defende que "A process map is a visual aid for picturing work processes", identificando todas as tarefas, inputs e outputs associados ao mesmo.
2.4.2 Tipos de Mapas de processos
Existem diferentes modelos de mapeamento, cada um com as suas vantagens e desvantagens. Assim, segundo Amanda Athuraliya (2018), pode-se escolher entre os seguintes modelos de ma-peamento:
• O primeiro que é apresentado é o flowchart, definido como um mapa simples e intuitivo onde são representados os passos do projeto, os seus inputs e outputs. Este tipo de mapea-mento é ainda, segundo a autora, recomendado para planear novos processos; modelar para documentação um processo existente; identificar problemas existentes; ajudar na comuni-cação entre equipas; analisar e gerir fluxos de trabalho. Um exemplo de um flowchart é apresentado na figura 2.1;
• o High-level Process Map, que se trata de um tipo de flowchart semelhante ao anterior. No entanto, apenas mostra as atividades core de um processo, não indo muito ao detalhe quanto a pontos de decisão, papéis dos utilizadores, etc. Contrariamente ao flowchart, recomenda-se a sua utilização quando recomenda-se procura derecomenda-senhar e definir todos os processos de uma unidade de negócio e/ou identificar os passos e os detalhes chave de um processo em particular. Um bom exemplo de um High-level Process Map é apresentado na figura 2.2;
• O Cross-Functional Flowchart é um tipo mais específico de flowchart. O fator que torna este modelo especial é que, ao contrário do flowchart tradicional, ele realça as relações entre os passos de um processo e as unidades funcionais por eles responsáveis, utilizando Swim Lanes. Assim aconselha-se a sua utilização quando se pretende melhorar a comunicação
2.4 Mapeamento de processos 11
Figura 2.1: Exemplo de um Flowchart Hope (2018)
entre equipas e/ou gerir mais eficazmente os fluxos de trabalho. Um bom exemplo de um Cross-Functional Flowcharté apresentado na figura 2.3;
• o SIPOC, sigla para fornecedores, entradas, processo, saídas e clientes (Suppliers, Inputs, Process, Outputs, Customer), que, ao contrário de todos os modelos atrás referidos, apre-senta de forma mais detalhada todos os intervenientes do processo, assim como a sua própria designação indica. Apesar da sua complexidade, a sua utilização é recomendada quando se procura identificar os elementos chave de um processo e se quer definir todos os objetivos de cada passo pertencente a um processo. Um bom exemplo de um mapa SIPOC é apresentado na figura 2.4.
2.4.3 Fases do mapeamento de um processo
Quando o objetivo é mapear um processo, é importante estudar-se qual a metodologia a seguir para o mapeamento do mesmo. Assim, juntando as perspetivas de vários autores, nomeadamente Anjard (1996) e Amanda Athuraliya (2018), o mapeamento de um processo passa pelas seguintes fases:
• Identificar qual o processo a mapear;
• Escolher a equipa indicada para proceder a esse mesmo mapeamento;
• Recolher toda a informação necessária. Isto inclui conhecer o ponto de inicio e de fim do processo, todos os passos requeridos, assim como todos os inputs e outputs;
12 Revisão de literatura
2.4 Mapeamento de processos 13
Figura 2.3: Exemplo de um Cross Functional Flowchart Nishadha (2018)
14 Revisão de literatura
• Organizar o fluxo de trabalho que ocorre durante o processo, assim como possíveis tempos que tenham de ser cumpridos;
• Escolher o tipo de mapeamento que mais se adequa não só ao processo, mas também ao objetivo do mapeamento;
• Proceder ao mapeamento do processo.
Ainda assim, Congram and Epelman (1995), referem a importância de haver um controlo e uma análise ao mapeamento e ao processo, antes de o tomar como oficial. Frequentemente o ma-peamento permite identificar oportunidades de melhoria que devem ser testadas e posteriormente implementadas.
Capítulo 3
Descrição do Problema
De maneira a tornar mais fácil a compreensão da envolvente do processo analisado nesta dis-sertação, é importante perceber-se melhor o contexto em que esse processo está inserido.
Como foi anteriormente referido, o Grupo Sonae Capital detém um número elevado de em-presas (cerca de 100 emem-presas, contudo mesmo durante o período em que esta dissertação foi desenvolvida, o número de empresas foi variando). Essas 100 empresas podem ser dividas em 7 segmentos, sendo eles: Ativos Imobiliários; Energias; Hotelaria; Refrigeração e HVAC; Engenha-ria IndustEngenha-rial; Fitness; Troia Operações.
Esta divisão em 7 segmentos tem como objetivo uniformizar alguns processos a serem efetua-dos para cada uma das empresas, de maneira a torná-los mais eficientes. Por outro lado, possibilita uma análise muito mais minuciosa a cada um dos segmentos, o que não seria possível de ser feito se todas as empresas tivessem de ser analisadas separadamente.
3.1
Os departamentos envolvidos no projeto
3.1.1 Departamento Group Reporting, Tax & Treasury
Este projeto foi maioritariamente desenvolvido dentro do departamento Group Reporting, Tax & Treasury. A estrutura que define este departamento é apresentada na figura 3.1.
É visível a divisão deste departamento em 4 áreas, sendo que cada uma delas tem uma função distinta. O projeto desenvolvido no âmbito desta dissertação, é um projeto transversal a todas estas áreas, incorporado, contudo, na área de Control & Development.
Começando então pela da área do Control & Development, esta é a divisão com menos re-cursos humanos de entre as 4 referidas. Composta por apenas um colaborador e um líder, as responsabilidades desta área são o controlo dos KPIs, a gestão de projetos transversais a toda a direção financeira, o controlo orçamental da direção financeira, o apoio a projetos específicos e a implementação de melhorias nos processos transversais a todo o departamento.
16 Descrição do Problema
Figura 3.1: Hierarquia organizacional do departamento financeiro.
De seguida, temos o departamento Treasury, responsável pelos projetos relacionados com as análises de Cash Flow(CF) (orçamento de CF e reporte do mesmo), com as previsões de tesouraria, com a gestão diária de bancos, com a contratação e controlo dos serviços bancários e com a gestão de risco da contraparte. Esta é a área que tem maior contato com o exterior.
A área designada por Tax, é composta por 4 colaboradores e um líder e é responsável pelo tratamento de impostos de todas as empresas pertencentes ao grupo Sonae Capital, bem como pela gestão fiscal dos mesmos. As funções desta área passam não só pelo apuramento periódico dos impostos, mas também pela elaboração e entrega das declarações fiscais à autoridade tributária, pelo processo de consolidação fiscal, pela otimização fiscal e pela elaboração de pareceres fiscais. Por fim, a área de Reporting, composta por 8 colaboradores e um líder, é responsável pela contabilidade geral, pelo fecho das contas e consolidação das mesmas e pelo reporte quer mensal quer anual por empresa e consolidado por segmento e Sonae Capital.
Sendo estas as 4 divisões que compõem o departamento Group Reporting, Tax & Treasury, podemos definir como missão global do mesmo "assegurar a criação e proteção de valor ao Grupo na componente financeira, garantindo a integridade e oportunidade da informação e uma gestão eficiente dos recursos e riscos financeiros."
3.1.2 Departamento Group Planning & Control & Investor Relations
Além do departamento Group Reporting, Tax & Treasury, no qual o projeto se inseriu, existia ainda contacto com outros departamentos pertencentes a Sonae Capital. Por exemplo o Group Planning & Control & Investor Relations, normalmente designado por PCG, é o departamento responsável pelo desenvolvimento do orçamento económico (que posteriormente se perceberá a relevância no processo estudado nesta dissertação), assim como por transmitir à área de treasury, as informações recebidas diretamente de cada um dos negócios envolvidos neste processo.
3.2 O processo a mapear 17
3.1.3 Departamento Accounts Payable & Receivable
O Accounts Payable & Receivable é o departamento responsável pela contabilização de do-cumentos financeiros de fornecedores bem como pela emissão da faturação a clientes de todas as empresas pertencentes ao grupo Sonae Capital. Este departamento é responsável por um input bastante importante no processo a estudar, nomeadamente na disponibilização da concretização dos detalhes de saldos iniciais (tanto de clientes como de fornecedores) anuais, cuja relevância será explicada posteriormente.
3.2
O processo a mapear
Umas das funções chave do departamento da área do treasury é a comparação efetuada en-tre os valores orçamentados para cada uma das empresas pertencentes ao grupo Sonae Capital e os valores reais verificados por essas mesmas empresas em termos de cash in e cash out. Este processo é feito mensalmente, em que, para além da referida comparação, é feito também um apu-ramento de uma nova previsão para o restante ano, tendo em conta não só o orçamento de cash flowinicial, mas também os valores reais já obtidos no ano em análise com efeito no ano atual. Também mensalmente é preparado um documento onde se resume toda a análise feita a estas com-parações e a justificação de desvios entre orçamento e o real, assim como quais as variações que são expectáveis no futuro.
Todos estes processos não só possuem uma periodicidade relativamente baixa (mensalmente, o que tendo em conta a complexidade do processo aliado ao facto de ter de ser feita uma vez para cada uma das cerca de 100 empresas que compõem o grupo representa uma frequência alta), mas principalmente são compostos na sua grande maioria por atividades que não representam qualquer tipo de valor acrescentado.
O grupo Sonae Capital definiu assim como prioridade reduzir o tempo despendido mensal-mente nestas atividades, libertando recursos humanos que permitam aprofundar a parte da análise que também pertence a este processo. Por outro lado, utilizando para este processo um modelo de-senhado em Excel®já elaborado há alguns anos atrás, acredita-se que poderá não estar totalmente
atualizado e adaptado às necessidades da empresa, pelo que se considerou importante existir uma revisão dos modelos utilizados. Desta forma, é então possível dividir este processo em 3 grandes fases, que serão apresentadas nas seguintes secções.
3.2.1 Transformação de Orçamento Económico em Cash Flow
A transformação do Orçamento Económico num Orçamento de Cash Flow é a primeira fase deste processo.
O orçamento económico é previamente construído pelo departamento Group Planning & Con-trol & Investor Relations, com o contributo de outras áreas da Sonae Capital. O orçamento é elabo-rado num ficheiro Excel®, e neste podem-se encontrar as previsões para cada uma das empresas, assim como alguns dos pressupostos utilizados para chegar a essas mesmas previsões. Sendo este
18 Descrição do Problema
um orçamento económico, as previsões nele encontradas são relativas a dados económicos, ou seja, são previsões de acordo com o momento de faturação das receitas ou dos gastos. Assim, são previsões dos valores que são referentes a receitas e a gastos registadas naquele mês na contabi-lidade da empresa. No entanto, em termos de cash o pretendido não é analisar economicamente cada um dos segmentos de empresas, mas sim em termos de necessidades ou excedentes de tesou-raria, pelo que surge a necessidade de transformar os dados económico em dados que representem o momento em que o pagamento (cash out) ou recebimento (cash in) vai ocorrer.
Assim sendo é necessário, na fase inicial, transformar o Orçamento Económico que nos é fornecido, num Orçamento de Cash Flow. Esta transformação é feita anualmente, para cada um dos cerca de 7 segmentos que compõem o grupo Sonae Capital.
O primeiro passo para transformar dados económicos em dados de cash flow passa pela apli-cação dos prazos de pagamento e de recebimento, ou seja, o tempo que passa entre o momento em que uma compra ou venda é faturada, e o momento em que o pagamento ou recebimento respetivo gera entrada ou saída de dinheiro da empresa. Quando se tratam de vendas a pronto pagamento (PP), o orçamento económico é igual ao orçamento de cash flow. Contudo, na maioria dos casos, isto não acontece, e estamos perante uma venda a crédito, e torna-se necessário apurar um prazo de pagamento médio tendo em conta todas as faturas. Com o intuito de tornar possível este cálculo, foram negociados com os vários fornecedores/clientes prazos de pagamento, tendo depois sido atribuído um prazo de pagamento a cada uma das tipologias das faturas. No modelo utilizado, existem tipologias de compras e vendas consoante os tempos médios de pagamento ou recebi-mento. Quando se fala destas tipologias, fala-se de casos bastante específicos em que os prazos de pagamento acordados sejam significativamente diferentes das restantes tipologias. Enquanto que a maioria das faturas entra na tipologia definida como "Outros", podemos encontrar, em alguns dos segmentos outras tipologias mais especificas. Dando só alguns exemplos, o segmento das energias, além da tipologia ’Outros’ tem ainda a tipologia ’Energia Térmica’ e ’Energia Elétrica’. Assim, estes prazos de pagamento acordados são os utilizados quando se aplica o prazo aos dados económicos presentes no orçamento.
Outro ponto que é necessário ter em conta quando se transformam dados económicos em dados de Cash Flow é a aplicação das taxas de IVA. No orçamento económico que é disponibilizado pelo Group Planning & Control & Investor Relations, estão representados os valores sem o IVA correspondente. Cabe então ao departamento Tax o apuramento e aplicação das taxas de IVA correspondentes a cada uma das tipologias de rendimentos e custos presentes no orçamento.
Por fim, esta transformação vai exigir o apuramento de saldos inicias de clientes e fornecedo-res que já constam na contabilidade do ano anterior. Sendo um orçamento um documento anual, e visto que um orçamento de Cash Flow reflete o momento em que o dinheiro efetivamente entra/sai da empresa, é normal que existam faturas relativas a anos anteriores cujo pagamento ou recebi-mento apenas vá acontecer no ano em análise. É nesta ótica que surgiu a necessidade de haver uma introdução dos saldos iniciais em várias rubricas do orçamento (compras, vendas e Capex). As da-tas de pagamento e recebimento destes documentos financeiros com impactos em cashflow no ano em análise são fornecidos pela área de Accounts Payable & Receivable, e incorporados no nosso
3.2 O processo a mapear 19
orçamento de Cash Flow. Existe uma componente específica de saldos iniciais, os saldos iniciais de dotações. Uma dotação é um acréscimo de rendimentos ou gastos que é lançado para influen-ciar a contabilidade de acordo com a periodicidade do gasto ou rendimento. Ou seja, se existe um contrato de uma renda a fornecedores, mensal, apesar de a fatura deste gasto correspondente ao mês não ter sido contabilizada no mês em que o custo é referente, é efetuada uma dotação que será anulada no momento em que a fatura é contabilizada. Desta forma, os saldos iniciais de dotações são gastos ou rendimentos que afetaram resultado no ano anterior, mas que geram pagamento ou recebimento no ano em análise (após contabilização do documento financeiro).
Os pressupostos utilizados nesta primeira fase do processo, nomeadamente o apuramento dos prazos médios de pagamento/recebimento e os valores das taxas de IVA utilizados, serão utilizados em fases posteriores deste processo.
3.2.2 Cálculo dos desvios e Forecast
Após a finalização do Orçamento de Cash Flow passa-se para a segunda fase do processo, que consiste não só na comparação entre o que foi orçamentado e o que se verifica na realidade, mas principalmente no cálculo de ajustes que sejam necessários fazer ao orçamento de maneira a ter uma previsão mais precisa desde o mês em análise até ao fim do ano.
De maneira a facilitar esta análise, foi dividida toda a atividade das empresas em 3 grandes grupos, sendo eles vendas, compras e investimento de Capex (Capital Expenditure). Para tratar cada um destes grupos existe um modelo específico (figura A.1 A.2, A.3 e A.4, Anexo A), também em Excel®, que permite não só a referida comparação entre o orçamentado e o real, como também calcular os ajustes a fazer, com base nos valores obtidos até agora, às previsões que existem até ao fim do ano em análise.
Nos ficheiros de análise do desvio de vendas, compras e Capex, ao serem carregados os valores do mês que se está a analisar (faturas de fornecedores e faturas emitidas a clientes), consegue-se perceber a precisão do orçamento quando comparado com o que efetivamente aconteceu. Adici-onalmente, permite-nos perceber quais os ajustes a fazer no orçamento, desde o mês em análise até ao fim do ano, tendo em conta o ocorrido até então, de maneira a criar uma previsão mais precisa, à qual chamamos forecast. Esses ajustes mudarão todos os meses, pelo que a linha que representa o forecast até ao fim do ano é uma linha dinâmica, que muda mensalmente. Na figura 3.2 conseguimos perceber a utilização desta nova previsão, ao verificar a relação entre a linha que representa o orçamento, a linha do real e o ajuste existente na linha de forecast em relação ao orçamento inicial.
De maneira a conseguir apurar estes valores de forecast, é importante que se defina a que se deve o desvio, estando previamente identificados 4 tipos de desvios possíveis. O desvio de vendas/compras/Capex, que é relativo quando o desvio é causado, efetivamente, por uma faturação diferente da esperada. Existe, também, o desvio de prazo, que é o desvio causado não por uma faturação diferente, mas sim por um desvio nos prazos médios de pagamento assumidos. O desvio de Saldo Inicial, é causado por uma diferença entre aquilo que era expectável pagar ou receber
20 Descrição do Problema
Figura 3.2: Gráfico com representação do orçamento, real e previsão/forecast
relativo a saldos iniciais e o que efetivamente foi pago ou recebido. O mesmo acontece com o desvio de dotação, quando uma dotação não é faturada no momento esperado.
Além destes 4 desvios, é ainda importante verificar o desvio existente em mais 2 campos, os gastos com pessoal e os impostos. Este controlo é feito noutro ficheiro existente (figura C.1, C.2 C.3, anexo C) que, tal como os modelos acima referidos, além da comparação entre o orçamento e o real nos ajudam a melhorar o forecast do mês em análise até ao fim do ano.
Por fim existe ainda o modelo global, onde se resume todos os resultados mensais do segmento, bem como de todas as empresas pertencentes a esse mesmo segmento, de forma a se obterem conclusões mais gerais acerca dos resultados mensais de cada uma das empresas e segmentos.
Toda esta fase do processo utiliza os pressupostos presentes no orçamento inicial. Por exem-plo, os prazos médios de pagamento e recebimento são bastantes úteis no apuramento do novo forecaste as taxas de imposto terão influência quando existe desvio de vendas.
3.2.3 Reporte
A terceira e ultima fase deste processo passa pelo reporte dos resultados obtidos. Este reporte é essencialmente uma análise mensal dos resultados obtidos que é enviada aos responsáveis do negócio, sendo esta a informação que pode ser considerada como o output de todo o processo. Por esta razão é uma parte importante do processo, onde o controlo e a análise devem tomar um papel importante.
Nesta análise encontramos diversas informações acerca da performance da empresa num de-terminado mês, nomeadamente:
• O Levered Free Cash Flow, que representa o dinheiro que uma empresa tem em caixa depois de ter pago todas as suas dívidas e coberto todos os seus gastos. É um dado importante para os analistas da empresa e do segmento pois representa o dinheiro disponível no fim do período disponível para distribuir dividendos. É nesta rubrica também que se apresenta o gráfico onde se expõe o mais recente forecast relativo à empresa em questão;
3.3 Ferramentas utilizadas 21
• O Fundo de Maneio, onde está representado o valor estimado como sendo necessário para garantir o funcionamento da empresa a curto prazo, que é reportado para o departamento de gestão de financiamento de longo prazo. Assim podemos referir-nos a este como uma almo-fada financeira com o objetivo de assegurar que a empresa, a curto prazo, tem capacidade de gerar liquidez, mesmo tendo em conta possíveis atrasos em alguns pagamentos;
• A dívida de cliente e a dívida a fornecedores, onde é representado o valor que ainda há a receber ou a pagar do mês em análise;
• O risco de crédito, onde é reportado o incumprimento atual dos clientes das empresas e do segmento em análise face à média de mercado, o nível de risco da dívida de clientes em aberto no final do mês em análise de acordo com o rating de risco da Dun & Bradstreet e o incumprimento ao regulamento interno do grupo Sonae Capital na conceção de crédito a clientes.
3.3
Ferramentas utilizadas
De maneira a conseguir completar todo este processo, é necessário recorrer a algumas aplica-ções informáticas. As principais são o Microsoft Excel®, o Microsoft PowerPoint®o SAP®, o Cash Management System®(CMS) e o Treasury Management System®(TMS).
O Microsoft Excel® é uma aplicação informática desenvolvida pela Microsoft, que permite trabalhar com folhas de cálculo, facilitando bastante o tratamento e análise de dados. Possibi-litam não só cálculos, mas também a criação de gráficos, pivot tables, e a programação de ma-cros, através de uma linguagem de programação conhecida como Visual Basic. A sua principal característica é a interação com um número bastante elevado de outras aplicações informáticas, principalmente devido ao quão enraizado já está no mundo empresarial.
O software Microsoft PowerPoint, também desenvolvido pela Microsoft, é também bastante utilizado neste processo. Consiste numa aplicação informática que permite a criação de apresenta-ções, e, neste processo, tem especial importância por ser nele que é produzido o outcome principal do mesmo.
O SAP, pode ser definido como um ERP (Entreprise Resources Planning), ou seja, um soft-waredesenhado para a gestão dos recursos de uma empresa. Produzido por uma empresa alemã, o SAP é a aplicação líder quando se fala de integração entre vários departamentos de uma empresa. De acordo com as necessidades de cada empresa, existem módulos personalizados de maneira a se adaptar às necessidades do negócio em que se insere.
Já o CMS pode ser definido como um sistema que permite otimizar a gestão do dinheiro mo-vimentado numa empresa. O Software utilizado neste processo, produzido pela empresa SAGE, permite gerir todas as entradas e saídas de dinheiro da empresa, sendo fundamental na recolha de dados para o cálculo depois do Cash Flow real. Outra grande vantagem deste software é a compatibilidade existente com o Excel®.
22 Descrição do Problema
Por fim o TMS, software que é disponibilizado pela empresa FIS, é um software utilizado para facilitar a gestão de toda a divida existente. Mais uma vez, um ponto fulcral a favor deste software é a compatibilidade existente com o Excel®.
3.3 Ferramentas utilizadas 23
Capítulo 4
Metodologia e Desenvolvimento
Tendo-se percebido o enquadramento do problema, assim como os objetivos a serem perse-guidos ao longo deste projeto, definiu-se como melhor abordagem começar por mapear o estado atual do processo. Apenas depois de mapeado e compreendido, se começa a identificar possíveis lacunas existentes neste processo, quer em termos de precisão quer em termos de eficiência. Por fim, tentam-se corrigir estas lacunas, de maneira a desenhar um processo que seja mais preciso e também mais eficiente.
4.1
Definição do tipo de mapeamento a utilizar
A primeira fase passou por escolher o tipo de mapeamento mais adequado ao processo que se estudou. Assim, definiu-se que a melhor maneira seria utilizar um flowchart com a nomenclatura associada à metodologia BPMN (Business Process Model and Notation).
A escolha por este tipo de mapeamento deveu-se ao fato de este ser um processo que, apesar de não ser novo, ainda não estava definido em nenhum tipo de documento. Por outro lado, é um processo cuja grande parte das atividades são desenvolvidas pelo mesmo utilizador, apesar de receber inputs de diferentes equipas.
Escolheu-se usar a nomenclatura BPMN, pois é a nomenclatura mais enraizada no mercado, pelo que facilita quer a definição quer a compreensão do flowchart.
Na tabela 4.1 pode-se consultar a simbologia que foi utilizada no mapeamento, de maneira a facilitar a compreensão do mesmo.
4.2
Mapeamento do Estado Atual
O primeiro passo para tornar possível o mapeamento do processo, consiste em perceber o que define o início e o fim do processo que pretendemos mapear.
Sendo vista como a parte mais mecânica e com mais atividades que não representam qualquer valor acrescentado neste processo, definiu-se como procedimento prioritário a mapear a compa-ração entre os valores orçados e os valores reais, assim como a definição de uma nova previsão,
4.2 Mapeamento do Estado Atual 25
Tabela 4.1: Simbologia BPMN utilizada no mapeamento
Atividade
Subprocesso
Base de Dados
Ficheiro
Caminhos Paralelos
denominada forecast. Assim, podemos dividir este procedimento em 6 subprocessos essenciais, sendo eles: a formatação dos ficheiros a utilizar; o carregamento das bases de CMS; o cálculo do desvio de compras, vendas e de Capex e o carregamento dos gastos com pessoal e impostos. O mapeamento obtido, apresentado na figura 4.2, é um mapeamento generalizado e que pode ser utilizado para análise de todas as empresas pertencentes à Sonae Capital.
Ao longo deste processo utilizar-se-á a interação com duas bases de dados, o SAP e o CMS. Dentro destas, existem depois diferentes tabelas de onde, utilizando as querys que forem neces-sárias, se obterão as views desejadas. Ao exportarmos essas views, obtemos as listas utilizadas depois nos modelos existentes em workbooks de Excel. Este processo está representado na figura 4.1.
4.2.1 Formatação dos ficheiros
O primeiro subprocesso analisado passa pela formatação dos ficheiros a utilizar. Todos os meses parte-se dos ficheiros em Excel utilizados no mês anterior, sendo posteriormente neces-sário proceder a algumas pequenas formatações, de maneira a que eles fiquem preparados para serem utilizados no mês em análise. Os 3 principais ficheiros a formatar são os ficheiros onde se processará a informação que permite o cálculo dos 3 tipos de desvios: compras, vendas e Capex.
26 Metodologia e Desenvolvimento
Figura 4.2: Modelo geral do processo de cálculo de desvios e apuramento do forecast Esses workbooks que são necessitam de ser formatados, contêm vários separadores, sendo cada um deles relativo a uma empresa pertencente ao segmento em análise. Existem também outros separadores com o objetivo de armazenaram algumas listas exportadas das bases de dados existentes.
Esta formatação é constituída por 4 passos principais, que podem ser executados em paralelo. Esses passos estão representados na figura 4.3, e, daqui para a frente, será nestes novos modelos formatados que se irá trabalhar.
4.2.2 Carregar as views de CMS
O passo seguinte é o primeiro que terá interação de um software que não é o Excel. Neste passo será necessário recorrer ao software CMS de maneira a obter os movimentos que foram
4.2 Mapeamento do Estado Atual 27
Figura 4.4: Modelo detalhado do subprocesso de carregamento das bases de CMS
executados no mês que estamos a analisar. De reforçar que a análise é feita por segmento, pelo que a view obtida deve conter dados de todo o segmento que pretendemos analisar. De seguida, a viewobtida deve ser introduzida no workbook de nome "mensal", do segmento em análise. Este workbookcontém vários separadores, tendo um separador específico para cada um dos meses do ano. Assim a lista obtida deve ser transferida para o separador correspondente ao mês em análise. Neste subprocesso, utiliza-se a base de dados existente em CMS, armazenando a lista obtida no workbook a ela destinada.
O mapeamento correspondente ao subprocesso está representado na figura 4.4.
4.2.3 Cálculo do desvio de Compras
Um dos passos mais complexos deste processo passa pelo cálculo dos desvios. Mesmo sendo semelhantes entre si, os 3 desvios calculados têm algumas particularidades, pelo que a análise à forma como são calculados é explicada separadamente.
Para obtermos o desvio de compras, é necessário recorrer ao software SAP, de onde se retirará depois 3 listas distintas: a lista com as faturas emitidas de fornecedores (compras) do segmento em análise, a lista com as dotações em aberto e a lista com as faturas compensadas com data de lançamento de anos anteriores, com o objetivo de analisar o saldo inicial de faturas de fornecedo-res. Estas três listas serão depois introduzidas no modelo existente no ficheiro Excel do cálculo de desvio de compras, onde será automaticamente apurado o desvio verificado até ao mês em análise, e apurado o forecast até ao fim do ano em análise.
Neste subprocesso existe interação com a base de dados existente no software SAP, e ainda com a workbook utilizada para análise do desvio de compras.
28 Metodologia e Desenvolvimento
Figura 4.5: Modelo detalhado do subprocesso de cálculo do desvio de compras
4.2.4 Cálculo do desvio de Vendas
Tal como no apuramento do desvio de Compras, o desvio de Vendas vai requerer a utiliza-ção do software SAP, sendo que a fase inicial passa também pela exportautiliza-ção das listas com as faturas emitidas a clientes (vendas), com as dotações em aberto e com as faturas compensadas pelos clientes relativas a anos anteriores. Também de forma análoga com o procedimento ante-rior, estas listas serão depois introduzidas no modelo em Excel desenhado para cálculo de desvio de vendas. A principal diferença entre este e o desvio de compras, é o fato de o desvio de ven-das requerer a utilização de outra lista, devido a existirem venven-das com a condição de pagamento "pronto-pagamento". Estas vendas têm de ser obtidas usando uma query própria, também da base de dados de SAP. Outra diferença prende-se com os valores recebidos referentes a adiantamentos, que também serão importantes no cálculo de desvios e principalmente no apuramento do forecast. Neste subprocesso existe interação com a base de dados existente no software SAP, e ainda com a workbook utilizada para análise do desvio de vendas.
O mapeamento deste subprocesso é apresentado na figura 4.6.
4.2.5 Cálculo do desvio de Capex
O desvio de Capex representa um subprocesso mais simples, que também requer a interação com o SAP. Este desvio apenas requer a utilização de duas listas, visto não existirem dotações de Capex. Desta forma obtém-se em SAP as faturas de fornecedor lançadas no mês em análise, bem como as faturas pagas a fornecedores (compensadas) com data de lançamento anterior ao ano em análise (saldos inicias de Capex).
Neste subprocesso existe interação com a base de dados existente no software SAP, e ainda com a workbook utilizada para análise do desvio de Capex.
4.3 Identificação de oportunidades de melhoria e definição de novo modelo 29
Figura 4.6: Modelo detalhado do subprocesso de cálculo do desvio de vendas O subprocesso é apresentado na figura 4.7
4.2.6 Importação de gastos com pessoal e impostos
A última etapa consiste na introdução dos valores relativos a gastos com pessoal e impostos no calculo dos desvios. Este processo, representado na figura 4.8, recorre ao CMS e aos ficheiros utilizados para os custos com pessoal e impostos de cada segmento, de maneira a preencher este inputpara o calculo dos desvios.
4.3
Identificação de oportunidades de melhoria e definição de novo
modelo
Agora que foi representado e definido o processo, em termos das ações que são da respon-sabilidade do utilizador, tomou-se como prioridade aumentar a qualidade do forecast realizado durante o processo e também a credibilidade dos desvios calculados e reportados. Para isso foram estudados pormenorizadamente os workbooks onde se encontram os modelos utilizados para o cálculo dos mesmos. Realço que estes modelos foram criados em 2012, pelo que os pressupostos utilizados na altura podem já não se verificar.
Prosseguiu-se então para a alteração de algumas condições neste processo. Serão explicadas de seguida as consideradas mais relevantes.
30 Metodologia e Desenvolvimento
Figura 4.8: Gastos com Pessoal e Impostos
4.3.1 Cálculo dinâmico de prazos de pagamento e recebimento
A primeira oportunidade de melhoria que se explorou passou pela análise dos prazos de pa-gamento utilizados. Anteriormente, assumiam-se os prazos acordados com os fornecedores como sendo os prazos reais, não existindo nenhuma análise à fiabilidade dos mesmos. Assim, visto já possuirmos nos workbooks as listas com as faturas compensadas, introduziu-se no ficheiro um novo separador que permite o cálculo automático os prazos médios de pagamento reais, tendo em conta os dados relativos ao último ano (figura B.5, anexo B).
Contudo, definiu-se que os prazos utilizados continuariam a ser os prazos acordados com as empresas, servindo esta nova capacidade do modelo apenas como um controlo. Caso se verifi-casse uma diferença grande entre o prazo verificado, e o prazo real médio, seria feita uma análise posterior de maneira a perceber se deveria ser alterado o prazo médio utilizado para forecast.
Outra vantagem deste método é que, ao calcular o prazo médio mensal, consegue-se perceber se existe algum tipo de sazonalidade nos prazos de pagamento, o que pode ajudar a melhorar a qualidade do forecast. Contudo, isto requereria uma análise mais pormenorizada aos dados.
4.3.2 Nova fórmula de cálculo do Forecast
Inicialmente o forecast era feito tendo em conta ou as faturas registadas em sistema de vendas e compras a crédito, aplicando o prazo de pagamento ou recebimento acordado, ou para os meses que ainda não fossem alcançados por este prazo, tendo-se em conta apenas o orçamento de cash flow. Como as faturas, quando são lançadas, têm associadas uma data de vencimento, ou seja, a data em que a fatura deverá ser paga ou recebida, achou-se por bem começar a alocar essa fatura, em termos de forecast, no mês definido nessa data de vencimento.
Com esse objetivo criaram-se dois novos separadores, sendo um eles o local para onde se exportará, todos os meses, a lista com os dados relativos a faturas em aberto do segmento em questão, ou seja, as faturas que se encontram a pagamento ou recebimento que vão gerar cash in ou cash out no futuro. O outro separador novo, representado na figura B.7, do anexo B, é onde se agrupa as faturas em aberto nesse mês, por empresa, mês de vencimento e tipologia de fatura.
A utilização dos documentos financeiros que aguardam pagamento ou recebimento apenas são aplicados consoante o prazo médio de pagamento. Assim, nos meses que já não são abrangidos
