1 introdução - Projeto Pesquisa

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 à MercedezBenz 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.
1.1
PROBLEMA
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.
1.2
JUSTIFICATIVA
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.
1.3
OBJETIVOS
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.
2.1
FUNÇÕES DA EMPRESA
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
2.2
GERÊNCIA DE CUSTOS
“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.
PE _ quantidade  Custos _ fixos _ totais  Mar.gem _ contribuiç ão _ unitária
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).
2.3
ELEMENTOS PARA TOMADA DE DECISÃO EXECUTIVA – OS INDICADORES
“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
n
VPL  
t 1
FCt
(1  i ) t
VPLa  VPL *
IBC 
l * (1  i) n
(1  i) n  1
Valor _ presente _ fluxo _ beneficios
Valor _ presente _ fluxo _ investimentos
ROIA  100( n IBC  1)
Atratividade do resultado
VPL > 0
VPLa > 0
IBC > 1
Ganho além da TMA em relação ao risco
23
n
TIR  i , quando, VPL  
j 0
[CFj]
 Zero
(1  i ) j
TIR > TMA
T
PB   CFt  I 0
PB < vida do investimento
t 0
PF  TIR , quando
VPL  ambos _ os _ projetos
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.
2.4
ESTATÍSTICA À TOMADA DE DECISÃO
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.
Yi   0  1 X i   i
Onde:
Yi : variável resposta (dependente);
X i : uma constante conhecida (não é variável aleatória);
 0 _ e _ 1 : 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:
a11 x1  ...  a1n xn  b1
am1 x1  ...  amn xn  bm
Sujeito à: a : x j  0j
Função objetivo:
Min c1 x1  c 2 x 2  ...  c n x n
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
2.5
RACIOCÍNIOS E SEUS TIPOS – ELEMENTOS CONCEITUAIS À TOMADA DE
DECISÃO
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
2.6
CLASSIFICAÇÃO DE SISTEMAS
“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.
Nível
Estratégico
Sistemas de apoio ao
executivo
Nível
Tático
Sistemas de apoio à decisão
Sistemas de informação gerencial
Nível
Operacional
Sistema de processamento de transações
Fonte: Adaptado de Stair e Reynolds (2011).
Figura 2 – Classificação de sistemas
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 referirse 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.
2.7
SUPORTE A DECISÕES
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.
2.8
FRAMEWORK
“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.
2.9
TRABALHOS CORRELATOS
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.
3.1
SISTEMA ATUAL
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.
3.2
ESPECIFICAÇÃO DOS REQUISITOS
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
RF01: O framework deverá fornecer interfaces com implementações de
referência para entrada de dados
RF02: O framework deverá retornar ao sistema lista de metas baseadas
nas margens
RF03: O framework deverá retornar ao sistema lista de projeções
baseadas nos totalizadores informados;
Caso de Uso
UC01
UC02
UC03
38
RF04: O framework deverá retornar ao sistema reajustes baseados nos
totais apresentados
RF05: O framework deverá retornar ao sistema otimizações baseadas nas
informações do processo de aquisição/produção
UC04
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
3.3
ARQUITETURA DO FRAMEWORK
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.
3.4
MODELO DE NEGÓCIOS
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.
3.5
UTILIZAÇÃO DOS RACIOCÍNIOS À TOMADA DE DECISÃO
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.
3.6
PRODUÇÃO DO BSC
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.
3.7
IMPLEMENTAÇÃO
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,
pagamento periódicos;
c) irr(double[] income) – para taxa interna.
double f,
boolean t)
– para
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)
LinearRegression.
chamado pela instanciação de um objeto do tipo
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 LinearRegression();
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, instances);
Double coeficienteCorrelacao = evaluation.correlationCoefficient();
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
org.apache.commons.math3.optimization
objetos
simplex
ficam
no
pacote
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,
constraints,
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.
Figura 9 – Grafo de precedência de cálculos
Indicadores
Totalizadores
Controles
49
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
estimarRegressaoLinear(List<T> ts)
invoca
o
método
público
List<T>
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,constraints,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,
InterfaceIndicadores,
IntenfaceControles,
InterfaceTotalizadores,
InterfaceIndicadoresFinanceiros,
InterfaceProdutoCaracteristica;
InterfaceProduto
e
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 {
public static void main(String[] args) throws Exception {
2
// Heranca das caracteristicas do framework
3
Core core = new Principal();
4
5
// Injeção de depêndencia das entradas
6
7
// Cria uma nova instancia das margens pela referencia da
8
interface
9
10
11
12
13
14
15
16
17
18
19
InterfaceMargens interfaceMargens = new Margens();
interfaceMargens.setCustosFixos(54000.0);
interfaceMargens.setCustosFixosPercentual(64);
interfaceMargens.setCustosVariaveisPercentual(32);
interfaceMargens.setLucroPercentual(4);
// Injeta as margens pela interface
core.setInterfaceMargens(interfaceMargens);
// Injeta referência de novos controles para saída de
dados
InterfaceControles interfaceControles = new Controles();
57
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
int numeroMesesPagamento = 12;
interfaceControles.setNumeroMesesPagamento(numeroMesesPagamento)
;
int taxaDesconto = 5;
interfaceControles.setTaxaDesconto(taxaDesconto);
core.setInterfaceControles(interfaceControles);
// Cria um arraylist pela referencia da interface
ArrayList<InterfaceTotalizadores>
interfaceTotalizadoresPeriodos = new ArrayList<>();
InterfaceTotalizadores interfaceTotalizadores = null;
// Cria uma nova instancia dos indicadores pela referencia
da interface
interfaceTotalizadores = new Totalizadores();
interfaceTotalizadores.setPeriodo(3.0);
Double ativoTotal3 = 0.0;
interfaceTotalizadores.setAtivoTotal(ativoTotal3);
Double custosFixos3 = 54000.0;
interfaceTotalizadores.setCustosFixos(custosFixos3);
Double faturamentoCliente3 = 110.0;
interfaceTotalizadores.setFaturamentoCliente(faturamentoCliente3
);
Double faturamentoTotal3 = 98000.0;
interfaceTotalizadores.setFaturamentoTotal(faturamentoTotal3);
Double saldoFluxoCaixa3 = 7000.0;
interfaceTotalizadores.setSaldoFluxoCaixa(saldoFluxoCaixa3);
Double faturamentoTotalAnterior3 = 82000.0;
interfaceTotalizadores.setFaturamentoTotalAnterior(faturamentoTo
talAnterior3);
Double faturamentoTotalLiquido3 = 93000.0;
interfaceTotalizadores.setFaturamentoTotalLiquido(faturamentoTot
alLiquido3);
Double gastosFabricacao3 = 0.0;
interfaceTotalizadores.setGastosFabricacao(gastosFabricacao3);
Double gastosGerais3 = 0.0;
interfaceTotalizadores.setGastosGerais(gastosGerais3);
Double lucroLiquidoOperacionalTotal3 = 7840.0;
interfaceTotalizadores.setLucroLiquidoOperacionalTotal(lucroLiqu
idoOperacionalTotal3);
Double orcamentosAprovados3 = 700.0;
interfaceTotalizadores.setOrcamentosAprovados(orcamentosAprovado
s3);
Double orcamentosElaborados3 = 115.0;
interfaceTotalizadores.setOrcamentosElaborados(orcamentosElabora
dos3);
// Adiciona os indicadores a lista de periodos pela
referencia da interface
interfaceTotalizadoresPeriodos.add(interfaceTotalizadores);
// Cria uma nova instancia dos indicadores pela referencia
da interface
interfaceTotalizadores = new Totalizadores();
interfaceTotalizadores.setPeriodo(4.0);
Double ativoTotal4 = 0.0;
58
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
interfaceTotalizadores.setAtivoTotal(ativoTotal4);
Double custosFixos4 = 54000.0;
interfaceTotalizadores.setCustosFixos(custosFixos4);
// Continua populando métodos assessores dos arrays
relativos a cada período mensal
// Injeta as lista de indicadores pela interface
core.setInterfaceTotalizadoresPeriodos(interfaceTotalizadoresPer
iodos);
// Injeta referência de novos indicadores para saída de
dados
InterfaceIndicadores interfaceIndicadores = new
Indicadores();
core.setInterfaceIndicadores(interfaceIndicadores);
// Injeta referência de novos indicadores para saída de
dados
InterfaceIndicadoresFinanceiros
interfaceIndicadoresFinanceiros = new IndicadoresFinanceiros();
core.setInterfaceIndicadoresFinanceiros(interfaceIndicadoresFina
nceiros);
// Injeta a lista de produtos e suas caracteristicas
ArrayList<InterfaceProduto> interfaceProdutos = new
ArrayList<>();
for (int j = 0; j < 1; j++) {
InterfaceProduto interfaceProduto = new Produto();
List<InterfaceProdutoCaracteristica>
interfaceProdutoCaracteristicas = new ArrayList<>();
for (int k = 0; k < 0; k++) {
InterfaceProdutoCaracteristica
interfaceProdutoCaracteristica = new ProdutoCaracteristica();
String nome = "nome" + k;
interfaceProdutoCaracteristica.setNome(nome);
Double valor = (double) k;
interfaceProdutoCaracteristica.setValor(valor);
interfaceProdutoCaracteristicas.add(interfaceProdutoCaracteristi
ca);
}
interfaceProduto.setInterfaceProdutoCaracteristicas(interfacePro
dutoCaracteristicas);
Double lucro = 100.00 * j;
interfaceProduto.setLucro(lucro);
interfaceProdutos.add(interfaceProduto);
}
// Construir estimativas
// Metas
Controles metasControles = (Controles)
core.estimarMetasControles();
59
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
System.out.println("Metas controles");
System.out.println(metasControles.getCustoPercentualMercadoriaVe
ndida());
System.out.println(metasControles.getMargemPercentualContribuica
o());
System.out.println(metasControles.getMargensPercentualTotal());
System.out.println(metasControles.getMarkupPercentual());
Totalizadores metasTotalizadores = (Totalizadores)
core.estimarMetasTotalizadores();
System.out.println("Metas totalizadores");
System.out.println(metasTotalizadores.getFaturamentoTotal());
System.out.println(metasTotalizadores.getGastosGerais());
System.out.println(metasTotalizadores.getGastosFabricacao());
System.out.println(metasTotalizadores.getFaturamentoTotalLiquido
());
System.out.println(metasTotalizadores.getLucroLiquidoOperacional
Total());
Indicadores metasIndicadores = (Indicadores)
core.estimarMetasIndicadores();
System.out.println("Metas indicadores");
System.out.println(metasIndicadores.getGastoUnitarioFabricacao()
);
System.out.println(metasIndicadores.getLucroLiquidoOperacional()
);
// Projeções
ArrayList<Totalizadores> projecoesTotalizadores = (ArrayList)
core.estimarProjecoesTotalizadores();
System.out.println("Projecoes totalizadores");
for (Totalizadores totalizadores : projecoesTotalizadores)
{
System.out.println("Projecao");
System.out.println(totalizadores.getPeriodo());
System.out.println(totalizadores.getAtivoTotal());
System.out.println(totalizadores.getCustosFixos());
System.out.println(totalizadores.getFaturamentoCliente());
System.out.println(totalizadores.getFaturamentoTotal());
System.out.println(totalizadores.getFaturamentoTotalAnterior());
System.out.println(totalizadores.getFaturamentoTotalLiquido());
System.out.println(totalizadores.getGastosFabricacao());
System.out.println(totalizadores.getGastosGerais());
System.out.println(totalizadores.getLucroLiquidoOperacionalTotal
());
System.out.println(totalizadores.getOrcamentosAprovados());
System.out.println(totalizadores.getOrcamentosElaborados());
System.out.println(totalizadores.getProdutosDefeito());
System.out.println(totalizadores.getProdutosTotal());
System.out.println(totalizadores.getSaldoFluxoCaixa());
}
System.out.println("Projecoes indicadores");
ArrayList<Indicadores> projecoesIndicadores = (ArrayList)
core.estimarProjecoesIndicadores();
60
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
for (Indicadores indicadores : projecoesIndicadores) {
System.out.println("Indicadores");
System.out.println(indicadores.getAumentoFaturamento());
System.out.println(indicadores.getEficienciaComercial());
System.out.println(indicadores.getGastoUnitarioFabricacao());
System.out.println(indicadores.getGrauDependencia());
System.out.println(indicadores.getLucroLiquidoOperacional());
System.out.println(indicadores.getQualidade());
System.out.println(indicadores.getResultadoOperacional());
}
IndicadoresFinanceiros projecoesIndicadoresFinanceiros =
(IndicadoresFinanceiros)
core.estimarProjecoesIndicadoresFinanceiros();
System.out.println("Projecoes indicadores financeiros");
System.out.println(projecoesIndicadoresFinanceiros.getPontoFisch
er());
System.out.println(projecoesIndicadoresFinanceiros.getRetornoInv
estimentoAdicionado());
System.out.println(projecoesIndicadoresFinanceiros.isRetornoInve
stimentoAdicionadoViavel());
System.out.println(projecoesIndicadoresFinanceiros.getTaxaIntern
aRetorno());
System.out.println(projecoesIndicadoresFinanceiros.isTaxaInterna
RetornoViavel());
System.out.println(projecoesIndicadoresFinanceiros.getValorPrese
nteLiquido());
System.out.println(projecoesIndicadoresFinanceiros.isValorPresen
teLiquidoViavel());
System.out.println(projecoesIndicadoresFinanceiros.getValorPrese
nteLiquidoAnualizado());
System.out.println(projecoesIndicadoresFinanceiros.isValorPresen
teLiquidoAnualizadoViavel());
System.out.println(projecoesIndicadoresFinanceiros.getIndiceBene
ficioCusto());
System.out.println(projecoesIndicadoresFinanceiros.isIndiceBenef
icioCustoViavel());
System.out.println(projecoesIndicadoresFinanceiros.getPeriodoRec
uperacaoInvestimento());
System.out.println(projecoesIndicadoresFinanceiros.isPeriodoRecu
peracaoInvestimentoViavel());
// Reajustes
Margens reajustes = (Margens) core.estimarReajustes();
System.out.println("Margens");
System.out.println(reajustes.getCustosFixos());
System.out.println(reajustes.getCustosFixosPercentual());
System.out.println(reajustes.getCustosVariaveisPercentual());
System.out.println(reajustes.getLucroPercentual());
// Otimizações
ArrayList<InterfaceProduto> interfaceProdutosOtimizacoes =
(ArrayList<InterfaceProduto>) core.estimarOtimizacoes();
for (InterfaceProduto interfaceProdutoOtimizacoes :
interfaceProdutosOtimizacoes) {
61
189
190
191
System.out.println("Quantidade");
System.out.println(interfaceProdutoOtimizacoes.getQuantidade());
}
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.
3.8
RESULTADOS E DISCUSSÃO
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.
4.1
EXTENSÕES
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-decisaoerrada-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/produtosservicos/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ãocontadores: 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%C
3%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
investimentos: Fundamentos, técnicas e aplicações. 5. ed. São Paulo: Atlas, 2004. 178 p.
de
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
1
Muito
Importante
Regular
Irrelevante
2
3
4
5
irrelevante
Expectativa
Muito preciso
Preciso
Regular
Impreciso
Muito impreciso
1
2
3
4
5
75
Metas estimadas
Controles
Estimativa
Importância Expectativa
Estimativa
Importância Expectativa
Percentual total
de margens
Markup
percentual
Custo
percentual da
mercadoria
vendida
Margem
percentual de
contribuição
Totalizadores
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
Grau de
dependência
Gasto unitário
fabricação
Aumento
faturamento
Qualidade
Lucro liquido
operacional
Resultado
operacional
Eficiência
comercial
Estimativa
Importância Expectativa
77
Projeções estimadas
Totalizadores
Estimativa
Junho
Importância Expectativa
Julho
Agosto
R$ 63.333
R$ 55.333
R$ 47.333
1
2
(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
R$ 58.333
R$ 50.333
R$ 42.333
1
2
(R$ 25.136)
(R$ 32.746)
(40.356)
1
3
R$ 99
R$ 96
R$ 94
2
3
721
726
731
2
3
121
123
124
1
2
Faturamento
total
Saldo fluxo
caixa
total liquido
Lucro liquido
operacional total
Faturamento por
cliente
Orçamentos
aprovados
Orçamentos
elaborados
Indicadores
Estimativa
Junho
Grau de
dependência
Gasto unitário
fabricação
Aumento
faturamento
Qualidade
Lucro liquido
operacional
Resultado
operacional
Eficiência
comercial
Julho
Importância Expectativa
Agosto
78
Indicadores
financeiros
Valor presente
liquido
Valor presente
liquido
anualizado
Índice beneficio
custo
Retorno
investimento
adicionado
Taxa interna
retorno
Período
recuperação
investimento
Ponto Fischer
Estimativa
Importância Expectativa
79
Reajustes estimados
Reajustes
Custos fixos percentual
Custos variáveis percentual
Lucro percentual
Estimativa
Importância
Expectativa
80
Otimizações estimadas
Produto
Lucro final obtido:
Quantidade necessária estimada
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.
_____________________________________