capítulo i - uenf.br(datasul). 5 – treinar os ... necessárias ao processo...

1

CAPÍTULO I

INTRODUÇÃO

1.1 CONTEXTO

Nas duas últimas décadas ocorreram profundas mudanças nos sistemas produtivos.

A globalização da economia, acirrando a concorrência, e a inovação tecnológica,

propondo novas formas de fabricação e comunicação, forçaram as empresas a

repensar sua estrutura de produção (TUBINO, 2000).

Segundo Dalmoro (2003), vivencia-se uma realidade onde a globalização da

economia é cada vez mais freqüente. Neste cenário, a competitividade entre as

empresas tende a aumentar cada vez mais. Empresas precisam ser competitivas e,

para tanto, buscam desenvolver produtos com altos padrões de qualidade, que

atendem às necessidades dos seus clientes. Além disso, devem possuir sistemas de

produção flexíveis e produtivos, com capacidade e flexibilidade para se adaptar

rapidamente às mudanças impostas pelas necessidades do mercado. Logo, a

capacidade de competitividade das empresas está diretamente associada à

flexibilidade e à habilidade que possuem para responder pró ativamente às novas

exigências dos clientes, e às mudanças do mercado ou da sociedade.

Em meio a todas essas mudanças, entre outras necessidades, urge encontrar um

modelo mais adequado possível para se realizar a previsão de demanda dos

produtos da empresa.

Um modelo de empresa, segundo Dalmoro (2003), é uma representação

computacional da estrutura, atividades, processos, informações, recursos, pessoas,

comportamentos, metas e restrições de um negócio, governo ou outra empresa.

A modelagem de empresa corresponde à documentação das características de uma

organização a partir de seus processos de negócios. A documentação é realizada

utilizando-se modelos para registrar os processos, recursos, estrutura,

organizacional e sistema de informação (DALMORO 2003).

2

Segundo Vernadat (1996), modelagem de empresa é um conjunto de atividades ou

processos usados para desenvolver as várias partes de um modelo de empresas

para atingir alguma finalidade desejada e tem por propósito:

� Projetar ou reprojetar, integrar e especificar uma parte da empresa (aspectos

funcionais, comportamentais, de informação, de organização ou aspectos

estruturais como estruturas de decisão);

� Melhor representar e entender como a empresa (ou alguma parte) funciona;

� Capitalizar o conhecimento adquirido ou Know-how para posterior uso;

� Racionalizar e assegurar o fluxo de informação;

� Analisar algum aspecto da empresa (análise econômica, análise organizacional,

análise quantitativa, análise qualitativa, layout de equipamentos, etc);

� Simular o comportamento de alguma parte da empresa;

� Tomar melhores decisões sobre a operação e organização da empresa;

� Controlar, coordenar ou monitorar alguma parte da empresa (isto é, algum

processo).

A experiência tem mostrado que o projeto e integração de empresa são um

empreendimento complexo e de alto risco e para adquirir eficiência no projeto e

integração, novas metodologias, técnicas e ferramentas computacionais devem ser

utilizadas para tratar esta complexidade, além do uso de modelos de referência.

Modelos de referência significam modelos de empresas construídos por

fornecedores comerciais de sistemas ou por instituições de pesquisa acadêmica,

que podem ser facilmente adaptados a cada empresa em particular, isto é, com

menor esforço de projeto (CAMPOS, 1998).

1.2 OBJETIVO

Baseado nos modelos de referência de processos de previsão de demanda e

respectivo modelo de sistema de informação proposto por Santos (2001), o objetivo

deste trabalho é implementar na prática os processos e um módulo de sistema de

informação para a previsão de demanda em uma indústria de auto peças, e assim

analisar as funcionalidades e aplicabilidade desses modelos de referência. O

sistema de informação será desenvolvido em Java e será integrado ao ERP da

empresa.

3

1.3 JUSTIFICATIVA

Em geral, as empresas, principalmente de pequeno e médio porte, não realizam

previsão de demanda de produtos como prática integrada a seus procedimentos

habituais. Em alguns casos utilizam apenas procedimentos qualitativos e opiniões.

Segundo Fleury et al. (2000), a não documentação desses processos é comum nas

empresas.

O relacionamento entre consumidores e fornecedores sofre mudanças contínuas

dadas às pressões competitivas da indústria, forçando modificações significativas

nas relações entre a linha de produção e seus fornecedores (FLYNN at al, 1996).

Segundo Proto & Mesquita (2003), a atividade de planejamento da capacidade é de

grande importância dentro do processo de planejamento estratégico de empresas de

capital intensivo. Um dos pré-requisitos para um bom planejamento de capacidade é

dispor de sistema de previsão de demanda consistente.

Mediante as inúmeras inovações que estamos vivendo, e a necessidade de

encontrarmos modelos de previsão de demanda que atendam melhor as

necessidades de melhoria na gestão de produção, é intenção testar os modelos

teóricos de Santos (2001), aplicando-os em um estudo de caso.

Para tanto será utilizado uma estimulante plataforma a Java. Segundo Lopes (2004)

a Java além de ser uma ótima linguagem de programação para a Internet, a

tecnologia Java está equipada para dominar o mundo da programação para

computadores em geral, e também o mundo dos sistemas embutidos. Um único

aplicativo Java pode rodar em diferentes plataformas, pois o compilador Java gera

um tipo de código especial, chamado bytecode.

Campos & Santos (2000), propõem um modelo de referência que visa possibilitar o

aprendizado e aplicação dos conhecimentos que definem como cada etapa do

processo deve ser realizado para que possa ser empregado no ambiente

empresarial. O que se espera é a formalização e domínio de conhecimentos e o

emprego do modelo como referência para a reengenharia dos processos e sistemas

de informação.

4

Segundo Eriksson & Penker (2000) apud Santos (2001), os modelos possibilitam o

aumento do atendimento do negócio promovendo a percepção de novas

oportunidades para a sua melhoria. A partir do modelo, é possível então adaptar,

projetar ou desenvolver um sistema de informação (software) apropriado para

suportar o funcionamento do negócio. Assim, o modelo de empresa possibilitará um

projeto de sistema de informação com maior consistência, uma vez que toda a

realidade da empresa será levantada e as verdadeiras necessidades do negócio

conhecidas, organizadas e registradas do modelo.

Através deste trabalho, buscaremos identificar os pontos positivos e negativos

contidos no trabalho de Santos (2001) visando o levantamento e adequações

necessárias para o uso dos modelos de referência que foram propostos com base

puramente teórica.

1.4 METODOLOGIA DE TRABALHO

Para atingir os objetivos deste trabalho, faz-se necessário:

1 - Estudar o modelo de referência contido no trabalho de Santos (2001), com a

finalidade de aplicação na área de previsão de demanda de produtos.

2 - Definir os requisitos da Empresa Particular (uma indústria de auto peças)

considerando os níveis desejados de desempenho (redução de custos e estoque,

sem prejuízo quanto ao prazo de entrega para os clientes).

3 - Desenvolver modelos particulares da empresa baseados nos modelos de

referência de processos e de sistema de informação contidos no trabalho de Santos

(2001), e nos requisitos particulares da empresa.

4 - Implementar os modelos particulares de processos e desenvolver o módulo de

sistemas de informação em Java utilizando a base de dados do ERP da empresa

(Datasul).

5 – Treinar os funcionários da empresa envolvidos na previsão de demanda de

produtos e testar os processos e sistemas de informação originários dos modelos

particulares propostos.

5

6 - Operar com o sistema durante um período de 4 a 6 meses.

7 - Analisar as possíveis dificuldades, tanto de implementação como de operação, e

aprimorar a acurácia, priorizando uma melhor previsão de demanda, através da

operação do sistema.

8 - Verificar resultados, medir o desempenho através dos possíveis benefícios dos

processos de previsão de demanda e respectivo Sistema de Informação.

1.5 ESTRUTURA DA DISSERTAÇÃO

Este trabalho é composto por 6 capítulos, onde:

O capítulo I apresenta uma introdução composta pelo contexto, objetivo, justificativa,

metodologia do trabalho e estrutura da dissertação.

O capítulo II aborda a administração da produção, em especial sobre a gestão da

demanda, nos advertindo sobre sua importância e relatando propostas e

procedimentos para uma melhor previsão de demanda.

O capítulo III aborda a modelagem de empresas apresentando alguns conceitos

básicos. Apresenta a linguagem de modelagem CIMOSA e a linguagem de

modelagem de sistemas orientada a objetos UML.

O capítulo IV, apresenta os processos de empresa e do modelo de informação, da

aplicação teórica de auxílio a previsão de demanda de produtos, contido no trabalho

de Santos (2001).

O capítulo V apresenta a aplicação do modelo de referência ressaltando as

diferenças com o modelo particular da empresa e apresentando uma análise sobre a

aplicabilidade do modelo de referência.

No capítulo VI são apresentadas as conclusões e perspectivas do trabalho.

6

CAPÍTULO II

GESTÃO DA DEMANDA

Neste capítulo será feita uma revisão da literatura visando uma melhor abordagem

sobre administração da produção e gestão da demanda, que visa conciliar os fatores

que impactam a relação empresa e o mercado.

2.1 ADMINISTRAÇÃO DA PRODUÇÃO E A DEMANDA

A gestão da produção está na essência da vida empresarial, uma vez que

representa o ato de criação. Uma vez que a criação de produtos e serviços é a

principal razão da existência de qualquer organização, a administração da produção

deve ser o centro de suas atividades (SLACK et al.,1997).

É sabido que a empresa existe para reproduzir seu capital, desta forma devem ser

observados vários aspectos que podem influenciar a escolha do cliente e que ao

mesmo tempo, estão dentro do escopo de atuação da função das operações

produtivas da organização: custo, velocidade de entrega, confiabilidade,

flexibilidade, qualidade, serviços (CORRÊA et al., 2001).

Observando esses aspectos ficará mais fácil alcançar os mercados demandantes.

Uma vez que não há mercados demandantes suficientes para todos os ofertantes

colocarem seus produtos, alguns conseguirão fazê-lo e outros não. O que fará a

diferença é oferecer o que lhes mais interessa (CORRÊA et al., 2001).

São de enorme importância as informações para o apoio a tomada de decisões,

táticas e operacionais como: o que, quando e com que recursos produzir e comprar;

para que sejam atingidos os objetivos estratégicos da organização (CORRÊA et al.

2001).

A previsão é uma informação indispensável para o planejamento da produção,

vendas e finanças de uma empresa, permitindo aos administradores antever o futuro

e planejar adequadamente ações para o desenvolvimento de planos de capacidade,

fluxo de caixa, vendas, produção, estoques, mão de obra, compras, etc (SANTOS,

2001).

7

Na literatura pode-se encontrar vários trabalhos e pesquisas na área de previsão de

demanda. Eles possuem características diferentes, e se concentram em uma ou

mais questões (modelos, algoritmos, descrição de procedimentos, software, etc),

sendo que estes trabalhos se complementam (SANTOS & CAMPOS 2000).

Segundo Tubino (1998), existem várias técnicas e modelos para a previsão de

demanda. Apesar da evolução dos recursos computacionais e da sofisticação

matemática das técnicas e modelos para a previsão da demanda dos produtos, ela

não é uma ciência exata e envolve uma boa dose de experiência e julgamento

pessoal do planejador. O valor previsto será sempre uma aproximação do valor real.

Porém, quanto mais apurada a técnica empregada, melhor a base na qual o

planejador decidirá.

Martins & Laugeni (2002) nos advertem quanto a importância da previsão pois nos

permitem utilizar as máquinas de maneira adequada, para realizar a reposição dos

materiais no momento e na quantidade certa, e para que todas as demais atividades

necessárias ao processo industrial sejam adequadamente programadas. Apesar de

as previsões serem importantes e úteis para o planejamento das atividades, elas

apresentam erros em suas estimativas, devendo-se ser cuidadoso tanto na coleta de

dados como na escolha do modelo de previsão, para que diminuam os erros. Um

dos pré-requisitos para um bom planejamento da capacidade é dispor de um sistema

de previsão de demanda consistente.

Segundo Tubino (2000) a previsão de demanda é a variável mais importante dentro

de um sistema de produção e seguem ou deveriam seguir alguns passos: o objetivo,

a coleta e a análise dos dados, a seleção da técnica de previsão, a obtenção das

previsões e o monitoramento do modelo. Monks (1987) conceitua previsões como

avaliações de ocorrências de eventos futuros incertos. E que a mesma tem como

propósito usar a melhor informação disponível para dirigir atividades futuras em

direção às metas da empresa.

Pacheco & Silva (2003) apresentam a previsão de demanda como uma estrada para

o planejamento de capacidade, programação de parada de ativos para manutenção,

definição de níveis de serviço, entre outros. Contrariamente ao que ocorre com os

8

produtos, não é possível estocar serviços não prestados durante os períodos de

menor demanda para o atendimento em período de alta demanda (CORRÊA &

GIANESI, 1994). Percebe-se portanto, que uma questão crucial no setor de serviços

é o dimensionamento da capacidade a ser adicionada, e também em quando

expandi-la. Capacidade ociosa pode implicar em elevados custos unitários para o

serviço prestado, enquanto falta de capacidade pode, implicar em deterioração dos

níveis de serviço prestados ao cliente (PACHECO & SILVA, 2003).

O processo de Gestão de Demanda tem apresentado um grande destaque no meio

empresarial devido a sua responsabilidade com relação à coordenação do

relacionamento entre o ambiente produtivo da empresa e seu mercado consumidor.

Além disso, cada vez mais novos sistemas computacionais são disponibilizados no

mercado e se tornam acessíveis a um grupo maior de empresas (AZEVEDO et al.,

2003).

Segundo Saliby (2003), quem atua na gestão de produção deverá estar atento a

vários fatores, dentre eles a sazonalidade. A demanda por produtos e serviços é

geralmente influenciada por componentes sazonais que devem ser levados em

conta para uma utilização mais eficiente dos recursos e oportunidades disponíveis.

Desta forma, entra a importância do planejamento que deve seguir alguns passos:

1- Levantamento da situação presente;

2- Desenvolvimento e reconhecimento da “visão” de futuro, com ou sem

intervenção;

3- Tratamento conjunto da situação presente e da “visão” de futuro por alguma

lógica que transforme os dados coletados sobre o presente e o futuro em

informações que passam a ser disponibilizadas numa forma útil para a tomada de

decisão gerencial logística;

4- Tomada de decisão gerencial;

5- Execução do plano.

Mesmo quando planejamos nos deparamos com algumas incertezas da previsão.

Em geral, as previsões de mais longo prazo são feitas sob condições de maior

incerteza. (CORRÊA et al., 2001)

9

Do ponto de vista da produção e logística, o mundo ideal seria aquele em que a

produção e demanda por um produto ou serviço fosse o mais estável possível,

exigindo assim um mínimo de intervenção no processo. Mas, felizmente ou

infelizmente, o mundo nunca é como gostaríamos que fosse! (SALIBY, 2003)

Assim como a produção, a demanda da empresa também deve ser gerenciada,

devido a alguns fatores (CORRÊA et al, 2001):

1. Poucas empresas podem alterar os volumes de produção de um período para

outro, de forma a atender às variações da demanda;

2. Para muitas empresas, principalmente aquelas multidivisionais, ao menos parte

da demanda não vem do ambiente externo, mas de outras divisões ou de

subsidiárias, o que permite esforços de administração de demanda;

3. Empresas que têm relações de parcerias com seus clientes podem negociar

quantidade e momento da demanda por eles gerada, de modo a melhor adaptá-

la a suas possibilidades de produção;

4. A demanda de muitas empresas, principalmente as que produzem produtos de

consumo, pode ser criada ou modificada, tanto em termos de quantidade quanto

de momento, por meio de atividade de Marketing, promoções, propaganda,

esforço de venda, entre outros;

5. Mesmo empresas que produzem outros tipos de produtos, que não de consumo,

podem exercer influência sobre a demanda por meio de esforço de venda,

mediante sistemas indutores de comportamento de seus vendedores e

representantes comerciais (sistema de cotas e comissões variáveis, por

exemplo).

2.2 FATORES DE RELEVÂNCIA NA GESTÃO DE DEMANDA

Segundo Dias (1999), em geral os trabalhos encontrados na literatura sobre previsão

concentra-se nas questões quantitativas. Só mais recentemente tem se dado mais

atenção ao tratamento do processo de previsão como um todo.

10

CORRÊA et al. (2001), na figura 2.1, apresenta os principais elementos da Gestão

de Demanda:

1- Habilidade para prever a Demanda – É muito importante que a empresa saiba

utilizar todas as ferramentas disponíveis para conseguir antecipar a demanda

futura com alguma precisão. Isso pode envolver formar e manter uma base de

dados históricos de vendas, assim como informações que expliquem suas

variações e comportamento no passado, utilizar modelos matemáticos

adequados que ajudem a explicar o comportamento da demanda, compreender

como os fatores ou variáveis internas (promoções, etc.) e externas (clima,

condições econômicas, etc.) influenciam o comportamento da demanda, coletar

informações relevantes do mercado e ser capaz de derivar daí uma estimativa da

demanda futura;

2- Canal de Comunicação com o Mercado – A empresa geralmente está

preocupada somente em vender, desprezando uma função extremamente

importante: trazer informações dos clientes e do mercado para a empresa, em

base contínua e permanente;

3- Poder de Influência sobre a Demanda – Além de tentar prever o

comportamento da demanda é fundamental que a empresa procure influenciá-lo.

Esta influência pode dar-se sobre a demanda já manifesta ou sobre a demanda

que vai acontecer. Em qualquer circunstância, é importante que as ações

desferidas pela empresa para influenciar sua demanda sejam conhecidas e

levadas em conta na previsão de vendas futuras. Embora óbvia, nem sempre

Gestão de

Demanda

Influência sobre o

mercado

Previsão de

demanda

Promessa de

prazos

Comunicação com o mercado

Priorização e

alocação

Figura 2.1 – Elementos de Gestão de Demanda (CORRÊA et al., 2001)

11

essa preocupação está presente, fazendo com que as previsões incorporem

incertezas geradas pelo desconhecimento que os responsáveis pelas previsões

têm das ações da área comercial;

4- Habilidades de Prometer Prazos – Importante para garantir o desempenho em

confiabilidade de entregas, a atividade de promessa de prazo também é de

responsabilidade de quem faz a gestão da demanda;

5- Habilidade de Priorização e Alocação - O objetivo do planejamento é criar

condições para que a empresa consiga atender a toda a demanda dos clientes.

Contudo, se ocorre de não haver produtos suficientes ou se os recursos e

materiais necessários não estão disponíveis, é preciso decidir quais clientes

serão atendidos total ou parcialmente e quais terão de esperar.

Segundo Corrêa et al. (2001), a gestão da demanda é uma função ativa e essencial

para o bom desempenho do planejamento. Os principais processos operacionais da

função de gestão de demanda são:

� Processo de previsão de vendas;

� Processo de cadastramento de pedidos;

� Processo de promessa de data de entrega;

� Processo de definição e avaliação do nível de serviço ao cliente;

� Processo de planejamento de necessidades entre unidades produtivas e centros

de distribuição;

� Processo de distribuição física de produtos aos clientes e/ou centros de

distribuição.

Como visto anteriormente, a previsão da demanda é uma das funções da gestão da

demanda.

2.3 FATORES QUE PODEM AFETAR O DESEMPENHO DE UM MODELO DE

PREVISÃO SEGUNDO TUBINO (2000)

Segundo Tubino (2000), alguns fatores afetam o desempenho de um modelo de

técnica de previsão:

� A técnica de previsão pode estar sendo usada incorretamente, ou sendo mal

interpretada;

12

� A técnica de previsão perdeu a validade devido a uma mudança em uma

variável importante, ou devido ao aparecimento de uma nova variável;

� Variações irregulares na demanda pode ter acontecido em função de greves,

formação de estoques temporários, catástrofes naturais, etc;

� Ações estratégicas de concorrência, afetando a demanda;

� Variações aleatórias inerentes aos dados de demanda (TUBINO 2000).

2.4 COMPLEXIDADES E INCERTEZAS DA PREVISÃO

Segundo Diaz & Pires (2003), a previsão da demanda é uma etapa crítica para todos

os membros de uma cadeia de suprimentos devido à complexidade e às incertezas

intrínsecas a suas atividades.

Quando falamos em gerenciamento de demanda vem nos à mente quem é

responsável pela gestão de demanda. É sabido, que em algumas empresas, tem se

adotado a alternativa de criar uma área específica para cuidar da gestão de

demanda, que funcionalmente, pode estar ligada à diretoria comercial, à diretoria

industrial, à diretoria logística ou à diretoria financeira. O importante é que o

responsável por essa área seja capaz de articular a participação das demais áreas,

garantindo a obtenção das informações e o comprometimento adequado de todos

(CORRÊA et al., 2001).

O gerenciamento da demanda é um fator importante para a integração das

empresas que compõem a cadeia de suprimentos. Uma gestão integrada da

demanda na cadeia produtiva compreendida pelos fornecedores, fabricantes,

distribuidores e varejistas, levará a maior precisão dos dados trocados dentro da

cadeia, minimizando a propagação de erros de previsão, reduzindo as incertezas na

gestão da capacidade produtiva, diminuindo os estoques, entre outras vantagens

(DIAZ & PIRES, 2003).

O planejamento da produção de qualquer empresa que produz para estoque se

inicia com a análise da previsão da demanda futura. Desta análise será definido o

que produzir, em que quantidade e quando produzir. A oferta e a procura, porém,

modificam-se constantemente (PORTER, 1996). O grau de complexidade do

gerenciamento da demanda depende de negócio para negócio. Por exemplo, nas

13

empresas que produzem sob encomenda (make to order) a gestão é facilitada, pois

esta empresa trabalha com pedidos em carteira. Já para empresas que produzem

para estoque (make to stock) a sua gestão se baseia na previsão de vendas

(forecasting), e portanto sujeitas a todas as desvantagens e riscos inerentes a uma

previsão (PIRES & MUSETTI, 2001). Mesmo para empresas que produzem sob

encomendas (make to order), a gestão de demanda também se torna bastante

incerta se for considerado um cenário de longo prazo, além dos pedidos existentes

em carteira.

Segundo Slack et al. (1997), vários fatores podem influenciar na demanda:

� Habilidade na mão de obra;

� Adequação do local em si;

� Imagem do local;

� Conveniência para os clientes;

� Escolha do local.

Segundo Tubino (2000), alguns cuidados básicos devem ser tomados na coleta e

análise dos dados, entre eles os seguintes:

• Quantos mais dados históricos forem coletados e analisados, mais confiável a

técnica de previsão será;

• Os dados devem buscar a caracterização da demanda pelos produtos da

empresa, que não é necessariamente igual as vendas passadas, pois pode ter

ocorrido falta de produtos, postergando as entregas ou deixando de atendê-las;

• Variações extraordinárias da demanda, como promoções especiais ou greves,

devem ser analisadas e substituídas por valores médios, compatíveis com o

comportamento normal da demanda;

• O tamanho do período de consolidação dos dados (semanal, mensal, trimestral,

anual, etc.).

Com a definição da técnica de previsão e a aplicação dos dados passados para

obtenção dos parâmetros necessários, podemos obter as projeções futuras da

demanda. Quanto maior for o horizonte pretendido, menor a confiabilidade na

demanda prevista (TUBINO, 2000).

14

À medida que as previsões forem sendo alcançadas pela demanda real, Tubino

(2000) considera importante monitorar a extensão do erro entre a demanda real e a

prevista, para verificar se a técnica e os parâmetros empregados ainda são válidos.

Em situações normais, um ajuste nos parâmetros do modelo, para que reflita as

tendências mais recentes, é suficiente. Em situações críticas, um reestudo desde o

primeiro passo (o objetivo do modelo) pode incluir um novo exame dos dados e a

escolha de uma nova técnica de previsão.

2.5 PROCEDIMENTOS PARA UMA MELHOR PREVISÃO DE DEMANDA

Existem vários procedimentos ou processos propostos para a previsão de demanda

na teoria.

2.5.1 PROCESSO DE PREVISÃO SEGUNDO BRANDER (1995)

Este processo de previsão está esquematizado figura 2.2.

� COLETAR E ANALISAR OS DADOS

Após digitados no sistema os dados devem ser avaliados, ou seja, é necessária

uma análise exploratória dos dados para que possíveis distorções sejam retiradas

dos históricos. Essas distorções podem ser causadas por: erro na digitação dos

dados; falta de produtos; especulação do mercado sobre variações de preço;

OK Revisar o modelo

Monitoramento dos

erros

N

Coletar e Analisar os

dados

Módulo de Previsão

Cálculo da Previsão

Previsão Final

Vendas

Os erros estão satisfatórios?

S

Figura 2.2 – Processo de Previsão (adaptado de BRANDER, 1995)

15

eventos esporádicos que têm relação com a demanda; expectativas de promoções,

etc. Além disso, para previsão é importante trabalhar com dados de demanda e não

de entregas ou faturamento. Isso exige outro “filtro manual” dos dados na entrada

dos sistema de previsão.

� FAZER A PREVISÃO QUANTITATIVA – RECURSO COMPUTACIONAL

Esse é o momento em que as técnicas quantitativas de previsão devem ser

aplicados aos dados. As técnicas quantitativas podem ser classificados em duas

categorias: as Séries Temporais e os Modelos Causais. A principal diferença está

nas premissas dos modelos: os modelos causais procuram relações do tipo “causa e

efeito” para explicar o comportamento variável. Já as séries Temporais se baseiam

na hipótese de que o futuro será uma continuação ou repetição do passado.

Atualmente, o computador tem tido papel fundamental para a aplicação de tais

técnicas.

� REVISAR A PREVISÃO

Para rever as previsões algumas questões devem ser respondidas.

• O resultado do modelo matemático é factível? As premissas adotadas na

construção do modelo continuam válidas?

• As informações sobre os consumidores, concorrentes, distribuidores, estão

disponíveis? Sem elas os dados históricos não passam de um “amontoado de

números”, que muitas vezes não ajudam a entender a demanda e, portanto prevê-la.

• Existe algum esforço especial de marketing? Se existe, qual o resultado

esperado?

• Ocorrerá algum evento que afete a demanda?

� MONITORAR O ERRO

O erro de previsão vai sempre existir devido à componente aleatória da demanda.

Entretanto é importante acompanhá-lo para garantir que esteja dentro dos limites

aceitáveis, e para evitar o viés.

16

2.5.2 PROCESSO DE PREVISÃO SEGUNDO DIAS (1999)

DIAS (1999), apresenta uma outra abordagem proposta por Kress & Snyder (1994).

Sua sugestão está descrita a seguir e está esquematizada na figura 2.3.

• DEFINIR O PROPÓSITO DA PREVISÃO

Porque a previsão é necessária? Como os resultados serão usados? Que tipo de

decisão será tomada com a previsão? Estas questões irão influir nas características

chaves da previsão descritas a seguir.

• IDENTIFICAR AS CARACTERÍSTICAS CHAVE DA PREVISÃO

Qual a agregação por região? A previsão deve ser feita para cada região ou para um

país como um todo? Qual o nível de detalhe necessário? Qual agregação por

produto? A previsão deve ser feita por produto, família de produtos, modelos? Qual

a extensão dos períodos de previsão? As previsões devem ser feitas por mês,

quinzena, semana, dia? Qual o horizonte da previsão? Quantos períodos são

necessários de antecedência?

1- Definir o propósito da previsão

2- Identificar as características chaves da previsão

3- Identificar forças internas e externas

4- Selecionar o modelo mais apropriado

5- Fazer uma previsão inicial

6- Revisar a previsão com os usuários

7- Fazer a previsão formal

8- Monitorar o erro

Figura 2.3 – Processo de Previsão (adaptado de Kress & Snuder 1994)

17

• IDENTIFICAR FORÇAS INTERNAS E EXTERNAS

Fatores que influenciam a demanda como as forças internas são mais fáceis de

identificar como mudanças na planta da fábrica, lançamento de novos produtos,

dados históricos de vendas, etc. Já as forças externas como nível de atividades

econômica, ações de governo, ações dos competidores, etc. são mais difíceis de

obter, mas também podem ser valiosas fontes de informação à previsão.

• SELECIONAR O MODELO MAIS APROPRIADO

A seleção do modelo mais apropriado é função de 6 fatores: horizonte de previsão;

acurácia desejada; padrões da demanda; custo da técnica; disponibilidade de dados

e complexidade dos modelos.

• FAZER UMA PREVISÃO INICIAL

Depois que as forças internas e externas foram consideradas e o modelo foi

selecionado, então a previsão inicial deve ser elaborada. Na construção da previsão

inicial as condições de mercado e o plano de marketing devem ser considerados.

Com a utilização de informações que inserem as previsões em seu contexto, as

distorções serão evitadas.

• REVISAR A PREVISÃO COM BASE NA PERCEPÇÃO DOS USUÁRIOS DA

PREVISÃO

A previsão deve ser revisada pelo responsável pelas decisões e se este tiver uma

justificativa, então a previsão deve ser ajustada.

• FAZER A PREVISÃO FORMAL

A previsão formal é estabelecida após a revisão dos responsáveis pelas decisões ou

até pela alta gerência.

• MONITORAR ERRO

A última etapa do processo de previsão é o monitoramento dos erros. Como os erros

de previsão afetam várias funções de uma empresa, eles devem ser acompanhados

de perto para que quando necessário, ações corretivas no processo sejam tomadas

rapidamente.

18

2.5.3 PROCESSO DE PREVISÃO SEGUNDO TUBINO (2000)

Segundo Tubino (2000), uma vez decidida a técnica de previsão e implantado o

modelo, há necessidade de acompanhar o desempenho das previsões e confirmar

sua validade perante a dinâmica atual dos dados. É necessário manter um modelo

atualizado de previsão e monitorar esse modelo, para se ter sempre previsões

confiáveis da demanda. Essa monitoração é realizada por meio de cálculo e

acompanhamento de erro da previsão, que é a diferença entre o valor real e o valor

previsto pelo modelo para o dado período. A manutenção e monitoração de um

modelo de previsão confiável buscam:

� Verificar a acuracidade dos valores previstos;

� Identificar, isolar e corrigir variações anormais;

� Permitir a escolha de técnicas, ou parâmetros, mais eficientes.

Tubino (2000), divide um modelo de previsão de demanda em cinco etapas básicas,

conforme figura 2.4. Inicialmente, define-se o objetivo do modelo, com base na qual

coletam-se e analisam-se os dados, seleciona-se a técnica de previsão mais

apropriada, calcula-se a previsão da demanda e como forma de feedback,

monitoram-se e atualizam-se os parâmetros empregados no modelo por meio da

análise do erro de previsão.

Objetivo do Modelo

Coleta e Análise dos Dados

Seleção da Técnica de Previsão

Obtenção das Previsões

Monitoração do Modelo

Figura 2.4 – Etapas do Modelo de Previsão da Demanda

19

Neste capítulo foi apresentada uma abordagem sobre administração da produção e

a gestão da demanda. No próximo capítulo serão apresentados os objetivos da

modelagem de empresa e uma abordagem sobre ERP, CIMOSA, UML.

20

CAPÍTULO III

MODELAGEM DE EMPRESA E SISTEMA ERP

Neste capítulo serão abordados os conceitos de modelagem de empresa, e

apresentadas algumas técnicas de modelagem, destacando-se as linguagens

CIMOSA e UML. Também será apresentado uma breve descrição de características

de ERP.

3.1 INTRODUÇÃO

Uma empresa é um sistema complexo constituído de centenas de processos a

serem controlados e coordenados, milhares de ordens a serem executadas e

centenas de megabytes de dados a serem processados ou trocados. Para tratar

essa complexidade no projeto de empresas, torna-se necessário uma representação

desse sistema, ou seja, modelá-lo (VERNADAT, 1996).

Segundo Torres (2002) a modelagem de processos de negócios não deve ser mais

vista só como uma ferramenta de definir e delimitar o que fazer e entender sobre o

funcionamento das partes dos sistemas. O avanço das tecnologias permite, agora,

que os modelos sejam utilizados além dessas características. É importante que os

modelos venham a ser utilizados mais dinamicamente, através da interação com os

recursos computacionais e na recuperação de indicadores de desempenhos

posteriormente a sua simulação. Portanto, um aspecto dinâmico deve ser conferido

a esses modelos, quando, devido aos avanços tecnológicos, é possível de forma

interativa gestor-modelo alavancar o processo de decisão através de uma operação

em tempo real.

Segundo Shen et al. (2004) o processo de modelagem de empresa é uma parte

essencial para o desenvolvimento de um sistema de informação tendo vantagens e

desvantagens, onde afirma que não podemos nos limitar apenas ao tipo de visão de

empreendimento.

Muitos modelos diferentes podem ser feitos de um dado objeto, sendo que cada

modelo destaca certas características de um objeto e ignora outras. Para escolher o

melhor modelo para as suas finalidades, você terá de decidir quais características

21

que devem ser destacadas para atender essa finalidade (MCMENAMIN & PALMER,

1991 apud SANTOS 2001).

Para tratar a complexidade da empresa no seu projeto de integração deve-se utilizar

metodologias e linguagens adequadas para a modelagem e análise desses

sistemas. A experiência tem mostrado que o projeto e integração de empresa são

um empreendimento complexo e de alto risco e adquirir eficiência no projeto e

integração, novas metodologias, técnicas e ferramentas computacionais devem ser

utilizadas para tratar esta complexidade, além do uso de modelos de referência.

Modelos de referência significam modelos de empresas construídos por

fornecedores comerciais de sistemas ou por instituições de pesquisa acadêmica,

que podem ser facilmente adaptados a cada empresa em particular, isto é, com

menor esforço de projeto (CAMPOS, 1998). Alguns autores definem modelos

genéricos, parciais ou padrão de forma semelhante.

Torres (2002) aponta as limitações dos modelos de processos de negócios e a

necessidade de ser utilizado de forma mais flexível e dinâmica, que é definida como

a capacidade de os modelos recuperarem informações de forma instantânea e,

então, monitorar o desempenho organizacional através de sua interação com os

recursos organizacionais com o uso de novas tecnologias. Esses modelos

possibilitam à organização uma maior flexibilidade na forma de controlar os seus

negócios, pois uma alteração nos seus processos acarreta uma alteração no

desenho do modelo.

Um modelo de empresa geralmente consiste de vários modelos como modelos de

produtos, de recursos, de atividades, de informação, de organização, modelos

econômicos, e estruturas de decisão, sendo que para seu desenvolvimento são

necessárias técnicas e ferramentas de suporte (CAMPOS, 1998).

Segundo Vernadat (1996), a modelagem de empresas está relacionada com

respostas às questões como: “o que”, “como”, “quando”, “quem”, e “onde” da

empresa. O “o que” refere-se às operações e objetos processados pela empresa.

“Como” refere-se à definição do comportamento da empresa, ou a maneira como as

coisas são feitas. O “quando” fornece a noção de tempo e está associado aos

22

eventos representando mudanças no estado da empresa. O “quem” refere-se aos

recursos ou agentes da empresa. Os aspectos “quanto” (por exemplo – aspectos

econômicos) e “onde” (logísticos) também são importantes aspectos a serem

considerados.

Algumas estruturas, arquiteturas e metodologias têm sido recentemente propostas

para a modelagem e integração de empresas. Estas propostas são originadas de

consórcios privados, grandes programas governamentais, através de institutos de

pesquisa, ou entidades de padronização (VERNADAT, 1996).

Segundo Vernadat (1996), dentre os trabalhos em busca de melhores estruturas de

modelagem de empresa podemos destacar:

1. ISO- Tem como objetivo proporcionar estrutura conceitual para a compreensão

da manufatura de peças discretas, e ser usado para identificar áreas de

padronização necessárias para integrar sistemas de manufaturas. É estruturado

em três submodelos: CAD, SFPM e GAM.

2. CEN ENV 40 003- Determina uma estrutura para atividades de padronização

futura na área de modelagem de empresas CIM CEN 1190

3. CIMOSA- Tem por objetivo ajudar companhias a gerenciar mudanças e integrar

seus recursos e operações para fazer face à competição mundial e competir em

preço, qualidade e tempo de entrega. A base para chegar à isso é um modelo de

empresa integrada.

4. GIM- Uma metodologia para análise e projeto conceitual de sistemas de

manufatura. GIM tem sua origem no GRAI. Na raiz de ambas está um modelo

conceitual GRAI. O modelo diz que qualquer empresa é feito de três

fundamentais sub-sistemas: um Sistema Físico, um Sistema de Informação, e um

Sistema de Decisão. GRAI adiciona um Sistema de Operação.

5. PERA- Sua metodologia tem sido desenvolvida com base em trabalhos

anteriores na área CIM. É projetada para usuários não educados em ciência da

computação. Tem mostrado sua capacidade de ser estendido a vários setores da

indústria, sendo a primeira arquitetura que considera o fator humano

completamente (SHEN et al., 2004).

23

6. ARIS- Sua estrutura é muito similar à CIMOSA. O foco é essencialmente em

engenharia de softwares e aspectos organizacionais no projeto de integração de

sistemas de empresas.

7. GERAM- É construído basicamente através de resultados CIMOSA, GIM e

PERA, e após completo será submetido aos organismos de padronização

internacionais.

Vernadat (1996), concluiu que dentre as várias metodologias comparadas, CIMOSA

é a mais completa, mas que não existe e dificilmente, existirá uma metodologia que

suporte todas as necessidades de modelagem. Ele propõe que uma metodologia

deve descrever as características essenciais da empresa e não necessariamente de

forma detalhada. Cabe lembrar que uma metodologia é um conjunto de métodos,

formalismos e ferramentas para serem usados de modo estruturado para resolver

um problema. Um método é organizado em fases metodológicas e uma fase pode

ser organizada em tarefas.

Mas antes se torna necessário definir melhor o que é o termo arquitetura e o que

seriam arquiteturas de referência.

O termo Arquitetura refere-se a um conjunto organizado de elementos com claras

relações entre um e outro, os quais juntos formam um todo, definido para uma

finalidade. E Arquiteturas de Referência são paradigmas intelectuais os quais

facilitam a análise, discussão e especificação de uma dada área ou assunto. Ela

fornece um modo de ver, conceber e falar sobre uma questão (VERNADAT, 1996).

3.2 CIMOSA

Segundo Dalmoro (2003) a Arquitetura de Sistema Aberto para Manufatura

Integrada de Computador (CIMOSA) visa o desenvolvimento de uma arquitetura de

referência aberta para a definição, especificação e implementação de sistemas CIM.

Esta foi desenvolvida por um consórcio denominado AMICE e a documentação

completa está disponível em seu documento formal de referência, publicado em

1996. As definições apresentadas por CIMOSA serviriam de base para o

desenvolvimento de outras arquiteturas e métodos de trabalho.

24

Segundo Kosanke (1995), a arquitetura CIMOSA (CIM Open System Architeture)

constitui-se em um dos principais esforços no sentido de proporcionar uma

arquitetura para modelagem, análise e projeto de sistema CIM (Computer Integrated

Manufacturing). A arquitetura CIMOSA possibilita a obtenção de um modelo de

empresa integrado, o qual captura e estrutura as características essenciais da

empresa, além de fornecer condições para uma infra-estrutura que suporte a

integração das operações da empresa. Recentemente, ela tem sido estendida à

modelagem de toda a empresa e contribui fortemente nos trabalhos de padronização

de organismos internacionais.

Segundo CIMOSA Association (1996), apud Santos (2001), CIMOSA é composta de

três componentes principais:

� Estrutura de Modelagem de Empresa;

� Infra-estrutura de integração; e

� Ciclo de vida do Sistema da Empresa.

3.2.1 A ARQUITETURA CIMOSA

A Arquitetura CIMOSA desenvolveu-se como uma série de projetos ESPRIT (EP

688, EP 5288, e EP 7110) financiados pelo Comitê Europeu e parceiros de projetos

reunindo fornecedores CIM, grandes usuários e centros de pesquisa. Outros projetos

ESPRIT também têm contribuído com CIMOSA testando e validando princípios de

CIMOSA, como VOICE (EP 6682), CIMPRESS (EP 5532) e CODE (EP5499)

(KOSANKE, 1995). O objetivo de CIMOSA é ajudar companhias a gerenciar

mudanças e integrar seus recursos e operações para fazer face a competição

mundial em preço, qualidade e tempo de entrega. A base para chegar a isso é um

modelo de empresa integrada baseado em sistemas abertos.

CIMOSA tem promovido o termo “processo de negócio” (business process) e

introduzido a análise baseada em processos para a modelagem e integração de

empresas, ultrapassando os limites da organização, oposto à análise baseada em

funções ou atividades. De grande importância, CIMOSA introduz a idéia de

arquitetura de sistemas abertos para empresas CIM, constituída de módulos de

sistemas CIM baseados em padrões, descritos em termos de aspectos funcionais,

de informação, de recursos e aspectos organizacionais, projetados de acordo com

25

um método estruturado de engenharia. Assim, produtos baseados na arquitetura

CIMOSA são compatíveis entre si, independente do fornecedor, e podem ser

conectados segundo as necessidades dos usuários e os quais podem ser

conectados em uma arquitetura consistente, modular e evolucionária para uso

operacional (plug and play approach). CIMOSA também tem consolidado e provado

a validade do método para integração de empresas baseado em modelos (AGUIAR,

1995)

Uma das contribuições importantes de CIMOSA é a definição da infra-estrutura de

integração genérica, necessária para a implementação de Programas de Integração

de Empresa (BERNUS et. al, 1995).

Comparando com outros métodos de modelagem e integração CIM, as principais

vantagens de CIMOSA são:

� Cobre adequadamente os aspectos funcionais e comportamentais de sistemas

CIM;

� Suporta a descrição da especificação de projeto e implementação do sistema de

acordo com os requisitos de usuários (processo de derivação);

� Restringe o número de blocos de construções possíveis forçando vendedores

fornecer componentes padrões;

� Está em linha com os padrões internacionais em desenvolvimento para CIM

(STEP, OSI, MAP, ENV 12 204). (VERNADAT, 1996)

Segundo Berio & Vernadat (1999), CIMOSA provê quatros modos para

sincronização de processo:

� Sincronização através de eventos;

� Sincronização por disponibilidade de objeto;

� Sincronização através de disponibilidade de recursos;

� Sincronização de transcurso de mensagem.

Normalmente são implementados mecanismos de comunicação ao nível de

atividade de processos. Em CIMOSA, ambas as comunicações síncronas ou

assíncronas entre atividades são permitidas. No capítulo IV são apresentados

alguns modelos baseados em CIMOSA.

26

Ainda, segundo Vernadat (1996), CIMOSA fornece:

� O princípio de economia de esforço de projeto, através de seu processo de

particularização (do genérico ao particular, conforme cubo CIMOSA) e da

reutilização de modelos parciais através de uma biblioteca de modelos parciais

na arquitetura de referência (por exemplo fornecidos por fornecedores CIM);

� O princípio de módulos padrões com representação uniforme de dados e funções

como também interfaces padrões para simples conexões (sistema “plug and

play”) por meio de uma plataforma de integração interoperável, chamada de

Infraestrutura de Integração CIMOSA;

� O princípio de modelagem de toda a empresa por meio de quatro vistas

integradas;

� O princípio de integração baseada em modelos por meio de um modelo de

implementação executável;

� CIMOSA proporciona um método de modelagem que satisfaz os princípios de

generalidade, reusabilidade, decomposição funcional, separação de

funcionalidade e comportamento, separação de processos e recursos, e

conformidade, todos juntos.

Enquanto que CIMOSA é considerada a metodologia de modelagem de empresas

mais completa, a linguagem UML é a linguagem mais utilizada atualmente na

modelagem de sistema de software.

3.3 UML – UNIFIED MODELING LANGUAGE

É uma linguagem gráfica para visualização, especificação, construção e

documentação de artefatos de sistemas complexos de software e proporciona uma

forma padrão para a preparação de arquitetura de projeto de sistemas, incluindo

aspectos conceituais tais como processo de negócios e funções do sistema, além de

itens concretos como classes escritas em determinada linguagem de programação,

esquemas de bancos de dados e componentes de software reutilizáveis (BOOCH et

al., 2000).

Segundo Kim et al. (2003), a UML tornou-se rapidamente um padrão de fato para a

engenharia de software. Ela fornece um conjunto de notações para modelagem

27

projetadas para suportar especificidades de domínios e ciclos de vidas envolvidas na

engenharia de softwares orientados a objetos.

Para Torres (2002), a UML possui diversos diagramas como de atividades, de “Use

Cases” (ou casos de uso), de colaboração, de seqüência, de estado, de classe, de

objeto, de componentes e desdobramento. Foi lançada por Grady Booch e Jim

Rambaugh (DEREK, 1997 apud TORRES, 2002) na OOPSLA’ 95, organizada pela

Rational Software Corporation, com o nome de Método Unificado. Em 1996, esse

método foi renomeado para UML. No início de 1997, a UML foi submetida pela OMG

para padronização, e tem sido endossada por várias empresas de software.

Segundo Furlan (1998) apud Santos (2001), a UML pode ser usada para:

� Mostrar as fronteiras de um sistema e suas funções principais utilizando atores e

casos de uso;

� Ilustrar a realização de casos de uso como diagramas de interação;

� Representar uma estrutura estática de um sistema utilizando diagramas de

classe;

� Modelar o comportamento de objetos como diagrama de transição de estado;

� Revelar a arquitetura de implementação física com diagrama de componente e

de implementação;

� Estender sua funcionalidade através de estereótipos.

A UML propõe, também, o diagrama de componentes. O diagrama de componentes

é um gráfico de componentes conectados pelos relacionamentos de dependências

em que podem ser associados a outros por retenção física que representa

relacionamentos de composição. Um diagrama de componentes mostra as

dependências entre componentes de software (TORRES, 2002).

No capítulo IV são apresentados exemplos de alguns diagramas em UML.

A modelagem de empresa ou de sistema de informação pode servir de base para o

desenvolvimento e implantação de processos de negócios e sistemas ERP.

28

3.4 MRP II E ERP

O ERP (Enterprise Resource Planning) é um sistema de informações que suporta

todas as áreas de uma empresa. O conceito onde se apoiam os sistemas MRP II

nasceu do que hoje é conhecido como módulo MRP – o cálculo de necessidade de

materiais. A partir daí, são agregados os módulos de programação – mestre de

produção (MPS), cálculo grosseiro de necessidade de capacidade (RCCP), cálculo

detalhado de necessidade de capacidade (CRP), controle de fábrica (SFC), controle

de compras (PVR) e, mais recentemente Sales & Operations Planning (S&OP). O

sistema, então, deixou de atender apenas as necessidades de informação referente

ao cálculo de necessidade de materiais para atender às necessidades de

informação para a tomada de decisão gerencial sobre outros recursos de

manufatura. O MRP passou a merecer, então, a denominação de MRP II, passando

a significar sistema de planejamento de recursos de manufatura.

29

Na figura 3.1 podemos identificar três grandes blocos dentro do sistema MRP II

(CORRÊA et al., 2001):

Figura 3.1 – Sistema MRPII (adaptado de CORRÊA et al., 2001)

30

• O comando – composto pelos níveis mais altos de planejamento (S&OP, Gestão

de Demanda e MPS/RCCP) que é responsável por “dirigir” a empresa e sua

atuação no mercado. É principalmente neste bloco que recai a responsabilidade

pelo desempenho competitivo da empresa, sendo portanto um nível de decisão

de alta direção;

• O motor – composto pelo nível mais baixo de planejamento (MRP/CRP),

responsável por desagregar as decisões tomadas no bloco de “comando”,

gerando decisões desagregadas nos níveis requeridos pela execução, ou seja, o

que, quanto e quando produzir e/ou comprar, além das decisões referentes a

gestão da capacidade de curto prazo;

• As rodas – compostas pelos módulos ou funções de execução e controle

(Compras e SFC), responsáveis por apoiar a execução detalhada daquilo que foi

determinado pelo bloco anterior, assim como controlar o cumprimento do

planejamento, realimentando todo processo.

Conforme Corrêa et al. (2001) os aspectos mais importantes que devem ser

considerados na implantação de sistemas MRPII:

• O comprometimento da alta direção – a implantação de um sistema de porte do

MRP II só terá chance de sucesso se a alta direção da empresa estiver

comprometida com seus resultados;

• A educação e o treinamento – sem dúvida, os principais responsáveis pelas

implantações de sucesso, a educação com conceitos de MRP II, utilizando-se as

mais modernas ferramentas, e o treinamento no uso do sistema devem ser

extensivos a todos os usuários diretos e indiretos do sistema, em todos os níveis,

e feito desde a etapa de escolha do sistema para implantação e até o uso

regular;

• A escolha adequada de sistema, hardware e software – embora não garantam o

sucesso da implantação, escolhas adequadas podem prevenir problemas futuros,

já que estas decisões são difíceis de reverter. Infelizmente a maioria das

empresas coloca um peso excessivamente grande sobre estas decisões, em

função do volume dos investimentos necessários, reservando pouca atenção

para os demais aspectos, normalmente mais importantes;

• A acurácia dos dados de entrada – o MRP II depende visceralmente de uma

base de dados acurada e atualizada. Começar a utilizar o MRP II antes de atingir

31

os níveis requeridos de acurácia de dados é assumir um risco grande de

desacreditar o sistema rapidamente junto a seus usuários, o que é a maneira

mais fácil de chegarmos ao fracasso de implantação. O esforço de conseguirmos

os níveis desejados de acuidade de dados pode demandar um longo e

trabalhoso processo de mudanças de rotinas e procedimentos, o que nem

sempre é fácil ou barato. Mas é condição essencial para conseguirmos obter as

potenciais vantagens que o sistema pode oferecer;

• O gerenciamento adequado da implantação – o gerenciamento da implantação

deve ser feito de forma criteriosa, cuidadosa e coordenada, conforme a melhor

técnica de gestão de projetos, tomando-se o cuidado de envolver todas as

pessoas que terão contato com o sistema (quer seja como usuários quer seja

como operadores) desde as primeiras etapas do processo. A equipe de

implantação deve contar com a participação de pessoas provenientes de todas

as funções envolvidas; elas devem ser pessoas que tenham bom trânsito e

influência em seus setores de origem e, se possível, devem dedicar-se ao projeto

de implantação em tempo integral. Não devemos nunca esquecer os aspectos

humanos numa implantação de MRP II. Em última análise, seu sucesso ou

insucesso é uma função direta de como as pessoas o aceitam e lidam com ele.

Hoje, segundo Corrêa et al (2001), um grande número de empresas de porte médio

a grande, no Brasil e no exterior, têm grandes expectativas quando na implantação

dos ERPs, podendo-se citar:

• Que disponibilizem a informação certa e boa na hora certa, nos pontos de

tomada de decisão gerencial, ao longo de todo o empreendimento,

principalmente em termos do fluxo logístico;

• Que forneçam os meios para uma perfeita integração entre os setores da

organização, por meio do compartilhamento de bases de dados únicas e não

redundantes, nas quais cada elemento de dado esteja em um e apenas um

local;

• Que forneçam os meios para que se deixe de gastar esforço gerencial e

operacional nas interfaces entre sistemas de informações que não conversam

entre si;

• Que tornem o processo de planejamento operacional mais transparente,

estruturado e com responsabilidades mais definidas;

32

• Em última análise, que apóiem a empresa nos seus esforços de melhoria de

desempenho operacional para que melhor possa se sair, frente aos concorrentes,

no atendimento aos clientes.

Corrêa et al. (2001) apresenta diferentes módulos hoje disponíveis na maioria dos

“ERPs” (figura 3.2). Um detalhamento das funções suportadas por ERPs é

apresentado no Anexo II.

Figura 3.2 Estrutura Conceitual dos Sistemas ERP (Adaptado de Corrêa et. Al., 2001).

Segundo Corrêa et al.(2001), a implantação de sistema ERP deve ser gerenciada

por pessoas que entendem de mudança organizacional e de negócio, deve ser feita

por pessoal interno da própria empresa, possivelmente facilitando em situações

pontuais por capacitação externa (desde que haja uma preocupação explícita de

incorporar a capacitação aportada ao acervo permanente da empresa), deve contar

com o comprometimento da alta direção, deve ter uma visão clara e compartilhada

de situação futura, enfim, todos os aspectos que, já se sabe há muito tempo, devem

estar presentes em projetos de mudanças organizacionais relevantes.

33

Neste capítulo a revisão bibliográfica possibilitou uma abordagem sobre modelagem

de empresas e de sistemas de informação, vista como uma ferramenta para o

projeto e desenvolvimento de ERPs.

No capítulo seguinte são apresentados os modelos de referência proposto por

Santos (2001).

34

CAPÍTULO IV

MODELO DE REFERÊNCIA SEGUNDO SANTOS (2001)

Neste capítulo descreveremos as principais partes do Modelo de Empresa e do

Modelo de Informação proposto por Santos (2001) a ser usados como referência

para implantação de um sistema particular em uma indústria de auto peças.

4.1 INTRODUÇÃO

Os modelos de referência obtidos são elaborados seguindo uma seqüência de

desenvolvimento, que visa integrar os conceitos de modelagem CIMOSA e UML,

conforme descrição a seguir. Observa-se que o modelo de descrição de

implementação não foi considerado por Santos (2001) pois não foi realizada a

implementação na prática do modelo, no trabalho anterior. A seguir descreve-se

resumidamente os procedimentos adotados para o desenvolvimento do modelo de

empresa e modelo de informação.

4.1.1 PROCEDIMENTO PARA O MODELO DE EMPRESA

Para Santos (2001) a obtenção do modelo de referência do processo de previsão de

demanda utiliza uma seqüência de desenvolvimento, baseado nas duas primeiras

fases do Processo de Modelagem CIMOSA, organizados em duas fases (utiliza a

linguagem CIMOSA). A primeira fase, de criação do Modelo de Definição dos

Requisitos- MDR, consiste basicamente no levantamento dos requisitos e

informações básicas do processo de previsão, resultando em um desenho não

detalhado desses processos. Na segunda fase, o modelo de Especificação de

Projeto – MEP, consiste no detalhamento dos modelos e respectivos gabaritos.

Nestes modelos o principal enfoque é dado aos aspectos de função e informação do

processo de previsão de demanda. Os objetivos de modelagem são descritos a

seguir.

4.1.1.1 MODELAGEM DE DEFINIÇÃO DE REQUISITOS- MDR

• Identificar e definir o domínio do trabalho – Domínio CIMOSA (DMi);

• Definir os processos elementares de cada domínio – Processos de Domínio

CIMOSA (PDi);

35

• Definir as atividades que compõem cada processo de domínio – Atividades de

Empresa CIMOSA (AEi);

• Estabelecer as informações de entrada e de saída para cada atividade de

empresa – Vista de Objetos CIMOSA (VOi).

4.1.1.2 MODELAGEM E ESPECIFICAÇÃO DE PROJETO – MEP

• Detalhar e projetar os Domínios;

• Detalhar e Projetar os processos de Domínio;

• Detalhar e projetar as Atividades de Empresa;

• Detalhar e projetar as Vistas de Objetos;

4.1.2 PROCEDIMENTO PARA MODELO DE SISTEMA DE INFORMAÇÃO

Utilizou-se diagramas da linguagem UML nas seguintes fases:

• A partir do modelo de Empresa, deve-se encontrar e descrever ações que

produzam resultados de valor para o sistema (Casos de Uso) e quem realça

cada ação (Ator) – resultou no Diagrama de Casos de Uso;

• Baseado na descrição de casos de uso (UML), descrição das atividades de

empresa e vistas de objetos (CIMOSA), definir as classes de objetos e os

relacionamentos existentes entre as classes – resultou no Diagrama de Classes;

• Representar como cada caso de uso deverá ser realizado no sistema,

especificando, o ator que realiza a ação, a seqüência de operações necessárias

para realizações da ação e que classes de objetos participam – resultou no

Diagrama de Seqüência.

No desenvolvimento e documentação dos modelos apresentados por Santos (2001)

são utilizadas ferramentas computacionais de suporte também chamadas

ferramentas CASE, que proporcionam um ambiente de modelagem dinâmico,

simplificado e padronizado. Na modelagem de processos de previsão de demanda

foi utilizado software CIMTOOL e na modelagem do sistema de informação foi

utilizado o software Rational Rose.

36

4.2 MODELO DE DEFINIÇÃO DE REQUISITOS – MDR

CIMOSA estabelece que o processo de modelagem inicia com o Modelo de

Definição de Requisitos, onde o primeiro passo é determinar os domínios e

processos de domínios.

A figura 4.1 demonstra a relação entre os domínios Marketing/Vendas, Previsão de

Demanda e PCP (Planejamento e Controle de Produção). Neste exemplo, o setor de

Marketing e Vendas fornece informações para a realização da previsão de demanda.

As informações relativas à previsão são então enviadas para o domínio de PCP.

A previsão de demanda é o domínio que se está analisando (DM1 – Previsão de

Demanda), ou área funcional da empresa, porém este possui interação com outros

domínios. Os domínios que não serão modelados neste trabalho estão marcados

com linha dupla, conforme figura 4.1.

Para um domínio devem ser identificados os processos que o compõem. Os

processos de domínio (PDi) devem ser destacados quando o resultado de sua

execução alimenta outro processo dentro do domínio.

DDMM22 –– PPCCPP

- Controle da Produção

- Planejamento Agregado

- Planejamento Mestre - Planejamento das

Necessidades de Materiais - M.R.P.

- Programação da Produção

DDMM33 –– VVEENNDDAASS// MMAARRKKEETTIINNGG//

- Recebimento de

Pedidos - Pesquisa de

Mercado - ….

DDMM11 –– PPRREEVVIISSÃÃOO DDEE DDEEMMAANNDDAA

- Projeto Previsão

- Dados de Demanda - Previsão de

Demanda - Monitorar Erro

Figura 4.1 - Principais Domínios e Relacionamentos de Domínios identificados.

37

Ao analisar as principais questões e atividades que envolvem a previsão de

demanda, foram encontrados 4 processos elementares que são: o Projeto do

Processo de Previsão (PD1), o Registro de Dados de Demanda (PD2), a realização

da previsão de Demanda (PD3) e o Monitoramento dos Erros (PD4), cuja interação é

representada na figura abaixo:

Na figura 4.2 as setas representam eventos de entrada e saída para cada processo

de domínio. Assim, a partir da solicitação de um novo projeto de previsão (EV-

Req_Projeto_Previsão), tem início o processo do projeto de previsão (PD1-

Projetar_Previsão). A cada pedido de produtos (EV-Pedido_Produtos), o processo

dados de demanda (PD2-Dados_Demanda) é acionado para atualizar a demanda de

cada produto pedido. A requisição de previsão de demanda (EV-

Req_Previsão_Demanda) inicia o processo de previsão de demanda (PD3-

Previsão_Demanda), que define a previsão. Periodicamente um evento (EV-

PD2 –

PD3 –

PD4 –

EV-Pedido_Produtos

EV-Periódico

EV-Req_Previsão_Demanda

PD1 –

EV-Req_Projeto_Previsão

EV-Projeto_Previsão

EV-Dados_Demanda

EV- Previsão_Definida

EV-Rever_Projeto

EV-Rever_Previsão

Figura 4.2 - Coordenação dos Processos.

38

Periódico) inicia o processo de monitoramento do erro de previsão (PD4-

Monitorar_Erro), e o resultado desse processo pode ser ou um evento de solicitação

de revisão do projeto (EV-Rever_Projeto) ou um evento para revisão da previsão

(EV-Rever_Previsão).

Em cada processo de domínio faz-se uma análise comportamental, buscando

identificar através da decomposição funcional dos processos do negócio as

operações que definem a estrutura do processo, reunindo as atividades de empresa

(AEi) que fazem parte de cada processo. O MEP é um detalhamento do MDR e por

isto é suficiente apresentar o MEP (modelos e gabaritos).

PD1 – Projetar_Previsão (Figuras 4.3 e 4.4) (Gabarito 1)

AE1 – Analisar_Objetivos

AE2 – Definir_Características

AE3 – Identificar_Fator_Influência

AE4 – Ajustar_Dados

AE5 – Selecionar_Modelos

AE6 – Documentar_Participantes

AE7- Liberar_Processo

PD2 – Dados_Demanda (Figuras 4.5 e 4.6) (Gabarito 2)

AE8 – Registrar_Dados

PD3 – Previsão_Demanda (Figuras 4.7 e 4.8) (Gabarito 3)

AE9 – Analisar_Previsão


AE10 – Gerar_Cenários

AE11 – Revisão_Gerencial

AE12 – Apresentar_Previsão

PD3 – Monitorar_Erro (Figuras 4.9 e 4.10) (Gabarito 4)


AE13 – Calcular_Erro

AE14 – Analisar_Erro

39

Em seguida é feita uma análise operacional de cada processo, para definir as

entradas, as saídas e o estado final de todas as atividades. No modelo as entradas e

as saídas da atividade são definidas por vistas de objetos (VOi), que são mostrados

na seção seguinte.

Enfim, cada item do modelo identificado (construtores da linguagem), Domínio,

Processo de Domínio, Atividades de Empresa, Vista de Objetos são representados

de forma textual em gabaritos explicativos, sendo detalhados ao longo do processo

de modelagem conforme necessidade.

Para finalizar a modelagem de definição de requisitos, deve-se fazer uma verificação

de consistência desse modelo. Os modelos e respectivos gabaritos resultantes

dessa fase de modelagem são apresentados e detalhados na seção seguinte.

4.3 MODELAGEM DA ESPECIFICAÇÃO DE PROJETO – MEP

Inicialmente faz-se uma revisão do Modelo de Definição de Requisitos para

identificar redundâncias e consolidar o modelo obtido na fase anterior da

modelagem, passando a seguir para a definição do comportamento, regras e

alternativas. Nesta fase cada detalhe identificado em um construtor (Processo de

Domínio, Atividade de Empresa, Vista de Objeto) é descrito detalhadamente num

gabarito correspondente. Alguns construtores também possuem representação

gráfica.

A seguir serão demonstrados os gabaritos dos processos identificados na fase MDR

e detalhados nesta fase, assim como a representação gráfica de alguns

construtores.

4.3.1 PROCESSO PROJETAR PREVISÃO

O Gabarito 1 representa a descrição detalhada do processo de domínio Projetar

Previsão (PD1 – Projetar_Previsão) e demonstra por exemplo, a descrição do

processo, o procedimento e a relação de atividades do processo.

40

A representação gráfica do processo é dada pela figura 4.3, que permite visualizar

as atividades que compõem o processo do Projeto de Previsão e o estado final de

cada atividade.

DOMAIN PROCESS Name: Projetar_Previsao Identifier: PD1- Projetar_Previsao Type: Previsão Design Authority: Luciana Rocha OBJECTIVES: Projetar ou reprojetar o Processo de Previsão de Demanda, conforme solicitado pelos usuários da empresa. CONSTRAINTS:

DESCRIPTION:

O Projeto de Processo de Previsão (PD1-Projetar_Previsão) determina os procedimentos necessários para a realização da previsão de demanda de um determinado produto (ou família de produto), conforme requerido (EV-Req_Projeto_Previsão ou EV-Rever_Projeto_Previsão) por gerentes da empresa. O processo inicia com a análise dos objetivos da previsão, passando pela definição de suas características, ajuste de dados da demanda, identificação de fatores de influências, seleção de modelos matemáticos, documentação dos modelos e termina com a sua liberação e apresentação a todos os participantes. A documentação do modelo consiste na representação dos procedimentos, responsabilidades e regras que orientam os processos que compõem a previsão (PD2-Dados_Demanda, PD3-Previsão_Demanda, PD4-Monitor_Erro). O projeto deve ser realizado por um especialista em previsão (analista de previsão), com aprovação final dos gerentes das unidades que solicitaram e usarão a previsão. Este processo também pode ser realizado, se após monitoramento dos erros de previsão (PD4-Monitorar_Erro) for identificado a necessidade de alterações no projeto do processo de previsão (EV_Rever_Projeto).

Event: EV_Req_Projeto_Previsao EV_Rever_Projeto PROCEDURE:

Start = Analisar_Objetivos

Analisar_Objetivos ObjetivosAnalisados Definir_Caracteristicas

Definir_Caracteristicas CaracteristicasDefinidas Identicar_Fator_Influencia

Identicar_Fator_Influencia FatoresIdentificados Ajustar_Dados

Ajustar_Dados DadosAjustados Selecionar_Modelos

Selecionar_Modelos ModelosSelecionados Documentar_Participantes

Documentar_Participantes ModeloParticular Liberar_Processo

Liberar_Processo ProcessoLiberado Finish

Liberar_Processo ReverProjeto Analisar_Objetivos COMPONENTS: Analisar_Objetivos Definir_Caracteristicas Fator_Influencia Ajustar_Dados Selecionar_Modelos Documentar_Participantes Liberar_Processo

Gabarito 1 - Processo PD1-Projetar_Previsão.

41

Start

Analisar_Objetivos

Definir_Caracteristicas

Identicar_Fator_Influencia

Ajustar_Dados

Selecionar_Modelos

Documentar_Participantes

Liberar_Processo

Finish

ObjetivosAnalisados

CaracteristicasDefinidas

FatoresIdentificados

DadosAjustados

ModelosSelecionados

ModeloParticular

ProcessoLiberado

ReverProjeto

Na figura 4.4 são representadas cada atividade do processo Projetar Previsão,

mostrando os componentes de entrada e saída representados pelas vistas de

objetos.

Figura 4.3 - Processo PD1-Projetar_Previsão

42

Analisar_ObjetivosVO_Historico_PrevisaoVO_Requisicao_Projeto

VO_Analista_Previsao

VO_Objetivos_Previsao

ES ObjetivosAnalisados

Definir_CaracteristicasVO_Historico_PrevisaoVO_Objetivos_Previsao


VO_Caracteristicas_Previsao

ES CaracteristicasDefinidas

VO_Sistema_Computacional

Liberar_ProcessoVO_Modelo_Particular

VO_Caracteristicas_PrevisaoVO_Objetivos_Previsao

VO_Gerente

VO_Projeto_Processo

ES ProcessoLiberado


ES Rever_Projeto

Identicar_Fator_InfluenciaVO_Fatores_InfluenciaVO_Historico_Previsao



VO_Fatores_Influ_Demanda


VO_Caracteristicas_Previsao ES FatoresIdentificados

Ajustar_DadosVO_Dados_DemandaVO_Fatores_Influ_Demanda

VO_Caracteristicas_PrevisaoVO_Objetivos_Previsao


VO_Ajuste_Dados

ES DadosAjustados


Documentar_ParticipantesVO_Informacoes_PrevisaoVO_Modelos_ReferenciaVO_Participantes


VO_Modelo_Particular

ES ModeloParticular

VO_Sistema_ComputacionalVO_Grupo_Gerentes


Selecionar_Modelos

VO_Ajuste_Dados

VO_Biblioteca_ModelosVO_Dados_Demanda


VO_Modelos_Erros

VO_Modelos_Previsao

ES ModelosSelecionados



Figura 4.4 - Atividades com respectivas entradas e saídas (Vistas de Objetos) do Processo PD1-

Projetar_Previsão.

43

4.3.2 PROCESSO DADOS DE DEMANDA

Assim como no processo Projetar Previsão, o Gabarito 2 representa a descrição

detalhada do processo de domínio Dados de Demanda (PD2-Dados_Demanda).

A figura 4.5 representa o processo Dados de Demanda, demonstrando que este é

formado de uma atividade única, registro de dados, cujo estado final será demanda

registrada.

Start

Registrar_Dados

Finish

DemandaRegistrada

DOMAIN PROCESS Name: Dados_Demanda Identifier: PD2- Dados_Demanda Type: Design Authority: Luciana Rocha OBJECTIVES: Este processo visa registrar informações referentes aos pedidos dos produtos realizados pelos clientes. CONSTRAINTS: DESCRIPTION: Todos os pedidos de produtos realizados pelo mercado (EV-Pedido_Produtos), independentes de serem atendidos ou não, devem ser registrados no banco de dados do sistema de previsão. Event: Ev-Pedido_Produtos PROCEDURE:

Start = Registrar_Dados

Registrar_Dados DemandaRegistrada Finish COMPONENTS: Registrar_Dados

Gabarito 2 - PD2-Dados_Demanda.

Figura 4.5 - Processo PD2-Dados_Demanda.

44

Abaixo a figura 4.6 representa os componentes da atividade Registrar Dados.

4.3.3 PROCESSO PREVISÃO DE DEMANDA

O processo de domínio Previsão de Demanda é descrito no Gabarito 3, apresentado

abaixo:

Registrar_DadosVO_Pedido_Produtos

VO-Sistema_Computacional

VO_Dados_Demanda

ES DemandaRegistrada


Dados_Demanda.

DOMAIN PROCESS Name: Previsao_Demanda Identifier: PD3- Previsao_Demanda Type: Design Authority: Luciana Rocha OBJECTIVES: Realizar a previsão de demanda de produtos conforme definido no projeto do processo. CONSTRAINTS: DESCRIPTION: O Processo de Previsão de Demanda consiste em realizar a previsão de demanda pelo analista de previsão e demais participantes, utilizando-se o sistema de informação de auxílio à previsão. Este processo é realizado de forma automática pelo sistema de previsão, após o projeto (ou reprojeto) do processo de previsão, e posteriormente de forma periódica. Este processo inicia com uma análise da requisição de previsão, passando pelo ajuste dos dados de demanda, definição de previsões baseadas em modelos matemáticos e possíveis cenários. Então é feita uma revisão gerencial e após a apresentação dos resultados finais do processo de previsão aos seus usuários. Event: EV-Req_Previsao_Demanda EV-Rever_Previsao PROCEDURE:

Start = Analisar_Requisicao

Analisar_Requisicao RequisicaoAnalisada Ajustar_Dados

Ajustar_Dados DadosAjustados Gerar_Cenarios

Gerar_Cenarios CenariosGerados Revisao_Gerencial

Revisao_Gerencial RevisãoRealizada Apresentar_Previsao

Revisao_Gerencial NovoCenario Gerar_Cenarios

Apresentar_Previsao Fim-Previsao Finish COMPONENTS: Analisar_Requisicao Ajustar_Dados Gerar_Cenarios Revisao_Gerencial Apresentar_Previsao

Gabarito 3 - Processo PD3-Previsão_Demanda.

45

A figura 4.7 representa as atividades do processo Previsão de Demanda com seus

respectivos estados finais.

Na figura 4.8 estão representadas todas as atividades do processo Previsão de

Demanda e suas respectivas vistas de objetos, exceto o modelo da atividade

“Ajustar_Dados” que é o mesmo apresentado na figura 4.4.

Start

Analisar_Requisicao

Ajustar_Dados

Gerar_Cenarios

Revisao_Gerencial

Apresentar_Previsao

Finish

RequisicaoAnalisada

DadosAjustados

CenariosGerados

RevisãoRealizada

NovoCenario

Fim-Previsao

Figura 4.7 - Processo PD3-Previsão_Demanda.

46

Analisar_RequisicaoVO_Historico_PrevisaoVO_Requisicao_Previsao

VO_Caracteristicas_PrevisaoVO_Modelo_ParticularVO_Objetivos_Previsao


VO_Requisicao_Analisada

ES RequisicaoAnalisada


Gerar_Cenarios

VO_Dados_DemandaVO_Ajuste_DadosVO_Fatores_Influ_Demanda

1 VO_MODELOS_PREVISAO

VO_Requisicao_Analisada



VO_Cenarios

ES CenariosGerados



Revisao_Gerencial

VO_CenariosVO_Fatores_Influ_DemandaVO_Historico_PrevisaoVO_MetasVO_Previsoes

VO_Grupo_Gerentes

VO_Metas_Revisadas

VO_Previsao_Final

VO_Req_Novos_Cenarios

ES RevisaoRealizada

ES NovoCenarioVO_Caracteristicas_Previsao



Apresentar_PrevisaoVO_Previsao_Final

VO_Grupo_Gerentes

VO_Previsao_Apresentada

ES Fim-Previsao



Previsão_Demanda.

47

4.3.4 PROCESSO MONITORAR ERRO

O processo de monitoramento de erro é descrito pelo Gabarito 4 e a Figura 4.9.

Start

Ajustar_Dados

Calcular_Erro

Analisar_Erro

Finish

Dados_Ajustados

Erros_Fora_Limites

Erros_Dentro_Limites

Erros_Analisados

DOMAIN PROCESS Name: Monitorar_Erro Identifier: PD4-Monitorar_Erro Type: Design Authority: Luciana Rocha OBJECTIVES: Calcular e analisar os erros de previsão visando o monitoramento da previsão de demanda e, conseqüentemente, verificar a eficácia do processo de previsão. CONSTRAINTS: DESCRIPTION: Por melhor que seja o processo de previsão, um erro de previsão vai sempre existir devido à componente aleatória da demanda. Então, é importante acompanhar os erros para garantir que eles permaneçam dentro de limites aceitáveis. Os erros de previsão afetam várias funções de uma empresa, e devem ser acompanhados de perto para identificar, quando necessário, ações corretivas que rapidamente devam ser tomadas. Assim, ao final de cada período de previsão, é preciso verificar a necessidade de ajuste dos dados de demanda (AE4-Ajustar_Dados), calcular os erros de previsão e compará-los com os limites de erros (AE13-Calcular_Erro). Caso os erros sejam maiores do que os limites aceitáveis, esses erros devem ser analisados a fim de encontrar e registrar suas razões, definir ações de correção para a previsão ou para todo o processo (EA14-Analisar_Erros). Event: EV-Periodico PROCEDURE: Start = Ajustar_Dados Ajustar_Dados Dados_Ajustados Calcular_Erro Calcular_Erro Erros_Fora_Limites Analisar_Erro Calcular_Erro Erros_Dentro_Limites Finish Analisar_Erro Erros_Analisados Finish COMPONENTS: Ajustar_Dados Calcular_Erro Analisar_Erro

Gabarito 4 - Processo PD4-Monitorar_Erro.

Figura 4.9 - Processo PD4-Monitorar_Erro.

48

Na Figura 4.10 são representados os gráficos das atividades que compõem o

processo Monitorar Erro.

As Vistas de Objetos representam as informações necessárias para realização de

cada atividade e informações obtidas como resultado destas atividades. A descrição

das vistas de objetos definem informações elementares ou seus atributos. A seguir

temos um exemplo de descrição da vista de objeto Requisição_Projeto, conforme

gabarito 5:

Calcular_ErroVO_Dados_Monitorament

o

VO_Limites_Erro

s

VO_Sistema_Computaciona

l

VO_Erro_Previsa

o VO_Requisicao_Analise

ES Erros_Dentro_LimitesES Erros_Fora_Limites

Analisar_ErroVO_Dados_Monitoramento


VO_Analise_Erro

EV Rever_ProjetoES Erros_Analisados



VO_Erro_Previsao

EV Rever_PrevisaoVO_Caracteristicas_Previsao


Monitorar_Erro.

OBJECT VIEW Name: Requisicao_Projeto Identifier: VO1-Requisicao_Projeto Type: Projeto Design Authority: Luciana Rocha DESCRIPTION: Esta vista de objeto é relativa a requisição de projeto de previsão. LEADING OBJECT: Requisicao_Projeto PROPERTIES: IE Codigo_Processo_Previsao IE Fase_Decisao IE Informacoes_Adicionais IE Objeto_Prever IE Prazo IE Setor_Usuario IE Status IE Tipo_Previsao IE Usuario IE Versao

Gabarito 5 -Vista de Objeto Requisição de Projeto de Previsão.

49

Neste trabalho, a análise de recursos e os aspectos da organização não são

detalhados, assim como informações sobre o tempo de processamento de cada

atividade.

Em geral, de acordo com a empresa a previsão de demanda pode ser realizada por

diferentes setores e com objetivos diferentes. Estas particularidades da empresa

poderão ser acrescentadas ao modelo de referência proposto, caracterizando um

modelo particular.

O projeto do Sistema de Informação, considerado na modelagem de processos

através de CIMOSA, é moderado através da UML e descrito na seção seguinte.

4.4 MODELO DE SISTEMA DE INFORMAÇÃO

O modelo do sistema de informação utiliza todas as informações levantadas no

modelo de empresa. Tem um caráter genérico, e desta forma é proposto ser

adaptável a empresas de diferentes áreas de atuação.

Os principais diagramas utilizados na construção do protótipo do sistema de

informação são:

• Os Diagramas de Caso de Uso que representam as principais atividades do

processo e os respectivos executores (atores) de cada atividade, configurando as

necessidades internas de cada processo do modelo de empresa e suas relações

com o mundo exterior.

• Os Diagramas de Classe que representam os objetos existentes nos processos

de modelo de empresa, através de classes de objetos. As classes de objetos

resultarão em tabelas no banco de dados físico.

• Os Diagramas de Seqüência que demonstram a dinâmica das relações dos

objetos necessários à realização de cada caso de uso no sistema de informação.

4.4.1 DIAGRAMA DE CASO DE USO DO NEGÓCIO

O Diagrama de Caso de Uso é formado a partir da análise do ambiente que envolve

o sistema e suas respectivas fronteiras. Na identificação dos casos de uso, foi

utilizado o detalhamento dos processos modelados anteriormente (figura 4.11),

50

buscando encontrar ações que produzam um resultado definido e de valor para o

usuário na execução de cada processo.

O diagrama a seguir representa os possíveis usuários do negócio e suas respectivas

ações de acordo com o papel de cada um dentro do sistema.

51

Definir Modelo de Referência

Grupo de Modelagem

Calcular Erro de Previsão

Gerar Requisição do Processo de Previsão

Registrar Dados de Demanda

Sistema Computacional

Requisitar Projeto Previsão

Liberar Projeto do Processo de Previsão

Gerente

Realizar Revisão Gerencial

Definir Modelo Particular do Processo de Previsão

Apresentar Previsão Final

Consultar Modelo de Referência

Consultar Modelo Particular

Consultar Cenários

Consultar Metas

Grupo de Gerentes

Verificar Objetivos da PrevisãoDefinir Característica da Previsão

Definir Modelos Previsão

Analisar Requisição do Processo de Previsão

Analisar Resultdo de Erro

Identificar Fatores de Influência da Demanda

Definir Ajuste de Dados

Gerar Cenários de Previsão

Consultar Demanda Ajustada

Coletar Fatores de Influência

Consultar Requisição Previsão

Consultar Histórico de Erros

Verificar Histórico de Previsão

Consultar Objetivos

Consultar Características

Consultar Fatores de Influência da Demanda

Consultar Modelos Previsão

Consultar Fator de Influência

Consultar Modelos Selecionados

Consultar Ajuste de Dados

Analista Previsão

Cadastrar Objeto a Prever

Consultar Limites Erro

Figura 4.11 - Diagrama de Caso de Uso do negócio.

52

4.4.2 DIAGRAMA DE CLASSE DO NEGÓCIO

As informações levantadas através do diagrama de caso de uso acima são

analisadas e descritas detalhadamente e, juntamente com as vistas de objetos que

compõem cada atividade do modelo de empresa (Seção 4.1.1), é possível encontrar

os objetos que formam o ambiente do sistema, e definir seus relacionamentos em

Diagrama de Classe do Negócio, representado pela figura 4.12.

Em cada classe do diagrama são representados os requisitos mínimos para a

existência de cada classe (atributos) e as relações entre cada uma delas

(relacionamentos).

Porém, para uma melhor representação e entendimento do diagrama de caso de

uso e diagrama de classe, serão formados grupos dentro de cada diagrama,

baseados no significado de cada elemento e na forte relação existente entre cada

elemento. O agrupamento é feito em estruturas chamadas pacote. Cada pacote

define um processo do modelo de empresa.

Na seção seguinte será demonstrado o Processo Projetar Previsão e como são

definidos seus diagramas.

53

Figura 4.12 – Diagrama de Classe do Negócio

1..*

AtividadeVista

TipoVista

ItemPedido

PrecoPedidoQuantidade

ModeloAtividade

OrdemAtividade

ItemVista

CodItemVistaNomeItemVista

Evento

CodEventoNomeEvento

Vista

CodVistaNomeVistaObjetivoVistaDescricaoVista

1..11..* 1..11..*

Processo

CodProcessoNomeProcessoObjetivoProcessoDescricaoProcesso

1..*

1..1

1..*

1..1

ModeloReferencia

CodModeloReferDescricaoModeloDataModelo 1..*1..1 1..*1..1

TipoAgregacao

CodTipoAgregacaoNomeTipoAgregacao

AnaliseErro

RazaoErroAcoesControleErro

ResultadoAjuste

CodResultadoAjusteAjusteFinalPeriodoFinal

Pedido

CodPedidoDataPedidoDataEntregaTipoCompra

Cliente

CodClienteNomeClienteEnderecoClienteCEPTelefoneSexoDataNascimentoCPFIdentidadeDataCadastro

1..*

1..1

1..*

1..1

TipoDecisao

CodTipoDecisaoNomeTipoDecisao

SetorUsuario

CodSetorUsuarioNomeSetor

Prazo

CodPrazoNomePrazoTamanhoPrazo

ObjetoPrever

CodObjetoNomeObjetoComentarioObjeto

1..1

1..*

1..1

1..*

Bairro

CodBairroBairro

1..*

1..1

1..*

1..1

Cidade

CodCidadeCidade

1..*1..1

1..*1..1

1..*

1..1

1..*

1..1

1..*

1..1

1..*

1..1

Estado

CodEstadoEstado

1..*

1..1

1..*

1..1

1..11..* 1..11..*

EquacaoCorrelacao

CodEquacaoCorrelacaoEquacaoCorrelacaoObs_Correlacao

TipoCliente

CodTipoClienteNomeTipoCliente

0..*

0..*

0..*

0..*

Periodo

CodPeriodoPeriodo

RequisicaoProjeto

CodReqProjetoDataReqProjInfo_Adicionais

1..*

1..*

1..*

1..*1..*

1..*

1..*

1..*

1..*

1..1

1..*

1..1

1..1

1..*

1..1

1..*

Regiao

CodRegiaoNomeRegiaoTipoRegiao

1..*

1..*

1..*

1..*

1..*

1..*

1..*

1..*1..*

1..*

1..*

1..*

RequisicaoPrevisao

CodReqPrevisaoDataReqPrevisao

Caracteristica

VersaoProjetoDataVersaoProjetoInicioHorizonteFinalHorizonteSituacaoVersaoProjeto

1..1

0..1

1..1

0..1

0..*1..1

0..*1..1

1..*

1..1

1..*

1..1

1..1

1..1

1..1

1..1

1..*

1..1

1..*

1..1

1..1

0..*

1..1

0..*

PrevisaoFinal

CodPrevisaoFinalRevisaoGerencial

1..*1..1

1..*1..1

ResultadoCenario

CodResultadoCenarioResultadoCenarioPeriodoResultado

ValorParam

CodValorParamValorParamModelo

LimiteErro

LimiteMaximoLimiteMinimo

1..1

1..*

1..1

1..*

Cenario

CodCenarioNomeCenarioAnaliseCenario

1..1

1..1

1..1

1..1

1..*

1..1

1..*

1..1

ValoresFator

CodValorFatorValorFatorDataValorFator

ItensDemanda

CodItemDemandaDataDemandaQuantidadeDemanda

AjusteDados

CodAjusteDadoValorAjusteDescricaoAjuste

Participante

CodParticipanteNomeParticipante

1..*1..*

1..*1..*

ModeloParticular

CodModeloParticular

1..10..*

1..10..*

0..1

1..1

0..1

1..1

1..*0..*

Atividade

CodAtividadeNomeAtividadeObjetivoAtividadeDescricaoAtividade

1..*1..*

1..*1..*

1..* 1..*1..* 1..*

1..1

1..*

1..1

1..*

1..*

1..* 1..*

1..*1..*0..*

1..*

1..*

1..*

1..*

Produto

CodProdutoNomeProdutoPrecoProduto

1..*

1..*

1..*

1..*

1..* 1..*1..* 1..*

Metas

CodMetaDescricaoMeta

1..*

0..*

PrevisaoVersao

VersaoPrevisaoDataPrevisaoOrigemPrevisaoSituacaoPrevisaoObsPrevisao1..*

1..1

1..*

1..1

0..*

1..1

0..*

1..11..*

0..*

0..*

1..*

1..*

0..*

ModeloPrevisao

1..*

1..1

1..*

1..1

ParamModelo

CodParamModeloParametroModelo

1..*1..1 1..*1..1

BiBlioModelos

CodModeloTipoModeloNomeModelo

1..*

1..1

1..*

1..1

1..*

1..1

1..*

1..1

1..*

1..*

1..*

1..*

1..*

1..*1..*

ErroPrevisao

ValorErroDataErro

1..*1..1 1..*1..1

1..1

1..*

1..1

1..*

1..*

1..*

1..*

1..*

Demanda

CodDemanda

1..1

0..*

1..1

0..*

1..*

1..1

1..*

1..1

FatorInfluencia

CodFatorInfluenciaNomeFatorInfluenciaTipoFatorDataFatorDescricaoFator

1..*1..1 1..*1..1

1..*

1..1

1..*

1..1

0..*1..*1..*

0..*

54

4.4.3 DIAGRAMA DE CASO DE USO DO PROCESSO PROJETAR PREVISÃO

O diagrama de caso de uso do processo Projetar Previsão (Figura 4.13), é formado

pelos casos de uso e atores, relativos às atividades de empresa do modelo de

referência proposto e, apresenta as ações necessárias para realização do processo,

bem como quem realizará cada ação no sistema de informação.

L ib e ra r P ro je to do P ro c e s s o de P revis ão

G eren te

V e rific a r O b je t ivos d a P revis ão

De fi n ir Ca rac t e rí s t ic a da P re vis ã o

D e f in ir M ode l os P revis ão

Id en t ific a r F a to re s de In flu ên c ia da D em and a

D e fin i r o A jus t e de D ado s

A na lis ta P revis ão

D e fin ir M od e lo P a rt ic u la r d o P ro c es s o de P re vis ão

G rup o de G e re n tes

Figura 4.13 - Diagrama de Caso de Uso do processo PD1-Projetar_Previsão.

55

4.4.4 DIAGRAMA DE CLASSE DO PROCESSO PROJETAR PREVISÃO

O diagrama de classe representado pela figura 4.14 concentra as classes de objetos

encontradas através da descrição dos casos de uso e das vistas de objeto do

processo do Projeto de Previsão de Demanda. As classes neste diagrama

apresentam alguns métodos representando operações que poderão ser executadas

no sistema de informação.

Este diagrama de classe apresenta a classe relativa às regras de negócio do

sistema, representada pela classe de apoio, e a classe que representa o formulário

de apoio a tela correspondente ao processo Projetar Previsão no sistema, através da

classe de interface.

56

ProjetoTipoDecisao

Insert()

Delete()

(from Classe de Apoio)

DataModulo

(f rom Classe de Apoio) FormProjeto

OnclickPrimeiro()OnclickProximo()

OnclickAnterior()

OnclickUltimo()OnclickSituacao()

OnCreate()

AcresFator()AcresEquacaoCorrelacao()

AcresAjusteDados()AcresModelo()

AcresLimiteErro()AcresModeloParticular()

AcresParticipantes()

RetiraFator()RetiraEquacaoCorrelacao()

RetiraAjusteDados()

RetiraModelo()RetiraParticipantes()

(f rom Classe de Interface)

<<Interface>>

ClientesEnvolvidos

Insert()Post()

Delete()

(f rom Classe de Apoio)

Participante

CodParticipante

NomeParticipante

MostrarParticipantes()

Insert()Delete()

Edit()

Post()Select()

(f rom Classe de Negócio)

ModeloParticipante

Insert()

Delete()MostrarDados()

Post()

(from Classe de Apoio)

1..*

1..*

1..*

1..*

TipoCliente

CodTipoCliente

NomeTipoCliente

Insert()

Novo()

Edi t()Delete()

Select()

MostrarTipoCli ente()


0..1

0..*

0..1

0..*

Periodo

CodPeriodo

Periodo

Insert()

Edit()Post()

Delete()

Select()MostrarPeriodo()


Limi teErro

LimiteMaximo

LimiteMinimo

Insert()

Post()MostrarLimitesErro()

DeleteLimiteErro()


ModeloPrevisao

Insert()Post()

MostrarModelosPrevisao()

DeleteModeloPrevisao()

(from Classe de Negócio)

Regiao

CodRegiaoNomeRegiao

TipoRegiao

Insert()

Edit()Post()

Delete()Novo()

Last()

Next()First()

Prior()

MostrarRegiao()


BiBlioModelos

CodModelo

TipoModelo

NomeModelo

Insert()

Delete()Select()

Post()

Edi t()First()

Prior()

Next()Last()MostrarModelos()


1..1

1..*

1..1

1..*

1..*1..1

1..*1..1

TipoDecisao

CodTipoDecisao

NomeTipoDecisao

Insert()

Post()

Delete()Edit()

Select()


1..1

1..*

1..1

1..*Prazo

CodPrazoNomePrazoTamanhoPrazo

Insert()Delete()

Edit()

Post()Select()


ModeloParticular

CodModeloParticular

Insert()

Post()

Edit()MostrarModeloParticular()


0..*

0..*

0..*

0..*

1..*

1..1

1..*

1..1

1..1 1..*1..1 1..*

SetorUsuario

CodSetorUsuario

NomeSetor

Insert()

Post()Delete()

Select()


ProjetoSetorUsuario

Insert()

Delete()

(f rom Classe de Apoio)

1..1

1..*

1..1

1..*

FatorDemanda

CodFatorDemanda

Insert()

Post()Delete()

MostrarDados()


Requisi caoProjeto

CodReqProjetoDataReqProjInfo_Adicionais

Insert()Delete()

Prior()

Last()Next()

First()

Post()Select()

MostrarDados()


1..1

1..*

1..1

1..*

1..*

1..*

1..*

1..*

1..11..*1..11..*1..11..1

1..11..1

1..11..*

1..11..*

1..1

0..1

1..1

0..1

1..*

1..*

1..*

1..*

1..1

1..*

1..1

1..*

ObjetoPrever

CodObjeto

NomeObjetoComentarioObjeto

Insert()Delete()

Edit()

Post()Select()

First()

Next()Prior()

Last()


1..*

1..1

1..*

1..1

1..1

1..1

1..1

1..1

EquacaoCorrelacao

CodEquacaoCorrelacao

EquacaoCorrelacaoObs_Correlacao

Insert()Post()

Delete()

Edit()MostrarEquacao()


AjusteDados

CodAjusteDado

ValorAjuste

DescricaoAjuste

CalcularDemandaAjustada()

Insert()Post()

Delete()

MostrarDadosAjuste()


1..1

1..*

1..1

1..*

1..1

1..*

1..1

1..*1..*

1..1

1..*

1..1

1..*

1..1

1..*

1..1

Caracteristica

VersaoProjeto

DataVersaoProjeto

InicioHorizonteFinalHorizonte

SituacaoVersaoProjeto

Insert()

Edit()

Post()Prior()First()

Next()Last()

Insert()

MostrarDados()AlterarSituacao()


1..1

0..*

1..1

0..*

1..1

1..*

1..1

1..*

1..*

1..1

1..*

1..1

1..1

1..*

1..1

1..*

0..*1..1

0..*1..1

1..*

1..*

1..*

1..*1..*

1..*

1..*

1..*

1..1

1..*

1..1

1..*

1..1

1..*

1..1

1..*

0..*

0..*

0..*

0..*

0..1

1..1

0..1

1..1

FatorInfluencia

CodFatorInfluencia

NomeFatorInfluencia

TipoFatorDataFator

DescricaoFator

Insert()

Edit()

Post()Delete()

First()

Next()Prior()

Last()

MostrarFatores()


1..1

0..*

1..1

0..*

Demanda

CodDemanda

Insert()Post()

MostrarDados()


0..*

1..1

0..*

1..1

1..*

0..*

1..*

0..*

Figura 4.14 – Diagrama de Classe do Processo PD1-Projetar_Previsão

57

4.4.5 DIAGRAMA DE SEQÜÊNCIA DA ATIVIDADE ANALISAR OBJETIVOS

Cada caso de uso possui um diagrama de seqüência correspondente. Os diagramas

de seqüência representam a seqüência de ações que o usuário (ator) poderá

realizar no sistema. É composto por uma estrutura que representa o usuário, as

classes de objeto que participam da ação e os métodos (operações) que

representam a ação.

A visão dinâmica do modelo, sob a ótica do usuário, é representada através dos

diagramas de seqüência e cada diagrama de seqüência irá gerar uma tela

correspondente no sistema de informação.

O diagrama de seqüência abaixo representa o caso de uso da atividade Analisar

Objetivos do processo Projetar Previsão.

: A n a l i s t a

P r e v i s ã o

: F o r m

P r i n c i p a l

: F o r m P r o j e t o : R e q u i s i c a o

P r o j e t o

:

C a r a c t e r i s t i c a

O n c l i c k ( )

O n C r e a t e ( )

M o s t r a r D a d o s ( )

O n c l i c k S i t u a c a o ( )

A l t e r a r S i t u a c a o ( )

O n c l i c k P r i m e i r o ( )F i r s t ( )


O n c l i c k P r o x i m o ( ) N e x t ( )


O n c l i c k A n t e r i o r ( ) P r i o r ( )


O n c l i c k U l t i m o ( ) L a s t ( )



Figura 4.15 - Diagrama de Seqüência do Caso de Uso Analisar Objetivos.

58

Neste capítulo foram apresentados os principais construtores dos modelos de

referência de previsão de demanda de produtos conforme descrito por Santos

(2001).

No capítulo seguinte será apresentado a particularização desses modelos de

referência para o desenvolvimento de um sistema de previsão de demanda, e a

avaliação de questões relativas aos modelos de referência e ao processo de

particularização desses modelos.

59

CAPÍTULO V

DESENVOLVIMENTO DE UM SISTEMA DE PREVISÃO BASEADO EM UM

MODELO DE REFERÊNCIA

Neste capítulo será apresentado o desenvolvimento de um sistema de previsão

particular de uma empresa baseado no modelo de referência segundo Santos

(2001), e serão tecidas considerações sobre a aplicabilidade dos modelos de

referência e as adequações funcionais necessárias para o desenvolvimento do

modelo e sistema particular.

5.1 INTRODUÇÃO

Neste trabalho, baseado nos modelos de referência contidos no trabalho de Santos

(2001), foi criado um modelo de sistema de informação, e ao mesmo tempo, tem

como objetivo analisar as funcionalidades e aplicabilidade desse modelo de

referência para a previsão de demanda em uma indústria de autopeças. Essa

empresa tem como meta aprimorar a acurácia de suas decisões de gerência,

através um melhor processo e ferramentas para a previsão de demanda.

O estudo utiliza dados reais de uma indústria de autopeças do interior do Estado do

Rio de Janeiro. Os produtos por ela fabricados são destinados à aplicação em

equipamentos industriais como: Reboques e Semi Reboques, e Trucks. A empresa

recebe os pedidos de seus representantes por intermédio de meio eletrônico

diariamente, para montagem e entrega em sete dias úteis. Para tanto necessita

conhecer a demanda futura para, por exemplo, decidir adquirir matéria prima, e

recursos para fabricação das peças.

A empresa objeto de aplicação do modelo de referência de Santos (2001), utilizava

para previsão de demanda o sistema de informação ERP com software DATASUL –

EMS que se baseava em Médias Aritméticas sem levar em consideração os fatores

que influenciam o mercado, entre outras informações qualitativas de

acompanhamento da previsão (histórico), o que dificultava o processo de previsão

de demanda.

60

A seguir será descrita a empresa tomada como sede da aplicação, utilizando dados

reais para aplicação do sistema de informação.

5.2 DESCRIÇÃO GERAL DO SISTEMA PARTICULAR DESENVOLVIDO

Diferenciando do protótipo que foi desenvolvido em linguagem Delphi 4.0 com banco

de dados Access 2000 por Santos (2001), o sistema aqui apresentado foi

desenvolvido em linguagem Java, que tem uma linguagem aberta, opção da firma

empreendedora, uma vez que já possui grande parte de seu sistema nesta forma de

trabalho, possibilitando redução de custos.

Cabe ressaltar que o sistema foi desenvolvido com uma interface WEB, não sendo

possível explorar todos os recursos visuais de uma aplicação desktop.

No protótipo de Santos (2001) a previsão de demanda é suposta ser iniciada de

maneira formal, através de uma requisição. Já no caso da empresa em estudo, não

se obedece a formalidades, pois é uma empresa de médio porte e a previsão é

iniciada de maneira informal, vislumbrando um curto prazo para previsão.

A empresa estabelece como objetivo do Projeto de Previsão a realização da

previsão para produtos, compostos pelos modelos de peças que comercializa,

chamado de família de produtos. O setor que utilizará a previsão (setor usuário) será

o Marketing que baseados nos resultados da previsão deverá estabelecer decisões

de gerenciamentos dos setores de Planejamento da Produção, Suprimentos,

Financeiros, entre outros. A previsão da demanda foi estabelecida para um período

mensal.

Buscando melhor funcionalidade e diminuição na burocracia o presente sistema gera

diversos cenários, cada um com seu fator de influência, e posteriormente é gerada

uma previsão para cada cenário. A base de demanda dos cenários é feita através do

histórico de pedidos processados dos meses anteriores, e é estabelecido fatores de

influência para projeções futuras, durante o horizonte de tempo considerado. Os

resultados da previsão são avaliados através do monitoramento de erros.

61

5.2.1 LOGON USUÁRIO

A figura 5.1 apresenta a tela inicial da aplicação. Cada usuário cadastra previamente

seu logon e sua senha, e somente terá acesso permitido às suas áreas de interesse

de cadastro, atualizações, ou visualização.

5.2.2 MENU GERAL

A figura 5.2 apresenta as opções do Menu Geral com todas as opções permitidas de

acordo com o perfil do usuário. Para o usuário com acesso total, será permitida

através desta tela a autorização para cadastrar, consultar e gerenciar a previsão.

Figura 5.1 – Logon Usuários

62

O protótipo apresentado por Santos (2001), foi baseado no conceito de um sistema

Workflow, o que nesse sistema não foi utilizado, isto é, não existe a definição de

uma seqüência obrigatória ou formal de atividades definida previamente pelo

sistema, ou mesmo quais pessoas que devem fazer cada atividade.

A seguir é apresentado como os processos, atividades e funcionalidades definidas

no modelo de referência foram implementadas no sistema particular de previsão de

demanda, incluindo as principais telas da aplicação. São tecidos comentários sobre

as diferenças entre o modelo de referência e o particular.

5.3 IMPLEMENTAÇÃO DO PROCESSO DADOS DE DEMANDA

O modelo de referência deste processo está descrito na sessão 4.3.2 e ilustrado

pelo gabarito 2. A seguir descreve-se a implementação da única atividade desse

processo.

5.3.1 REGISTRAR DADOS

A atividade Registrar Dados é feita conforme descrito no protótipo de Santos (2001),

independente se os pedidos foram atendidos ou não. A base de dados é captada do

Figura 5.2 tela de Menu Geral

63

ERP (DATASUL – EMS) através do “Upload Pedido”, no Menu Geral, do sistema em

Java.

5.4 IMPLEMENTAÇÃO DO PROCESSO PROJETAR PREVISÃO


pelo gabarito 1. A seguir são comentadas as implementações das respectivas

atividades.

5.4.1 ANALISAR OBJETIVOS

Ao contrário da abordagem de Santos (2001) no sistema aplicado à indústria de

auto-peças, esta atividade é realizada de maneira informal, destinada unicamente

aos departamentos de marketing, vendas, planejamento e controle da produção,

compras, financeiro, e abrange todas as regiões.

5.4.2 DEFINIR CARACTERÍSTICAS

A atividade de definir características no protótipo descrito por Santos (2001), nesta

aplicação foi chamado por Requisição de Previsão.

O processo de previsão da empresa em questão contempla geralmente todas as

famílias de produtos em todas as regiões, porém foi aberto esses campos, após

consulta ao departamento comercial da empresa, em virtude de uma eventual

previsão para promoção em determinada família ou região. Nesta não foi criado o

campo tipo de cliente, pois a empresa onde foi desenvolvido a aplicação não

classifica sua previsão para determinados tipos clientes.

Como no protótipo proposto por Santos (2001), também nesta etapa se define as

características da previsão como: “horizonte de tempo” e “tipo da decisão”, conforme

ilustra a figura 5.3.

64

5.4.3 IDENTIFICAR FATOR DE INFLUÊNCIA

Uma vez mais diferenciando do trabalho de Santos (2001), nesta aplicação foi

invertido a ordem de colocação do fator de Influência pela Definição de Cenário e

onde se define o modelo matemático a ser utilizado, uma vez que podemos gerar

vários cenários diferentes, e cada um deles com seu fator de influência e seu modelo

matemático. O fator de influência será arbitrado em uma outra seção.

Nesta etapa não foi considerada a utilização do gráfico na visualização de cada

cenário gerado, uma vez a empresa identifica a visualização somente do cenário

aprovado.

A figura 5.4 contempla também a base de dados (limites) inicial e final da demanda,

bem como um campo de observação para descrição das características atribuídas

aos diversos cenários.

Figura 5.3 Requisição de previsão

65

O fator de Influência se cadastra na etapa seguinte ao modelo particular, como

ilustra a figura 5.5, onde identifica qual deve ser o fator, descreve seu valor, e no

campo observação, a descrição do ajuste para auxiliar futuros esclarecimentos.

Figura 5.4 Tela de Definição de Cenário

Figura 5.5 Tela Ajustar Dados

66

5.4.4 AJUSTAR DADOS

Nesta aplicação o Ajuste de Dados relativo a Demanda não foi implementado

Porém, pode-se fazer correções relativas a alguns fatores de influência através da

função Ajuste de Previsão, que é aplicado para acertos após uma previsão já ter

sido gerada e aprovada. Esta atividade pode ser feita a partir do ícone “Ajuste de

Previsão” no campo do Menu Geral.

A empresa em estudo identifica que somente fatores ocorridos após a geração da

previsão como: promoção da concorrência, variação cambial repentina, ou ainda

mudanças na taxa de Juros, entre outros, poderiam mascarar uma previsão.

5.4.5 SELECIONAR MODELOS

Como mencionado o modelo de aplicação foi desenvolvido em Java, e em busca de

uma otimização do projeto esta atividade de Seleção de Modelos matemáticos foi

associada à atividade de “Definição de Cenário”, descrita no item 5.4.3. O modelo

desenvolvido na empresa foi o de Regressão Linear e o de Média Aritmética, sendo

que futuramente poderão ser implementados e testados outros.

5.4.6 DOCUMENTAR E DEFINIR PARTICIPANTES

A empresa utilizada como modelo de aplicação, utilizou parcialmente esta atividade

tendo em vista desburocratizar, pois a participação na análise dos objetivos,

definição das características, identificação dos fatores de influência, ajuste de dados,

entre outros, são definidas pelos gerentes e pela diretoria comercial que se

posicionam em uma mesma sala.

Para os demais departamentos, como Financeiro, Planejamentos e Controle da

Produção, Compras, Controle de Materiais, que também utilizam a Previsão, é

permitido somente a visualização para consulta. Esta permissão é feita no perfil do

cadastro do usuário.

5.5 IMPLEMENTAÇÃO DO PROCESSO PREVISÃO DA DEMANDA

O modelo de referência deste processo está descrito na sessão 4.3.3 é ilustrado


atividades.

67

5.5.1 ANALISAR DADOS DA REQUISIÇÃO DE PREVISÃO

Esta atividade foi desenvolvida em uma outra etapa na aplicação em questão, ou

seja, após Geração da Previsão com diversos cenários a equipe se reúne com

objetivo de identificar qual será o mais indicado para aprovação.

5.5.2 GERAR CENÁRIOS

Esta atividade foi nomeada “Gerar Previsão”. Nesta fase será feita a geração de

todos os cenários propostos com seus respectivos: fatores de influência, base de

dados, modelos de previsão. A figura 5.6 ilustra a atividade Gerar Previsão.

5.5.3 REVISÃO GERENCIAL

Chamamos esta por “Aprovação da Previsão”, que se resume na escolha do cenário

mais adequado, aprovando-o através do campo “Aprova Previsão” do Menu Geral,

conforme mostra a figura 5.7. Também como contempla o modelo proposto por

Santos (2001), nesta fase também se pode fazer ajustes à previsão, através do

campo “Ajuste de Previsão” no campo Menu geral.

Figura 5.6 – Tela Gera Previsão

68

5.5.4 APRESENTAR A PREVISÃO

Esta atividade já está acessível após sua aprovação através do campo “Consulta

Previsão”. Nesta fase é comunicado a todos os setores, por meio eletrônico, que a

previsão está acessível para consulta.

5.6 IMPLEMENTAÇÃO DO PROCESSO MONITORAR ERRO



atividades.

5.6.1 CALCULAR ERRO

Esta etapa descrita no modelo de referência proposto por Santos (2001) foi

desenvolvida aqui da seguinte forma: No início de cada mês é feita a captura dos

pedidos colocados do mês anterior, mesmo aqueles que não foram entregues,

através do campo “Upload Pedido”, no campo do Menu Geral, do Sistema ERP

(Datasul – EMS) da empresa.

Figura 5.7 – Tela de Aprova Previsão

69

Nesta mesma atividade através do campo “Gera Demanda Real”, onde é feita a

escolha da previsão a ser confrontada, o sistema irá automaticamente comparar a

previsão desejada com os valores reais, conforme mostra a figura 5.8. Na etapa

seguinte pode-se visualizar o erro gerado na tela Análise da Previsão mostrado na

figura 5.9.

5.6.2 ANALISAR ERRO

A atividade Analisar Erro proposta por Santos (2001) foi aqui chamada de “Análise

de Previsão”, também permite comentar as razões do erro, e as ações a serem

tomadas a fim de corrigir os parâmetros para as próximas previsões. Esta

visualização pode ser feita através do campo “Gráfico” no Menu Geral, conforme

mostra figura 5.9.

Figura 5.8 – Tela Gera Demanda Real (Cálculo do Erro)

70

A figura 5.10 pode-se registrar as possíveis causas do erro, bem como as ações

propostas para correções de previsões futuras.

Figura 5.9 Consulta Análise da Previsão (Gráfico)

71

Figura 5.10 Análise da Previsão (Registro Causa – Ação Corretiva)

5.7 IMPORTÂNCIA E APLICABILIDADE DO MODELO DE REFERÊNCIA

De forma geral, todas as atividades e funcionalidades descritas no modelo de

referência foram considerados importantes e aplicáveis em um sistema particular de

previsão de demanda de empresa, porém neste trabalho, pela limitação de tempo ou

pelo fato de não ser tão essencial no momento para a empresa em questão,

algumas não foram implementadas (ver tabela 5.1).

Os modelos de referência relativos às atividades documentar e definir participantes e

apresentar a previsão final foram implementadas parcialmente no desenvolvimento

do sistema, pois a empresa não necessita do Workflow, isto é, de uma seqüência

formal de atividades. O sistema apresenta grande funcionalidade, pois permite que

um determinado participante possa solicitar e acompanhar um processo de previsão,

através das opções do menu que se apresenta de forma dinâmica. Desta forma, o

usuário de acordo com seu perfil, será permitido o acesso a inclusão de uma

72

requisição, ou apenas a consulta dos cenários aprovados e análise da previsão

diferentemente do modelo de Santos (2001).

Devido a falta de tempo, apenas o modelo matemático de média aritmética foi

implementado. O modelo de regressão linear foi feito, porém será implementado

após o registro de um histórico da demanda. O diferencial do modelo de Santos é a

possibilidade de registrar informações qualitativas ao processo de previsão, e assim,

por exemplo, poder interpretar os resultados dos erros de previsão.

Atividades do Modelo de

Referência

Importância

para a Empresa

(Alta, Média,

Baixa)

Aplicado no Modelo

Particular

(Sim, Parcialmente,

Não)

1. Dados de Demanda Alta Sim

2. Analisar Objetivos Alta Sim

3. Definir Características Alta Sim

4. Identificar Fator de Influência Alta Sim

5. Ajustar dados Baixa Parcialmente

6. Selecionar Modelos Baixa Sim

7. Documentar e Definir

Participantes

Média

Parcialmente

8. Analisar Dados da Requisição

de Previsão

Alta

Sim

9. Gerar Cenários Alta Sim

10. Revisão Gerencial Alta Sim

11. Apresentar a Previsão Final Média Parcialmente

12. Calcular Erro Alta Sim

13. Analisar Erro Alta Sim

5.8 ATIVIDADES DO MODELO PARTICULAR

Tabela 5.1 Comparativo das atividades do Modelo de Referência e Modelo Particular

73

5.8 ATIVIDADES DO MODELO PARTICULAR

Apesar do sistema não ser um workflow, nem ter sido definido um processo formal

de previsão de demanda na empresa, pode-se definir uma seqüência lógica de

atividades a ser executada, como se fosse um modelo de processo particular de

previsão, conforme a figura 5.11.

Start

Requisição Previsão – figura 5.2

Analisar Objetivos – sessão 5.4.1

Definir Características – sessão 5.4.2

Gerar Cenário – figura 5.4

Identificar Fator de Influência- figura 5.5

Gerar Previsão – figura 5.6

Aprovar Previsão – figura 5.7

Liberar Processo – sessão 5.5.4

Finish

Figura 5.11 – Processo particular de Previsão de Demanda

74

Na figura 5.12 descreveremos a seqüência lógica das atividades para análise de

erros da previsão, que chamamos de Análise da Previsão, descrito na sessão 5.6.2.

5.9 DIAGRAMA DE CLASSES DE OBJETO PARTICULAR DA EMPRESA

Na figura 5.13 a seguir, é apresentada parte do Diagrama de Classes de Objetos do

sistema e informação particular na linguagem UML.

Start

Coleta de Dados Reais – sessão 5.6.1

Gerar Demanda Real – Figura 5.8

Análise da Previsão – Figura 5.9

Finish

Figura 5.12 – Processo Particular de Análise de Erros

75

Figura 5.13 – Modelo de Objetos do Sistema particular

76

CAPÍTULO VI

CONSIDERAÇÕES FINAIS

Neste trabalho, foi aplicado o modelo de Santos (2001) para previsão de demanda

para produtos, através do desenvolvimento de um sistema integrado ao ERP Datasul

de uma empresa de auto peças, escrito em linguagem Java.

Conforme observou Santos (2001) o modelo por ela proposto deve sofrer

adequações para que seja aplicado atendendo a particularização da empresa.

A aplicação do modelo particular foi avaliada nos últimos seis meses, onde mostrou

sua aplicabilidade e possibilitou redução de tempo para processar os cálculos da

previsão. Entre outras questões pode-se observar que no sistema anterior de

previsão usava-se o histórico dos produtos faturados, mas notou-se que eles não

contemplavam os fatores sazonais, algo que foi adequado e hoje já damos ênfase a

fatores de influência na aplicação descrita. Outro ponto de destaque foi que durante

a aplicação do modelo particular, verificou-se que a base de dados levava em conta

a data do faturamento dos pedidos. Em um determinado mês, com todos os pedidos

prontos, devido a um contra tempo os mesmos não puderam ser faturados,

constatou-se que isto causaria erro nos cálculos de futuras previsões. Para tanto foi

necessário alterar a tomada de dados, que passou a ser baseada na data de

entrega dos pedidos, e assim eles ficarão registrados, sendo ou não entregues.

O ERP era usado para realizar a previsão, levava aproximadamente 02 horas para

processar seus cálculos, e quando havia necessidade de fazer alterações nessa

previsão gastava-se um tempo ainda maior. O presente software em Java eliminou o

problema do tempo, processando o cálculo em aproximadamente 02 minutos.

Também proporciona alterações nos dados de entrada e saída da previsão de

maneira mais fácil e simples.

Algo relevante que podemos destacar quanto a tela Gerar Cenários em comparação

ao modelo anterior da empresa é que o mesmo permite visualizar vários cenários e

alterá-los cada um individualmente sem que para tanto seja necessário perder os

cenários já existentes, possibilitando desta forma comparações. O modelo utilizado

77

anteriormente ela empresa permitia alterações, mas não conservava os cenários

gerados anteriormente.

No decorrer desses quatro meses de estudo foi observado que a falta de

informações sobre as variações de fatores que influenciaram os faturamentos dos

anos anteriores, impediram de aproximar a previsão de demanda neste período. Mas

mesmo neste período já pudemos observar a real necessidade no comportamento

da previsão mediante as informações coletas e registradas no software, o que será

de grande valia para os meses subseqüentes. Constatou-se que alguns fatores de

influência que anteriormente não eram considerados como significativos, como:

volume das chuvas, taxa Selic, colheita de grãos nacional e internacional, entre

outros, serviram para nortear previsões de demanda.

A tabela 6.1 ilustra o resultado das previsões e o cálculo do erro para o período de

cinco meses de aplicação.

1 PREVISÃO DA DEMANDA

MÊS 1.1.1 DEZ/04 Jan/05 Fev/05 Mar/05 Abr/05

PREVISÃO 378,750 421,581 384,024 406,600 345,623

DEMANDA REAL 327,558 422,739 353,718 352,995 348,296

ERRO SISTEMA PROPOSTO 13,52% -0,27% 7,89% 13,18% -0,77%

ERRO SISTEMA ANTERIOR 22,37% 17,43% 18,02% 19,15% 18,59%

A empresa, objeto do estudo de caso, considera de extrema importância a pesquisa

científica e está satisfeita com o empreendimento, que foi facilitado pelo modelo de

referência.

Como sugestão para trabalhos futuros o modelo particular de previsão poderá

aplicar uma inteligência computacional através de redes neurais, algoritmo de lógica

nebulosa, ou ainda máquina de inferência.

78

Concluímos então que o modelo de referência de Santos (2001), aplicado neste

trabalho, melhorou e contribui para o sucesso da previsão da demanda na empresa

de auto peças estudada e tem boa capacidade para ajudar a desenvolver modelos e

sistemas particulares.

79

BIBLIOGRAFIA

AGUIAR, M. W. C., Rapid Prototyping of Integrated Manufacturing Systems by

Accomplishing odel-enactment, em Integrated Manufacturing Systems

Engeneerin., Chapman and Hall, 1995.

AMARAL, D.C., ROZENFELD, Prof. H. Modelagem de Empresa. Disponível em:

http://www.nema.org.br/conhecimentos/conhecimentos acesso em: 28/08/2004.

AZEVEDO, R.C., REBELATO, D.N., BREMER, C.F., TOLONI, A. L.A. O Uso de

Sistemas ERP no Processo de Gestão de Demanda em Ambientes Make- To-

Stock – XXIII Encontro Nacional de Engenharia de Produção. Ouro Preto, MG:

2003.

BERIO, G., VERNADAT, F.B. New Developments in Enterprise Modelling using

CIMOSA Computers in Industry 40, 99 – 114 p., 1999.

BERNUS, P., NEMES, L., EDITORS, T. J. W. Architectures for Enterprise

Integration. Findings of the IFAC/IFIP Task Force on Architectures for Enterprise

Integration. Chapman & Hall: November, 1995.

BOOCH, G., RUMBAUGH, J., JACOLSON, I. UML, Guia do Usuário. Rio de

Janeiro: Campus, 2000.

CAMPOS, Renato. Uma Proposta de Modelagem para Integração de Sistemas

de Gestão de Produção em Empresas de Manufatura.Tese (Doutorado em

Engenharia Mecânica), Campinas- S.P.:Universidade Estadual de Campinas-

UNICAMP, 195p., 1998.

CORRÊA, Henrique L.; GIANESI, Irineu G. N.; CAON, Mauro. Planejamento,

Programação e Controle da Produção. 4ª ed. São Paulo: Atlas, 2001.

DEITEL, H.M., DEITEL, P.J. JAVA Como Programar, 3ª ed. Porto Alegre: Bookman

Editora, 2001.

80

DIAS, G.P.P. Proposta de processo de Previsão de Vendas para Bens de

Consumo XIX ENEGEP / V Congresso Internacional de Engenharia de

Produção. Rio de Janeiro, 1999.

DIAS, M.A.P. Administração de Materiais: Uma Abordagem Logística. São

Paulo: Editora Atlas, 1990.

DIAZ, C.A.P., PIRES, S.I.R. Variação da Demanda ao Longo da Cadeia de

Suprimentos: O Efeito da Amplificação da Demanda, XXIII Encontro Nacional

de Engenharia de Produção. Ouro Preto – MG, 2003.

ERIKSON, H., PENKER, M. Business Modeling With UML:Business Patterns at

Work. Canada: Wiley, 2000.

FLEURY, Paulo Fernando et al. Logística Empresarial. São Paulo: Atlas, 2000.

FURLAN, J.D. Modelagem de Objetos através da UML- The Unifield Modeling

Language. São Paulo: Makron Books, 1998.

KIM, C.H., WESTON, R.H. The Complementary use of IDEF and UML Modelling

Approches. Computers in Industry 50. 35 – 56 p. 2003.

KOSANKE, K . CIMOSA Overview and Status. NETHERLANS: Computer in

industry. V.27, n.2, p. 101-109., 1995.

MARTINS, P., LUGENI, F. Administração da Produção. São Paulo: Editora

Saraiva, 2002.

MONKS, Joseph G. Previsão: Métodos Estatísticos. In Administração da

Produção. São Paulo. Mc Graw-Hill. 1987.

PACHECO, R.F., SILVA, A.V.F. Aplicação de Modelos Quantitativos de Previsão

em uma empresa de Transporte Ferroviário, XXIII Encontro Nacional de

Engenharia de Produção. Ouro Preto – MG, 2003.

81

PIRES, S.R.I. Gestão Estratégica da Produção. Piracicaba – SP: Unimep, p.119-

167, 1995.

PORTER, M.E. Vantagem Competitiva São Paulo: Editora Campus, 1996.

PROTO, L. O. L., MESQUITA, M.A.M. Previsão de Demanda para Planejamento

da Capacidade de Empresa do setor Cimenteiro XXIII Encontro Nacional de

Engenharia de Produção. Ouro Preto – MG, 2003.

SALIBY, Eduardo. Lidando com Sazonalidades no Processo Logístico. Centro de

Estudos em Logística – COPPEAD- UFRJ, Rio de Janeiro. Disponível em:

http://www.coppead.ufrj.br/pesquisa/cel/new/fs-busca.htm?fr-sazonal.htm acesso em

30/09/2003.

SANTOS, Luciana Rocha dos. Modelagem de Processos de Empresas e Projeto

de Sistemas de Informação: Uma Aplicação para Auxílio à Previsão de

Demanda de Produtos. 147f. Dissertação (Mestrado) – Programa de Pós-

Graduação em Ciências de Engenharia, Universidade Estadual do Norte

Fluminense, Campos dos Goytacazes – RJ., 2001.

SANTOS, L.R., CAMPOS, R. Modelagem de Processos e Definição de

Requisitos de um Sistema de Informação para Previsão de Demanda, Encontro

Nacional de Administração. Campinas – SP, 2001.

SHEN, H., WALL, B., ZAREMBA, M., CHEN, Y., BROWNE, J. Integration of

Business Modelling methods for Enterprise Information System Analysis and

user Requirements Gathering. Computers in Industry 54. 307 – 323 p. 2004.

SLACK, Nigel et al. Administração da Produção. São Paulo: Atlas, 1997.

TORRES, J.B. Um Modelo Dinâmico de apoio a Gestão Organizacional baseado

na Modelagem de Processos utilizando Componentes de Software. Dissertação

de tese submetida à Universidade Federal de Santa Catarina, Florianópolis: 2002.

82

TUBINO, Dalvio Ferrari. Manual de Planejamento e Controle da Produção. 2ª ed.

São Paulo: Atlas, 2000.

VERNADAT, F.B.A. Enterprise Modeling and integration, Principles and

Aplications.Londres: Chapman & Hall, 1995.

83

ANEXO I

MODULOS DISPONIVEIS NA MAIORIA DOS ERPs

Segundo Corrêa et al. (2001), os fornecedores vão, com objetivo de ampliar o

escopo dos produtos vendidos, agregando mais e mais módulos que suportam mais

e mais funções, integradamente, aos módulos de manufatura, com escopo que

passou a transcender em muito o escopo de manufatura. Quando os fornecedores

passam a considerar que suas soluções integradas são suficientemente capazes de

suportar as necessidades de informação para todo o empreendimento, passam a se

auto denominar fornecedores, não mais de MRPII mas de sistemas ERP.

1. Módulos Relacionados a Operações e Supply Chain Management

Previsões/ Análises de Vendas (Forecasting/Sales Analysis)

Auxilia a função de previsão de vendas da empresa. Em geral, esses módulos

trazem alguns modelos matemáticos simples para correlações e extrapolações como

medidas móveis, amaciamento exponencial e correlações por mínimos quadrados. É

necessário estar atento para o fato de que o uso de uma técnica inadequada de

previsão de vendas pode trazer mais malefícios que benefícios para um bom

funcionamento do sistema MRP II/ERP. Não basta, portanto, escolher um dos

modelos disponíveis nesses módulos ao acaso e passar a usá-lo. É necessária uma

criteriosa análise com testes estatísticas, tanto para decidirmos qual dos modelos

disponíveis melhor se aplica à situação analisada quanto para decidirmos como

parametrizar o modelo escolhido. Também é importante considerar que o uso

exclusivo de um modelo matemático de série temporal histórica (como são os

modelos geralmente disponíveis nos softwares comerciais) pode carregar riscos

importantes de erros em ambientes turbulentos, onde a hipótese de que o futuro irá

repetir os padrões de comportamento passado pode não se manter. Nesse caso, os

resultados do modelo matemático devem ser ajustados por análises qualitativas

criteriosas. Os módulos de análise de vendas, em geral, também permitem

levantamentos estatísticos de vendas históricas por período, por cliente, por região,

entre outros;

84

Listas de Materiais (Bom – Bills of Material)

Módulo responsável pelo apoio à manutenção das estruturas de produtos da

organização: substituição de componentes e mudanças de engenharia em geral

devem fazer-se refletir no sistema MRPII/ERP. O módulo de lista de materiais apóia

esta função. Em geral traz funções de substituição em massa de componentes

(quando um componente não substituído em apenas um produto mas em todos

onde aparece), geração de estruturas de produtos baseados em outra já existente e

parecida e outras que se destinam a facilitar o processo de entrada dos dados de

atualização.

Programação-Mestre de Produção/ Capacidade Aproximada (MPS – Master

Production Scheduling/ RCCP – Rough-Cut Capacity Planning)

Planejamento de Materiais (MRP – Material Requirements Planning)

Planejamento Detalhado de Capacidade (CRP – Capacity Requirements Planning)

Compras (Purchasing): O módulo de compras visa apóia informacionalmente o

processo decisório da função de suprimentos dentro da empresa. Auxílio a cotações

(guardando as condições das últimas cotações, por fornecedor, por exemplo),

emissão e gestão de pedidos de compras, follow-up de compras (fornecendo listas

de todos os materiais que devem chegar na semana subseqüente e seus

fornecedores, para acompanhamento, por exemplo), manutenção de cadastro de

fornecedores, acompanhamento de desempenho de compradores são algumas das

funções apoiadas pelas melhores soluções de aplicativo MRP II/ERP.

Controle de Fabricação (SFC – Shop Floor Control)

Controle de Estoque (Inventory): O módulo de controle de estoques apoia a função

de controle de inventários. Posições de níveis de estoque, transações de

recebimento, transferências, baixas, alocações de materiais, entre outras são

apoiadas por esse módulo. A gestão de materiais, às vezes chamados não-

produtivos (que não pertencem a nenhuma estrutura de produtos), também é feita

no âmbito desse módulo, utilizando lógicas de ponto de reposição, revisão periódica

ou outra. Procedimentos necessários a garantir uma boa acurácia dos registros de

85

posições de estoques, como rotinas de inventário rotativo (em que se inventariam os

continuamente os materiais em vez de inventariarmos todos uma vez por ano)

também em geral são apoiados por esse módulo.

Engenharia (Engineering): Módulo que se encarrega de apoiar a função de

engenharia no que se refere as suas interfaces com o processo de planejamento –

controle de mudanças de engenharia, controle de números de desenhos, controle de

mudanças de processos produtivos e roteiros de fabricação, tempos referentes aos

processos produtivos, entre outros.

Distribuição Física (DRP – Distribution Requirements Planning): Gestão da

demanda, para um tratamento mais detalhado do módulo DRP.

Gerenciamento de Transporte (TM – Transport Management): Módulo que apóia a

tomada de decisão em relação ao transporte de materiais (em geral de produtos

acabados). Cadastramento e controle de fornecedores de serviço de transporte,

alocação de veículos a rotas, montagem de cargas de veículos, entre outras, são

funções que o módulo TM pode suportar.

Gerenciamento de Projetos (Project): Algumas empresas, embora interessadas na

integração que os sistemas ERP proporcionam, têm características específicas em

seus sistemas produtivos que fazem com que os módulos do MRP II original sejam

inadequados para o apoio as suas necessidades de informação. As empresas que

trabalham com grandes produtos não repetitivos, por exemplo (grandes

transformadores, grandes máquinas especiais feitos por encomenda, por exemplo),

trabalham “por projeto”. Cada produto é um projeto e como tal, tem um início bem

definido, um grande número de atividades não repetitivas inter-relacionadas e um

final bem definido. Nesses casos, não consideramos que os módulos originais do

MRP II sejam suficientes. É necessário um apoio para a gestão da rede de

atividades inter-relacionadas, normalmente com lógica COM ou PERT (Critical Path

Method ou Program Evaluation and Review Technique). Esse apoio é provido pelo

módulo de gestão de projetos, que trabalha naturalmente integrado com outros

módulos do ERP.

86

Apoio à Produção Repetitiva: Algumas situações industriais trabalham com

produções de tal forma repetitivas que a lógica estrita do MRP não se adequa

perfeitamente. Nas produções de altos volumes, por exemplo, é comum achar

situações em que, nas fábricas, trabalhamos com taxa de produção diária, semanal,

ou outra, em vez de trabalharmos com ordem de produção (que é como o MRP

trabalha). É necessário, portanto, para aquelas empresas que desejam utilizar o

MRP II e que tenham produções de altos volumes e repetitivas, que sejam apoiadas

por alguma ferramenta que ajude na compatibilização da forma que o MRP II

trabalha (por exemplo, com ordens de produção). Esse apoio é dado pelo módulo de

apoio à produção repetitiva.

Apoio à Gestão de Produção em processos: Empresas que têm produção em fluxo

contínuo também, em princípio, não são bem atendidas pela lógica original estrita do

MRP II. Algumas soluções de aplicativos de software MRP II, portanto disponibilizam

um módulo específico para o apoio à produção em fluxo contínuo, muitas vezes

chamado módulo de apoio à gestão de produção em processo, inclusive com o

tratamento adequado de co-products e by-products.

Apoio à Programação com Capacidade Finita de Produção Discreta:

Configuração de Produtos:

2. Módulos Relacionados à Gestão Financeira/ Contábil/ Fiscal

Contabilidade Geral: Módulo que contempla todas as funções tradicionais

necessárias para atender a necessidades da contabilidade geral.

Custos: Módulo que apóia a apuração de custos de produção integrado com os

módulos que geram as transações físicas que originam as transações de custos.

Podemos, em geral, apurar custos-padrão, custos efetivos sendo que algumas

soluções apóiam inclusive as empresas que decidem adotar a lógica de custeio por

atividade (ABC).

Contas a Pagar: Módulo que apóia o controle das obrigações e pagamentos devidos

pela empresa, cadastro de fornecedores, entre outros.

87

Contas a Receber: Controle de contas a receber, cadastro de clientes, controle de

situação creditícia de clientes, prazos, entre outros.

Faturamento: Módulo que apóia a emissão e controle de faturas e duplicatas

emitidas e apóia também as receitas fiscais referente à venda de produtos.

Recebimento Fiscal: Módulo que apóia as transações fiscais referente ao

recebimento de materiais.

Contabilidade Fiscal: Módulo que apóia as transações da empresa em seus

aspectos de necessidade de cumprimento de requisitos legais (manutenção de

livros fiscais etc).

Gestão de Caixa: Módulo financeiro de apoio à gestão (planejamento e controle)

dos encaixes e desencaixes da empresa.

Gestão de Ativos: Módulo que apóia o controle dos ativos (aquisição, manutenção,

baixas) da empresa.

Gestão de Pedidos: Módulo de apoio à administração dos pedidos de clientes.

Aprovação de crédito, controle de datas, entre outros.

Definição e Gestão dos Processo de Negócio (Workflow): Módulo que apóia a

empresa no sentido de mapear e redefinir seus processos administrativos.

3. Módulos Relacionados à Gestão de Recursos Humanos

Pessoal (Personnel): Controla o efetivo de pessoal da empresa, tratando de

aspectos como centros de custo no qual os funcionários, programação de férias,

currículos, programação de treinamento, avaliações entre outros.

Folha de Pagamento (Payroll): Controla a folha de salários dos funcionários da

empresa.

88

JAVA

A infra-estrutura de hardware necessária pode ser assim dividida:

• Servidor

Pentium III com 512 MB de memória RAM de 20 GB de disco

• Estação de Trabalho

Pentium II com 64 MB de memória RAM e 10 GB de disco

• Aplicações Instaladas

Aplicações Instaladas:

• Servidor

J2DK 1.4.x

JaKarta-apache-tomcat 4.1.x

• Estação de trabalho

Web Browser - IE ou Mozilla

capítulo i - uenf.br(datasul). 5 – treinar os ... necessárias ao processo...

Documents