CAPÍTULO I INTRODUÇÃO

Transcrição

1 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 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 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 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 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 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 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 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 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 10 CORRÊA et al. (2001), na figura 2.1, apresenta os principais elementos da Gestão de Demanda: Previsão de demanda Influência sobre o mercado Promessa de prazos Gestão de Demanda Comunicação com o mercado Priorização e alocação Figura 2.1 Elementos de Gestão de Demanda (CORRÊA et al., 2001) 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

11 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 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 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 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 PROCESSO DE PREVISÃO SEGUNDO BRANDER (1995) Este processo de previsão está esquematizado figura 2.2. Coletar e Analisar os dados Vendas Módulo de Previsão Monitoramento dos erros Cálculo da Previsão Previsão Final Os erros estão satisfatórios? N S OK Revisar o modelo Figura 2.2 Processo de Previsão (adaptado de BRANDER, 1995) 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;

15 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 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 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) 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?

17 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 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 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 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 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 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 Determina uma estrutura para atividades de padronização futura na área de modelagem de empresas CIM CEN 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 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 As definições apresentadas por CIMOSA serviriam de base para o desenvolvimento de outras arquiteturas e métodos de trabalho.

24 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 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 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 ). (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 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 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 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 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 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 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 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 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 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 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 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 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) 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; 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 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. DM1 PREVISÃO DE DEMANDA - Projeto Previsão - Dados de Demanda - Previsão de Demanda - Monitorar Erro DM2 PCP - Controle da Produção - Planejamento Agregado - Planejamento Mestre - Planejamento das Necessidades de Materiais - M.R.P. - Programação da Produção DM3 VENDAS/ MARKETING/ - Recebimento de Pedidos - Pesquisa de Mercado -. Figura Principais Domínios e Relacionamentos de Domínios identificados. 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.

37 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: EV-Req_Projeto_Previsão EV-Projeto_Previsão PD1 EV-Rever_Projeto EV-Pedido_Produtos EV-Periódico PD2 PD4 EV-Dados_Demanda EV-Req_Previsão_Demanda EV-Rever_Previsão EV- Previsão_Definida PD3 Figura Coordenação dos Processos. 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-

38 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 AE4 Ajustar_Dados AE10 Gerar_Cenários AE11 Revisão_Gerencial AE12 Apresentar_Previsão PD3 Monitorar_Erro (Figuras 4.9 e 4.10) (Gabarito 4) AE4 Ajustar_Dados AE13 Calcular_Erro AE14 Analisar_Erro

39 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 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 40 DOMAIN PROCESS Name: Identifier: Type: Design Authority: Projetar_Previsao PD1- Projetar_Previsao Previsão 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. 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.

41 41 Start Analisar_Objetivos ObjetivosAnalisados Definir_Caracteristicas CaracteristicasDefinidas Identicar_Fator_Influencia FatoresIdentificados Ajustar_Dados ReverProjeto DadosAjustados Selecionar_Modelos ModelosSelecionados Documentar_Participantes ModeloParticular Liberar_Processo ProcessoLiberado Finish Figura Processo PD1-Projetar_Previsão 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.

42 42 ES ObjetivosAnalisados VO_Historico_Previsao VO_Requisicao_Projeto Analisar_Objetivos VO_Objetivos_Previsao VO_Analista_Previsao ES CaracteristicasDefinidas VO_Historico_Previsao VO_Objetivos_Previsao VO_Sistema_Computacional VO_Analista_Previsao Definir_Caracteristicas VO_Caracteristicas_Previsao VO_Caracteristicas_Previsao VO_Objetivos_Previsao VO_Fatores_Influencia VO_Historico_Previsao Identicar_Fator_Influencia ES FatoresIdentificados VO_Fatores_Influ_Demanda VO_Sistema_Computacional VO_Analista_Previsao VO_Caracteristicas_Previsao VO_Objetivos_Previsao ES DadosAjustados VO_Dados_Demanda VO_Fatores_Influ_Demanda VO_Sistema_Computacional VO_Analista_Previsao VO_Objetivos_Previsao VO_Ajuste_Dados VO_Biblioteca_Modelos VO_Dados_Demanda VO_Sistema_Computacional VO_Analista_Previsao VO_Caracteristicas_Previsao VO_Objetivos_Previsao VO_Informacoes_Previsao VO_Modelos_Referencia VO_Participantes VO_Sistema_Computacional VO_Grupo_Gerentes VO_Caracteristicas_Previsao VO_Objetivos_Previsao VO_Modelo_Particular VO_Sistema_Computacional VO_Gerente Ajustar_Dados Selecionar_Modelos Documentar_Participantes Liberar_Processo VO_Ajuste_Dados ES ModelosSelecionados VO_Modelos_Erros VO_Modelos_Previsao ES ModeloParticular VO_Modelo_Particular ES ProcessoLiberado ES Rever_Projeto VO_Projeto_Processo Figura Atividades com respectivas entradas e saídas (Vistas de Objetos) do Processo PD1- Projetar_Previsão.

43 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). DOMAIN PROCESS Name: Identifier: Type: Design Authority: Dados_Demanda PD2- Dados_Demanda 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. 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 DemandaRegistrada Finish Figura Processo PD2-Dados_Demanda.

44 44 Abaixo a figura 4.6 representa os componentes da atividade Registrar Dados. ES DemandaRegistrada VO_Pedido_Produtos Registrar_Dados VO_Dados_Demanda VO-Sistema_Computacional Figura Atividades com respectivas entradas e saídas (Vistas de Objetos) do Processo PD2- Dados_Demanda PROCESSO PREVISÃO DE DEMANDA O processo de domínio Previsão de Demanda é descrito no Gabarito 3, apresentado abaixo: DOMAIN PROCESS Name: Identifier: Type: Design Authority: Previsao_Demanda PD3- Previsao_Demanda 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 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 RequisicaoAnalisada Ajustar_Dados DadosAjustados Gerar_Cenarios CenariosGerados NovoCenario Revisao_Gerencial RevisãoRealizada Apresentar_Previsao Fim-Previsao Finish Figura Processo PD3-Previsão_Demanda.

46 46 VO_Caracteristicas_Previsao VO_Modelo_Particular VO_Objetivos_Previsao VO_Historico_Previsao VO_Requisicao_Previsao VO_Sistema_Computacional VO_Analista_Previsao VO_Caracteristicas_Previsao VO_Dados_Demanda VO_Ajuste_Dados VO_Fatores_Influ_Demanda VO_Requisicao_Analisada 1 VO_MODELOS_PREVISAO VO_Sistema_Computacional VO_Analista_Previsao VO_Objetivos_Previsao VO_Caracteristicas_Previsao VO_Caracteristicas_Previsao VO_Cenarios VO_Fatores_Influ_Demanda VO_Historico_Previsao VO_Metas VO_Previsoes VO_Sistema_Computacional VO_Grupo_Gerentes Analisar_Requisicao Gerar_Cenarios Revisao_Gerencial ES RequisicaoAnalisada VO_Requisicao_Analisada ES CenariosGerados VO_Cenarios ES RevisaoRealizada ES NovoCenario VO_Metas_Revisadas VO_Previsao_Final VO_Req_Novos_Cenarios ES Fim-Previsao VO_Previsao_Final VO_Sistema_Computacional VO_Grupo_Gerentes Apresentar_Previsao VO_Previsao_Apresentada Figura Atividades com respectivas entradas e saídas (Vistas de Objetos) do Processo PD3- Previsão_Demanda.

47 PROCESSO MONITORAR ERRO O processo de monitoramento de erro é descrito pelo Gabarito 4 e a Figura 4.9. DOMAIN PROCESS Name: Identifier: Type: Design Authority: Monitorar_Erro PD4-Monitorar_Erro 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. Start Ajustar_Dados Dados_Ajustados Calcular_Erro Erros_Fora_Limites Analisar_Erro Erros_Dentro_Limites Erros_Analisados Finish Figura Processo PD4-Monitorar_Erro.

48 48 Na Figura 4.10 são representados os gráficos das atividades que compõem o processo Monitorar Erro. VO_Limites_Erro s VO_Dados_Monitorament o VO_Sistema_Computaciona l VO_Caracteristicas_Previsao VO_Objetivos_Previsao VO_Dados_Monitoramento VO_Erro_Previsao VO_Sistema_Computacional VO_Analista_Previsao Calcular_Erro Analisar_Erro ES Erros_Dentro_Limites ES Erros_Fora_Limites VO_Erro_Previsa VO_Requisicao_Analise o EV Rever_Previsao EV Rever_Projeto ES Erros_Analisados VO_Analise_Erro Figura Atividades com respectivas entradas e saídas (Vistas de Objetos) do Processo PD4- 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: OBJECT VIEW Name: Identifier: Type: Design Authority: Requisicao_Projeto VO1-Requisicao_Projeto Projeto 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 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 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 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 51 Gerente Requisitar Projeto Previsão Calcular Erro de Previsão Sistema Computacional Liberar Projeto do Processo de Previsão Gerar Cenários de Previsão Registrar Dados de Demanda Gerar Requisição do Processo de Previsão Definir Característica da Previsão Verificar Objetivos da Previsão Coletar Fatores de Influência Apresentar Previsão Final Definir Modelo Particular do Processo de Previsão Consultar Modelos Selecionados Identificar Fatores de Influência da Demanda Consultar Fatores de Influência da Demanda Realizar Revisão Gerencial Definir Modelos Previsão Consultar Modelo Particular Consultar Metas Analisar Resultdo de Erro Consultar Modelo de Referência Consultar Objetivos Grupo de Gerentes Definir Ajuste de Dados Verificar Histórico de Previsão Consultar Histórico de Erros Consultar Características Consultar Cenários Consultar Fator de Influência Consultar Modelos Previsão Definir Modelo de Referência Cadastrar Objeto a Prever Consultar Demanda Ajustada Consultar Ajuste de Dados Consultar Limites Erro Consultar Requisição Previsão Analisar Requisição do Processo de Previsão Grupo de Modelagem Analista Previsão Figura Diagrama de Caso de Uso do negócio.

52 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 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 53 Figura 4.12 Diagrama de Classe do Negócio AtividadeVista TipoVista ItemPedido PrecoPedido Quantidade ModeloAtividade OrdemAtividade ItemVista CodItemVista NomeItemVista Evento CodEvento NomeEvento Vista CodVista NomeVista ObjetivoVista DescricaoVista Processo CodProcesso NomeProcesso ObjetivoProcesso DescricaoProcesso ModeloReferencia CodModeloRefer DescricaoModelo DataModelo TipoAgregacao CodTipoAgregacao NomeTipoAgregacao AnaliseErro RazaoErro AcoesControleErro ResultadoAjuste CodResultadoAjuste AjusteFinal PeriodoFinal Pedido CodPedido DataPedido DataEntrega TipoCompra Cliente CodCliente NomeCliente EnderecoCliente CEP Telefone Sexo DataNascimento CPF Identidade DataCadastro TipoDecisao CodTipoDecisao NomeTipoDecisao SetorUsuario CodSetorUsuario NomeSetor Prazo CodPrazo NomePrazo TamanhoPrazo ObjetoPrever CodObjeto NomeObjeto ComentarioObjeto Bairro CodBairro Bairro Cidade CodCidade Cidade Estado CodEstado Estado EquacaoCorrelacao CodEquacaoCorrelacao EquacaoCorrelacao Obs_Correlacao TipoCliente CodTipoCliente NomeTipoCliente 0..* 0..* 0..* 0..* Periodo CodPeriodo Periodo RequisicaoProjeto CodReqProjeto DataReqProj Info_Adicionais Regiao CodRegiao NomeRegiao TipoRegiao RequisicaoPrevisao CodReqPrevisao DataReqPrevisao Caracteristica VersaoProjeto DataVersaoProjeto InicioHorizonte FinalHorizonte SituacaoVersaoProjeto * 0..* 0..* 0..* PrevisaoFinal CodPrevisaoFinal RevisaoGerencial ResultadoCenario CodResultadoCenario ResultadoCenario PeriodoResultado ValorParam CodValorParam ValorParamModelo LimiteErro LimiteMaximo LimiteMinimo Cenario CodCenario NomeCenario AnaliseCenario ValoresFator CodValorFator ValorFator DataValorFator ItensDemanda CodItemDemanda DataDemanda QuantidadeDemanda AjusteDados CodAjusteDado ValorAjuste DescricaoAjuste Participante CodParticipante NomeParticipante ModeloParticular CodModeloParticular 0..* 0..* * Atividade CodAtividade NomeAtividade ObjetivoAtividade DescricaoAtividade 0..* Produto CodProduto NomeProduto PrecoProduto Metas CodMeta DescricaoMeta 0..* PrevisaoVersao VersaoPrevisao DataPrevisao OrigemPrevisao SituacaoPrevisao ObsPrevisao 0..* 0..* 0..* 0..* 0..* ModeloPrevisao ParamModelo CodParamModelo ParametroModelo BiBlioModelos CodModelo TipoModelo NomeModelo ErroPrevisao ValorErro DataErro Demanda CodDemanda 0..* 0..* FatorInfluencia CodFatorInfluencia NomeFatorInfluencia TipoFator DataFator DescricaoFator 0..* 0..*

54 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. V e rific a r O b je tivos d a P revis ão De fi nir Ca rac t e ríst ic a da P re vis ã o A nalis ta P revis ão Id en tific a r F a to re s de In flu ên c ia da D em and a D e fin ir M odel os P revis ão D e fin i r o A jus t e de D ado s G rup o de G e re ntes D e fin ir M od elo P a rtic u lar d o P ro c es s o de P re vis ão G eren te Lib erar P rojeto do P ro c e s s o de P revis ão Figura Diagrama de Caso de Uso do processo PD1-Projetar_Previsão.

55 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 56 RequisicaoProjeto (from Classe de Negócio) CodReqProjeto DataReqProj Info_Adicionais Insert() Delete() Prior() Last() Next() First() Post() Select() MostrarDados() Caracteristica BiBlioModelos (from Classe de Negócio) CodModelo TipoModelo NomeModelo Insert() Delete() Select() Post() Edit() First() Prior() Next() Last() MostrarModelos() (from Classe de Negócio) VersaoProjeto DataVersaoProjeto InicioHorizonte FinalHorizonte SituacaoVersaoProjeto Insert() Edit() Post() Prior() First() Next() Last() Insert() MostrarDados() AlterarSituacao() Prazo (from Classe de Negócio) CodPrazo NomePrazo TamanhoPrazo Insert() Delete() Edit() Post() Select() 0..* 0..* 0..* LimiteErro (from Classe de Negócio) LimiteMaximo LimiteMinimo Insert() Post() MostrarLimitesErro() DeleteLimiteErro() ProjetoSetorUsuario (from Classe de Apoio) Insert() Delete() Periodo (from Classe de Negócio) CodPeriodo Periodo Insert() Edit() Post() Delete() Select() MostrarPeriodo() Regiao (from Classe de Negócio) CodRegiao NomeRegiao TipoRegiao Insert() Edit() Post() Delete() Novo() Last() Next() First() Prior() MostrarRegiao() ModeloPrevisao (from Classe de Negócio) Insert() Post() MostrarModelosPrevisao() DeleteModeloPrevisao() TipoCliente (from Classe de Negócio) CodTipoCliente NomeTipoCliente Insert() Novo() Edit() Delete() Select() MostrarTipoCliente() 0..1 ProjetoTipoDecisao (from Classe de Apoio) Insert() Delete() 0..* SetorUsuario (from Classe de Negócio) CodSetorUsuario NomeSetor Insert() Post() Delete() Select() 0..* ClientesEnvolvidos (from Classe de Apoio) Insert() Post() Delete() DataModulo (from Classe de Apoio) Demanda (from Classe de Negócio) CodDemanda Insert() Post() MostrarDados() TipoDecisao (from Classe de Negócio) CodTipoDecisao NomeTipoDecisao Insert() Post() Delete() Edit() Select() * ModeloParticular (from Classe de Negócio) CodModeloParticular Insert() Post() Edit() MostrarModeloParticular() 0..* ObjetoPrever (from Classe de Negócio) CodObjeto NomeObjeto ComentarioObjeto Insert() Delete() Edit() Post() Select() First() Next() Prior() Last() 0..* FatorDemanda (from Classe de Negócio) CodFatorDemanda Insert() Post() Delete() MostrarDados() FatorInfluencia (from Classe de Negócio) 0..1 CodFatorInfluencia NomeFatorInfluencia TipoFator DataFator DescricaoFator Insert() Edit() Post() Delete() First() 0..* Next() Prior() Last() MostrarFatores() 0..* ModeloParticipante (from Classe de Apoio) Insert() Delete() MostrarDados() Post() Participante (from Classe de Negócio) CodParticipante NomeParticipante MostrarParticipantes() Insert() Delete() Edit() Post() Select() <<Interface>> FormProjeto (from Classe de Interface) AjusteDados (from Classe de Negócio) CodAjusteDado ValorAjuste DescricaoAjuste CalcularDemandaAjustada() Insert() Post() Delete() MostrarDadosAjuste() EquacaoCorrelacao (from Classe de Negócio) CodEquacaoCorrelacao EquacaoCorrelacao Obs_Correlacao Insert() Post() Delete() Edit() MostrarEquacao() OnclickPrimeiro() OnclickProximo() OnclickAnterior() OnclickUltimo() OnclickSituacao() OnCreate() AcresFator() AcresEquacaoCorrelacao() AcresAjusteDados() AcresModelo() AcresLimiteErro() AcresModeloParticular() AcresParticipantes() RetiraFator() RetiraEquacaoCorrelacao() RetiraAjusteDados() RetiraModelo() RetiraParticipantes() Figura 4.14 Diagrama de Classe do Processo PD1-Projetar_Previsão

57 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 ( ) 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 ( ) M o s t r a r D a d o s ( ) O n c l i c k P r o x i m o ( ) N e x t ( ) M o s t r a r D a d o s ( ) O n c l i c k A n t e r i o r ( ) P r i o r ( ) M o s t r a r D a d o s ( ) O n c l i c k U l t i m o ( ) L a s t ( ) M o s t r a r D a d o s ( ) Figura Diagrama de Seqüência do Caso de Uso Analisar Objetivos.

58 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 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 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 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. Figura 5.1 Logon Usuários 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.

62 62 Figura 5.2 tela de Menu Geral 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 e ilustrado pelo gabarito 2. A seguir descreve-se a implementação da única atividade desse processo 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

63 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 O modelo de referência deste processo está descrito na sessão e ilustrado pelo gabarito 1. A seguir são comentadas as implementações das respectivas atividades 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 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 64 Figura 5.3 Requisição de previsão 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.

65 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 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 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 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 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 é ilustrado pelo gabarito 3. A seguir são comentadas as implementações das respectivas atividades.

67 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 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. Figura 5.6 Tela Gera Previsão 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.

68 68 Figura 5.7 Tela de Aprova Previsão 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 O modelo de referência deste processo está descrito na sessão e ilustrado pelo gabarito 4. A seguir são comentadas as implementações das respectivas atividades 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.

69 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. Figura 5.8 Tela Gera Demanda Real (Cálculo do Erro) 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.

70 70 Figura 5.9 Consulta Análise da Previsão (Gráfico) 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.

71 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 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 Tabela 5.1 Comparativo das atividades do Modelo de Referência e Modelo Particular 5.8 ATIVIDADES DO MODELO PARTICULAR

73 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 Start Requisição Previsão figura 5.2 Analisar Objetivos sessão Definir Características sessão 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 Finish Figura 5.11 Processo particular de Previsão de Demanda

74 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 Start Coleta de Dados Reais sessão 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 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.

75 Figura 5.13 Modelo de Objetos do Sistema particular 75