Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
FRAMEWORK MULTICORPORATIVO DE APOIO AO
EXECUTIVO
RUDIMAR IMHOF
BLUMENAU 2012
2012/1-17
RUDIMAR IMHOF
FRAMEWORK MULTICORPORATIVO DE APOIO AO
EXECUTIVO
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação— Bacharelado.
Prof. Marcel Hugo, Mestre - Orientador
BLUMENAU 2012
2012/1-17
FRAMEWORK MULTICORPORATIVO DE APOIO AO
EXECUTIVO
Por
RUDIMAR IMHOF
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Marcel Hugo, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Roberto Heinzle, Doutor – FURB
______________________________________________________ Membro: Prof. Mauro Marcelo Mattos, Doutor – FURB
Blumenau, 06 de julho de 2012.
Dedico este trabalho a todos aqueles que depositaram confiança e que de uma forma ou de outra contribuíram para sua realização.
AGRADECIMENTOS
O presente trabalho é resultado do esforço das pessoas que em mim depositaram
conhecimento e confiança e com sua colaboração aperfeiçoaram seu resultado final, dentre as
quais, apesar de extensa lista, não posso esquecer, nem deixar de mencionar:
Minha família, por terem sempre me auxiliado em todos os momentos que necessitei.
Ao professor Adilson Vahldick, meu orientador no curso de Ciência da Computação,
por ter em mim depositado confiança e agregado conhecimentos valiosos em relação à
programação de sistemas bem como indicado, no caso deste trabalho, bibliografia relacionada
à arquitetura de frameworks.
Ao meu orientador, MSc. Marcel Hugo, por sua orientação, crítica e sugestão dos
caminhos e alternativas, sem os quais por certo a conclusão deste trabalho não seria possível.
À professora Janaina Poffo Possamai, por seus conhecimentos em estatística e
otimização e seus esforços na busca de soluções relativas a esta área, motivo, muitas vezes, de
dúvidas minhas com relação à modelagem matemática dos problemas propostos.
Ao colaborador da empresa participante do estudo de caso e aqui não mencionado
nome como opção do autor em consideração ao regime de capital não aberto adotado pela
empresa, mas que ainda assim tem suas informações apresentadas em folha de assinatura a
parte e que consta apenas na versão impressa do trabalho.
A minha namorada e também revisora, Taira Franciele Skerke, pelo seu apoio e
também auxílio na revisão ortográfica e gramatical.
Aos membros da banca por suas possíveis críticas e sugestões, as quais certamente
originaram melhorias a serem incorporadas ao resultado final deste trabalho.
A todos, meu agradecimento.
Mathematical reasoning may be regarded rather schematically as the exercise of a combination of two facilities, which we may call intuition and ingenuity.
Alan Turing
RESUMO
O presente trabalho utilizou-se da relação entre as mudanças de mercado e as decisões corporativas para investigar conceitos científicos e tecnologias envolvidas na criação de uma ferramenta de apoio ao executivo. Dentre as etapas, iniciou-se a busca por informações relativas ao ambiente empresarial, como análise de custos, indicadores e Balanced Scorecard, como forma de situar os objetivos para a ferramenta desenvolvida, e então se seguiu à busca por informações estatísticas e algoritmos relacionados à inteligência artificial que contribuíssem para o modelo de desenvolvimento da ferramenta almejada. A ferramenta apresentada foi concebida sob a forma de um framework devido à característica que esses normalmente apresentam em relação ao reuso e baixo acoplamento. Assim, menciona-se também no decorrer do trabalho conceitos relativos à injeção de dependência e herança por abstração das características, conceitos estes relacionados à implementação de frameworks. Como resultados, obteve-se um framework utilizando de forma branda os conceitos anteriormente mencionados para que fossem abrangidos em sua totalidade através das escolhas de implementação, sem prejuízo aos demais conceitos levantados no decorrer do trabalho.
Palavras-chave: Indicadores. Estatística. Framework.
ABSTRACT
This work study relationship between market changes and corporate decisions to investigate the scientific concepts and technologies involved in creating a toolkit to support the executive. Among the measures were sought information about the business environment, such as cost analysis, indicators and balanced scorecard as a way to locate targets for the developed tool, then the search was made of statistical information and algorithms related to artificial intelligence, which promote both the development model of the toolkit. The kit of tools have been constructed in the form of a framework, due to the characteristic that they generally have about the re-down and coupling. Therefore, in this work are also mentioned concepts of dependency injection by abstraction and inheritance of characteristics, concepts related to the implementation of these structures. As a result, we obtained a table with the concepts mentioned trying to play through the implementation of the application of the concept as a whole, without prejudice to other concepts related to this work.
Key-words: Indicators. Statistics. Framework.
LISTA DE FIGURAS
Figura 1 – Indicadores de desempenho .................................................................................... 21
Figura 2 – Classificação de sistemas ........................................................................................ 28
Figura 3 – Relacionamento dos sistemas pelos níveis .............................................................. 30
Figura 4 – Arquitetura comum à concepção de um framework ............................................... 34
Figura 5 – Arquitetura do framework ....................................................................................... 39
Figura 6 – Diagrama de casos de uso para o framework .......................................................... 41
Figura 7 – Descritivo das fases ................................................................................................. 42
Figura 8 – Diagrama de sequência do framework .................................................................... 43
Figura 9 – Grafo de precedência de cálculos ............................................................................ 49
Figura 10 – Diagrama de atividades para fase projeções ......................................................... 52
Figura 11 – Diagrama de atividades para fase reajustes ........................................................... 54
Figura 12 – Diagrama de atividades para fase otimizações...................................................... 55
LISTA DE QUADROS
Quadro 1 – Ponto de equilíbrio operacional ............................................................................. 20
Quadro 2 – Métodos de cálculo e atratividade dos indicadores ............................................... 23
Quadro 3 – Modelo de regressão linear simples....................................................................... 25
Quadro 4 – Modelo para problema de programação linear ...................................................... 26
Quadro 5 – Diferença entre os tipos de raciocínio ................................................................... 27
Quadro 6 - Requisitos funcionais ............................................................................................. 38
Quadro 7 - Requisitos não funcionais ...................................................................................... 38
Quadro 8 - Trecho de código para regressão linear .................................................................. 46
Quadro 9 - Trecho de código para obtenção do coeficiente de correlação ............................... 47
Quadro 10 - Exemplo de operacionalidade do framework ....................................................... 61
LISTA DE SIGLAS
BSC – Balanced Scorecard
DI – Dependency Injection
DM – Data Mining
DSS – Decision Support System
ERP – Enterprise Resource Planning
ESS - Executive Support System
IBC – Índice Benefício Custo
IoC – Inversion of Control
MIS – Management Information System
MPE – Micro Pequena Empresa
PB – Pay Back
PF – Ponto Fischer
PPL – Problema de Programação Linear
ROIA – Retorno do Investimento Adicionado
SAD – Sistema de Apoio a Decisão
SAE – Sistema de Apoio ao Executivo
SIE – Sistema de Informação Executiva
SIG – Sistema de Informação Gerencial
SPT – Sistema de Processamento de Transações
TIR – Taxa Interna de Retorno
VPL – Valor Presente Líquido
VPLa – Valor Presente Líquido Anualizado
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 PROBLEMA ..................................................................................................................... 13
1.2 JUSTIFICATIVA .............................................................................................................. 13
1.3 OBJETIVOS ...................................................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 FUNÇÕES DA EMPRESA ............................................................................................... 15
2.1.1 Funções financeiras ......................................................................................................... 16
2.1.2 Funções administrativas .................................................................................................. 16
2.1.3 Funções comerciais ......................................................................................................... 17
2.1.4 Funções técnicas.............................................................................................................. 18
2.1.5 Funções contábeis ........................................................................................................... 18
2.2 GERÊNCIA DE CUSTOS ................................................................................................ 19
2.3 ELEMENTOS PARA TOMADA DE DECISÃO EXECUTIVA – OS INDICADORES 20
2.3.1 Indicadores de desempenho ............................................................................................ 20
2.3.2 Indicadores financeiros ................................................................................................... 22
2.3.3 Balanced Scorecard ........................................................................................................ 23
2.4 ESTATÍSTICA À TOMADA DE DECISÃO ................................................................... 24
2.4.1 Regressão linear .............................................................................................................. 24
2.4.2 Programação linear.......................................................................................................... 26
2.5 RACIOCÍNIOS E SEUS TIPOS – ELEMENTOS CONCEITUAIS À TOMADA DE
DECISÃO .......................................................................................................................... 27
2.6 CLASSIFICAÇÃO DE SISTEMAS ................................................................................. 28
2.7 SUPORTE A DECISÕES ................................................................................................. 31
2.7.1 Paradigma construtivista – Metodologias multicritério .................................................. 32
2.7.2 Paradigma racionalista – Pesquisa operacional............................................................... 33
2.8 FRAMEWORK ................................................................................................................... 33
2.9 TRABALHOS CORRELATOS ........................................................................................ 35
3 DESENVOLVIMENTO .................................................................................................... 37
3.1 SISTEMA ATUAL ........................................................................................................... 37
3.2 ESPECIFICAÇÃO DOS REQUISITOS ........................................................................... 37
3.3 ARQUITETURA DO FRAMEWORK .............................................................................. 38
3.4 MODELO DE NEGÓCIOS .............................................................................................. 40
3.4.1 Diagrama de casos de uso ............................................................................................... 40
3.4.2 Fases do framework – Diagrama de sequência ............................................................... 41
3.5 UTILIZAÇÃO DOS RACIOCÍNIOS À TOMADA DE DECISÃO ................................ 43
3.6 PRODUÇÃO DO BSC ...................................................................................................... 44
3.7 IMPLEMENTAÇÃO ........................................................................................................ 44
3.7.1 Técnicas e ferramentas utilizadas.................................................................................... 44
3.7.1.1 Apache POI ................................................................................................................... 45
3.7.1.2 Waikato Environment for Knowledge Analysis - WEKA ........................................... 46
3.7.1.3 Apache Commons Math ............................................................................................... 47
3.7.2 Estrutura de funcionamento das fases ............................................................................. 48
3.7.2.1 Fase Metas .................................................................................................................... 48
3.7.2.2 Fase Projeções .............................................................................................................. 50
3.7.2.3 Fase Reajustes ............................................................................................................... 53
3.7.2.4 Fase Otimizações .......................................................................................................... 54
3.7.3 Operacionalidade da implementação .............................................................................. 56
3.8 RESULTADOS E DISCUSSÃO ...................................................................................... 61
4 CONCLUSÕES .................................................................................................................. 63
4.1 EXTENSÕES .................................................................................................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 65
12
1 INTRODUÇÃO
“ [...] o Brasil era o destino perfeito para sua primeira fábrica de automóveis fora da
Alemanha” (CORREA; MANO, 2011). Em meados de 1990, houve uma previsão de
crescimento demasiado da indústria automobilística brasileira quando a DaimlerChrysler,
fusão da alemã Daimler-Benz e a americana Chrysler, decidiu erguer uma fábrica no Brasil.
Com o mercado em crescimento e expectativas acima da média, havia perspectivas de sucesso
do empreendimento, o que não veio a se concretizar pois, a produção necessária, estimada em
70.000 unidades, atingiu somente 61.000 veículos modelo Classe A, o que gerou à Mercedez-
Benz perdas acumuladas em $ 500.000.000. Nesse caso, é possível concluir que ocorreu
algum erro no processo de tomada de decisão por parte da Mercedez-Benz, o que poderia ser
evitado se utilizadas ferramentas que permitissem ao executivo vislumbrar dados numéricos e
indicadores que apoiassem sua decisão para que esta fosse a mais realista e objetiva possível.
O apoio à decisão executiva encontra relações as mais diversas no ambiente
empresarial. Segundo Stair e Reynolds (2011, p. 401) “um dos papéis-chave dos executivos é
fornecer uma ampla visão para toda a organização. Essa visão inclui as mais importantes
linhas de produtos e serviços da organização, os tipos de negócios que ela apoia hoje e no
futuro e seus objetivos principais”. Através das funções empresarias que se constituem como
as grandes áreas relativas à empresa, é possível avaliar a relação entre dados referentes à
organização e os indicadores necessários ao seu gerenciamento.
Os indicadores mais adequados para a organização são normalmente aqueles que
melhor incrementarem o resultado de uma maneira geral. Para tanto, imprescindível também é
a análise dos custos envolvidos relacionados aos indicadores determinados, pois os cálculos
referentes aos indicadores apresentam precedentes, dentre os quais, muitos inerentes à área de
custos. Uma excelente forma de visualizar os indicadores é agrupá-los sob perspectivas ou
segmentos. Para tanto, tem-se o Balanced Scorecard, que conforme Campos (1998, p. 59)
“permite aos executivos traduzir os objetivos estratégicos de uma empresa em um conjunto
coerente de medidores de desempenho inseridos em quatro perspectivas diferentes.
Alguns elementos, que podem ser utilizados para incrementar funções relacionadas à
implementação dos indicadores, dizem respeito à estimativa de valores. A estatística, uma
grande área de estudo relacionada ao tema, tem a possibilidade de predizer valores, inclusive
com coeficiente designador da acurácia de tal estimativa. Área relacionada também à
aprendizagem dos parâmetros de máxima probabilidade em valores contínuos, assunto este,
13
inerente ao ramo da inteligência artificial e que utiliza de modelo gaussiano linear para
descrever o modelo de probabilidade que segundo Russel e Norvig (2004, p. 698) é
“minimizado pelo procedimento padrão de regressão linear”, explorado neste trabalho pela
utilização do WEKA, uma biblioteca composta por algoritmos de aprendizagem de máquina.
Uma forma de conceber tal solução é através da implementação de um framework, o
qual, diferentemente de um sistema, tem propósito mais genérico. Esta característica é
especialmente válida devido à reutilização das mesmas rotinas para diferentes situações. “Um
framework é uma coleção de artefatos de software que é utilizável por várias aplicações
diferentes. Esses artefatos são, em geral, classes, juntamente com o software exigido para
utilizá-las” (BRAUDE, 2005, p. 567). Em geral, frameworks têm também alta relação com a
camada de negócios, camada esta na qual normalmente atuam.
O presente trabalho, a partir disso, desenvolveu pacotes de classes e interfaces que
constituem um framework responsável pelas operações relacionadas a decisões de nível
estratégico empresarial. Para isso, são analisados dados recebidos pelo framework, advindos
de um ou mais sistemas. Após análise de tais dados, são retornados pelo framework
indicadores que permitam melhor compreender fatores relacionados ao universo desta
empresa, desde o momento do seu projeto de criação até sua constituição legal e operação no
mercado.
11..11 PPRROOBBLLEEMMAA
Os problemas envolvidos na construção deste trabalho relacionam-se à tomada de
decisões executivas em ambientes multicorporativos. Restringe-se a construção do trabalho às
decisões que sejam comuns a um universo distinto de empresas.
11..22 JJUUSSTTIIFFIICCAATTIIVVAA
Dentre as razões que justificam a confecção deste trabalho, estão:
a) a falta de informações para tomada de decisão no momento de concepção de
empreendimentos;
b) a falta de critério decisório para elaboração do planejamento de uma empresa;
14
c) a falta de critério decisório para adaptação do planejamento à realidade vivenciada.
11..33 OOBBJJEETTIIVVOOSS
O objetivo geral do trabalho é desenvolver um framework como sistema de apoio ao
executivo (SAE) responsável pelas operações relacionadas a decisões de nível
estratégico, fornecendo informações referentes a metas, projeções, reajustes e otimizações
para empresas de qualquer tipo.
Os objetivos específicos do trabalho a partir do desenvolvimento do referido
framework, consistem em:
a) análise do processo de tomada de decisão em diferentes empresas;
b) definição do conjunto de indicadores a ser trabalhado;
c) elaboração do modelo de projeções, reajustes e otimizações.
15
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo aborda temas a serem apresentados nas seções a seguir, tais como
funções da empresa, gerência de custo, indicadores, estatística, raciocínios e seus tipos,
classificação de sistemas, suporte a decisões, frameworks e trabalhos correlatos.
22..11 FFUUNNÇÇÕÕEESS DDAA EEMMPPRREESSAA
O estudo das funções da empresa é uma etapa importante para evidenciar-se sua
estrutura e desta forma fazer com que as estimativas e indicadores sejam condizentes com a
estrutura definida. “Fayol salienta que toda empresa apresenta seis funções: a saber: (i)
funções financeiras; (ii) funções administrativas; (iii) funções comerciais; (iv) funções
técnicas; (v) funções contábeis; (vi) funções de segurança” (CHIAVENATO, 2000, p. 83).
[...] a visão de Fayol sobre as funções está ultrapassada. Hoje, as funções recebem o nome de áreas da administração: as funções administrativas recebem o nome de área de administração geral; as funções técnicas recebem o nome de área de produção, manufatura ou operações, as funções comerciais, de área de vendas/marketing. As funções de segurança passaram para um nível mais baixo. E, finalmente, surgiu a área de recursos humanos ou gestão de pessoas. (CHIAVENATO, 2000, p. 83).
Uma maneira de organizar a divisão funcional é em relação a seus departamentos. A
opção mais comum para divisão de departamentos é a departamentalização por funções.
Ainda segundo Chiavenato (2000, p. 284), “a divisão do trabalho faz com que a organização
se departamentalize de acordo com o critério de semelhança de funções, em atividades
agrupadas e identificadas pela mesma classificação funcional, como produção, vendas e
finanças”.
Para o alcance dos objetivos estabelecidos, optou-se por utilizar a departamentalização
por funções, visto ser esta a opção escolhida pela maior parte das empresas, utilizando as
funções básicas de Fayol como referência para as funções primárias e incorporando as
funções de segurança às funções administrativas. Desta forma, alcançou-se a seguinte
proposta de divisão funcional:
a) funções financeiras;
b) funções administrativas;
16
c) funções comerciais;
d) funções técnicas;
e) funções contábeis.
Cabe aqui aprofundar um pouco cada uma das funções, para vivenciar seus recursos e
sua real necessidade a estimativa dos valores e indicadores posteriormente evidenciados.
2.1.1 Funções financeiras
As finanças constituem uma importante etapa dentro do planejamento da empresa,
visto que uma decisão bem ou mal tomada nesta etapa pode significar o crescimento ou queda
da empresa em relação ao seu mercado. Há que se considerar, então, os indicadores para
análise de investimentos e, desta forma, decidir a viabilidade financeira do negócio.
De acordo com Souza (2003, p. 73), “os critérios de rentabilidade tradicionais são
baseados nos fluxos de caixa descontados”.
Os indicadores de análise de projetos de investimentos podem ser subdivididos em dois grandes grupos: indicadores associados à rentabilidade (ganho ou criação de riqueza) do projeto e indicadores associados ao risco do projeto. Na primeira categoria estão o Valor Presente Líquido (VPL); o Valor Presente Líquido Anualizado (VPLa); a Taxa Interna de Retorno; o Índice Benefício/Custo (IBC); e o Retorno sobre Investimento Adicionado (ROIA). Na segunda categoria estão a Taxa Interna de Retorno (TIR); o Período de Recuperação do Investimento (PayBack); e o ponto de Fischer. (SOUZA; CLEMENTE, 2004, p. 70).
2.1.2 Funções administrativas
Tal como afirma Chiavenato (2000, p. 84), “as funções administrativas envolvem os
elementos da administração, isto é, as funções do administrador”, a saber:
a) prever: visualizar o futuro e traçar o programa de ação;
b) organizar: constituir o duplo organismo material e social da empresa;
c) comandar: dirigir e orientar o pessoal;
d) coordenar: ligar, unir, harmonizar todos os atos e esforços coletivos;
e) controlar: verificar se tudo ocorre de acordo com as regras estabelecidas e as
17
ordens dadas.
Assim, para a tomada de decisão nesta etapa, há que se considerar as previsões de
maneira a constituir um arranjo de informações que sirva de modelo para as direções a serem
tomadas, além da necessidade de controlar os resultados de modo a melhorar cada vez mais o
rumo do empreendimento e de comandar e coordenar as tarefas vinculadas aos recursos
humanos da empresa.
Tarefa, para Chiavenato (2000, p. 60), “é toda atividade executada por uma pessoa no
seu trabalho dentro da organização. A tarefa constitui a menor unidade possível dentro da
divisão do trabalho em uma organização”.
Cargo é o conjunto de tarefas executadas de maneira cíclica ou repetitiva. Desenhar um cargo é especificar seu conteúdo (tarefas), os métodos de executar as tarefas e as relações com os demais cargos existentes. O desenho de cargos é a maneira pela qual um cargo é criado, projetado e combinado com outros cargos para execução das tarefas. (CHIAVENATO, 2000, p. 60).
2.1.3 Funções comerciais
A área comercial relaciona-se à compra e venda de mercadorias e, desta maneira, tem
forte conexão com a gestão dos estoques da empresa. Cabe ao responsável pela área manter
um volume adequado de produtos para ofertar ao mercado, assim como estabelecer quotas de
vendas realistas para que o giro dos estoques se mantenha de forma satisfatória.
“Uma quota de vendas é uma meta de desempenho atribuída aos vendedores ou à
empresa” (SEBRAE, 2007). As quotas auxiliam o responsável pelas vendas no alcance da
meta da empresa. Diferentes tipos de quotas são utilizados no dia a dia das empresas. A maior
parte, no entanto, utiliza-se da quota baseada no volume de vendas, segundo a qual o
vendedor atinge sua cota ou não. Outras, ainda, podem utilizar a quota por lucratividade, na
qual produtos de maior lucratividade rendem maior pontuação; quotas por atividades, na qual
as atividades que implicam vendas é que somam a pontuação; e quotas mistas com a
combinação de mais de uma das estratégias citadas.
Além disso, é necessário também estabelecer a estratégia de marketing a ser adotada
pela empresa. Kotler (1998, p. 97), define o composto de Marketing como “o conjunto de
ferramentas que a empresa usa para atingir seus objetivos de marketing no mercado alvo”. O
18
composto de marketing a que se refere o autor é comumente chamado de 4Ps do marketing,
nomenclatura essa utilizada para definir os elementos fundamentais do marketing que são
praça, produto, preço e promoção.
2.1.4 Funções técnicas
As funções técnicas estão relacionadas, de maneira geral, ao setor de produção da
empresa. O setor de produção abrange toda a oferta de serviços necessários, internos ou
externos, recursos e mão de obra necessária para executá-lo. O processo de produção pode
diferenciar-se muito, a depender da estrutura de cada empresa. Em determinada empresa, o
processo de produção pode compreender a confecção de um produto, já em outra, a prestação
de serviços. Ainda assim, para ambas as situações, quanto mais a empresa produzir, maior
será seu lucro.
O estímulo adicional para que os operários ultrapassem o tempo padrão é o prêmio de produção. O tempo padrão – isto é, o tempo necessário para o operário realizar a tarefa racionalizada – constitui o nível de eficiência equivalente a 100%. A produção individual até o nível de 100% de eficiência é remunerada pelo número de peças produzidas. Acima de 100% de eficiência, a remuneração por peça é acrescida de um prêmio de produção ou incentivo salarial adicional que aumenta à medida que se eleva a eficiência do operário. (CHIAVENATO, 2000, p. 61).
2.1.5 Funções contábeis
A divisão contábil pode estabelecer os dados numéricos para avaliação do estado atual
e previsão futura do empreendimento. “O balanço patrimonial reflete a posição financeira em
determinado momento de uma empresa” (MARION; LUDÍCIBUS, 2009, p. 15). De tal modo,
representa o balanço patrimonial uma excelente ferramenta de auxilio à tomada de decisão.
19
22..22 GGEERRÊÊNNCCIIAA DDEE CCUUSSTTOOSS
“Podemos definir genericamente custos como sendo a mensuração econômica dos
recursos (produtos, serviços e direitos) adquiridos para a obtenção e a venda dos produtos e
serviços da empresa.” (PADAVEZE, 2003, p. 4). A esta mensuração atribui-se critérios de
classificação do comportamento dos custos envolvidos.
As possíveis classificações para os custos estão dispostas em duas vertentes:
a) custos diretos e indiretos;
b) custos fixos e variáveis.
Segundo Padaveze (2003, p. 53) “custos diretos e indiretos podem ser classificados em
fixos e variáveis, quando tomamos como referencial o seu comportamento em relação ao
volume de produção (ou venda)”. É importante essa classificação para que se possa adicionar
aos custos uma variável independente, para estudos prospectivos, ou seja, propósito de
previsões, e o processo de tomada de decisão para possíveis novas alternativas de execução.
Conforme mencionado por Padaveze (2003), “a abordagem de custos fixos e variáveis
tem maior relação com análise preditiva de comportamento relacionado a corporação”. De
uma forma geral, custos fixos são aqueles que não se alteram em função do volume
produzido, opondo-se aos variáveis que tem exatamente esta função. Portanto, a metodologia
de custos fixos e variáveis tem maior relação com a formação do mark-up, utilizado para
formação do preço de venda, pois o custeio utilizado pelo mark-up é do tipo por absorção e
referenciado por este método de custo.
“Calcula-se um mark-up tal que, aplicado sobre o custo unitário obtido sob um
método, obtenha-se o preço de venda desejado, que deverá cobrir todos os custos e despesas e
oferecer uma margem desejada” (PADAVEZE, 2003, p. 161). De forma sumarizada, pode-se
dizer que se obtendo todos os custos e o lucro a ser cobrado, o mark-up será a divisão do
percentual restante após subtração das despesas pelo percentual total representante do
produto. O percentual restante representa o custo industrial, ou custo da mercadoria para os
segmentos de comércio. Ou seja, o custo que a mercadoria representa ante o total do seu preço
final.
Com similar propósito está a margem de contribuição, a qual representa o lucro
variável, sendo o lucro um dos aspectos relacionados ao mark-up. Tem-se então que, em cada
unidade vendida, a empresa lucrará determinado valor. Multiplicado pelo total vendido,
teremos a margem de contribuição total do produto para a empresa.
20
Diante da margem de contribuição é possível calcular-se o ponto de equilíbrio
operacional, ou a quantidade de vendas necessária para obter-se o lucro desejado que pode ser
calculado conforme Quadro 1.
unitáriaãocontribuiçgemMartotaisfixosCustosquantidadePE __.___ ÷≡ Fonte: Padaveze (2003, p. 286).
Quadro 1 – Ponto de equilíbrio operacional
Assim, obtêm-se a quantidade necessária de produção, ao passo que multiplicando-se
os dois valores de forma percentual é possível obter-se o valor necessário de vendas.
Além destes, outros custos podem ser controlados, como os gastos gerais, referentes à
soma de todos os gastos; os gastos de fabricação, resultado da subtração da mão de obra dos
gastos gerais; o faturamento líquido, resultante do faturamento total subtraindo-se os
impostos; o lucro líquido operacional, obtido pela subtração dos impostos do lucro bruto,
entre outros, conforme melhor visualizado em Sebrae (2004).
22..33 EELLEEMMEENNTTOOSS PPAARRAA TTOOMMAADDAA DDEE DDEECCIISSÃÃOO EEXXEECCUUTTIIVVAA –– OOSS IINNDDIICCAADDOORREESS
“Resumidamente, pode-se afirmar que a gestão empresarial de uma micro e pequena
empresa é a soma da atividade “escolha dos indicadores de desempenho” mais a “reunião de
análise e melhorias desses indicadores”” (DIAS, 2007, p. 7). E sob essa perspectiva é possível
avaliar o desempenho desta empresa no mercado e implementar melhorias caso se façam
necessárias.
2.3.1 Indicadores de desempenho
“O indicador de desempenho não é como qualquer outro indicador. Ele precisa estar
orientado para a saúde operacional da empresa, ou seja, só se pode afirmar que um indicador é
de desempenho quando ele melhorar e o resultado operacional da empresa também melhorar”
(DIAS, 2007, p. 9). E, desta forma, têm os indicadores relação direta com os resultados, pelo
simples fato de advir destes.
A escolha dos indicadores é uma etapa importante ao empresário, pois ao escolher
poucos indicadores pode haver dificuldades pela falta de informações para decisão ao passo
21
que escolhê-los em demasia pode dificultar sua implementação pela grande quantidade de
informações excedentes, que não afetam o resultado e nem melhoram seu comportamento no
mercado. Por isso, conforme Dias (2007, 13), “para uma micro ou pequena empresa ter
resultado, a escolha de três a cinco indicadores de desempenho a ajudaria a atingir o seu
resultado operacional”.
Alguns dos principais indicadores de desempenho, relacionados a micro ou pequena
empresa (MPE), conforme ilustrado na Figura 1, segundo Dias (2007, 16), são:
a) grau de dependência - dividir o total de faturamento com produtos e serviços de
um determinado cliente pelo total de faturamento da mpe;
b) novos clientes - número de novos clientes que a micro ou pequena empresa
conquistou no mês;
c) gasto geral de fabricação da mpe - dividir o gasto geral de fabricação pelo
faturamento total da mpe;
d) aumento do faturamento da mpe - dividir o faturamento geral do mês atual pelo
faturamento geral do mês anterior;
e) qualidade - dividir o total de produtos ou serviços produzidos com defeitos pelo
total de produtos ou serviços produzidos pela micro e pequena empresa;
f) lucro líquido operacional da mpe - diminuir o faturamento total líquido pelos
gastos gerais da micro e pequena empresa;
g) resultado operacional da mpe - dividir o lucro líquido operacional da micro e
pequena empresa (faturamento total menos gastos gerais) pelo ativo total da mpe;
h) eficiência comercial da mpe - dividir o total de orçamentos aprovados pelos
clientes pelo total de orçamentos elaborados e enviados para os clientes da micro e
pequena empresa.
Fonte: Dias (2007, p. 22).
Figura 1 – Indicadores de desempenho
22
Nota-se entre os indicadores citados, que estes normalmente expressam a relação entre
dois ou mais totais. De forma distinta estão os indicadores financeiros, os quais são
normalmente encontrados por meio de métodos baseados nos fluxos de caixa estimados para
os investimentos.
2.3.2 Indicadores financeiros
Os indicadores para análise de investimentos classificam-se em indicadores de
rentabilidade, em que se destacam o valor presente líquido (VPL), o valor presente líquido
anualizado (VPLa), a taxa interna de retorno (TIR), o índice benefício custo (IBC), o retorno
sobre investimento adicionado (ROIA) e indicadores associados ao risco, podendo ser citados
a taxa interna de retorno (TIR), o período de recuperação do investimento (PB) e o ponto de
Fischer (PF).
A decisão de se fazer investimentos de capital é parte de um processo que envolve a geração e a avaliação das diversas alternativas que atendam às especificações técnicas dos investimentos. Após relacionadas as alternativas viáveis tecnicamente é que se analisam quais delas são atrativas financeiramente. É nessa última parte que os indicadores gerados auxiliarão o processo decisório. (SOUZA; CLEMENTE, 2004, p. 69).
O Quadro 2, fundamentado em conceitos de Souza e Clemente (2004) descreve as
formas de cálculo e a análise da atratividade do resultado obtido.
Método de cálculo do indicador Atratividade do resultado
t
n
t i
FCtVPL
)1(1 +=
=∑ VPL > 0
1)1(
)1(**
−++=n
n
i
ilVPLVPLa VPLa > 0
tosinvestimenfluxopresenteValor
beneficiosfluxopresenteValorIBC
___
___= IBC > 1
)1(100 −= n IBCROIA Ganho além da TMA em relação ao risco
23
iTIR = , quando, Zeroi
CFjVPL
j
n
j
=+
==∑
)1(
][
0
TIR > TMA
00
ICFPB t
T
t
===∑ PB < vida do investimento
TIRPF = , quando
projetososambosVPL __= Comparação das alternativas
Onde:
i = taxa
n = períodos
CFj = fluxo de investimentos
Demais representações = elementos frequentes como ∑ como representação de um
somatório e também as resultantes dos demais cálculos referenciados pelo cálculo atual.
Fonte: Adaptado de Souza e Clemente (2004).
Quadro 2 – Métodos de cálculo e atratividade dos indicadores
A composição dos indicadores citados tanto no aspecto geral como financeiro podem
servir de parâmetro para guiar o planejamento da empresa e, desta forma, aperfeiçoar o que
for passível de melhoria, impedir resultados insatisfatórios antes que aconteçam e repará-los
caso acontecerem.
2.3.3 Balanced Scorecard
Dentre as metodologias de medição normalmente adotadas, destaca-se o Balanced
Scorecard que tem como propósito a medição e controle de vários dos indicadores já
mencionados. Esta metodologia efetua a medição e a classifica sob 4 perspectivas que guiam
a visão e estratégia do negócio. São elas:
a) financeiro;
b) clientes;
c) processos internos;
d) aprendizado e crescimento.
24
O desempenho financeiro, indicador de resultado (lag indicator), é o critério definitivo do sucesso da organização. A estratégia descreve como a organização pretende promover o crescimento de valor sustentável para os acionistas; O sucesso com os clientes-alvo é o principal componente da melhora do desempenho financeiro. Além de medir através de indicadores de resultado como satisfação, retenção e crescimento o sucesso com os clientes, a perspectiva de clientes define a proposta de valor para segmentos de cliente-alvo. A escolha da proposição de valor para os clientes é o elemento central da estratégia; Os processos internos criam e cumprem a proposição para os clientes. O desempenho dos processos internos é um indicador de tendência de melhorias que terão impacto junto aos clientes e nos resultados financeiros; Ativos intangíveis são a fonte definitiva de criação de valor sustentável. Os objetivos de aprendizado e crescimento descrevem como pessoas, tecnologia e clima organizacional se conjugam para sustentar a estratégia. As melhorias nos resultados de aprendizado e crescimento são os indicadores de tendência para os processos internos, clientes e desempenho financeiro. (KAPLAN; NORTON, 2004, p. 7).
Estas perspectivas agrupam os indicadores que fundamentarão o último estágio do
processo decisório, a tomada de decisão.
22..44 EESSTTAATTÍÍSSTTIICCAA ÀÀ TTOOMMAADDAA DDEE DDEECCIISSÃÃOO
Dentre os aspectos estatísticos que podem ser utilizados para tomada de decisão,
encontram-se a regressão linear e a programação linear.
2.4.1 Regressão linear
Conforme Azevedo (1997, p. 10) um modelo de regressão linear se caracteriza por
apresentar formalmente as duas seguintes propriedades de uma relação estatística:
a) da população de onde retiram-se as observações, tem-se uma distribuição de
probabilidade de Y, para cada nível de X;
b) as médias dessas distribuições de probabilidade variam de alguma forma
sistemática com X.
Os modelos de regressão linear mais difundidos são a regressão linear simples e
regressão linear múltipla. Considerando o aspecto da estimativa com orientação à
implementação da rotina, pode-se afirmar de uma forma geral que tanto a regressão simples
como as demais produzirão a estimativa apenas para uma das propriedades do conjunto de
propriedades do elemento. A diferença está que a regressão linear simples considera apenas
25
uma propriedade para estimar o resultado, normalmente expressa através do par ordenado,
período + propriedade1, estimando-se um modelo que representará os próximos valores da
propriedade1, ao passo que os demais modelos de regressão consideram um par de elementos,
expresso, como, por exemplo, período + propriedade1 + propriedade2 + propriedadeN,
estimando-se um modelo que representará os próximos valores apenas da propriedade1. Ou
seja, apesar de considerar mais elementos, o resultado será para apenas um valor em ambos os
casos, mas a análise levará em consideração também as demais propriedades no caso da
regressão linear múltipla.
O modelo de regressão linear simples é expresso conforme o Quadro 3.
iii XY εββ ++= 10
Onde:
iY : variável resposta (dependente);
iX : uma constante conhecida (não é variável aleatória);
10 __ ββ e : são parâmetros;
iε : é um erro aleatório
Fonte: Azevedo (1997, p. 13).
Quadro 3 – Modelo de regressão linear simples
Um dos métodos mais comuns para otimização de problemas envolvendo regressão
linear é o método dos mínimos quadrados, o qual, conforme Azevedo (1997, p. 13) “considera
a soma dos quadrados dos desvios de Y com relação ao seu valor esperado”, ou seja, procura
minimizar o erro através de sua distribuição pelo conjunto de elementos.
Um importante aspecto a se considerar para o modelo é atestar-se a sua acurácia. Uma
forma comum de atestar é através do emprego do coeficiente de correlação de Pearson que
tem, de uma forma geral, como propriedade mensurar em uma escala de -1 a 1 a relação
entres as variáveis do modelo. Caso o coeficiente obtido se enquadre abaixo de 0, diz-se que
as variáveis são inversamente proporcionais, caso se enquadre em valores próximos de 0, a
relação é fraca, para valores mais próximos de 1, diz-se que ocorre uma relação de moderada
a forte.
26
2.4.2 Programação linear
“É um problema de otimização que consiste em achar os valores das variáveis x1, x2,
...xn que minimizam (ou maximizam) a função objetivo” (LINS, 2006, p. 8). Os modelos de
programação linear têm por objetivo sua maximização, minimização ou a busca das variáveis
que atendam a um objetivo específico. Alguns elementos são necessários aos problemas de
programação linear (PPL).
Variáveis de decisão: são as variáveis consideradas relevantes ao problema, passíveis de quantificação e disponíveis; Função objetivo: é uma função, produto de coeficientes pelas variáveis de decisão, que se deseja otimizar no problema, como a maximização do lucro ou minimização dos custos; Restrições: correspondem aos elementos restritivos que todo problema possui, como limitações de recursos produtivos ou capital para investimento. (LINS, 2006, p. 7).
Os elementos citados têm relevância maior na formulação do problema normalmente
advindo de alguma situação em particular como, por exemplo, a maximização de lucro de
determinado negócio. Um modelo de PPL, pode ser visualizado no Quadro 4.
Restrições:
11111 ... bxaxa nn ≥++
bmxaxa nmnm ≥++ ...11
Sujeito à: jxa j ∀≥ 0:
Função objetivo:
Min nnxcxcxc +++ ...2211
Fonte: Lins (2006, p. 11).
Quadro 4 – Modelo para problema de programação linear
Primeiro o conjunto de restrições limita o problema ao vetor de restrições apresentado,
após, a função objetivo apresenta o modelo de função para minimização da solução.
A solução do problema pode ser encontrada pela resolução do tableau simplex.
Conforme Lins (2006, p. 91) “o tableau simplex é uma forma de esquematizar os PPL’s. O
quadro apresenta os coeficientes das variáveis em colunas e as restrições e função objetivo em
linhas”. A solução é encontrada pela iteração do algoritmo simplex sob um poliedro que
representa o tableau e que se refina incorporando variáveis de folga ao problema até
encontrar-se a solução na qual todos os elementos de Z são maiores que zero e que representa
a solução ótima do problema.
27
22..55 RRAACCIIOOCCÍÍNNIIOOSS EE SSEEUUSS TTIIPPOOSS –– EELLEEMMEENNTTOOSS CCOONNCCEEIITTUUAAIISS ÀÀ TTOOMMAADDAA DDEE DDEECCIISSÃÃOO
Conforme Russel e Norvig (2004, p. 567) “o príncipio básico da teoria da decisão é a
maximização da utilidade esperada”. Para tanto, há que se considerar os tipos de raciocínio,
elementos imprescindíveis a tomada de decisão. Os tipos de inferências mais comuns para os
raciocínios são a dedução e a indução. Além desses, tem-se estudado mais recentemente um
novo tipo de inferência, descrita como abdução.
De forma geral, a dedução concebe suas inferências em uma expressão do tipo, a parte
está para o todo, então as propriedades destas partes também. Já na inferência por indução, o
todo está para as partes, então as propriedades deste todo também. Esses dois tipos mais
comuns de raciocínio procuram suas razões a partir do relacionamento prévio dos elementos
evidenciados. Já a abdução, de forma geral, procura a relação dos objetos a partir de suas
propriedades. Segundo Heinzle (2011, p. 138) “essa forma de raciocinar é caracterizada por
estudar fatos de interesse e então buscar a invenção de uma teoria capaz de explicá-los”.
Assim, descrevendo de maneira sucinta, a abdução parece ser a única forma de
raciocínio a criar novo conhecimento, pois estuda as relações a partir das propriedades e não
as propriedades a partir das relações.
Destaca-se, no Quadro 5, um exemplo de Pierce, criador da abdução em sua teoria do
raciocínio, a qual demonstra de maneira coerente a diferença entre os tipos de raciocínio
citados.
Dedução Regra: Todos os feijões deste pacote são brancos Caso: Estes feijões provêm deste pacote Resultado: Estes feijões são brancos Indução Caso: Estes feijões provêm deste pacote Resultado: Estes feijões são brancos Regra: Todos os feijões deste pacote são brancos Abdução Regra: Todos os feijões deste pacote são brancos Resultado: Estes feijões são brancos Caso: Estes feijões provêm deste pacote
Fonte: Pierce (1972 apud HEINZLE, 2011, p.140).
Quadro 5 – Diferença entre os tipos de raciocínio
28
22..66 CCLLAASSSSIIFFIICCAAÇÇÃÃOO DDEE SSIISSTTEEMMAASS
“Os tipos de sistemas de informação mais comuns nas organizações de negócios são
aqueles projetados para o comércio eletrônico e móvel, processamento de transações,
informações gerenciais e apoio a decisão” (STAIR; REYNOLDS, 2011, p.14). A distribuição
da maior parte destes sistemas situa-se em torno da estrutura organizacional e é a maneira
como normalmente são classificados também. Assim, de forma geral, temos sistemas de
informações relacionados à operação, sistemas para o nível tático - alimentados por dados do
nível operacional, e também sistemas para o nível estratégico - alimentados por dados do
nível tático, cada nível com uma ou mais classificações de sistemas e cada classificação com
uma ou mais nomenclaturas envolvidas.
Na Figura 2, pode-se observar algumas classificações de sistemas conforme seu nível.
Fonte: Adaptado de Stair e Reynolds (2011).
Figura 2 – Classificação de sistemas
Nível Estratégico
Nível Tático
Nível Operacional
Sistemas de apoio ao executivo
Sistemas de apoio à decisão
Sistemas de informação gerencial
Sistema de processamento de transações
29
Tal como se observa na Figura 2, no nível operacional, situam-se os sistemas de
processamento de transações (SPT), dentre esses, os mais diversos.
As atividade de processamento incluem coletar dados, editá-los, corrigi-los, manipulá-los, armazená-los e produzir documentos. O resultado de processar transações de negócio é que os registros da organização são atualizados para refletir o estado da operação na época da última transação processada. (STAIR; REYNOLDS, 2011, p.331).
Como exemplo, pode-se mencionar os Enterprise Resource Planning (ERP), os quais
incorporam a maior parte dos sistemas elementares deste nível e alimentam os sistemas de
nível tático.
No nível tático estão os sistemas de informação gerencial (SIG), também conhecidos
como Management Information System (MIS), além dos Sistemas de Apoio à Decisão (SAD),
também chamados de Decision Support System (DSS). “O propósito principal do MIS é
auxiliar uma organização a alcançar seus objetivos, fornecendo aos gerentes uma perspectiva
detalhada das operações regulares da organização para que eles possam controlar, organizar e
planejar de forma mais eficaz” (STAIR; REYNOLDS, 2011, p.371). Em um DSS conforme
Stair e Reynolds (2011, p.388) “o foco é a eficácia da tomada de decisão, quando enfrentado
com problemas de negócios não estruturados ou semiestruturados”. A diferença principal
entre um SIG e um SAD ou um MIS e um DSS diz respeito a suas formas de interação.
Enquanto um SIG fornece as informações baseadas em dados pré-dispostos dos níveis
operacionais e pós-processados pelo sistema, um SAD as fornece baseadas em inferências
resultantes da aquisição de conhecimento prévio informado pelo usuário, interpretados junto
ao nível operacional e igualmente processadas pelo sistema.
Já no nível estratégico, situam-se os sistemas de informação executiva (SIE), os quais
têm propósito similar aos SIG, representadas por indicadores, mas neste caso relacionadas ao
nível estratégico e normalmente alimentadas pelo nível tático. Alguns autores utilizam a
nomenclatura sistemas de apoio ao executivo ou executive support system (ESS) para referir-
se ao mesmo tipo de sistema. O termo parece um pouco equivocado, pois baseando-se
também na definição de nível tático, como SIG e SAD, que são sistemas distintos, não devem
dizer respeito a mesma classificação e também porque as decisões deste nível normalmente
não são baseadas em inferências, as quais seriam o caso de apoio à decisão, pois os dados
advindos ou foram processados pelo SIG ou já foram inferidos de um SAD, ambos do nível
tático e portanto não havendo razoabilidade em inferir-se uma informação já predisposta.
Além disso, um SIG trabalha com atributos contínuos ao passo que um SAD trabalha com
30
atributos discretos. Isto porque conforme Stair e Reynolds (2011, p. 392) “um DSS enfatiza
decisões reais e estilos de tomada de decisão”, ao passo que um “MIS geralmente enfatiza
somente as informações”.
Apesar dos conceitos imprecisos, uma comparação entre sistemas de apoio à decisão,
SAD ou DSS, e sistemas de apoio ao executivo, SAE ou ESS, torna a dúvida esclarecida por
Stair e Reynolds (2011).
Um ESS é um tipo especial de DSS e, como um DSS, é projetado para dar suporte às tomadas de decisões de alto nível na organização. Os dois sistemas são, no entanto, diferentes de forma importante. Os DSS fornecem uma variedade de ferramentas de modelagem e análise para capacitar os usuários a analisar completamente os problemas, isto é, eles permitem aos usuários responder as questões. Os ESS apresentam informações estruturadas sobre aspectos da organização que os executivos consideram importantes. (STAIR; REYNOLDS, 2011, p. 400).
O raciocínio é ilustrado pela Figura 3.
Fonte: Adaptado de Stair e Reynolds (2011).
Figura 3 – Relacionamento dos sistemas pelos níveis
A Figura 3 relaciona alguns dos argumentos anteriormente levantados. Como pode ser
visto no relacionamento em destaque na figura, apesar de não razoável argumento para
sustentar um SAE como SIE, por um SIE normalmente não tratar de inferências, também não
31
é razoável tratá-lo como apoio, pois os únicos caminhos possíveis para premissas seriam
advirem do SAD, com decisões já inferidas, e assim gerando incoerente reprocesso, ou da
base, gerando contratempos desnecessários ao executivo, por necessidade de indicar as
premissas. Assim, os dois termos podem ser usados para designar a mesma classificação, pois,
as inferências normalmente adotadas no apoio não se fazem presentes e também não seria
sensato à divisão por classificação de sistemas com mesma função, que neste caso relacionado
ao apoio executivo. Assim convenciona-se com qualquer uma das duas formas, seja sistema
de apoio ao executivo, seja sistema de informações executivas, pois ainda que não
relacionadas às inferências, tratam da mesma função.
22..77 SSUUPPOORRTTEE AA DDEECCIISSÕÕEESS
O suporte a decisões estuda maneiras de verificar a viabilidade de determinada escolha
dado um contexto previamente estabelecido. Compreender, também, técnicas que permitam
mensurar dados de maneira a constituir regras que comportem decidir, entre as escolhas
elencadas, qual delas atende de maneira mais satisfatória à proposta instituída.
Alguns autores decompõem estas técnicas em paradigmas científicos. “As
metodologias voltadas ao apoio à decisão adotam o construtivismo como paradigma
científico, ao contrário das metodologias voltadas a tomada de decisão, que seguem o
paradigma racionalista” (ENSSLIN; MONTIBELLER NETO; NORONHA, 2001, p. 35).
Esses mesmos autores ainda atribuem as metodologias multicritério como implementações do
apoio à decisão e pesquisa operacional como implementações à tomada de decisão.
É possível afirmar, por fim, que o paradigma racionalista ou metodologias muticritério
é de grande validade para a fase de definição de metas, visto seu processamento basear-se
essencialmente nos critérios e seus valores. Isto é, não se utiliza de resultados anteriores,
indisponíveis nessa fase, já que as metas representam valores a serem alcançados
independente de resultados passados, ao passo que o paradigma construtivista ou baseado na
pesquisa operacional pode utilizar-se de resultados anteriores, sendo assim recomendável para
efetuarem-se projeções de resultados.
32
2.7.1 Paradigma construtivista – Metodologias multicritério
Segundo Ensslin, Montibeller Neto e Noronha (2001, p. 35), “o paradigma
construtivista é o mais apropriado em fornecer apoio aos processos decisórios que envolvem
situações complexas”. Conforme mencionado anteriormente, existe uma diferença entre o
processo de apoio à decisão e o processo de tomada de decisão.
Os métodos para tomada de decisão multicritério, em geral, fazem uso de um conjunto
de soluções possíveis e então são definidos os critérios necessários para obtenção de soluções
do problema. Dessa forma, é possível avaliar o grau de satisfação em relação a cada
alternativa. A decisão multicritério engloba metodologias que podem ser aplicados à análise
de situações complexas.
Situações complexas são aquelas que envolvem múltiplos atores, cada um deles com seu sistema de valores, múltiplos objetivos com conflitos de interesses, diferentes níveis de poder entre os atores e necessidade de negociação entre eles, além de uma enorme quantidade de informações qualitativas e quantitativas. (ENSSLIN; MONTIBELLER NETO; NORONHA, 2001, p. 35).
Conforme Gomes, Araya e Carignano (2004, p. 5), dentre os métodos mais divulgados
para tomada de decisão multicritério em cenários complexos, têm-se: “(i) métodos da escola
americana e (ii) métodos da escola francesa ou européia”.
Os métodos da escola americana descendem de deu método mais difundido, no qual
são baseados os demais, sendo denominado Analytical Hierarchy Process (AHP).
Basicamente, o AHP, principal método da escola americana, fundamenta sua decisão
atribuindo-se pelo usuário graus de importância para os atributos, além de preferência do
valor para a lista de valores de cada atributo. Desta forma, os responsáveis indicam o que é
importante e por meio disso o método se refina para atendê-lo ao indicar quais dentre as
seleções têm maior aproximação em relação aos aspectos requeridos.
Os métodos da escola francesa descendem igualmente do seu método mais difundindo
e que leva o nome de Electre - ELimination Et Choix Traduisant la REalité. “Os métodos
Electre fazem parte dos denominados Métodos de Superação, pois eles têm, como conceitos
teórico central, as relações de superação” (GOMES; ARAYA; CARIGNANO, 2004, p. 97). O
funcionamento diferencia-se por não estabelecer fila total de prioridades e sim relações de
importância. Assim, é possível indicar que A é prioritário a B, que A é prioritário a C e que C
33
é também prioritário a B. Ou seja, a ordem de importância é constituída de relações
independentes, dando maior flexibilidade ao resultado.
2.7.2 Paradigma racionalista – Pesquisa operacional
A pesquisa operacional trata de problemas de otimização em geral. Boa parte de suas
soluções provém de soluções baseadas no algoritmo simplex, muito utilizado para solucionar
problemas de programação linear, como são conhecidos a maior parte dos problemas de
pesquisa operacional.
Estes problemas relacionados à programação linear tratam de questões em que exista
uma função objetivo e restrições a essa função. Assim, o problema pode ser expresso com a
variável numérica a ser atingida em função de uma série de recursos e uma série de limitações
que impedem ou de alguma maneira restringem determinados recursos conforme visto nas
seções anteriores.
22..88 FFRRAAMMEEWWOORRKK
“Um framework pode comportar-se como uma aplicação genérica que personalizamos
inserindo nossas próprias partes. Os artefatos do framework estão em geral na forma pronta
para usar e são códigos nativos” (BRAUDE, 2005, p. 567). Um framework deve ser
desenvolvido utilizando-se a arquitetura mais abstrata possível, permitindo, assim, a
flexibilidade necessária à estrutura da aplicação. A camada de negócios de um framework de
suporte a decisões está vinculada ao controle que será elencado. Segundo Braude (2005, p.
569), uma “possível utilização de um framework se dá por ele conter o controle”. Controle
este relativo às regras de negócio mencionadas.
“Ao construir frameworks, buscamos generalizações (abstrações) das classes que
selecionamos até o momento” (BRAUDE, 2005, p. 570). Normalmente um framework é
concebido partindo-se de uma lista de softwares previamente construídos. Assim,
generalizando-se algumas de suas partes, é possível chegar a um framework que provenha
funcionalidades para uma diversidade de aplicações.
34
Muitas são as definições sobre as características necessárias a concepção de um
framework. Algumas delas dizem respeito a sua forma de composição ser constituída de
Frozen Spots e Hot Spots que seriam respectivamente partes fixas e partes flexíveis. Outras
dizem respeito à presença da inversão de controle (IoC), característica esta bastante comum
em frameworks, dentre estes destacam-se os containers leves, bastante difundidos e aceitos.
Segundo Fowler (2004) “dizer que containers leves são especiais porque usam inversão de
controle é como dizer que meu carro é especial porque tem rodas.” O framework inverte o
controle de algum aspecto sob guarda de aquisição de informação pela aplicação. Ou seja,
dependência de injeção dos dados relativos ao controle. Assim, outra característica presente
em frameworks diz respeito à injeção de dependência ou dependency injection (DI). “Ao
aplicarmos IoC, objetos são dados as suas dependências em tempo de criação por alguma
entidade externa que coordena cada objeto do sistema. Quer dizer dependências são injetadas
nos objetos” (WALLS; BREIDENBACH, 2006, p.16).
Portanto, resumidamente, um framework deve trabalhar com abstrações das partes
fixas e normalmente prover interfaces para implementação pela aplicação das características
relativas à injeção das dependências necessárias a inversão de controle do framework e
concebidas pela aplicação por meio de herança das características do framework.
A Figura 4 ilustra uma arquitetura genérica com características de um framework.
Fonte: Adaptado de Walls e Breidenbach (2006).
Figura 4 – Arquitetura comum à concepção de um framework
35
A aplicação implementa a interface do framework em questão em uma classe de
objeto, o qual foi criado pela aplicação e injetado no núcleo do framework. Este núcleo é
representado por uma classe abstrata da qual a aplicação realiza herança das características e
recebe resultados dos processamentos advindos por referência dos objetos injetados.
22..99 TTRRAABBAALLHHOOSS CCOORRRREELLAATTOOSS
Dentre os trabalhos correlatos encontrados, pode-se listar Heckler (2009), com sua
ferramenta de apoio a gerência de configuração, Silva (2010), com seu arcabouço para tomada
de decisão colaborativa, e Casotti (1993), descrevendo aspectos relativos à programação
multiobjetivo.
Heckler (2009) procura implementar em seu trabalho de graduação um software para
gerência baseado em qualidade seguindo características relativas aos padrões de qualidade
para desenvolvimento de software mencionados em modelos como CMMI e MPS.BR.
Heckler (2009) o nomeia como Redmine GCO, uma ferramenta de apoio para a Gerência de
Configuração. Como resultados, Heckler (2009) cita um ganho de qualidade vinculado à
otimização dos processos de desenvolvimento resultante do software implementado.
Silva (2010), por sua vez, desenvolveu um arcabouço de tomada de decisão
colaborativa para o gerenciamento da evolução de empresas virtuais. Em seu arcabouço, Silva
(2010) descreve a criação de um protocolo de tomada de decisão. Segundo Silva (2010), é
este o responsável pelo processamento relativo às decisões e é baseado em um modelo
adaptado a sua implementação que é nomeado como Engineering Change Management
(ECM). Seu arcabouço ainda avalia o grau de confiança entre os parceiros, justamente por se
tratar de um software colaborativo. Como resultados, Silva (2010) constata que a utilização de
ferramentas de apoio colaborativo como a sua são capazes de melhorar a qualidade de
decisões tomadas por coordenar melhor o processo e permitir um melhor embasamento para a
tomada de decisão.
Casotti (1993) apresenta modelagem de problemas da vida real resolvidos por meio de
técnicas as mais variadas combinadas em um software de apoio a decisão. Uma abordagem
utilizada por Casotti (1993) é a metodologia multicritério por meio de modelagem
matemática.
36
Nos trabalhos pesquisados, foram encontradas informações relevantes tanto a respeito
da construção de sistema de suporte à decisão como em Heckler (2009) e Silva (2010), quanto
informações a respeito das técnicas relacionadas ao apoio à decisão, como em Casotti (1993),
que servirão também de embasamento para construção da ferramenta a que se propõe esse
trabalho.
37
3 DESENVOLVIMENTO
Neste capítulo, serão abordados temas relativos ao desenvolvimento do framework. Na
seção 3.1, será apresentado o sistema que fará uso do framework; na seção 3.2, podem ser
visualizados os requisitos do framework; posteriormente, na seção 3.3, será apresentado o
modelo de arquitetura do framework; na seção 3.4, pode ser visto o modelo de negócios
utilizado pela ferramenta; na seção 3.5, a utilização dos raciocínios à concepção do
framework, na seção 3.6, tem-se a produção do modelo para o balanced scorecard (BSC) e na
seção seguinte, 3.7, será demonstrada a implementação do framework através da sua
constituição por fases. Por fim, na seção 3.8, serão mencionados os resultados da ferramenta
produzida.
33..11 SSIISSTTEEMMAA AATTUUAALL
O framework deve ser multicorporativo e, desta forma, necessita ser construído de
forma a suportar diferentes aplicações. Por essa razão, qualquer sistema pode fazer uso do
framework desde que implementadas suas interfaces de referência. Os estudos de caso são
procedidos junto à implementação.
33..22 EESSPPEECCIIFFIICCAAÇÇÃÃOO DDOOSS RREEQQUUIISSIITTOOSS
O Quadro 6 lista os requisitos funcionais (RF) previstos para o framework e sua
rastreabilidade, ou seja, vinculação com o(s) caso(s) de uso associado(s).
Requisitos Funcionais Caso de Uso
RF01: O framework deverá fornecer interfaces com implementações de
referência para entrada de dados UC01
RF02: O framework deverá retornar ao sistema lista de metas baseadas
nas margens UC02
RF03: O framework deverá retornar ao sistema lista de projeções
baseadas nos totalizadores informados; UC03
38
RF04: O framework deverá retornar ao sistema reajustes baseados nos
totais apresentados UC04
RF05: O framework deverá retornar ao sistema otimizações baseadas nas
informações do processo de aquisição/produção UC05
Quadro 6 - Requisitos funcionais
O Quadro 7 lista os requisitos não funcionais (RNF) previstos para o sistema.
Requisitos Não Funcionais
RNF01: O framework deverá utilizar UML como linguagem de modelagem
RNF02: O framework deverá utilizar Java como linguagem de programação
RNF03: O framework deverá utilizar Eclipse como IDE para desenvolvimento em Java
RNF04: O framework deverá utilizar bibliotecas como Weka, Apache POI e Apache
Commons Math para implementação das rotinas relacionadas às projeções, cálculos
financeiros e otimizações.
Quadro 7 - Requisitos não funcionais
33..33 AARRQQUUIITTEETTUURRAA DDOO FFRRAAMMEEWWOORRKK
Na Figura 5, pode ser visualizado o modelo de arquitetura. Nele, pode-se observar
como será procedido o fluxo de informações relativo ao funcionamento do framework.
39
Figura 5 – Arquitetura do framework
40
Como se pode constatar na Figura 5, os artefatos abstratos referentes à implementação
do framework são destacadas pela boundary box frozen spots, ao passo que a implementação
destes arfetatos, suas dependências e heranças são procedidas pela aplicação na boundary box
hot spots. A injeção das dependências é demonstrada pela utilização de um único injetor,
apenas para visualização, mas na implementação encontra-se um injetor para cada
dependência. O mesmo ocorre com as instâncias pelo framework de objetos da aplicação, em
que existe um construtor de objetos filho para cada pai injetado pela aplicação. O framework
não tem capacidade para criar um objeto, pois desconhece a característica do objeto injetado,
mas conhece sua interface, por isso, pode solicitar a aplicação por um método de interface a
criação de um novo objeto filho, a partir da referência do objeto pai já injetado. É assim que o
framework constrói novos objetos mesmo desconhecendo suas características.
33..44 MMOODDEELLOO DDEE NNEEGGÓÓCCIIOOSS
Esta seção apresenta o diagrama de casos de uso como auxílio ao processo inicial de
modelagem do framework.
3.4.1 Diagrama de casos de uso
Nesta subseção, apresenta-se a modelagem do diagrama de casos de uso, o qual cria a
perspectiva inicial ao desenvolvimento do framework. O detalhamento dos casos de uso, bem
como a descrição de seus cenários, são apresentados a partir do Apêndice A. A Figura 6
apresenta o diagrama de casos de uso para o framework.
41
Figura 6 – Diagrama de casos de uso para o framework
3.4.2 Fases do framework – Diagrama de sequência
Convencionou-se utilizar para a implementação do framework um modelo de fases
onde cada uma das fases descrevesse o processamento de rotinas necessárias à conclusão dos
casos de uso anteriormente relacionados. Para modelagem inicial, um simples descritivo das
fases foi concebido como demonstrado na Figura 7.
42
Figura 7 – Descritivo das fases
A Figura 7 descreve as entradas e saídas referentes a cada uma das fases. Após
visualização da descrição dos dados, foi possível a concepção do diagrama de sequência do
framework, como apresentado na Figura 8.
43
Figura 8 – Diagrama de sequência do framework
No diagrama de sequências apresentado na Figura 8, o fluxo de execução consiste de
injeção das dependências, destacado em azul, chamadas aos métodos relativos às estimativas
e solução de cada retorno por meio de objetos filhos a partir da referência do objeto pai
injetado.
33..55 UUTTIILLIIZZAAÇÇÃÃOO DDOOSS RRAACCIIOOCCÍÍNNIIOOSS ÀÀ TTOOMMAADDAA DDEE DDEECCIISSÃÃOO
Dos raciocínios estudados à tomada de decisão, destaca-se para a implementação dos
conceitos neste framework a dedução e a indução, as quais tiveram seus conceitos utilizados
pelo grafo de precedência de cálculos. Isto porque, como os elementos finais caracterizam
suas heranças em relação à raiz, deduz-se que as mudanças na raiz serão em igual proporção
nestes elementos, caso das metas. E no processo inverso, caso dos reajustes, tem-se elementos
44
finais já especializados caracterizando a generalização na raiz, ou seja, se os elementos finais,
neste caso, os totais, apresentam tais valores, induz-se que as margens devem ser corrigidas na
mesma proporção.
33..66 PPRROODDUUÇÇÃÃOO DDOO BBSSCC
A produção de um balanced scorecard está relacionada à concepção dos valores a cada
uma das perspectivas evidenciadas pela metodologia dentre os quais estão, como já citados na
fundamentação, a perspectiva financeira, de clientes, processos internos, aprendizado e
crescimento. O framework implementa a produção dos indicadores, deixando para aplicação a
opção por exibi-los da maneira que melhor lhe convier.
33..77 IIMMPPLLEEMMEENNTTAAÇÇÃÃOO
Com os conceitos estudados, técnicas levantadas e modelagens procedidas, dá-se a
construção do framework que forneça as listas mencionadas conforme requisições do sistema.
3.7.1 Técnicas e ferramentas utilizadas
As seguintes tecnologias foram utilizadas para a construção do framework:
a) linguagem Java: linguagem de alto nível, alta portabilidade e que permite
integração com weka, apache commons math e apache POI, ambas de extrema
importância para construção do trabalho;
b) reflection: capacidade inerente à linguagem de instrospeccionar os seus elementos,
no caso, as classes de objeto;
c) dependency injection: construção da injeção de dependência pela própria estrutura
do framework
d) IDE eclipse: IDE bastante utilizada e com vários recursos além de uma gama de
linguagens suportadas;
45
e) biblioteca WEKA: biblioteca com vários recursos para área de inteligência
artificial;
f) biblioteca apache commons math: biblioteca com vários recursos para área
estatística, otimização, álgebra linear, números complexos, algoritmos de
inteligência artificial, dentre outros;
g) biblioteca apache POI: biblioteca para manipulação de formatos com funções
adicionais aos cálculos financeiros;
h) estilo arquitetural em camadas: estilo bastante conhecido e difundido devido à
flexibilidade na construção e baixo acoplamento fornecido.
As seções seguintes detalham algumas das tecnologias indispensáveis à constituição do
framework.
3.7.1.1 Apache POI
A apache POI é uma biblioteca para manipulação de formatos de documentos o qual
inclui também rotinas para cálculos financeiros. A maior parte das rotinas relacionadas a
finanças encontra-se nos pacotes, org.apache.poi.ss.formula.functions.FinanceLib e
org.apache.poi.ss.formula.functions.Irr .
Nos pacotes citados, podem ser encontradas a maior parte das rotinas comuns em
cálculos financeiros, especialmente no que tange às rotinas também encontradas em
calculadoras financeiras.
Dentre os métodos mais comuns encontrados nos pacotes FinanceLib e Irr, vale
destacar:
a) npv(double r, double[] cfs) – para calcular o valor presente;
b) pmt(double r, double n, double p, double f, boolean t) – para
pagamento periódicos;
c) irr(double[] income) – para taxa interna.
46
3.7.1.2 Waikato Environment for Knowledge Analysis - WEKA
Weka é uma biblioteca de uso para utilização de implementações relacionadas a
rotinas de inteligência artificial, e mais especificamente na área de Data Mining (DM), é
distribuída sob licença pública e tem seus fontes abertos para colaborações.
Esta biblioteca tem, entre suas rotinas, implementações para classificação de dados,
clusterização e regras de associação. Entre estes grupos está a regressão linear classificada no
pacote weka.classifiers.functions.LinearRegression do Weka.
Para uso da implementação da LinearRegression, faz-se necessário uso do arquivo
ARFF do Weka. O arquivo ARFF é um simples arquivo que descreve uma relação, seus
atributos e valores separados por vírgula.
Os elementos necessários ao arquivo ARFF são os seguintes, sucedidos pelos seus
dados:
a) @RELATION – descreve a relação, como uma tabela em BD uma relação fornece
uma descrição para a estrutura;
b) @ATTRIBUTE – descreve os atributos sucedidos por seu tipo, no caso da
regressão linear sempre do tipo REAL, pois a regressão linear não comporta
atributos discretos;
c) @DATA – descreve os dados sucedidos pelos seus valores separados por vírgula,
uma linha representa de forma geral uma tupla, para fator comparação.
Pode-se mencionar o principal método para regressão linear no Weka como sendo
buildClassifier(instances) chamado pela instanciação de um objeto do tipo
LinearRegression . O uso do buildClassifier consiste em receber o conjunto de dados
através do arquivo carregado no Loader do weka.
Instances instances = arffLoader.getDataSet();
LinearRegression linearRegression = new LinearRegre ssion();
linearRegression.buildClassifier(instances);
Quadro 8 - Trecho de código para regressão linear
Com relação ao coeficiente de Pearson, o valor da correlação pode ser obtido através
do método evaluation.correlationCoefficient() , o qual é advindo de um objeto de
classe Evaluation , como demonstrado no Quadro 9.
47
Evaluation evaluation = new Evaluation(instances);
evaluation.evaluateModel(linearRegression, instance s);
Double coeficienteCorrelacao = evaluation.correlati onCoefficient();
Quadro 9 - Trecho de código para obtenção do coeficiente de correlação
3.7.1.3 Apache Commons Math
Apache commons math é uma biblioteca para utilização de rotinas relacionadas à
matemática e inteligência artificial. Apresenta rotinas vinculadas à análise numérica, números
complexos, algoritmos genéticos, otimização, caso em particular do simplex, entre outros.
A utilização da biblioteca dá-se de maneira similar à modelagem do problema PL, pois
a biblioteca utiliza os mesmos termos e elementos para definição do problema.
As rotinas da classe de objetos simplex ficam no pacote
org.apache.commons.math3.optimization distribuídas em outros sub-pacotes conforme a
função requerida. Algumas rotinas comuns ao uso da biblioteca são:
a) LinearConstraint(coefficients, relationship, value) – são as restrições,
as quais tem em sua instanciação a composição de uma lista de coeficientes;
valores para a restrição, um atributo operador relacional e um valor limitante para
a restrição;
b) LinearObjectiveFunction(coefficients, constantTerm) – representa a
função objetivo expressa também com uma lista de coeficientes e uma constante;
c) PointValuePair pointValuePair =
simplexSolver.optimize(linearObjectiveFunction, con straints,
goalType, restrictToNonNegative) – através do PointValuePair a
solução é obtida passando como parâmetros para o objeto da classe
SimplexSolver os elementos necessários ao cálculo, como a função objetivo, a
lista de restrições, o tipo do objetivo (maximizar ou minimizar) e a restrição de não
negatividade.
48
3.7.2 Estrutura de funcionamento das fases
Foi adotada para implementação do framework uma estrutura de funcionamento
própria para cada uma das fases, visto terem elas objetivos diferentes entre si, utilizando-se,
portanto, tecnologias e rotinas distintas.
3.7.2.1 Fase Metas
Para construção da fase metas, tomou-se como entrada as margens fornecidas pela
aplicação e, como objetivos, fornecer o maior número de atributos contínuos que apoiem as
rotinas do executivo, sejam estas indicadores ou mesmo valores relacionados ao negócio.
Assim, na busca por indicadores em função das margens e tomando como referência os
estudos junto à fundamentação teórica, procedeu-se a um grafo para descrever quais cálculos
seriam necessários para atingir-se o indicador mencionado e então, quais cálculos seriam
necessários para atingir-se o cálculo anterior, e assim sucessivamente, até atingir-se o nó raiz,
que seria representado pelas margens fornecidas. O grafo construído com base na composição
dos cálculos fornecidos junto à fundamentação teórica pode ser visualizado na Figura 9.
49
Figura 9 – Grafo de precedência de cálculos
Indi
cado
res
Tot
aliz
ador
es
Con
trol
es
50
Ao vislumbrar o grafo, nota-se a entrada representada pelas margens e a partir daí a
decomposição de cálculos necessários para atingir os indicadores sempre referenciados pelo
seu precedente obrigatório. Por essa mesma razão, é possível concluir a impossibilidade de
cálculos referentes às metas para alguns dos indicadores levantados na fundamentação pela
simples razão de não apresentarem alguns dos precedentes obrigatórios ao seu cálculo.
3.7.2.2 Fase Projeções
As rotinas necessárias à projeção incluem a regressão linear procedida junto à
aplicação da biblioteca de uso WEKA. Apesar de já serem conhecidos os dados a serem
estimados pelo modelo de regressão, construiu-se as rotinas de forma a comportar qualquer
circunstância em que se desejar trabalhar com estimativas. Dessa forma, diminui-se o
acoplamento do código e facilita possível reutilização das estimativas para outras ocasiões. O
local onde a estimativa é acoplada ao problema em questão, no caso estimativas de negócios,
é na camada de controle.
Abstraindo-se então a camada de controle, com funcionamento já descrito no diagrama
de sequência, a implementação da regressão é dada por meio do uso de reflexão com
regressão linear simples.
O método público setLinearRegression(List<T> ts) recebe uma lista genérica de
elementos. Com esta lista, então, o método setLinearRegression povoa um arquivo ARFF
com uma relação padrão através da iteração das fields, onde por meio do name da field os
atributos referentes ao WEKA são inseridos e, por meio de seus valores no índice da field lida
pelo índice do Array de elementos genéricos, recebe seu valor. Assim, o ARFF é povoado.
Então a camada de controle invoca o método público List<T>
estimarRegressaoLinear(List<T> ts) onde agora a lista é reconstruída por reflexão de
forma idêntica à lista recebida e seus valores são resultado da aplicação do modelo de
regressão retornado pelo WEKA após invocar o método buildClassifier(instances) do
WEKA, como já demonstrado na fundamentação. Além disso, ocorre também o povoamento
do coeficiente de correlação de Pearson relativo a cada um dos fields, por aplicação do
modelo de regressão sucessivamente a cada um dos pares de elementos compostos por
período e field estimado. Foi convencionado que a lista retornada deve ter tamanho idêntico à
51
lista fornecida para estimativa, ou seja, o número de estimativas retornadas é igual ao número
de elementos fornecidos.
Após a estimativa referente aos totalizadores invocada pela camada de controle, os
indicadores são também estimados a partir do simples cálculo em função do resultado da
estimativa dos totalizadores. Além dos indicadores, são também estimados um caso especial
de indicador, os indicadores financeiros. Os indicadores financeiros são estimados pela
aplicação da classe FinancaPOI , a qual implementa os cálculos relativos às finanças com
auxílio da biblioteca ApachePOI. Para isso, utiliza-se o resultado da estimativa dos
totalizadores. Os cálculos financeiros normalmente compõe-se de valores que possivelmente
serão realizados e tem como serventia verificar a viabilidade ou não em se proceder a estas
realizações. De igual forma, apresenta-se o cálculo no framework; os valores são primeiro
estimados e então, baseado nestes valores, efetuam-se os cálculos necessários e verifica-se a
viabilidade ou não das estimativas. Para isto, a classe FinancaPOI foi concebida de forma a
comportar um método para cada indicador financeiro. Esta mesma classe apresenta também
os métodos booleanos referentes a cada indicador, os quais verificam a viabilidade para cada
um deles.
O diagrama de atividades da Figura 10 ilustra o fluxo de execução desta fase.
52
Figura 10 – Diagrama de atividades para fase projeções
53
3.7.2.3 Fase Reajustes
Em um primeiro momento, optou-se por utilizar a programação linear como forma de
mensurar as estimativas relativas a esta fase, onde a modelagem do Problema de Programação
Linear (PPL) seria composta de tal forma a ter como objetivo as margens e como restrições a
estrutura de controles ou totalizadores, o que mostra-se mais adequado. Sucedeu-se então a
busca por orientação relacionada à estatística por tratar-se de área distinta ao segmento da
computação e apresentar-se como um problema sem semelhança, no tange a pesquisa
operacional, aos demais já observados pelo autor. Assim, esta situação foi conduzida a MS.
Janaina Poffo Possamai que após reflexão sobre o tema e confirmação na figura de seu
orientador do doutorado em decurso, concluíram em conjunto a seguinte avaliação, conforme
Possamai (2012).
Conversamos sobre o assunto e o seu caso é bem complexo, pois teríamos restrições sem coeficientes constantes (números), mas sim variáveis. Assim não é um problema de programação linear, o que torna sua modelagem bastante complexa e sua resolução ainda mais.
Assim, a programação linear foi concebida na fase otimizações e para esta fase
reajustes utilizou-se raciocínio semelhante à fase metas, só que de maneira oposta e desta
forma percorre-se o grafo de precedência de cálculos pelo caminhamento nó final, que neste
caso são os totalizadores, para raiz e não raiz para o nó final, como no caso da fase metas.
No entanto, são necessários antes os valores evindenciados para o reajuste, então como
os reajustes serão relativos ao próximo período optou-se então por primeiro estimar os
totalizadores do próximo período e então a partir destas estimativas, estimar os reajustes
necessários. Para a estimativa das próximas totalizações, realiza-se uma rotina idêntica à fase
projeções.
Assim, após a estimativa e o caminhamento contrário do grafo, calcula-se os custos
fixos totais, os custos variáveis totais e o lucro total. Assim, pela descoberta destes valores em
relação ao faturamento é possível encontrar o percentual adequado para cada uma destas
margens e assim tornar o valor cobrado adequado ao mercado vivenciado.
O diagrama de atividades da Figura 11 ilustra o procedimento de cálculo do reajuste.
54
Figura 11 – Diagrama de atividades para fase reajustes
3.7.2.4 Fase Otimizações
Para a fase otimização é invocado o método otimizarObjetivo(List<Restricao>
restricoes, List<Objetivo> funcaoObjetivo) da classe SimplexSolverCM . Esta é a
classe responsável por tratar as rotinas relativas ao solver com apoio da biblioteca
CommonsMath.
Como já demonstrado na fundamentação o uso do solver consiste em invocar o método
simplexSolver.optimize(linearObjectiveFunction,cons traints,goalType,restric
tToNonNegative,) o qual tem como parâmetros a função objetivo, as restrições, o objetivo
da função(maximizar ou minimizar) e a restrição de não negatividade.
55
Como resultados o solver retorna as variáveis de decisão e a solução obtida. O
framework retorna esses valores para aplicação na própria lista de elementos recebida. Ou
seja, a lista recebida que tinha todos os valores, menos os valores de X, será retornada com
todos os valores, inclusive os de X.
O diagrama de atividades da Figura 12 ilustra o processamento das rotinas de
otimização.
Figura 12 – Diagrama de atividades para fase otimizações
56
3.7.3 Operacionalidade da implementação
A operacionalidade do framework se dá por herança de suas características;
implementação das interfaces disponibilizadas, injeção das dependências relacionadas a estas
interfaces e então invocar-se o método desejado para cálculo necessário relacionado a
qualquer uma das fases.
Mais especificamente, herda-se a classe abstrata Core do framework; implementam-se
as interfaces InterfaceMargens , IntenfaceControles , InterfaceTotalizadores ,
InterfaceIndicadores , InterfaceIndicadoresFinanceiros , InterfaceProduto e
InterfaceProdutoCaracteristica ; injetam-se os valores pelos seus respectivos métodos
assessores e invoca-se um dos métodos disponíveis para a estimativa desejada.
A implementação das interfaces está relacionada a suas fases. Serão todas
implementadas pela aplicação somente para o caso de desejar-se utilizar todas as fases.
Um exemplo de operacionalidade do framework é demonstrado no Quadro 10, sendo
este referente ao estudo de caso aplicado com dados demonstrados por meio do Apêndice B.
Vale ressaltar que estes dados foram injetados manualmente através de uma classe, a qual
representa uma aplicação implementando o framework. As rotinas descritas nesta classe
seriam as mesmas utilizadas por uma aplicação real que viesse a fazer uso das funcionalidades
do framework.
1 public class Principal extends Core {
2 public static void main(String[] args) throws Exception {
3 // Heranca das caracteristicas do framework
4 Core core = new Principal();
5
6 // Injeção de depêndencia das entradas
7
8 // Cria uma nova instancia das margens pela refer encia da interface
9 InterfaceMargens interfaceMargens = new Margens();
10 interfaceMargens.setCustosFixos(54000.0);
11 interfaceMargens.setCustosFixosPercentual(64);
12 interfaceMargens.setCustosVariaveisPercentual(32) ;
13 interfaceMargens.setLucroPercentual(4);
14
15 // Injeta as margens pela interface
16 core.setInterfaceMargens(interfaceMargens);
17
18 // Injeta referência de novos controles para saíd a de dados
19 InterfaceControles interfaceControles = new Controles();
57
20 int numeroMesesPagamento = 12;
21 interfaceControles.setNumeroMesesPagamento(numeroM esesPagamento);
22 int taxaDesconto = 5;
23 interfaceControles.setTaxaDesconto(taxaDesconto);
24 core.setInterfaceControles(interfaceControles);
25
26 // Cria um arraylist pela referencia da interface
27 ArrayList<InterfaceTotalizadores> interfaceTotalizadoresPeriodos = new ArrayList<>();
28 InterfaceTotalizadores interfaceTotalizadores = n ull;
29
30 // Cria uma nova instancia dos indicadores pela r eferencia da interface
31 interfaceTotalizadores = new Totalizadores();
32 interfaceTotalizadores.setPeriodo(3.0);
33 Double ativoTotal3 = 0.0;
34 interfaceTotalizadores.setAtivoTotal(ativoTotal3) ;
35 Double custosFixos3 = 54000.0;
36 interfaceTotalizadores.setCustosFixos(custosFixos 3);
37 Double faturamentoCliente3 = 110.0;
38 interfaceTotalizadores.setFaturamentoCliente(fatur amentoCliente3);
39 Double faturamentoTotal3 = 98000.0;
40 interfaceTotalizadores.setFaturamentoTotal(faturam entoTotal3);
41 Double saldoFluxoCaixa3 = 7000.0;
42 interfaceTotalizadores.setSaldoFluxoCaixa(saldoFlu xoCaixa3);
43 Double faturamentoTotalAnterior3 = 82000.0;
44 interfaceTotalizadores.setFaturamentoTotalAnterior (faturamentoTotalAnterior3);
45 Double faturamentoTotalLiquido3 = 93000.0;
46 interfaceTotalizadores.setFaturamentoTotalLiquido( faturamentoTotalLiquido3);
47 Double gastosFabricacao3 = 0.0;
48 interfaceTotalizadores.setGastosFabricacao(gastosF abricacao3);
49 Double gastosGerais3 = 0.0;
50 interfaceTotalizadores.setGastosGerais(gastosGera is3);
51 Double lucroLiquidoOperacionalTotal3 = 7840.0;
52 interfaceTotalizadores.setLucroLiquidoOperacionalT otal(lucroLiquidoOperacionalTotal3);
53 Double orcamentosAprovados3 = 700.0;
54 interfaceTotalizadores.setOrcamentosAprovados(orca mentosAprovados3);
55 Double orcamentosElaborados3 = 115.0;
56 interfaceTotalizadores.setOrcamentosElaborados(orc amentosElaborados3);
57 // Adiciona os indicadores a lista de periodos pe la referencia da interface
58 interfaceTotalizadoresPeriodos.add(interfaceTotali zadores);
59
60 // Cria uma nova instancia dos indicadores pela r eferencia da interface
61 interfaceTotalizadores = new Totalizadores();
62 interfaceTotalizadores.setPeriodo(4.0);
63 Double ativoTotal4 = 0.0;
58
64 interfaceTotalizadores.setAtivoTotal(ativoTotal4) ;
65 Double custosFixos4 = 54000.0;
66 interfaceTotalizadores.setCustosFixos(custosFixos 4);
67 // Continua populando métodos assessores dos arra ys relativos a cada período mensal
68
69 // Injeta as lista de indicadores pela interface
70 core.setInterfaceTotalizadoresPeriodos(interfaceTo talizadoresPeriodos);
71
72 // Injeta referência de novos indicadores para sa ída de dados
73 InterfaceIndicadores interfaceIndicadores = new Indicadores();
74 core.setInterfaceIndicadores(interfaceIndicadores );
75
76 // Injeta referência de novos indicadores para sa ída de dados
77 InterfaceIndicadoresFinanceiros interfaceIndicadoresFinanceiros = new IndicadoresFinanceiros();
78 core.setInterfaceIndicadoresFinanceiros(interfaceI ndicadoresFinanceiros);
79
80 // Injeta a lista de produtos e suas caracteristi cas
81 ArrayList<InterfaceProduto> interfaceProdutos = new ArrayList<>();
82
83 for ( int j = 0; j < 1; j++) {
84 InterfaceProduto interfaceProduto = new Produto();
85
86 List<InterfaceProdutoCaracteristica> interfaceProdutoCaracteristicas = new ArrayList<>();
87 for ( int k = 0; k < 0; k++) {
88 InterfaceProdutoCaracteristica interfaceProdutoCaracteristica = new ProdutoCaracteristica();
89 String nome = "nome" + k;
90 interfaceProdutoCaracteristica.setNome(nome);
91 Double valor = (double) k;
92 interfaceProdutoCaracteristica.setValor(valor);
93 interfaceProdutoCaracteristicas.add(interfaceProdu toCaracteristica);
94 }
95 interfaceProduto.setInterfaceProdutoCaracteristica s(interfaceProdutoCaracteristicas);
96
97 Double lucro = 100.00 * j;
98 interfaceProduto.setLucro(lucro);
99 interfaceProdutos.add(interfaceProduto);
100 }
101
102 // Construir estimativas
103
104 // Metas
105 Controles metasControles = (Controles) core.estimarMetasControles();
59
106 System.out.println("Metas controles");
107 System.out.println(metasControles.getCustoPercentu alMercadoriaVendida());
108 System.out.println(metasControles.getMargemPercent ualContribuicao());
109 System.out.println(metasControles.getMargensPercen tualTotal());
110 System.out.println(metasControles.getMarkupPercent ual());
111
112 Totalizadores metasTotalizadores = (Totalizadores) core.estimarMetasTotalizadores();
113 System.out.println("Metas totalizadores");
114 System.out.println(metasTotalizadores.getFaturamen toTotal());
115 System.out.println(metasTotalizadores.getGastosGer ais());
116 System.out.println(metasTotalizadores.getGastosFab ricacao());
117 System.out.println(metasTotalizadores.getFaturamen toTotalLiquido());
118 System.out.println(metasTotalizadores.getLucroLiqu idoOperacionalTotal());
119
120 Indicadores metasIndicadores = (Indicadores) core.estimarMetasIndicadores();
121 System.out.println("Metas indicadores");
122 System.out.println(metasIndicadores.getGastoUnitar ioFabricacao());
123 System.out.println(metasIndicadores.getLucroLiquid oOperacional());
124
125 // Projeções
126 ArrayList<Totalizadores> projecoesTotalizadores = (ArrayList) core.estimarProjecoesTotalizadores();
127 System.out.println("Projecoes totalizadores");
128 for (Totalizadores totalizadores : projecoesTotalizador es) {
129 System.out.println("Projecao");
130 System.out.println(totalizadores.getPeriodo());
131 System.out.println(totalizadores.getAtivoTotal());
132 System.out.println(totalizadores.getCustosFixos()) ;
133 System.out.println(totalizadores.getFaturamentoCli ente());
134 System.out.println(totalizadores.getFaturamentoTot al());
135 System.out.println(totalizadores.getFaturamentoTot alAnterior());
136 System.out.println(totalizadores.getFaturamentoTot alLiquido());
137 System.out.println(totalizadores.getGastosFabricac ao());
138 System.out.println(totalizadores.getGastosGerais() );
139 System.out.println(totalizadores.getLucroLiquidoOp eracionalTotal());
140 System.out.println(totalizadores.getOrcamentosApro vados());
141 System.out.println(totalizadores.getOrcamentosElab orados());
142 System.out.println(totalizadores.getProdutosDefeit o());
143 System.out.println(totalizadores.getProdutosTotal( ));
144 System.out.println(totalizadores.getSaldoFluxoCaix a());
145 }
146
147 System.out.println("Projecoes indicadores");
148 ArrayList<Indicadores> projecoesIndicadores = (Arr ayList) core.estimarProjecoesIndicadores();
60
149
150 for (Indicadores indicadores : projecoesIndicadores) {
151 System.out.println("Indicadores");
152 System.out.println(indicadores.getAumentoFaturamen to());
153 System.out.println(indicadores.getEficienciaComerc ial());
154 System.out.println(indicadores.getGastoUnitarioFab ricacao());
155 System.out.println(indicadores.getGrauDependencia( ));
156 System.out.println(indicadores.getLucroLiquidoOper acional());
157 System.out.println(indicadores.getQualidade());
158 System.out.println(indicadores.getResultadoOperaci onal());
159 }
160 IndicadoresFinanceiros projecoesIndicadoresFinance iros = (IndicadoresFinanceiros) core.estimarProjecoesIndicadoresFinanceiros();
161
162 System.out.println("Projecoes indicadores financei ros");
163 System.out.println(projecoesIndicadoresFinanceiros .getPontoFischer());
164 System.out.println(projecoesIndicadoresFinanceiros .getRetornoInvestimentoAdicionado());
165 System.out.println(projecoesIndicadoresFinanceiros .isRetornoInvestimentoAdicionadoViavel());
166 System.out.println(projecoesIndicadoresFinanceiros .getTaxaInternaRetorno());
167 System.out.println(projecoesIndicadoresFinanceiros .isTaxaInternaRetornoViavel());
168 System.out.println(projecoesIndicadoresFinanceiros .getValorPresenteLiquido());
169 System.out.println(projecoesIndicadoresFinanceiros .isValorPresenteLiquidoViavel());
170 System.out.println(projecoesIndicadoresFinanceiros .getValorPresenteLiquidoAnualizado());
171 System.out.println(projecoesIndicadoresFinanceiros .isValorPresenteLiquidoAnualizadoViavel());
172 System.out.println(projecoesIndicadoresFinanceiros .getIndiceBeneficioCusto());
173 System.out.println(projecoesIndicadoresFinanceiros .isIndiceBeneficioCustoViavel());
174 System.out.println(projecoesIndicadoresFinanceiros .getPeriodoRecuperacaoInvestimento());
175 System.out.println(projecoesIndicadoresFinanceiros .isPeriodoRecuperacaoInvestimentoViavel());
176
177 // Reajustes
178 Margens reajustes = (Margens) core.estimarReajuste s();
179 System.out.println("Margens");
180 System.out.println(reajustes.getCustosFixos());
181 System.out.println(reajustes.getCustosFixosPercent ual());
182 System.out.println(reajustes.getCustosVariaveisPer centual());
183 System.out.println(reajustes.getLucroPercentual()) ;
184
185 // Otimizações
186 ArrayList<InterfaceProduto> interfaceProdutosOtimi zacoes = (ArrayList<InterfaceProduto>) core.estimarOtimizaco es();
187
188 for (InterfaceProduto interfaceProdutoOtimizacoes : interfaceProdutosOtimizacoes) {
61
189 System.out.println("Quantidade");
190 System.out.println(interfaceProdutoOtimizacoes.get Quantidade());
191 }
Quadro 10 - Exemplo de operacionalidade do framework
Na linha 1, a classe Principal herda as características da classe abstrata Core a qual
representa a estrutura central do framework, onde são injetadas as dependências, de onde são
obtidas referências para novos objetos e de onde são obtidas também as estimativas de cada
fase. Das linhas 8 a 100 são demonstradas as injeções de cada uma das dependências de
objetos. Como exemplo, na linha 9, é obtida a referência de um objeto pela sua interface, em
seguida, das linhas 10 a 13, são populados os métodos assessores do objeto e então é efetuada
a injeção desta dependência no núcleo do framework na linha 16. Vale lembrar que a
implementação do Quadro 10 é relativa ao estudo de caso, o qual não fez uso de todas as fases
do framework e, portanto da linha 68 a 100 os valores são fictícios e somente de carácter
demonstrativo. Das linhas 102 a 191, são obtidas as estimativas. Como exemplo, na linha 105
a aplicação cria uma referência de objeto de classe Controles com o nome metasControles
o qual obtêm do framework a estimativa referente as metas por meio de um Cast para o objeto
de classe (Controles) do método de núcleo do framework estimarMetasControles(). O
novo objeto calculado pelo framework é criado a partir da referência do objeto injetado, ou
seja, o objeto relativo à aplicação é criado pelo framework na própria aplicação.
33..88 RREESSUULLTTAADDOOSS EE DDIISSCCUUSSSSÃÃOO
A ferramenta foi concebida na forma de um framework e, portanto, não se trata de um
software final para utilização. O uso deste framework será mais relacionado ao desenvolvedor
do software que fará uso das suas funcionalidades que ao usuário final que utilizará o software
concebido pelo desenvolvedor.
Ainda assim, com o objetivo de verificar as funcionalidades, foi procedido o estudo de
um caso real, relacionado a uma empresa na área de serviços. Os dados que seriam advindos
de um software foram diretamente fornecidos pelo responsável da empresa1 e podem ser
visualizados no formulário de requisição de dados descrito no Apêndice B.
1 Foi optado por divulgar o nome da empresa em folha de assinatura a parte e que consta apenas na versão impressa. A empresa não coibiu a publicação dos dados em versão não impressa. Esta foi uma opção feita pelo autor do trabalho, em consideração ao regime de capital não aberto adotado pela empresa.
62
Como mencionado na operacionalidade, pode-se utilizar o conjunto de todas as fases
ou apenas aquela que mais condizer à circunstância evidenciada. A fase utilizada para o
estudo de caso foi aquela relativa às projeções. Isto porque trata-se de uma empresa
relacionada a serviços impossibilitando o uso da fase otimizações, vinculada ou ao processo
produtivo (indústria), ou as vendas (comércio) e porque a empresa opta por incorporar o
custos dos serviços a composição dos custos fixos, uma estratégia comum a área de serviços o
que acaba nesse caso por impossibilitar mensurar o custo do serviço prestado, elemento
necessário ao grafo de precedência de cálculos, utilizado pelo framework e das quais fazem
uso a fase metas e reajustes e desta forma impossibilitando o uso destas fases.
A aplicabilidade foi verificada através da análise de critérios de avaliação pelo
responsável onde o mesmo indicou a importância do indicador mensurado e sua opinião
baseada na sua experiência com relação à precisão da estimativa mencionada. Os dados
informados pelo responsável da empresa podem ser visualizados no relatório de entrega das
estimativas no Apêndice B.
Assim, após análise do relatório de entrega das estimativas, no que tange as projeções
é possível determinar que os indicadores apresentam relevância mas ainda passíveis de
melhorias com relação a precisão das estimativas.
63
4 CONCLUSÕES
O conjunto de fundamentos levantados foi suficiente para atender aos propósitos a
concepção do presente trabalho. Dentre os quais, pode-se mencionar a análise de obras e
materiais inerentes às funções empresariais, custos, indicadores e balanced scorecard como
forma de compreender melhor a perspectiva empresarial, até então desconhecida pelo autor
por não se tratar de assunto diretamente relacionado à área de atuação da pesquisa, mas, ainda
assim, vinculada à sua implementação final. Outro aspecto importante diz respeito às
pesquisas relacionadas as áreas de estatística e inteligência artificial, as quais, em conjunto,
permitiram a implementação das estimativas propostas no decorrer do trabalho. No que diz
respeito a frameworks, está o conjunto de características inerentes à sua implementação, que
contribuíram para a construção da arquitetura de forma objetiva.
Vale citar também que o resultado final obtido trata-se de escolhas de implementação
para a ferramenta. Para muitas situações, várias linhas de pensamento poderiam conduzir a
implementação. Procurou-se optar sempre por aquela que estivesse em conformidade com os
conceitos elencados e foram, na verdade, os conceitos os causadores de maior empecilho. Isto
porque, por muitas vezes, dava-se a tal situação em que escolher a alternativa X implicaria
incorrer num erro de arquitetura quebrando de certa forma a injeção de dependência, ou
escolher a alternativa Y e deixar de calcular o coeficiente de correlação ferindo um aspecto
estatístico. Pode-se dizer, então, que a maior dificuldade encontrada foi tentar atender a todos
os aspectos conceituais de forma amena e não incorrer em quebra de paradigma de nenhum
dos conceitos levantados.
Por fim, chega-se ao framework proposto o qual procura atender aos objetivos
mencionados através da concepção de suas fases de processamento. Para a fase metas, os
indicadores são gerados a partir das margens fornecidas pela aplicação e decompostos por
todos os cálculos intermediários necessários para se atingir os indicadores. São retornados a
aplicação o conjunto de todos os cálculos intermediários e indicadores gerados como forma de
situar as metas necessárias aos próximos períodos. Para a fase projeções aplica-se a regressão
linear aos totalizadores e indicadores injetados pela aplicação, forma esta de situar as
próximas estimativas dos valores injetados. Para a fase reajustes, inicialmente é estimado o
próximo período a partir dos dados injetados relativos aos períodos anteriores, então a partir
do período estimado calcula-se em ordem inversa por meio do grafo de precedência de
cálculos as margens necessárias aos valores vivenciados, como forma de adequar a empresa a
64
realidade estimada para o próximo período. Para a fase otimizações, são injetados pela
aplicação dados relativos ao processo produtivo ou de venda de produtos da empresa, e com
tais dados são calculados então as quantidades necessárias de cada produto para atingir-se o
máximo de lucro possível, como forma de otimizar a linha de produção ou o processo de
compra de estoque da empresa. Para as fases utilizadoras de modelo de regressão linear,
existe sempre um atributo adicional em relação ao seu original, relativo ao coeficiente de
correlação, o qual indica a precisão da estimativa do atributo referenciado.
Assim, avalia-se o resultado final do framework desenvolvido em uma escala de ruim a
ótimo como moderado, pois apesar dos objetivos estarem inicialmente abrangidos, fazem-se
necessários ainda alguns importantes elementos, fruto talvez de contribuições futuras através
de extensões à implementação proposta.
44..11 EEXXTTEENNSSÕÕEESS
Dentre as propostas para contribuição, está o crescimento do grafo de precedência de
cálculos incluindo-se possivelmente mais indicadores, os quais implicariam mais pesquisas
relativas à análise de custos e incrementariam ainda mais os nós precedentes secundários,
fornecendo, assim, uma maior quantidade de informações relacionadas ao negócio.
Outra proposta está relacionada ao modelo de estimativas, o qual pode ser
implementado não apenas com regressão linear simples, mas também com a regressão linear
múltipla, dentre outros métodos para estimativas de valor.
65
REFERÊNCIAS BIBLIOGRÁFICAS
AZEVEDO, Paulo Roberto Medeiros de. Modelos de regressão linear. 1. ed. Natal: Editora da UFRN, 1997. 211 p.
BRAUDE, Eric. Projeto de software: Da programação à arquitetura: uma abordagem baseada em Java. Porto Alegre: Bookman, 2005. 619 p.
CAMPOS, José Antonio. Cenário Balanceado: painel de indicadores para a gestão estratégica dos negócios. 1. ed. São Paulo: Aquariana, 1998. 181 p.
CASOTTI, Fábio Alexandre Gaion. Um sistema de suporte a decisão baseado em programação multiobjetivo. 1993. 174 f. Tese (Mestrado) - Curso de Engenharia Elétrica, Departamento de Telemática, Unicamp, Campinas, 1993.
CHIAVENATO, Idalberto. Introdução à teoria geral da administração. 6. ed. Rio de Janeiro: Campus, 2000. 700 p.
CORREA, Cristiane; MANO, Cristiane. O preço de uma decisão errada. São Paulo, 2005. Disponível em: <http://exame.abril.com.br/negocios/gestao/noticias/o-preco-de-uma-decisao-errada-m0039779>. Acesso em: 07 set. 2011.
DIAS, Sérgio Luiz Vaz. Indicadores de desempenho e gestão empresarial. Porto Alegre: Sebrae, 2007. Disponível em: <http://www.sebrae-rs.com.br/produtos-servicos/publicacoes/indicadores-desempenho-gestao-empresarial/429.aspx>. Acesso em: 28 maio 2012.
ENSSLIN, Leonardo; MONTIBELLER NETO, Gilberto; NORONHA, Sandro Macdonald. Apoio a decisão: Metodologia para estruturação de problemas e avaliação multicritério de alternativas. Florianópolis: Insular, 2001. 296 p.
FOWLER, Martin. Inversion of Control Containers and the Dependency Injection pattern. Chicago, 2004. Disponível em: <http://martinfowler.com/articles/injection.html>. Acesso em: 02 jun. 2012.
GOMES, Luiz Flavio Autran Monteiro; ARAYA, Marcela Cecilia González; CARIGNANO, Claudia. Tomada de decisão em cenários complexos. São Paulo: Pioneira Thomson Learning, 2004. 168 p.
HECKLER, Luiz Fernando. Redmine GCO: uma ferramenta de apoio para a Gerência de Configuração. 2009. 56 f. Trabalho de Conclusão de Curso (Graduação) - Curso de Ciências da Computação, Departamento de Instituto de Informática, Universidade Federal do Rio Grande do Sul, Rio Grande do Sul, 2009.
66
HEINZLE, Roberto. Um modelo de engenharia do conhecimento para sistemas de apoio a decisão com recursos para raciocínio abdutivo. 2011. 251 f. Tese (Doutorado em Engenharia e Gestão do Conhecimento) - Curso de Pós-graduação em Engenharia e Gestão do Conhecimento, Universidade Federal de Santa Catarina, Florianópolis.
KAPLAN, Robert; NORTON, David. Mapas estratégicos: Convertendo ativos intangíveis em resultados tangíveis. 1. ed. Rio de Janeiro: Elsevier, 2004. 469 p.
KOTLER, Philip. Administracao de marketing: analise, planejamento, implantacao e controle. 5. ed. São Paulo: Atlas, 1998. 725 p.
LINS, Marcos Pereira Estellita. Programação linear: com aplicações em teoria dos jogos e avaliação de desempenho. 1. ed. Rio de Janeiro: Editora Interciência, 2006. 292 p.
MARION, José Carlos; LUDÍCIBUS, Sergio de. Curso de contabilidade para não-contadores: Para as Áreas de Administração, Economia, Direito e Engenharia. 6. ed. São Paulo: Atlas, 2009. 274 p.
PADAVEZE, Clóvis Luís. Curso básico gerencial de custos. 1. ed. São Paulo: Pioneira Thomson Learning, 2003. 377 p.
POSSAMAI, Janaina Poffo. Estatística. [mensagem pessoal]. Mensagem recebida por: <[email protected]>. Acesso em: 16 maio 2012.
RUSSELL, Stuart Jonathan; NORVIG, Peter. Inteligência Artificial . 2. ed. Rio de Janeiro: Elsevier, 2004. 1021 p.
SEBRAE. Como elaborar um plano de vendas. Belo Horizonte, 2007. Disponível em: <http://www.biblioteca.sebrae.com.br/bds/bds.nsf/A15B930602D0F967832573D900489A03/$File/NT00037492.pdf>. Acesso em: 07 set. 2011.
SEBRAE. Procedimentos e controles. São Paulo, 2004. Disponível em: <http://antigo.sp.sebrae.com.br/principal/melhorando%20seu%20neg%C3%B3cio/orienta%C3%A7%C3%B5es/finan%C3%A7as/procctrl/default.aspx>. Acesso em: 27 mai. 2012.
SILVA, Marcus Vinicius Drissen. Um arcabouço de suporte à tomada de decisão colaborativa para o gerenciamento da evolução de empresas virtuais. 2010. 272 f. Tese (Doutorado) - Curso de Engenharia Elétrica, Departamento de Centro Tecnológico, Universidade Federal de Santa Catarina, Florianópolis, 2010.
SOUZA, Acilon Batista de. Projetos de investimento de capital: Elaboração, Análise e Tomada de Decisão. São Paulo: Atlas, 2003. 216 p.
SOUZA, Alceu; CLEMENTE, Ademir. Decisões financeiras e análise de investimentos: Fundamentos, técnicas e aplicações. 5. ed. São Paulo: Atlas, 2004. 178 p.
67
STAIR, Ralph M; REYNOLDS, George W. Princípios de sistemas de informação. 9. ed. São Paulo: Cengage Learning, 2011. 590 p.
WALLS, Craig; BREIDENBACH, Ryan. Spring em ação. 1. ed. Rio de Janeiro: Editora Ciência Moderna Ltda, 2006. 445 p.
68
APÊNDICE A – Detalhamento dos casos de uso
Este Apêndice apresenta a descrição dos principais casos de uso descritos na seção de especificação deste trabalho.
UC01 - Fornece interface de referência public UseCase: Fornecer interface padrão para entrada de dados
Scenarios
Fornecer interface {Principal}. 1- Sistema implementa interface fornecida pelo framework 2- Sistema solicita requisições através dos métodos públicos
UC02 - Retorna lista de metas public UseCase: Retorna lista contendo as metas necessárias para a empresa baseadas nas informações fornecidas pelo sistema por meio da implementação da interface.
Constraints
� Approved Pre-condition . As informações necessárias foram fornecidas pelo sistema através da implemantação da interface.
� Approved Post-condition . O sistema dispõe da lista de metas fornecida pelo framework.
Scenarios
Retornar metas {Principal}. 1- Sistema requisita metas 2- Framework percorre grafo de precedência de cálculos, caminhamento raiz nó 3- Framework efetua cálculos relacionados a construção da lista de metas 4- Framework retorna lista de metas Instanciar elementos {Alternativo}. 2.1 - Até finalizar lista de cálculos 2.1.1 - Instanciar cálculo 2.1.2 - Instanciar seus elementos 2.1.3 - Retornar ao passo 2.1 Tratar erro {Exceção}. 1- Na ocorrência de um erro 2- Framework empilha erro na lista de logs 3- Framework retorna ao passo 1 do cenário "Retornar metas"
UC03 - Retorna lista de projeções public UseCase: Retorna lista contendo as projeções para a empresa baseadas nos totalizadores informados.
Constraints
69
� Approved Pre-condition . Lista de totalizadores. � Approved Post-condition . O sistema dispõe da lista de projeções fornecida pelo
framework. Scenarios
Retornar projeções {Principal}. 1- Sistema requisita projeções 2- Framework instancia classe de regressão linear 3- Framework efetua projeções com uso da classe 4- Framework retorna lista de projeções Instanciar elementos {Alternativo}. 2.1 - Até finalizar lista de funções 2.1.1 - Instanciar função 2.1.2 - Instanciar seus elementos 2.1.3 - Retornar ao passo 2.1 Tratar erro {Exceção}. 1- Na ocorrência de um erro 2- Framework empilha erro na lista de logs 3- Framework retorna ao passo 1 do cenário "Retornar projeções "
UC04 - Retorna lista de reajustes public UseCase: Retorna lista contendo reajustes para a empresa baseadas nos valores praticados.
Constraints
� Approved Pre-condition . Valores praticados atualmente. � Approved Post-condition . O sistema dispõe da lista de correções fornecida pelo
framework. Scenarios
Retornar reajustes {Principal}. 1- Sistema requisita reajustes 2- Framework efetua projeção do próximo período com base nos valores anteriores 3- Framework percorrer grafo de precedência de cálculos, caminhamento nó raiz 4- Framework efetua cálculos necessários aos reajustes com base na projeção 5- Framework retorna lista de reajustes Instanciar elementos {Alternativo}. 3.1 - Até finalizar lista de cálculos 3.1.1 - Instanciar cálculo 3.1.2 - Instanciar seus elementos 3.1.3 - Retornar ao passo 2.1 Tratar erro {Exceção}. 1- Na ocorrência de um erro 2- Framework empilha erro na lista de logs 3- Framework retorna ao passo 1 do cenário "Retornar reajustes"
70
UC05 - Retorna lista de otimizações public UseCase: Retorna lista contendo as otimizações para a empresa baseadas na lista de produtos atualmente vivenciada pelo processo produtivo ou de venda.
Constraints
� Approved Pre-condition . Lista de produtos. � Approved Post-condition . O sistema dispões da lista de otimizações referentes as
quantidades produzidas/vendidas de produtos. Scenarios
Retornar otimizações {Principal}. 1- Sistema requisita otimizações 2- Framework compõe modelo matemático referente a lista informada 3- Framework efetua cálculos referentes ao tableau 4- Framework retorna lista de otimizações contendo as quantidades necessárias Tratar erro {Exceção}. 1- Na ocorrência de um erro 2- Framework empilha erro na lista de logs 3- Framework retorna ao passo 1 do cenário "Retornar otimizações"
71
APÊNDICE B - Formulário de requisição de dados
Solicito respeitosamente o preenchimento das questões a seguir a fim de testar a funcionalidade da ferramenta desenvolvida pela construção do modelo de estimativas a ser entregue para apreciação e feedback quando da sua conclusão. Informações relacionadas à estimativa necessária de vendas:
1- Qual a total de custos fixos mensais dos últimos três períodos da sua empresa? R: Março Abril Maio R$ 54.000,00 R$ 54.000,00 R$ 54.000,00 ( ) Relativo a outro segmento, não controlado ou desconhecido
2- Qual o percentual médio mensal que estes custos representam em relação ao faturamento? R: 64,00% ( ) Relativo a outro segmento, não controlado ou desconhecido
3- Qual o percentual médio mensal de custos variáveis?
R: 32,00% ( ) Relativo a outro segmento, não controlado ou desconhecido
4- Qual a margem percentual de lucro mensal normalmente desejada? R: 4,00% ( ) Relativo a outro segmento, não controlado ou desconhecido
Informações relacionados a estimativa futura dos valores já evidenciados:
5- Qual o ativo total da sua empresa? R: ( X ) Relativo a outro segmento, não controlado ou desconhecido
6- Qual o faturamento médio por cliente dos últimos três períodos? R: Março Abril Maio R$ 110,00 R$ 105,00 R$ 120,00 ( ) Relativo a outro segmento, não controlado ou desconhecido
7- Qual o faturamento total mensal dos últimos três períodos? R: Março Abril Maio R$ 98,00 R$ 82,00 R$ 97,00 ( ) Relativo a outro segmento, não controlado ou desconhecido
8- Qual o faturamento total liquido dos últimos três períodos? R: Março Abril Maio R$ 53.000,00 77.000,00 92.000,00
72
( ) Relativo a outro segmento, não controlado ou desconhecido 9- Qual o saldo final do fluxo de caixa dos últimos três períodos?
R: Março Abril Maio R$ 7.000,00 (R$ 7.000,00) R$ 11.000,00 ( ) Relativo a outro segmento, não controlado ou desconhecido
10- Quais os gastos com a fabricação do produto dos últimos três períodos? R: Março Abril Maio ( X ) Relativo a outro segmento, não controlado ou desconhecido
11- Quais os gastos gerais dos últimos três períodos? R: Março Abril Maio ( X ) Relativo a outro segmento, não controlado ou desconhecido
12- Qual o lucro liquido operacional apresentado nos últimos três períodos? R: Março Abril Maio 8,00% -9,00% 12,50% ( ) Relativo a outro segmento, não controlado ou desconhecido
13- Qual o total de orçamentos aprovados dos últimos três períodos? R: Março Abril Maio 700 710 690 ( ) Relativo a outro segmento, não controlado ou desconhecido
14- Qual o total média de orçamentos elaborados dos últimos três períodos? R: Março Abril Maio 115 118 118 ( ) Relativo a outro segmento, não controlado ou desconhecido
15- Qual a média de produtos com defeito nos últimos três períodos? R: Março Abril Maio ( X ) Relativo a outro segmento, não controlado ou desconhecido
16- Qual a média total de produtos vendidos nos últimos três períodos? R: Março Abril Maio ( X ) Relativo a outro segmento, não controlado ou desconhecido
73
Informações relacionadas a otimização do processo de vendas:
17- Qual os 5 principais produtos da empresa, sua quantidade média de vendas e o lucro obtido com cada um deles no último período? R: Produto Quantidade Lucro ( X ) Relativo a outro segmento, não controlado ou desconhecido
74
Relatório de entrega das estimativas / Formulário de satisfação O relatório é dividido em quatro grupos, as metas que são os valores que a empresa
necessita atingir para obter as margens previamente informadas, as projeções que são os
valores previstos para os próximos períodos em função dos valores informados já ocorridos,
os reajustes que representam o rearranjo das margens do produto em função do mercado
vivenciado, e as otimizações que representam a quantidade necessária estimada de produtos a
serem vendidos/produzidos em função do conjunto de produtos vendidos/produzidos
atualmente.
Para cada um dos valores/indicadores existem dois campos com escalas de 1 a 5
relativos à importância atribuída para o indicador e a expectativa sobre a precisão da
estimativa baseada na sua experiência com estes valores.
Importância
Muito
importante Importante Regular Irrelevante
Muito
irrelevante
1 2 3 4 5
Expectativa
Muito preciso Preciso Regular Impreciso Muito impreciso
1 2 3 4 5
75
Metas estimadas
Controles Estimativa Importância Expectativa
Percentual total
de margens
Markup
percentual
Custo
percentual da
mercadoria
vendida
Margem
percentual de
contribuição
Totalizadores Estimativa Importância Expectativa
Faturamento
total
Saldo fluxo
caixa
Custos fixos
Gastos
fabricação
Faturamento
total liquido
Gastos gerais
Lucro liquido
operacional
total
Faturamento por
cliente
Faturamento
total mês
anterior
Produtos com
76
defeito
Total de
produtos
Ativo total
Orçamentos
aprovados
Orçamentos
elaborados
Indicadores Estimativa Importância Expectativa
Grau de
dependência
Gasto unitário
fabricação
Aumento
faturamento
Qualidade
Lucro liquido
operacional
Resultado
operacional
Eficiência
comercial
77
Projeções estimadas
Totalizadores Estimativa Importância Expectativa
Junho Julho Agosto
Faturamento
total
R$ 63.333 R$ 55.333 R$ 47.333 1 2
Saldo fluxo
caixa
(R$ 23.766) (R$ 30.866) (R$ 37.966) 1 2
Custos fixos R$ 54.000 R$ 54.000 R$ 54.000 2 3
Faturamento
total liquido
R$ 58.333 R$ 50.333 R$ 42.333 1 2
Lucro liquido
operacional total
(R$ 25.136) (R$ 32.746) (40.356) 1 3
Faturamento por
cliente
R$ 99 R$ 96 R$ 94 2 3
Orçamentos
aprovados
721 726 731 2 3
Orçamentos
elaborados
121 123 124 1 2
Indicadores Estimativa Importância Expectativa
Junho Julho Agosto
Grau de
dependência
Gasto unitário
fabricação
Aumento
faturamento
Qualidade
Lucro liquido
operacional
Resultado
operacional
Eficiência
comercial
78
Indicadores
financeiros
Estimativa Importância Expectativa
Valor presente
liquido
Valor presente
liquido
anualizado
Índice beneficio
custo
Retorno
investimento
adicionado
Taxa interna
retorno
Período
recuperação
investimento
Ponto Fischer
79
Reajustes estimados
Reajustes Estimativa Importância Expectativa
Custos fixos percentual
Custos variáveis percentual
Lucro percentual
80
Otimizações estimadas
Produto Quantidade necessária estimada Lucro final obtido:
81
ANEXO A
Autorização para utilização da pesquisa na concepção da monografia
Eu, ______________________________, RG_______________,
CPF_______________ autorizo a utilização e atesto a veracidade dos dados por mim
informados na pesquisa relacionada à concepção da monografia do acadêmico Rudimar
Imhof.
_____________________________________
